企业官网建设流程全解析

1. 从一张领料单说起：工单发料为什么能卡住整个车间

做制造业信息化的同行应该都有过这种经历：车间主任拿着电话吼“料怎么还没发出来”，仓库班长说“系统里有单子但实物找不到”，IT这边打开SAP一看工单状态正常、MES里任务也激活了，WMS的拣货单却一直没生成。最后发现是三个系统的物料主数据不一致，库存地点编码差了一位。

这事的本质不是某一个系统出了问题，而是工单发料这件事天然跨了三个系统：SAP管“账”和“计划”，MES管“现场执行”，WMS管“实物库存”。三套系统各有各的数据模型和业务口径，但工单一开，物料从仓库到线边仓再到工位的过程，必须让三者对同一笔业务达成一致。只要中间任何一个环节的数据没对齐，整个链路就会卡住。

这篇内容我想完整梳理一下工单发料的完整路径：SAP里的生产订单怎么变成MES的工单，MES怎么触发WMS拣货，WMS实物下架后怎么回传SAP过账，以及倒冲、超耗、替代料这些实际业务中躲不开的场景怎么处理。适合制造企业的IT、精益生产推进人员、供应链管理者，以及做MES/WMS/SAP集成的实施顾问参考。看完之后你至少能回答三个问题：发料链路上每个系统各自该干什么、系统间数据怎么流转才算合理、出了问题第一步该去哪里查。

2. 系统分工与集成架构：把边界划清楚，问题就少一半

2.1 三套系统的“职责边界”先画清楚

很多项目做到一半才发现扯皮，根子在于三套系统的边界从一开始就没划明白。这里我直接给出我多年项目里验证过比较好用的分工原则：

SAP侧负责三件事：计划、成本、账务。生产订单（或工单）在SAP里创建，BOM展开之后产生组件需求，物料可用性检查（Available-to-Promise，ATP检查）决定能不能开工，工单发料和报工完成之后产生会计凭证，最终结算到产品成本。换句话说，SAP关心的是“这笔料从账上发没发、成本归集到哪个订单”。

MES侧负责现场调度、执行和数据采集。它接收SAP下达的生产订单，把它拆成工序级任务派给产线，记录实际的投料数量、报工数量、报废数量、工时数据，再把结果回传SAP。MES管的是“产线上到底干了多少活、用了多少料”。

WMS侧负责实物库存的精细化管理。物料在仓库里的库位、批次、数量、拣货任务、下架确认，都归WMS管。WMS回答的问题是“这批料放在哪个库位，拣出来没有，交给谁了”。

这个边界在方案设计阶段就要和业务方达成共识，尤其是“以谁的数据为准”这个问题。我的原则是：实物动作以WMS为准，生产执行以MES为准，财务账务以SAP为准。这三句话写进需求文档，后面所有争议都有了解释依据。

提示：如果企业没有上WMS，这个场景就简化为MES直接调SAP的BAPI发货，实物由人工在SAP里过账。逻辑类似，但少了一层实物精细化管理，后面我会针对这种情况单独说明。

2.2 接口方案选型：接口表、中间件还是API直连

边界划清楚之后，最现实的决策是接口怎么连。结合所见项目，主流是下面三种：

• 接口表模式：SAP和MES共用一套数据库中间表，或者通过视图/存储过程交换数据。优点是实施简单、排查问题直观，缺点是耦合度高，两边改表结构都要通知对方。
• 中间件模式：用SAP PO/PI/CPI或者独立的集成平台（比如某国产ESB），把三套系统的接口做松耦合。报文格式用XML或JSON，业务校验放在中间件。这种模式适合系统多、链路长、以后还要接新系统的场景。
• API直连：SAP通过RFC或者OData服务调用MES/WMS的接口，或者反过来。异步消息用RabbitMQ/Kafka这类消息队列做削峰。直连的问题在于，一旦对方系统升级接口，双方都要调整，对运维要求比较高。

我个人更推荐中间件模式，尤其是工单发料这种涉及多个系统、多个报文的链路。中间层可以做报文格式转换、备用重发、数据落库留痕。出问题的时候查中间件日志，比在三个系统里翻来翻去快得多。热词里有些朋友提到“sap cpi 配置token访问令牌”，这类工作就是典型的中间件集成要做的——SAP CPI作为云集成平台，和MES、WMS之间对接时也需要配置认证令牌和接口路由，原理和本地PO类似，都是把系统间通信抽出来统一管理。

集成架构图先定下来再写接口开发任务书。我见过一个项目，接口没有中间层，SAP直接调WMS的WebService，结果WMS系统版本升级后报文格式变了，SAP侧还要跟着改程序。后来所有接口都改走中间件，才把这类问题收敛住。

2.3 主数据同步：物料、工厂、库存地点、库位四件套

工单发料链路里最容易被忽视又最致命的，是主数据不同步。SAP里物料号是30位字符，MES里物料编码规则不同，WMS里又是另一套条码规则——映射关系没维护好，发料指令一下去，WMS找不到物料，或者找到物料但是批次对不上。

靠谱的做法是做一个主数据同步任务，每天至少同步一次，关键字段包括：

注意一个细节：SAP的库存地点和WMS的库位不是一回事。SAP里一个库存地点（比如1000工厂下的0001库位）在WMS里可能对应多个物理库位区域。做接口设计的时候，要单独维护一张映射表。我在一个项目里遇到过这种情况——SAP按库存地点0001发料，WMS系统里对应三个库区，拣货策略没配置，系统默认从第一个库区拣，结果把另一种同物料不同批次的货发到线边了。排查半天，最后就是映射表里少配了一条库位优先级的规则。

2.4 发料模式选型：先搞清“倒冲”和“领料申请”的适用场景

工单发料在业务上有两种主流模式：领料申请模式和倒冲发料模式。很多项目讨论发料流程时都会卡在这——业务方说要倒冲，IT说倒冲对账难，最后各退一步，搞了个“混合模式”。先别急着吵，理清楚逻辑再选。

领料申请模式的逻辑是：车间根据工单生成领料申请，仓库按单拣货发料，SAP里做发货过账，库存实时扣减。适用范围是生产计划稳定、物料齐套率可控、需要严格按单领料的行业（比如装配制造业），一般对应SAP移动类型261（成本中心发货）或261针对生产订单发货。

倒冲发料模式的逻辑是：先发一个“预扣”或“调拨”，把物料从仓库调拨到线边仓（移动类型311），生产完工后在MES报工，SAP根据报工数量和BOM用量自动扣减线边仓库存（移动类型261或相关倒冲移动类型）。适用范围是生产节拍快、物料用量相对固定、不希望在每个工单上都做一次领料动作的行业（比如注塑、冲压、包装行业）。

这里要提醒一句：倒冲不是“不盘点”，而是把发料动作后置到了报工环节。如果MES报工数据不准，倒冲出来的库存数据一定不准，后面盘点差异会大得让你怀疑人生。所以选择倒冲模式之前，先评估MES的报工数据采集能力和准确性。这个判断标准写进方案里，比业务部门拍脑袋强。

3. MES、SAP、WMS工单发料链路里的关键细节与实操要点

3.1 从SAP工单到MES任务的激活链路

工单发料的前置条件是工单在SAP里已经创建并下达。实际操作中，SAP生产订单通过CO01/CO02创建，下达（TECO之前的状态）之后，会产生组件需求记录在RESB表（生产订单组件需求表，热词里叫“sap生产订单底表”）。MES侧通过接口接收到这个订单以及组件清单，才能在产线上定义为一个可执行的任务。

这里有一个坑：SAP的生产订单在下达之后，组件需求并不会自动“锁定”库存。如果你在SAP里做了ATP检查（物料可用性检查），系统只是给出了“订单是否有足够库存”的信息，并不真正预留库存。真正让物料被“保留”给某张工单，需要系统配置里设置了“带库存调拨/预留的可用性检查”。否则可能出现工单下达到MES、MES又下发了拣货任务，但同时另外一张销售订单也把这批货给占用掉了的情况。

所以项目里我通常建议：SAP侧下达订单时做一次物料可用性检查，把结果同步给MES；MES侧拿到“可用”标记后才可以下发拣货。如果MES在SAP里配置的是“下达即发送”，那就要确保SAP侧在订单下达之前已经完成了物料的优先排序和分配。这块要和生产计划部门确认清楚，不要靠系统碰运气。

另外，关于工单状态：SAP生产订单下达之后的状态是“REL（Released）”，MES只有在收到REL状态的订单后才应该把任务下发到产线终端。如果MES收到的订单是“CRTD（Created）”状态，说明工单还未下达，这时候MES不应该触发任何发料逻辑。有些集成方案里SAP会在下达后调用MES接口，有些则是MES定时轮询SAP订单状态，两种都行，但务必在接口文档里明确状态过滤条件。

3.2 WMS拣货下架与SAP过账的衔接：移动类型与预留号

工单发料在SAP侧的核心过账操作，是使用移动类型261针对生产订单发货。但实物环节，是WMS先做拣货下架，再通知SAP过账。这里有一个非常关键的映射关系：

WMS的“拣货下架确认”事件，应映射到SAP的“发货过账”事件，而不是映射到“库存转移”。如果映射错了，比如WMS下架后只做了仓位转移、没有触发SAP的261过账，那么SAP里的生产订单组件需求依然挂在上游库存里，工单的投料数量永远为0，后面的工单完工确认、成本结算都会受到影响。

实操中建议这样设计接口：

1. MES将工单组件需求发送给WMS，包含：物料号、数量、库位、批次号（如果有批次管理）、目标库位（通常是线边仓）
2. WMS生成拣货单，仓库人员按单拣货、扫描确认
3. WMS在拣货完成时生成一个“发料确认”报文，发送给SAP
4. SAP收到报文后，调用BAPI（比如BAPI_GOODSMVT_CREATE）生成261物料凭证，同时传入生产订单号和预留号（Reservation Number）

这里特别强调预留号。SAP里工单下达后会自动生成预留（Reservation），预留号是后续物料过账和查看库存的关键索引。如果接口不给预留号，SAP系统会自动创建新预留，会导致预留重复、造成后续超耗判断混乱。所以在做SAP侧接口的时候，要把MES发来的生产订单号转换为SAP的订单号，再取出对应的预留号，放在过账参数里。

热词里有人提到“sap生产订单底表”，其实就是RESB表。在做报表开发或者是排查数据不一致问题时，RESB表是首选排查点。查询生产订单的组件需求数据，验证MES接收的组件清单和SAP侧是否一致，几乎所有库存差异问题最后都会追溯到RESB表的差异。

3.3 倒冲场景：报工、报废与差异扣减

如果企业选择的是倒冲发料模式，实际的发料动作是在MES报工之后由SAP自动完成的。热词里有“sap ko88 增强”——KO88是内部订单结算事务码，和倒冲里的成本归集不是一回事，但类似的逻辑：系统配置里通过增强实现特定过账逻辑。

倒冲的触发链路是这样的：

1. MES产线操作工完成一个工序或整张工单，录入报工数量、报废数量、工时
2. MES将报工数据发送给SAP
3. SAP根据MES发送的报工数量，结合BOM用量，计算组件消耗数量
4. SAP执行倒冲发货，从线边仓（库存地点1150之类）扣减库存
5. 如果线边仓库存不足，系统可能生成“短缺”记录，需要后续通过维修单或人工处理

倒冲里最常见的坑是报废数量的口径。MES报工时报废数量是10，SAP侧若没有同步报废数量，就只按“合格品报工数量”去倒冲BOM用量，会导致组件消耗少扣了，在制品成本失真。所以做接口设计时，一定要和财务确认清楚：倒冲的依据是报工数量，还是报工数量+报废数量。多数制造企业倒冲的依据应该是“实际投入数量”，也就是合格品数量+报废数量+在制品数量。

另一个坑是倒冲时点。可以设置成每道工序结束就倒冲，也可以设置成最后一道工序完成后一次性倒冲。前者实时性好，但会造成对线边仓库存的频繁扣减；后者逻辑简单，但是一旦最后一道工序迟迟不完工，线边仓的库存一直在账上挂着，很难反映真实状态。我的建议是：瓶颈工序或贵重物料按工序倒冲，普通物料按最后工序倒冲。这个原则可以根据项目实际情况调整。

注意：倒冲逻辑在SAP中其实是一个可配置选项，需要定义“倒冲的移动类型”和“倒冲的消耗数量规则”。不建议开发人员直接在标准功能里写增强去改倒冲逻辑，风险高、维护复杂。优先用后台配置解决。

3.4 超耗、替代料与特殊库存：三类躲不开的例外

工单发料做得多了你会发现，真正耗时间的不是正常链路，而是例外情况。这里说三个最常见的：

超耗处理：产线实际用料比BOM用量多，比如装配不良导致的配件报废。SAP默认不允许发料数量超过订单需求数量，这时要么增加订单数量（CO02里修改订单数量），要么通过“无订单发货”的流程走特殊发货，或者对超耗部分走成本中心费用化。项目中最稳妥的做法是给MES一个“超耗申请”功能，产线发起申请、生产主管审批、SAP侧接单过账。杜绝“先做了再补单”的习惯，否则月末成本差异极大。

替代料处理：BOM里的物料A缺货，实际用了物料B代替。这个在MES和WMS的系统里都简单，拣货按实际物料发就行，但SAP的BOM里没有物料B，直接过账261会报错。常见方案有两个：SAP里配置替代物料组或者做物料替换；或者MES发送报工数据时带替代料编码，SAP通过增强处理替代逻辑。后者灵活性更高，但维护成本也高。无论是哪种方式，财务上都要能追溯到“原计划料号”和“实际用料号”，否则成本核算没法向审计交代。

批次管理与分割评估：如果启用了批次管理，WMS下架时要扫描批次号，SAP过账时也要指定批次。这里容易出的问题是：WMS拣货批次和SAP过账批次不一致——尤其当同一物料多个批次同在一个库位时，人工拣错批次太常见了。建议在WMS拣货策略里强制“按批次下架”，并在扫描环节做批次校验。另外，如果启用了分割评估（比如同一物料按自产/外购分开估值），SAP的过账接口里必须明确评估类型，否则系统报错“输入评估类型”或“物料不存在”——热词里有人提到“sap中的q库存”、“sap 物料主檔marc中增加客制欄位”，这些都属于物料主数据和库存类型的细化管理，实际项目里往往是做增强开发的切入点。

4. 实操过程：从工单下发到发料过账的完整链路

4.1 一个标准流程的七步走

下面用一个装配制造业的常见场景串一遍完整流程。假设产品是电机，物料包括定子、转子、端盖、轴承、螺丝等，仓库和产线不在同一个物理区域。

第1步：SAP创建生产订单。计划员在SAP中用CO01创建生产订单，输入物料号、数量、工厂、订单类型，系统自动从BOM展开组件需求，生成预留。订单下达后状态变为REL。

第2步：MES接收工单。中间件将SAP生产订单信息（含订单号、物料号、数量、组件清单、计划开始/结束时间）发送到MES。MES生成工单和工艺路线任务，工单状态为“已下达”。

第3步：MES触发发料申请。工单在产线上达到开工条件（比如首件检验通过）后，MES根据组件清单生成发料申请，发给WMS。发料申请包含：订单号、组件物料号、需求量、线边仓目标库位。

第4步：WMS生成拣货任务。WMS收到发料申请，根据库存分配策略（先进先出/批次优先/库位顺序）锁定库存，生成拣货单。仓库人员用PDA扫描拣货，完成下架后，把实拣数量、批次、库位等数据回传。

第5步：WMS发货确认给SAP。WMS的拣货下架确认触发一条发货确认报文，经中间件发给SAP。SAP调用BAPI生成261物料凭证，组件库存从原材料库转移到生产订单，工单组件需求被核销。

第6步：MES报工触发倒冲或发料闭环。如果是倒冲模式，第4-5步可能变成：先做“调拨到线边仓”（如311），再在报工时倒冲过账。如果是领料模式，第5步已经完成发料过账。

第7步：MES完工确认回传。MES完成报工后，把合格品数量、报废数量、工时发送给SAP。SAP执行工单确认（CO11N逻辑），财务成本归集完成。

4.2 过账计算的关键参数：数量、批次、移动类型一个都不能少

SAP侧的发货过账，最常用的BAPI是BAPI_GOODSMVT_CREATE。在调用之前，需要把关键参数准备好，我列个清单：

其中最容易出错的是“数量”字段的换算单位。比如物料基本计量单位是KG，但MES/WMS里可能按PCS管理，如果接口层没有做单位转换，过账数量就会差一个数量级，这种错误往往到月末成本结算时才发现，非常痛苦。

另外，如果用BAPI_GOODSMVT_CREATE过账，要注意程序里必须设置BAPI2017_GM_ITEM_CREATE的STGE_LOC、MOVE_TYPE和ORDERID。同时，过账之后要检查BAPI返回值，尤其是MATERIAL_DOCUMENT字段——物料凭证号是后续追溯的唯一凭证，要落库保存。我见过有的接口程序没有检查BAPI返回值，其实过账失败了程序还返回成功，导致MES那边以为发料完成、实物也发了，SAP账上却根本没有扣——这种问题排查起来特别难受。

4.3 线边仓与库位管理的细节：从“大帐”到“细账”的设计

很多项目的矛盾根源在库位设计。SAP里库存地点可能只有两三个：0001原材料库、0002成品库、0003线边仓。但实际仓库可能有几十上百个物理库位。如果MES、WMS都直接按照SAP的库存地点来管，那线边仓的“细账”根本管不起来。

我的建议是做三级库位模型：

• 第一级：SAP工厂（Plant）
• 第二级：SAP库存地点（Storage Location），在SAP里维护
• 第三级：WMS物理库位（Bin Location），在WMS里维护

物料从原材料库发到线边仓，在SAP里可能只是从库存地点0001到库存地点0003的库位转移（移动类型311或261），但在WMS里实际是从货架A-03-02拣出、放到线边缓存区B-01。所以接口设计时，WMS的报文要同时带SAP库存地点编码和WMS物理库位编码。这个映射关系一定要在集成测试前建好，并且每周重新核对一遍。

另外，线边仓的“最大库存”和“安全库存”建议放在WMS里做，而不是全部压在SAP。因为线边仓的存放空间相对固定，WMS可以在拣货任务下达时做库容校验，一旦超过上限，自动拦截并提示MES调整到货计划。SAP的MRP跑出来的是宏观需求时间轴，无法细化到线边仓每个库位放不放得下，这层级的事让WMS管更合理。

4.4 SAP标准功能与增强的平衡：能配置的别开发，能标准化的别定制

热词里有“sap atc”、“sap请求”、“sap abap”等，这些说明不少项目正在做SAP的增强开发。工单发料链路里，哪些该做增强，哪些不该做，我拿实际项目的经验来讲。

建议做成标准配置的：移动类型的字段属性（比如是否允许负库存、是否允许超收、是否生成会计凭证）、订单类型相关参数文件、工厂/库存地点的默认设置、SAP后台的物料可用性检查规则。这些用标准事务配置即可，不要写代码。我见过有项目把倒冲的消耗数量计算逻辑直接写在程序里，结果每次需求变更都要改程序，又测试又传输，累得不行。其实这个需求用SAP后台配置就能实现——定义消耗规则、绑定到物料主数据，不需要一行代码。

建议通过增强实现的：特定业务口径的校验，比如发料前校验工单是否为“已验收”状态、校验物料是否通过质检放行、校验WMS回传的批次号是否与工单规定批次一致。这些校验用标准的“字段选择”和“校验规则”不一定覆盖得了，写增强（比如在MB_MIGO_BADI里做校验）更灵活。

SAP请求和传输是另一个容易忽视的点。生产系统和开发系统分开是基本要求，不要直接在PRD机改程序。项目里一定要有一套完整的传输机制——开发机改代码→测试机验证→PRD机传输。很多项目在“发料接口”这种不常改的程序上放松了传输管理，结果某次开发机调试时直接改到了PRD，把全厂的发料接口搞挂了。别问我是怎么知道的。

5. 常见问题与排查技巧：从接口报错到库存差异的实战指南

5.1 接口数据“卡住”的排查思路

工单发料链路最常见的现象是“卡住”——MES发了发料申请给WMS，WMS半天没收到；或者WMS发了确认给SAP，SAP迟迟没生成物料凭证。这种问题第一反应不要急着翻代码，而是按照下面的顺序排查：

1. 查中间件日志。报文到底有没有从A系统发出来、到没到中间件、中间件有没有转发出去了。中间件日志是判断问题发生在哪一段的最快路径。
2. 查系统接口监控表。很多项目的接口表里会有状态字段（如“待处理”“处理中”“完成”“失败”）。如果状态一直停在“处理中”，八成是对方系统没有返回，或者返回了但程序没更新状态。
3. 查对方系统的日志/监控。如果SAP侧一直没有调用BAPI，检查SAP的RFC日志或者中间件发出的调用有没有到SAP的gateway。常见原因是用户授权和RFC权限没配好——接口程序的调用用户没有权限执行BAPI，系统直接拒了，日志里未必有明显报错。
4. 查报文格式。最常见的坑是日期格式和数量字段精度不一致。比如SAP内部日期格式是YYYYMMDD，MES发来的是YYYY-MM-DD，字段定义稍有差异，对方系统解析直接失败。

需要特别提醒的是：接口报错时务必保留原始报文。不管是中间件也好，还是SAP侧的程序也好，一定要把原始请求和响应报文落库或写到日志文件。很多接口问题，对方系统只告诉你“报文格式有误”，但没有原始报文根本定位不了具体哪个字段有问题。

注意：做接口联调时，一定要做“异常报文”测试，不要只测正常路径。比如数量为0、物料不存在、批次为空、库存地点不存在这四种情况，必须各测一遍。很多系统上线后出问题，都是因为联调时只测了“好走的路”。

5.2 SAP过账失败的高频原因速查表

SAP过账失败基本都有错误消息号，排查起来其实有迹可循。我整理一个高频问题速查表，照着查能省很多时间：

出现这些报错时，SAP侧的BAPI返回值里会有错误消息文本，建议接口程序把消息文本原样回传给发起的系统（MES或WMS），操作人员才能根据提示处理。不要只在SAP侧看日志，然后告诉业务“你重新发一次”，业务人员会崩溃的。

5.3 三方库存不一致：先对主数据，再对流水，最后盘实物

复盘过很多工厂的库存差异问题，最后都得出一条经验：三方对账有一套铁律——先对主数据，再对流水，最后盘实物。

第一步对主数据。同一颗物料，SAP里物料号、计量单位、工厂、库存地点、批次主数据，和MES、WMS里的数据是否一致。差异最大的往往是计量单位（SAP基本计量单位是KG，MES里用个）和库存地点映射。这个不查好，后面所有对账都是白做。

第二步对流水。从时间维度拉出某颗物料一周以内的所有业务流水，分别看SAP的物料凭证、MES的报工/投料记录、WMS的出入库流水，比对同一业务在三个系统的记录是否匹配。重点看三个环节：WMS发料确认时点、SAP过账时点、MES报工时点。这三个动作只要有一个“时间错位”，就会出现某一天的库存三边对不上，但月底又能平的情况。在集成设计时，建议给每个报文加上“业务发生时间”字段，不要用系统处理时间做对账依据。

第三步盘实物。主数据和流水都对完还差不平，那基本就是实物出了问题——拣错料、放错库位、交接没登记。这时候不用在系统里继续折腾了，去仓库盘实物，按实物修正系统库存。

5.4 关于物料账、成本结算与月末关账的提醒

工单发料链路到“过账完成”并不算结束，月底的成本结算是最终的验收时刻。这里有几个和热词里“sap开物料账”、“sap 平行分类账”、“研发项目的成本归集”相关的经验建议：

• 物料账期开启前，务必将所有发料、报工、收货业务处理完。很多工厂每月27号关账，但MES的报工数据因为接口延迟，29号才传到SAP，导致SAP里的在制品余额与实际脱离。建议设置“业务截止时间”，MES侧在此之后禁止新报工，等SAP侧所有接口处理完再开物料账期。
• 工单差异在结算之前先做一次“差异分析”。通过CO03看工单的投料成本、报工成本、产出价值，如果差异率超过预设阈值（比如5%），先查清原因再结算，不要直接按差异总额过账。
• 如果涉及研发项目的领料，要提前配置好内部订单或WBS。热词里有“研发项目的成本归集，在sap里如何实现？通过内部订单吗”，答案是：通常用内部订单或WBS元素来归集，发料时指定对应的成本对象，月末结算到研发费用。但研发领料和生产发料最好不要混在同一个工单里，否则成本归集会乱。

5.5 集成测试：上线前最容易漏掉的几类场景

最后聊一个实操性极强的话题——集成测试。工单发料链路涉及三套系统，测试时不要只测“正常发料”这一条路径。我建议至少把下面这几类场景都跑一遍：

• 正常领料发料：整单发料、部分发料、超额发料（成功/失败两种结果）
• 库存不足发料：验证“负库存”配置是否正确，是否按预期拦截
• 批次物料发料：有批次、无批次、批次无效、批次重复四类情况
• 倒冲模式：正常报工倒冲、报废数量倒冲、线边仓欠料倒冲
• 冲销与退料：SAP生成的物料凭证冲销（移动类型262/261反向），WMS反向拣货是否同步
• 接口异常：中间件宕机、WMS超时无响应、SAP无权限报错，业务能否手工补单或重发

很多项目在集成测试时只跑“happy path”，结果上线第一周各种异常场景全冒出来了。尤其是冲销场景——SAP的261物料凭证被冲销后，MES和WMS里对应的“发料任务”状态是否跟着回滚，这个不提前设计好，月末对账时会非常痛苦。

6. 聊点项目实战之外的体会

工单发料看着是个技术问题，但做得多了你会发现，真正难的不是接口怎么写、BAPI怎么调，而是业务口径的统一。SAP里“发料完成”的含义和MES里“齐套”的含义、WMS里“拣货完成”的含义，在项目启动之初就要反复对齐，落实到文档甚至验收标准里，否则上线后每个系统都认为自己没错，但整个链路就是转不动。

我自己操作过几个项目之后，最大的体会是：一定要先把异常流程设计完再开发正常流程。很多团队习惯先把最顺畅的那条接口链路做出来，然后上线前几天才开始想“如果库存不足怎么办”“如果超耗怎么办”，最后成了救火队员。倒过来做——先把异常场景和对应的系统行为定义清楚，再回来写正常流程代码，整个接口的质量和稳定性会高一个台阶。

最后再分享一个小技巧：工单发料链路的日常监控，不要只看接口成功失败，还要看“数量”。我在项目里加过一个对账程序：每天凌晨比对SAP的261物料凭证数量、MES投料数量、WMS拣货数量，三者差异超过阈值自动告警。这个程序上线后解决了很多潜在的库存差异问题。搞信息化就是这样，很多时候卖点不在于功能多花哨，而在于能不能提前发现问题、避免月底的大盘点“惊喜”。