找到我们的时候，这家贸易商手里攒了小半年的扣款单，每张的理由都差不多：ASN 数据与实际到货不符——箱数对不上、托盘层级对不上、或者干脆迟发。
老板最憋屈的不是钱，是说不清责任。EDI 服务商说"我按你给的数据发的，数据是仓库给的"；仓库说"我发的货没问题，报文我又不管"；供应商夹在中间，每张扣款单都要开三方拉扯会，最后多数不了了之，认罚。
问题不在人，在架构
报文数据的旅程是这样的：仓库作业完 → 人工整理 Excel → 发给 EDI 商 → 录入生成 856。三次换手，每次都可能出错，而且出错之后无法定位是哪一手错的。这不是把人换勤快点能解决的事。
怎么改的
- 线路迁移：EDI 通道迁到我们这边，测试与旧线并行，切换当周零停单（怎么做到的见 不停单迁移）；
- 货转美西仓：库存转入我们美西仓，收柜、打板、贴标、出库都在一个系统里；
- 仓报一体：856 不再有人工环节——仓库出库确认的那一刻，ASN 按出库记录自动生成：几托、几箱、什么标、几点出的门，报文说的就是仓库做的。
结果
切换后的完整季度里，"报文与货不符"类扣款为零。不是我们盯得多紧，而是这类错误在架构上已经没有产生的路径——数据只有一份，没有"对不上"这回事。
给同行一句话：如果你的 EDI 商和你的仓库是两家公司，那每张扣款单都会变成罗生门。要么让仓库出报文，要么让报文商管仓库，二选一。