仓库已经发货，为什么系统还显示没发

用一次发运回执丢失的案例，分析 ERP、WMS、MES 与 TMS 的状态差异，区分消息接收与业务完成，说明重复重传、版本冲突、数量对账和异常重试怎样避免重复出库与漏单。

杨正武 · 发布于 2026-10-19

货车已经出门，ERP 订单仍显示待发。客服催仓库再确认一次，仓库点了重发，接口又生成一张出库单。同一批货只离开过一次，系统里却出现两次扣减。另一个方向，接口页面显示发送成功，业务端可能根本没有完成过账。

管理者要知道实物发生了什么、哪个系统尚未确认，以及能否安全恢复。这篇沿一笔独立模拟发运说明对接与对账，区别于系统恢复篇的整体恢复点与灾后核对，不涉及真实订单操作。

先把几个完成状态分开

名称相同也未必含义相同。工厂要约定出库时点、货权、仓库与线边的映射、部分发运以及冲销方式，并指定谁维护各类事实。MES 关心生产配送和实际投入，TMS 关心运输交接；不能把几个系统的“完成”字段无条件相互覆盖。

Microsoft 的系统数据交换说明将主数据、单据和进度数据分开。接入时可以沿这三类逐项核对物料编码、单位、批次、订单行、库存状态和收发结果，具体数据契约仍由项目确定。

模拟订单 SO-I100 发运 100 件，WMS 在 10:00 完成一次出库，事件身份为 SHIP-I100。ERP 收到事件并提交 100 件出库，生成事务 ERP-T100，但返回回执的网络中断。10:01，WMS 仍显示同步待确认。

这时真正缺失的是确认结果。发送方应先按原业务身份查询，或用原身份安全重试；接收方返回已经保存的 ERP-T100。若每次重发都新建事件和出库事务，第二次就可能再扣 100 件。

同一发运100件 + 原事件重传100件 → ERP累计仍为100件
同一事件身份改成98件 → 返回内容冲突，原100件结果不变
批准更正为98件 → 新建关联原事务的更正，使净结果减少2件

幂等表示相同业务请求重复到达仍得到同一次效果。去重键至少包含来源系统和稳定业务身份，还要检查原需求行与执行范围；只按传输消息 ID 去重，挡不住一次业务被不同消息重新包装。目标系统应把去重记录和业务过账放在能够保证一致的事务机制中。

发运事实怎样安全进入下游账目独立窗口查看 ↗

教学接口设计。消息送达、业务提交和对账分别留证；内容冲突转人工核对，不靠重复发送消除差异。

短暂网络故障可以按原身份退避重试，次数和时间窗口要有上限。物料映射不存在、批次资格不满足、单据已取消或内容冲突，通常需要修正依据后再恢复；无限重试只会增加噪声。

发送端保存已完成业务和待发送事件的一致关系，接收端保存应用结果，避免一边提交而另一边没有记录。是否采用事务发件箱、消息队列或其他机制，由实际架构决定。网络超时的业务结果可能未知，页面应显示“待查询”，不能直接当成没有发生。

顺序也要核对。取消消息先于创建消息、退料先于原交付、冻结晚于拣货但早于发运，都不能单靠消息抵达次序判断。传递业务版本、发生时间、原记录和关联动作，接收方根据有效状态执行。接口的访问权限与批准范围同样需要落实，Agent 不应通过换一个请求绕过业务限制。

PDA 和打印机是现场采集与标识设备，连接正常只能说明设备可用。断网缓存、重复扫码、补打标签的记录仍需回到仓储任务，不能拿设备在线率证明库存已经同步。

模拟同步窗口中有三个发运行，WMS 分别确认 100、60、40 件，合计 200。ERP 对应结果为 100、0、38，合计 138。逐行差异为 0、60、2，未对齐共 62 件。

其中第二行可能整条消息未送达，第三行可能是部分过账、口径错误或存在更正。62 件是同口径待核对差量，不直接等于丢货。若只看“已发送消息的成功率”，第二行没进入队列就可能被漏掉。

对账应从业务应有单据与目标实有事务两边取数，按工厂、货主、仓库、订单行、物料、批次、状态、单位和截止时点比较。还要检测目标端多出来的事务。补录、更正和迟到事件形成新一轮对账，保留上轮快照；不覆盖旧结果后声称从未出现差异。

管理场景样本可复算重复回执、身份冲突与 62 件差量；它只验证声明的教学条件。日常运行还要检查待发送记录积压、超过时限的未知结果和未闭环差异。资料核对于 2026-10-19，本文设计不承诺跨系统瞬间一致，业务完成以各端可核实的结果为准。