企业官网建设流程全解析

简介：SAP SD 模块中的交货单类型直接影响销售发货、退货与内部收货等流程。这份 PDF 面向 SAP SD 实施顾问、运维人员及初学销售与分销的中高级读者，系统梳理了交货单类型的配置要点：从凭证类别 J、7、T、G 的区分，到数字系统、订单参考、凭证内容、错误处理与特殊功能均有所覆盖。文件为 1 个 PDF，大小约 191KB，适合通勤或碎片时间反复查阅。目前已有 985 人学习。文档以配置界面为主线，解释了内外部编号规则、要求订单与省缺订单类型的差异、库址选择及途径确定逻辑，并针对 000043 报错、WM 仓库冲突、自动包装等实务场景给出提示。读者可据此快速理解交货单类型各参数含义，减少 SAP 项目中的试错成本。无论是日常配置维护，还是项目上线后的参数优化，按图索骥即可快速定位。

1. 交货单类型：SAP SD 里看似不起眼、配错却要返工的核心配置

接手过 SAP SD 模块的人基本都有这种经历：销售订单跑得好好的，一到开交货单（DN）就报错，不是提示单据类型不符，就是行项目莫名其妙消失，最后发现问题全出在交货单类型配置上。这个配置在 SPRO 里层级不深，字段也不算多，但每个字段都对应着开单、拣配、包装、发票一条链上的某个环节。一个项目需求字段填 201 还是 202，直接决定业务员能不能手动往交货单里加行；一个显示范围设成 UMAR，开单时可能连行项目都看不见。这套东西不装明白，后面每一张交货单都在踩雷。这篇把交货单类型的凭证类别、数字系统、订单参考、路径确定和几个高频报错拆开讲，适合正在配 SD 模块、或者拿着文档却不知道每个开关该往哪拨的实施和运维同学。

2. 凭证类别与数字系统：先把 J、7、T、G 选对，再谈编号规则

2.1 凭证类别：四个字母背后的业务边界

交货单类型（Delivery Type）里的凭证类别字段是第一个要定死的参数。它不是普通的分类标签，而是从底层区分这张单据属于哪一类业务。整个系统里，出货相关的凭证类别只有四个：J、7、T、G，碰都不要碰别的值，因为系统在后续的过账、物料移动、发票校验里都靠这个类别来判断业务逻辑。

J 是正常出货单，也是最常用的一个。常规销售发货、按订单交货都走 J，它对应的是一整套标准外向交货流程：从销售订单复制数据、确认库存、拣配、装运、发货过账。如果你手上没有任何特殊业务需求，交货单类型就直接建 J 开头的，比如 ZJ01 这类自有命名，凭证类别保持 J 不动。

7 是内向收货单。注意这个“内向”，它跟销售发货方向相反，多用在内部库存转储或者接收供应商货物的场景。比如公司内部工厂之间调拨，A 工厂发货，B 工厂收货，B 工厂开的收货交货单就是凭证类别 7。我第一次配 STO 的时候把收货方的交货单类型设成了 J，结果收货过账时系统提示移动类型不对，后来改成 7 才正常。

T 是退货单，处理客户退回商品的流程。退货交货单在开单时通常参考销售订单的退货行，但它的凭证类别要单独选 T，因为它涉及的库存移动是退货入库，不是正常发货出库。如果把 T 配成 J，最直接的后果是退货过账时库存方向反了，本应加库存变成减库存，对账的时候会非常酸爽。

G 是零售行业使用的类别。零售场景里出货单的格式、定价、库存逻辑跟传统分销不同，比如门店要货、POS 数据传输这类场景，普通 J 的字段状态和输出规则不一定满足，G 就是为这类零售特性预留的。做传统制造业分销项目的同学大概率用不到 G，但如果你在零售项目里配单，别图省事复用 J，直接建凭证类别为 G 的类型。

这四个类别里面，J 和 T 最容易被搞混，因为很多人想着“退回来的货也要过账，系统逻辑差不多”，实际上系统对 T 类单在行项目类别确定、库存更新上都有独立逻辑，不能相互替代。我的习惯是在命名上直接体现：正常出货 ZOR 开头，退货 ZRE 开头，内向收货 ZIN 开头，这样看到单号就能判断凭证类别，排查问题快很多。

2.2 数字系统：内部分配、外部范围与项目号增量

交货单类型配置页里的“数字系统”区域有三个字段：NR 内部分配、外部范围号、项目号增量。这三个字段管的是编号范围，也就是交货单号和行项目号怎么生成。

NR 内部分配，翻译成白话就是“内部编号规则”。勾上这个选项后，系统用内部给它分配号码范围，也就是编号范围配置里定义的区间，开单时系统自动取号，不允许手工输入单号。这种模式适合大多数业务场景，因为交货单是系统批量产生的凭证，人工干预单号容易出重复或断层。注意这里有个容易忽略的点：内部编号范围要提前在编号范围维护里配好序列，否则开单时提示“找不到编号范围”或者“编号范围已用完”。

外部范围号对应的是外部编号规则。如果业务上有必须和外部系统关联的场景，比如 WMS 传入的收货单号、EDI 进来的交货单号，那就要用外部编号，系统允许手工输入或者在接口程序里传值。用外部编号的最大风险是重复和空号，因为系统没法保证外部传入的号码一定合规。我一般建议能用内部就别用外部，除非接口对接实在绕不开。如果混合使用，记得外部范围号要单独建，不要和内部范围重叠，否则系统会混乱。

项目号增量是子项目的增加规则。交货单的行项目在创建时系统会默认给项目号，比如 10、20、30 这样跳着来，10 就是项目号增量。这个值决定了生成行项目时项目号的跨度，也影响系统在插入新行时是否能预留位置。常规配置是 10，这样在两个初始行之间手动插入一行时，可以用 15 这种中间值，不会影响已有行的项目号。如果在特殊场景下希望行项目紧凑排列，可以设成 1，但那样以后想插行就没有中间号可用了，只能改项目号，很麻烦。我在项目上统一用 10，包括后续还有子项目需求的时候也方便，子项目号同样按这个增量展开。

2.3 我给新项目组的默认配置参考

第一次配置交货单类型的时候，可以按照下面这张表先在测试环境跑通一版，再按业务实际调整。这张表不是标准答案，但大部分常规制造分销项目够用了。

这套默认值的思路很简单：先把限制都放开，跑通主流程，再根据业务需求逐步收紧。如果一开始就把要求订单设死、项目需求设成 201，后面手工开单或者临时改单都会被挡住，排查起来反而多一层干扰。

3. 订单参考逻辑：要求订单、省缺订单类型和项目需求怎么配

3.1 要求订单：什么时候必须参考订单创建

订单参考区域的第一个字段是“要求订单”，它控制的是交货单是否必须参考上游凭证创建，以及参考的凭证类型是否符合预期。这个字段的理解要分两层。

第一层是“是否必须参考订单”。如果这个选项勾选了，开交货单时就不能完全手工盲开，系统要求你输入参考的订单号；如果没勾选，那业务员直接新建一张空白交货单系统也接受，只是后续凭证可能带不出订单信息。

第二层是“参考的单据类型必须匹配”，这是最容易翻车的点。在开出货单时，界面通常会有一个预定义的交货类型，如果配置了必须参考订单，系统会校验：你参考的单据类型是否与交货单的预设规则一致。举个例子，交货单类型配置里写了“参考订单”，业务员开单时却用了一张采购订单来参考，系统会直接报错，提示参考单据类型不符合要求。反过来，如果在创建交货单时没有输入预定义交付类型，这个规则就不会触发校验，系统按普通逻辑处理。

这个字段的配置思路要跟着业务模式走。如果业务上不允许无单发货，那就必须勾上，并且要在项目里强调所有交货单都从订单流转过来。如果业务上偶尔有临时补单、紧急发货的情况，就先别勾，等流程稳定了再考虑要不要收紧。

3.2 省缺订单类型：STO 和公司间发票的默认值来源

订单参考区域的第二个字段是“省缺订单类型”，这个名字有点绕，它实际表达的意思是：这张交货单不需要强制参考订单来创建，可以独立开单，但是后续生成的下游凭证，比如发票，要依赖这里的订单类型来推导默认的发票类型。

这个字段在 STO（库存转储订单，Stock Transport Order）场景里尤其关键。公司内部或公司间做库存转储时，发货方开交货单，收货方做收货，然后还要开公司间发票进行内部结算。开公司间发票的时候，系统需要确定一个默认的发票类型，这个默认值就是从交货单上的“省缺订单类型”关联过去的。换句话说，你在交货单类型里写的这个订单类型，决定了后续开公司间发票时系统默认用哪个发票类型。

有个很容易踩的坑：省缺订单类型配了销售订单类型 OR，但公司间发票的默认类型其实应该由 STO 订单类型来触发。如果业务上是标准 STO，交货单的参考订单就是 STO 订单，那“省缺订单类型”这里要填 STO 对应的订单类型，而不是普通销售订单 OR。填错了，开公司间发票时带出来的发票类型不对，还得手动改，批量开票的时候就会批量出错。

配置这个字段之前，建议先理清三条链路：普通销售单发货、STO 公司间转储、退货流程，分别对应什么订单类型、交货单类型和发票类型。理清了再填，就不会出现“交货单能开，发票类型张张要改”的局面。

3.3 项目需求 201 与 202：行项目能否手动添加的开关

“项目需求”这个字段在默认配置里通常被忽略，但它在实际业务里非常有用。系统提供两个代表值：201 和 202。如果设置成 201，交货单的行项目只能从上游订单复制过来，业务员想在交货单上手动新增一行是被禁止的，系统不让你在 DN 里增加项目。如果设置成 202，就允许在交货单里手动增加行项目。

201 这个值适合流程严格、要求“有订单才发货”的业务。比如一些审单严格的制造企业，所有出库必须对应销售订单或 STO 行项目，仓库不允许自己往交货单里加东西。这种情况下设 201 是个很好的防线，业务员开单之后想多塞一行，系统直接拒绝，操作习惯被硬件限制住。

202 则适合仓库需要在发货时补充零配件、赠品、包装材料的场景。比如客户订单里只有主机，但仓库发货时发现要补一个说明书或一个转接头，有 202 权限就能直接往交货单里加一行，不用回去改销售订单。这种灵活性在实践中非常重要，但也意味着更容易开出没有订单参考的行项目，和前面“要求订单”产生潜在冲突，配的时候要想清楚这两个字段的组合策略。

我对这个字段的建议是：如果业务团队对仓库操作有信心，默认用 202；如果希望靠系统约束去防呆，用 201。两个值没有绝对的好坏，取决于你更怕“乱加行”还是更怕“加不了行”。

4. 凭证内容与业务增强：从库存选址到包装物料项目

4.1 库存选址与输出确定：仓库与打印的默认规则

凭证内容区域是整个交货单类型配置里字段最多的地方，里面每一项都管着一类后续功能。先说库存选址规则。

库存选址规则（Storage Location Selection Rule）解决的是“出货单自动确认仓库”的问题。系统里预定义了若干条规则，配置的时候从这些预定义规则里选一条。选中某条规则后，开交货单时系统会根据规则逻辑自动确认发货仓库和库位，而不是让业务员每个单子都手动选仓库。比如按物料主数据里的默认发货仓、按工厂下的某个特定仓库、按装运条件匹配的仓库，不同规则对应不同确认策略。

这块配置要和物料主数据、工厂设置配合。如果规则选的是按物料主数据带仓库，但物料主数据里这个字段是空的，那开单时系统还是会让你手动补仓库。所以选完规则后的测试要点是：找几个有完整物料主数据的料号跑一遍开单，确认仓库真的被自动带出来了。

输出确定过程（Output Determination Process）管的是交货单的输出行为，也就是打印、传真、EDI 这类输出的处理过程。系统通过这个字段找到对应的输出确定过程配置，然后按照其中的条件去匹配输出类型。输出类型这里单独列了一个字段，叫“默认的输出类型”，它决定的是交货单创建后系统默认激活哪种输出。比如你希望所有交货单创建后默认走打印标签，那默认输出类型就设成对应的打印输出类型编号。

还有两个字段容易被忽略：凭证状态组和应用程序。凭证状态组用于后勤信息系统（LIS）中的更新字段，它决定交货单在信息结构里以什么状态被更新统计，比如哪些单据计入已发货量、哪些不算。应用程序字段在输出控制里是个重要角色，系统默认出货单的应用程序是 V2，订单有订单的应用程序，发票有发票的，三个模块各不相同。输出确定之所以能把订单、出货单、发票的输出类型区分开，靠的就是这个应用程序字段。配置时别乱改它，一旦改成了别的应用代码，交货单的输出确定就找不到对应的配置，开单时一张都打印不出来。

4.2 途径确定：订单路径与重量组规则的三种玩法

途径确定（Route Determination）是我每次配置都格外仔细看的一块，因为它有三个可选项，而且三者的行为差异体现在“能不能手动改路径”这种操作层面，业务员遇到报错时往往一脸茫然。

这个字段有空白、A、B 三种设置。

空白表示没有新的路径确定。发货路径直接从订单带出，即使你在交货单类型里定义了按重量组重定路径的规则，也不会执行。也就是说，订单上写什么路径，交货单就带什么路径。这是最保守、最省事的玩法，好处是路径可控，坏处是订单和交货单如果相隔时间很长，期间运输条件变了，路径也不会自动更新。

A 表示按照重量组的规则重新确定交货单的路径，而且允许手动改成任意一个路径。这个选项适合运输条件经常变、需要灵活调整路径的业务。比如订单创建时重量组设的是卡车运输，但实际发货时货物超重，仓库操作员在交货单上手动改路径也完全不受限。

B 是 A 的限制版：按重量组规则重新确定路径，但不是所有路径都能随便改。能改成哪些路径，是由“通过已处理路径定义所认可的实际路径”决定的，这个配置存在 table TROAL 里。系统认可的路径集合里没有的，你手动也改不过去。这里的“计划路径”指的是订单上的路径。如果订单上面没有路径，那交货单路径是可以任意改的；如果订单上面有路径，系统认可的是这一个，此时如果再去改成了别的路径，就会触发报错，错误代码是 000043，含义就是“订单上面的路径与此不一致”。

B 选项适合那些运输路径受合同约束、不能随意更换的业务。比如某物流合同锁定了固定的线路和承运商，仓库想换承运商必须走审批，那 B 就是天然的管控手段。但要在项目上线前把可认可路径的值维护进 TROAL，否则仓库改路径时会被 000043 卡住，而且这个报错在界面上很不友好，业务员看不懂，接 IT 工单的时候你也很难一眼定位到是路径确定的配置在作怪。

4.3 交货分解、自动包装与包装物料项目

交货分解这块有两个字段：交货分解-仓库编号和交货分解-合作伙伴。

交货分解-仓库编号这个勾选项管的是 WM（仓库管理）场景下的仓库一致性校验。如果勾上了，开立出货单时系统会检查所有行项目里的 WM 仓库编号是否一致。举一个实际的翻车例子：业务员在一张交货单里录了两个行项目，第一行指定了 WM 仓 A，第二行指定了 WM 仓 B，此时系统弹出警告，提示行项目中有 WM 仓库与抬头的 WM 仓不符。这个警告里的“抬头的 WM 仓”不是真正的表头字段，它是系统取第一个行项目的 WM 仓作为默认值。如果没勾上这个选项，上述这种冲突不会提示，系统照常接受，但后续 WM 拣配时因为仓码不一致可能会出现波次分配问题，但问题藏在后面，反而不容易发现是这里没勾。

交货分解-合作伙伴在原配置文档里没有展开，但在我的实践里，它管的是交货单行项目被拆到不同仓库或不同交货批次后，合作伙伴数据如何重新确定或继承。配置原则建议保持和订单一致，不要单独给拆分配套重定义一套合作伙伴规则。

自动包装这个功能很适合有标准包装规范的企业。如果物料号建有包规，开出货单时会自动按包规执行打包。包规的建立是在 POP1 功能里维护包规，POF1 是激活包规的开关。很多人栽在“包规建了但没激活”，结果自动包装完全不生效，开单一切正常，就是不自动打包。这里的逻辑是：料号在主数据里维护了包装规则 → POF1 激活 → 开单时系统自动按照包规生成包装项。

生成包装物料项目就更细一层。这个功能的触发条件是一个组合逻辑链，缺一不可。首先，包材的“包装物料类型”属性和“一般交货项目”字段要有值，这个属性在物料主数据的 MM02 里维护，字段是 VHAR；其次，料号本身维护了销售组织，行项目类型确定分配正确；最后，交货单类型上勾选“生成包装物料项目”。这几条全部满足时，对交货单打包操作时，系统会把包材自动带出到行项目里。如果哪一条没满足，包材不会自动生成行项目，而且系统一般不会报错，属于典型的“静默失效”。排查顺序我建议按这条链倒着查：先看交货单类型勾没勾、再看物料属性 VHAR 有没有值、再验销售组织和项目类别确定。

4.4 再计划、分配模式与显示范围

再计划这个字段的触发条件是：开出货单的时间点在订单最后交期期间内，也就是命中订单计划行日期附近。此时系统会提示拣配日期报错。这个提示不是系统故障，而是再计划逻辑在提醒你：订单计划行日期已到，交货单的拣配日期需要重新确认。如果业务上允许延期发货，这个提示配置成警告即可；如果业务要求严格按期交货，这个字段可以配置成报错，直接拦住按期之外的交货单。

分配模式则是针对分散 WMS 的一个字段，用来指定分配到分散 WMS 中 inbound 交货或向外交货的时间。简单说，就是系统什么时候把交货信息推给外部 WMS——是在交货单保存时就分配，还是过账时才分配，或者手工触发。做接口集成时这个字段要和 WMS 团队对齐，推早了 WMS 还没准备好收货，推晚了仓库等待时间变长。

显示范围这个字段是开单界面的显示规则，有三个值：UALL 显示所有行项目；UHAU 只显示主要的行项目；UMAR 只显示选择的行。第三个值是最容易造成“开单看不到行项目”误会的元凶。有同事跟我反馈，说开一张新交货单，怎么界面里什么都看不到。一看配置，显示范围设成了 UMAR。问题是：你还没有选中任何行，系统自然只显示“你选择的行”，于是就是空的。这不是数据丢了，也不是交货单没建成功，纯粹是显示范围在作怪。如果业务上经常手工开单并要查看所有行，UALL 最稳。

事务流区域剩下的字段里，屏幕顺序组管的是交货单概览界面的字段排列和页签顺序，它和销售订单的屏幕顺序组是同一套机制；标准文本这个字段按文档说明系统暂未使用，我的建议就是留着别填；合伙人确定过程管的是交货单的合作伙伴确定规则，比如售达方、送达方、收货方怎么继承和确定，一般从订单带过来就够了，除非业务上对紧急联系人、最终收货人有特殊要求，否则不用另起一套。

5. 交货单类型配置避坑：五个真实翻车记录

5.1 报错 000043：订单路径与交货单路径不一致

现象：仓库在交货单上手动修改运输路径时，系统报错 000043，单子卡住不能保存。业务员不知道这个报错什么意思，来回试了好几个路径都失败。

原因：交货单类型里的途径确定字段设成了 B。B 的限制是只能改成“通过已处理路径定义所认可的实际路径”（table TROAL）。订单上没有路径时交货单路径可以任意改，但一旦订单上带了路径，手动改动作就触发校验，改到非认可路径就报 000043。

解决：有两种处理思路。一是业务上确实要求路径受控，那就把允许的可改路径都维护进 TROAL，告诉仓库只能从这些路径里选；二是我个人的经验做法，如果项目上线初期路径变更频繁，先用空白（路径从订单带出）过渡，等路径主数据稳定了再改成 B。别一上来就选 B，团队最容易在这个上面返工。

5.2 勾了交货分解仓库编号，多仓库行项目疯狂弹警告

现象：配置完 WM 场景后，业务员开一张包含多个行项目的交货单，只要两个行项目的 WM 仓码不同，系统就弹警告，说行项目中的 WM 仓库与抬头 WM 仓不符。业务员以为单据有问题，反复取消重开。

原因：交货单类型上勾了“交货分解-仓库编号”，系统要求检查行项目 WM 仓的一致性。所谓抬头的 WM 仓其实就是第一个行项目的 WM 仓，只要后续行项目不一样就触发警告。

解决：如果业务上本来就不允许一张交货单出现多个 WM 仓，建议保留勾选，让它继续拦截，并给业务员讲清楚这个警告的规则。如果业务上多仓库拼车发货本来就常见，就把这个勾去掉，让单子顺利开下去，后续拣配由 WM 模块去处理。关键是这两个选择要跟仓库实际流程一致，不能让这个警告天天弹但没人处理。

5.3 自动包装不生效：包规建了，但激活开关没打开

现象：顾问在测试环境给料号建好了包规，开交货单时却没有任何自动打包行为，整单正常保存，包装项目一个都没生成。

原因：包装规则建好只是第一步，POF1 激活包规这个开关没有打开。POP1 建包规、POF1 激活包规，这两步是串行的。包规没激活，系统在开单时根本找不到生效的包规，自动包装自然不执行，而且不报错。

解决：进 POF1 查看包规激活状态，将对应的包规激活，重新开单验证。也顺便检查一下包装物料类型和一般交货项目字段是否有值，保证整条链是通的。我的习惯是配完自动包装一定会做一张测试单，不只是看有没有打包，还要看包材是否被正确带出。

5.4 开交货单看不到行项目：不是数据丢，是显示范围设成了 UMAR

现象：用户新建一张交货单，界面一片空白，保存后查看也是空的。用户怀疑系统有问题，数据写丢了，IT 排查日志也没发现任何异常。

原因：交货单类型里的显示范围字段设置成了 UMAR，意思是“只显示选择的行”。开单时还没有选中任何行项目，界面自然什么都不显示。数据本身没有问题，只是被显示规则过滤了。

解决：如果这个类型是给手工开单用的，建议直接改回 UALL，显示全部行项目。如果业务上确实需要按选中行显示，需要给用户解释清楚操作方式，避免每次开单都吓一跳。我后来在一个项目里碰到同类问题，给用户写了操作说明，同时按业务要求把显示范围改成了 UHAU，只显示主要行项目，界面简化和可见性两头兼顾。

5.5 包材没有自动生成行项目：物料属性、销售组织、项目类型确定一个都不能少

现象：交货单类型已经勾了“生成包装物料项目”，物料主数据里也给包材维护了包装物料类型，但实际打包时包材就是没有出现在行项目里，用户以为打包功能坏了。

原因：这是一个组合条件。包材的包装物料类型属性（VHAR）要为非空，料号维护了销售组织，行项目类型确定分配正确，三者全部满足时开单才会把包材自动带到行项目。缺失任何一环，系统就静默处理，既不报错也不提示。

解决：按链路逐项排查。第一查物料主数据 MM02 里 VHAR 字段的值；第二查料号的销售组织视图是否完整；第三查行项目类型确定，看对应销售区域下能否识别到正确的项目类别。三个都通了，再重新做一张交货单验证。从那以后我配置这个功能必做一张“带包材的完整测试单”，确认包材行真的出来了，才敢告诉业务团队说可以用了。

6. 装完怎么验证跑通：用一张测试交货单走完整个链路

配置交货单类型这种主数据，最大的坑就是不知道“到底算不算配好了”。我的做法是：配完不急着移交，先手动走一张完整的测试交货单，把每个配置项对应到实际行为上，全部验证通过再移交。

第一步，确认凭证类别和数字系统。用配置好的交货单类型创建一张外向交货，看单号是不是按内部编号范围自动生成，行项目号是不是按项目号增量 10、20 这样排列。如果单号让用户手工输入了，说明外部编号范围被选中了，回去看 NR 内部分配。

第二步，验证订单参考逻辑。从一张销售订单创建外向交货，开单时带出预定义交货类型，检查参考订单校验是否生效。分别试两个方向：参考类型匹配的订单能不能正常开，参考类型不匹配的订单是不是被正确拦截。再把一张 STO 订单走完，确认后续公司间发票能带出正确的默认发票类型。

第三步，验证路径和仓库。拿着订单上没有路径的单子，和订单上有路径的单子各开一次，看交货单路径带出是否符合预期。如果途径确定配的是 B，还要尝试改一个不在 TROAL 里的路径，确认系统能拦住。同时在 WM 场景下开一张两行 WM 仓不同的单子，确认“交货分解-仓库编号”的警告要么弹出、要么按预期不弹，不要留下不确定状态。

第四步，验证包装与输出。找有包规的料号开单，确认自动打包执行、包材被带到行项目。然后检查输出确定，确认交货单保存后默认输出类型被激活，打印队列里有对应的输出单。

最后一步，检查显示范围。在开单界面确认行项目按要求显示，UALL 能看到全部、UHAU 只看主项、UMAR 下要先选中行才能看到。验证完以后，把测试单过账，查看后勤信息结构里的凭证状态有没有被正常更新。

这套验证流程走完之后，我会把测试单号、验证结果、每个配置项对应的现象整理成一个记录，放到项目配置文档里。从那以后我每次配完交货单类型都强制自己走一遍这五步，哪怕是改一个显示范围这种小字段也不跳过，因为省掉最后一步验证，往往过了两周才会被用户以工单的形式把问题踢回来。希望帮到你。

本文还有配套的精品资源，点击获取