EDIFACT标准下采购场景的实现（三）：DESADV发货通知

本文我们将学习如何解读发货通知报文（DESADV）的报文规范，并结合实际业务场景，讲解 DESADV 报文的整体结构以及每个段、每个栏位在业务中的真实含义，帮助大家在项目实施中更好地理解和使用 DESADV 报文。

EDI DESADV 是发货通知报文（Despatch Advice），也常被称为 ASN（Advance Shipping Notice），用于供应商或仓库向买方、收货方或物流方提前通知：“货物已经发出去了，或者已经打包完成可以来提货了。”

DESADV 通常是对买方采购订单（ORDERS）、订单确认（ORDRSP）或发货指令的响应，用来明确告诉接收方：

• 本次实际发运了哪些商品
• 发了多少数量
• 怎么包装的（托盘、箱子、SSCC码等）
• 批次信息、生产日期、到期日
• 预计什么时候到货

我们以一个典型的零售/跨境供应链场景来说明 DESADV 的使用。

假设某品牌商向其第三方物流仓库或供应商下了一份 ORDERS 订单，用于采购一批服装或电子配件。供应商完成拣货、打包、贴 SSCC 标签、装车后，会立即生成一份 EDI DESADV 报文，返回给品牌商或其海外仓库。 DESADV 报文中会明确说明：

• 实际发运的数量（可能与订单略有差异）
• 包装层次（多少托盘、每个托盘/箱的 SSCC 码）
• 商品批次、到期日
• 预计到货日期

品牌商系统接收到 DESADV 后，可以据此提前更新库存、入库预约、通知门店准备收货、甚至启动清关流程。 DESADV 报文在供应链中有着非常典型的应用场景，包括但不限于：

• 零售供应链：供应商/3PL 向品牌方提前通知发货明细
• 跨境电商：海外仓出库后向平台或卖家反馈 ASN
• 制造业 JIT/VMI：供应商向主机厂通知零部件发货进度
• 食品/医药行业：带批次和追溯信息的发货确认

接下来，我们从报文结构的角度整体看一下 DESADV 是如何组织的。

最外层是交换控制 UNB & UNZ，用于标识一次 EDI 交换；在交换内部，是具体的报文控制结构。UNH 与 UNT 是成对出现的，用于标识一条 DESADV 报文的开始和结束。UNH 用来声明：“从这里开始，是一条 DESADV 发货通知报文，使用的是哪一个 EDIFACT 版本。”UNT 用来声明：“这条 DESADV 报文到这里结束，并且包含多少个 Segment。”这部分内容本身不承载业务含义，但它是 EDI 报文能否被正确解析和校验的基础，任何缺失或不匹配，都会导致整条报文被拒收。

从 BGM 段开始，正式进入 DESADV 的业务数据部分，也就是我们通常所说的 Header（头部信息）。DESADV 的 Header 结构是唯一的，在一份报文中只会出现一次，主要用于回答这些问题：这是哪一份发货通知？谁在发货？发给谁？这份通知是什么时候生成的？

在结构上，DESADV 的 Header 主要由以下几段组成：

BGM：定义报文编号和发货通知的业务属性 DTM：描述报文层级的日期信息（创建日期、预计到货日期等）；NAD（SU / BY / DP）：描述发货通知涉及的各类业务参与方；RFF：建立与采购订单、发货单等单据的引用关系。

这些段共同构成了 DESADVHeader，在系统设计中，通常会被映射为一张 DESADVHeader 表，用于存储报文级别的信息。

DESADV 报文的核心业务内容，集中体现在 Detail（明细信息）部分。DESADV 的明细结构是一个以 CPS（包装序列）为起点的嵌套循环结构。现代 DESADV 普遍采用 CPS 来描述包装层次（托盘 → 箱子 → 商品），而在 CPS 之下或直接在明细层使用 LIN 表示商品行。

在结构层面，一个完整的包装/商品描述通常包含以下内容： CPS 标识包装序列层级；PAC 描述包装类型和数量；PCI / GIN 传递 SSCC 码、箱码等标识；LIN 标识商品行项目；PIA 描述买方和供应商的物料编号 IMD 补充物料的文本描述；QTY 说明实际发运数量；DTM / GIN 传递批次号、到期日等追溯信息；RFF 建立与原始订单的对应关系。

在系统实现中，一个 CPS 层级往往对应一条 DESADVPackage 记录，而 LIN 行对应一条 DESADVItem 记录。当一个托盘/箱子里有多种商品、或一批货分多个托盘时，就会形成嵌套结构。

下面我们按照报文顺序，逐段解析 DESADV 报文中每个段及其关键栏位的业务含义。

首先是 Header 部分。 BGM 段用于定义发货通知的业务属性。BGM01 表示报文类型代码，用于说明该报文是一条 DESADV 发货通知（通常 351）。BGM02 用于唯一标识本次 DESADV 报文，是供应商或仓库发送 ASN 时的核心业务编号，对应 ASN 编号。BGM03 用于说明该条数据的状态，9 表示原始数据。

DTM 段用于传递与 DESADV 报文相关的日期信息。当 DTM01=137 时，DTM02 表示该 DESADV 报文在供应商系统中的生成日期。当 DTM01=17 时，表示预计到货日期。

NAD 段用于描述发货通知中涉及的各类业务参与方信息。当 NAD+SU 出现时，表示该段描述的是供应商（发货方）信息，包括 SupplierCode、SupplierName、街道、城市、邮编、国家编码。当 NAD+BY 出现时，表示该段描述的是买方信息。当 NAD+DP 出现时，表示该段描述的是实际收货方信息，用于明确货物最终送达的仓库或门店地址。

RFF 段用于建立发货通知与相关业务单据之间的引用关系。当 RFF01=ON 时，表示关联的买方采购订单号和订单行号。当 RFF01=DQ 时，表示供应商内部的发货单号和行号。

接着是 Package 和 Item 部分。 CPS 段标志着一个包装序列的开始，用于描述托盘、箱子等物流单元的层次结构。 PAC 段用于说明当前层级的包装数量和类型，PAC01 表示包装件数，PAC 中的代码表示类型（如 CT=箱、09=托盘）。 GIN 段（通常跟在 PCI 后）用于传递包装的唯一标识，最常见的是 SSCC 码，用于全球物流追踪。

LIN 段标志着一条商品发运明细行的开始。LIN01 用于表示该行在 DESADV 报文中的顺序号，同时也是与原始订单行项目进行匹配的关键字段。 PIA 段用于传递物料在不同系统中的编号信息。当 PIA 使用 IN 限定符时，PIA0201 表示买方物料编码。当 PIA 使用 SA 限定符时，PIA0201 表示供应商内部物料编号。 IMD 段用于描述物料的文本信息，用于传递商品名称、规格或补充说明。 QTY 段用于说明供应商实际发运的数量。当 QTY01=12 时，表示本次发运数量，QTY0103 对应数量单位。 DTM 段用于描述批次相关日期，例如， DTM01=36 表示批次到期日。 GIN 段在这里也常用于传递批次号，部分客户还会要求 EUDR 相关的合规标识。

综合来看，一份 DESADV 报文在结构上可以清晰地拆分为以下层级关系： 一次交换中包含一条或多条 DESADV 报文； 每一条 DESADV 报文，只有一个 Header，可以包含多个包装明细； 每个包装层（CPS）可以包含多个商品行（LIN），每个 LIN 行对应实际发运数量、批次等信息。

这种 “DESADVHeader → DESADVPackage → DESADVItem” 的层级结构，正是 DESADV 报文在系统设计、数据库建模和 XML 设计中的核心逻辑基础。

在实际项目实施中，我们通常还会整理一份 Mapping 表。Mapping 表的一侧是 DESADV 规范中的 Segment 和数据元，另一侧是自定义 XML 结构和数据库字段。通过这种方式，可以让实施顾问、开发人员和运维人员在同一张表中对齐理解，大大降低项目交付和后期维护的复杂度。

以上就是 DESADV 报文的整体结构与字段详解。大家可以结合具体交易伙伴的 DESADV 规范，进一步调整字段使用方式（如是否强制 SSCC、是否需要 EUDR 合规字段等）。如有疑问，欢迎随时交流。

注：文案部分图片及内容来源于网络，版权归原创作者所有，如有侵犯到您的权益，请您联系我们进行删除，给您带来困扰，我们深感抱歉。