先说结论：EDI 856（advance ship notice，发货通知）被零售商拒收，八成不是 EDI 翻译器的问题，是仓库主数据的问题。排查链只有一条：997 回执告诉你哪一段报错 → 对照 856 报文定位该段 → 回溯 WMS 主数据、标签或承运商面单 → 修正重发。按这条链走，最多两个小时定位。这个坑我见过三次。
997 回执码：唯一的起点，别跳过这一步
856 发出去，零售商的 EDI 系统会回一个 997（functional acknowledgment，功能性确认）。很多人收到 997 看一眼就扔一边，这是错的——997 是唯一的报错入口。
按顺序做：
- 登录 EDI 门户（SPS Commerce、TrueCommerce 之类）或从邮箱下载当天的 997 文件，找到和你那票 856 控制号对应的那一份。
- 找到 AK9 段，看 AK901：R=整组拒收；E=带错接受（别松口气，零售商照样发 chargeback 罚款）；A=语法通过（注意：只代表语法没问题，业务数据过不了零售商校验的话，他们会另发 824 或邮件）。
- AK901 是 R 或 E 时，往上找 AK3 段：它会写明是哪个段报错（如 MAN、SN1、HL），以及该段在报文里的位置。
- 再找 AK4 段：报错的元素序号 + 错误码。常见错误码：5=元素值无效、8=该场景下不该出现、2=强制元素缺失。具体含义以零售商 EDI 规范文档为准。
856 报错段对照表：报文段 → 仓库根因 → 去哪查
| 997 指向的段 | 856 里它是干嘛的 | 仓库端最可能的根因 | 去哪查 |
|---|---|---|---|
| BSN | 发货通知编号 | 发货单号和 850 订单/出库单对不上 | WMS 单号规则、订单映射表 |
| HL | 层级（S 发货/O 订单/P 包装/I 行项目） | 层级顺序错、跳层、一个订单挂错发货 | 打包流程、WMS 打包逻辑 |
| MAN | SSCC 托盘序列号 | SSCC 重复！头号杀手 | 托盘主数据、号段管理 |
| LIN/SN1 | 商品行、数量 | UPC/GTIN 对不上、数量单位错 | 商品主数据、UOM 映射表 |
| TD3/TD5 | 承运商、设备、PRO 号 | PRO/BOL 号和面单不一致 | 承运商面单、TMS |
| N1 | 地址 | ship-to 地址错 | 客户主数据 |
| ISA/GS | 信封头 | 测试/生产标识 ISA15 发错（T 发到了生产通道） | EDI 配置 |
还有两个报文里看不见、但 997 照报的经典坑：UPC 前导零被 Excel 剥掉（CSV 用 Excel 打开保存一次，001234567890 就变成 1234567890）；数量单位大小写写错（EA 写成 Ea）。
EDI 856 排查链：六步，每一步都可执行
- 拿 997：按上面读出 AK901/AK3/AK4，记下报错段名。
- 拉 856 原文：在 EDI 翻译器里按控制号导出原始报文，找到报错段那一行，抄下它的关键值（如 MAN 段的 SSCC、SN1 段的数量和单位）。
- 查 WMS 主数据：拿着这个值去 WMS 里反查。SSCC 就去托盘表查重复；UPC 就去商品主数据查 GTIN 和销售单位；单号就去订单表查映射。
- 查标签：SSCC 问题必查 UCC-128 标签——标签上印的和 856 里发的是不是同一个？重打过标签没？（下面案例一就是栽在这）
- 查承运商面单：TD3/TD5 报错时，把 856 里的 PRO 号、BOL 号和承运商实际面单逐字核对。
- 修正→重发 EDI 856：数据修好后，在 EDI 翻译器里重发 856（控制号 ST02 用新号，别复用），盯着 997 回到 A，再跟零售商确认业务校验通过。
两个项目故事：都是半夜被电话叫醒的
案例一：2023 年 11 月，芝加哥郊区一家 3PL，服务十几个中小品牌。那天晚上 11 点，项目经理电话打过来：给 Target 的 300 多票 ASN（856）被拒收了，997 清一色 R，AK3 全部指向 MAN 段。我让他把 856 原文导出来，MAN 段的 SSCC 拿去 WMS 托盘表一查——重复了 40 多个。根因：10 月份 WMS 升级迁移，托盘号段序列被重置，旧 SSCC 又发了一遍。Target 的系统校验 SSCC 全局唯一，直接整批拒收。救法：当晚冻结发货，重建托盘号段（年份+仓库码+流水，位数留够），重打 UCC-128 标签，重发 856。48 小时内补完，chargeback 最后谈到 800 多美元。这个坑我见过三次，次次都是号段管理。
案例二：2024 年 3 月，洛杉矶一家美妆品牌，3PL 托管仓。给 Walmart 发 856，AK901=R，AK3 指向 SN1。报文里 SN102 数量 144，SN103 单位 CS（箱）。Walmart 的 850 订单行单位是 EA（个）。根因：WMS 商品主数据的销售单位填了 CS，EDI 映射直接把 CS 发出去；但这个 SKU 在 Walmart 档案里是按 EA 销售的。144 箱 vs 1728 个，对不上，拒收。救法：按零售商逐家维护 UOM 映射表，这个 SKU 发 Walmart 时单位改 EA、数量改 1728，重发通过。教训：UOM 映射表不能一套打天下，必须按零售商逐家维护。
上线前夜 checklist：856 发货通知翻车点清单
- SSCC 全库查重：跑一遍托盘表，SSCC 有重复的一票都不能发。
- UPC 前导零：从 WMS 导出的 CSV 用记事本打开验，别用 Excel（它会吃掉前导零）。
- HL 层级：至少抽 3 票，把 S→O→P→I 全链路对一遍。
- PRO/BOL：面单号写进 856 之前，先和承运商确认一遍。
- ISA15：生产环境必须是 P，测试报文别发到生产通道。
- 首票先发测试：等 997 回 A、零售商业务校验通过，再批量发。
反常识的判断，放在最后：八成 856 报错不是 EDI 翻译器的问题，是仓库主数据的问题。翻译器只校验语法，零售商校验的是业务——SSCC 唯一性、UPC 准确性、数量单位、地址，这些全在仓库手里。所以下次 856 被拒收，先查数据，再查报文，最后才怀疑翻译器。顺序反了，你会在 EDI 供应商的工单系统里浪费一整天。
作者：林晓｜WMS 实施顾问
