EDI 回执 997/824 看不懂：报文丢了、对方说没收到，排查链

先说结论：对方说"没收到"，先别急着重发。EDI 997 824 acknowledgment troubleshooting 的核心就一句话：先定位报文到底卡在哪一环，再决定重发还是补发。重发发错了，一票货能变成两票单据，这个坑我见过三次。

我做上线项目这些年，EDI 报错里最耗时间的从来不是报文格式错了，而是"对方说没收到"。你这边日志显示已发送，对方那边查不到，电话里各说各的，货还停在半路。这篇文章把排查链写死：按顺序查，一环一环排除，不用猜。

报文链路全图：先看报文要走几道门

一张 EDI 报文从发出到进对方业务系统，要过六道门，任何一道门卡住，对方都会说"没收到"：

我方 WMS 或 ERP：业务单据生成，交给翻译软件
我方 EDI 翻译软件：把业务数据翻成 EDI 报文，检查格式
传输层：走 VAN 或直连 AS2，把报文送到对方
对方网关：接收报文，确认传输到达
对方翻译软件：解析报文，检查格式和内容
对方业务系统：把报文写进收货、订单或应付系统

关键点在这里：997 只管到第 4 步和第 5 步的前半段，它确认的是"报文到了、格式能读"。至于对方业务系统认不认这张单，那是 824 管的事。很多人把这两步混成一步，查了半天查不出问题。

EDI 997 vs 824 对照表：各回什么

	997 功能确认	824 应用建议
回答的问题	报文收到了吗？格式对吗？	业务单据接受吗？内容有问题吗？
发出方	对方翻译软件	对方业务系统或应用层
常见状态	接受、带错接受、拒绝	接受、拒绝、需人工处理
收到意味着	传输和格式这一层通过了	业务层给出了明确答复
没收到意味着	报文可能没到，也可能对方没配回执	对方可能没启用 824，或业务系统还没处理
典型误读	997 通过 = 对方收到了单子	824 没来 = 对方没收到

反常识的判断来了：997 通过不等于业务单据被接受。997 是信封层面的确认，不是业务层面的确认。对方翻译软件说"格式没问题"，不代表对方收货系统认这张 ASN。真正决定单据有没有进对方系统的是 824，或者对方业务系统的实际处理结果。做 EDI 997 824 acknowledgment troubleshooting，第一步就是把这两层分开，而不是急着重发。

"对方说没收到"：EDI 997/824 五步排查链

按这个顺序查，不要跳步。每一步都要拿到证据再往下一步走，口头说"应该发了"不算证据。

第 1 步：查我方发送日志。 确认报文到底发出去了没有。看发送时间、报文控制号、接收方标识、发送状态是成功还是失败。很多"对方没收到"的起点其实是我方根本没发出去：定时任务没跑、队列堵了、翻译软件报错没人看。先把我方日志截图存下来，这是后面所有沟通的底。

第 2 步：查 VAN 或传输层回执。 如果走 VAN，查 VAN 的投递确认；如果走直连，查传输日志和对方网关的接收确认。这一环确认的是报文有没有离开我方、到达对方门口。VAN 显示已投递，对方网关没有接收记录，那问题在对方网关那侧；VAN 显示没投递，问题还在我方或传输层。

第 3 步：查对方网关。 让对方 IT 确认网关有没有收到这份报文。给对方的定位信息要精确：发送时间、报文控制号、报文类型、发送方和接收方标识。只说"我们昨天发了一张 ASN"对方查不出来，这是沟通上最常见的翻车点。

第 4 步：查对方翻译。 对方网关收到了，不代表翻译通过了。让对方确认翻译软件有没有解析这份报文、有没有报格式错误、有没有因为某个段或代码值不匹配被挂起。去年秋天，加州一个 3PL 仓就栽在这里：一张 856 发货通知发出去了，997 回的是接受，卡车到了对方仓门口，对方收货员却查不到这张 ASN，直接拒收，车在门口等了大半天。最后查下来，对方翻译通过了，但 ASN 没进对方收货系统，因为物料编码对不上，应用层其实已经回了 824 报错，只是没人看 824。

仓库IT人员检查服务器和网络设备，排查EDI报文传输问题

第 5 步：查对方业务系统。 前四步都通过了，最后确认对方业务系统里有没有这张单：ASN 能不能在收货计划里查到，订单能不能在对方系统里查到，发票有没有进应付。查不到，就让对方按业务单号、送货日期、物料编码这几个业务字段反查，不要只按报文控制号查。业务系统里的字段映射错了，报文控制号对得上也白搭。

重发 vs 补发：别把一票货变成两票

定位清楚之后，才轮到决定怎么补。重发和补发不是一回事，用错了会造出重复单据。

重发：同一份报文，原封不动再发一次，报文控制号不变。适用场景：报文根本没到对方手里，比如传输失败、对方网关没收到。重发前必须先确认对方确实没有收到，否则对方会收到两份一样的报文。
补发：按对方要求，重新生成或重新提交业务单据，报文控制号是新的。适用场景：原文已经到对方手里但被对方拒绝或挂起了，或者对方要求用新报文覆盖旧报文。补发前必须先确认旧报文在对方那边的状态：是被拒绝了、挂起了，还是已经进系统了。
绝对不要做的事：在没确认对方状态的情况下，直接换个控制号重发一遍。对方系统如果没有按控制号去重，就会把同一票货记成两票：两张 ASN、两个收货计划，严重的会重复收货、重复付款。收尾的时候，务必让对方书面确认旧报文作废或已处理，再发新的。

常见翻车点

997 带错接受当成通过。 997 的状态里有"接受""带错接受""拒绝"三种，带错接受的意思是格式大体通过、但有错误被标注出来了。很多人只看"有没有回 997"，不看里面的状态码和错误段，带错接受也当通过放行了。这个坑我见过三次，每次都是上线后才爆出来。
824 没人看。 很多项目把 824 接了，但没配告警、没人定期看。824 回了应用层拒绝，业务那边还以为单子已经进了对方系统。824 必须进监控，进待办，进责任人。
只按报文控制号沟通。 对方业务人员不认控制号，他们认订单号、送货日期、物料编码。跟对方业务人员排查时，给业务字段；跟对方 IT 排查时，给控制号和时间戳。两套定位信息都要备齐。
测试时只测顺向流程。 上线前只测"报文发过去、997 回来"，不测"对方拒绝怎么办""824 报错怎么办""重发会不会重复"。上线前夜 checklist 里必须有这三条的演练记录。