EDIFACT标准下采购场景的实现（二）：ORDRSP 订单响应

EDI ORDRSP 是订单响应报文，用于供应商对买方发送的订单（ORDERS）进行确认、修改或拒绝。

本文主要介绍订单响应报文（ORDRSP） 的报文规范，并结合实际业务场景，讲解 ORDRSP 报文的整体结构以及每个段、每个栏位在业务中的真实含义。我们以下方ORDRSP报文作为示例，帮助大家在项目实施中更好地理解和使用。

ORDRSP 通常是对前一份 ORDERS 订单报文的直接回应，用来明确告诉买方：

订单是否被接受、数量是否有调整、交期是否确认或变更。

我们以一个典型的制造业采购场景来说明 ORDRSP 的使用。

假设某汽车零部件制造商向其原材料供应商发送了一份 ORDERS 报文，用于采购钢材。供应商在接收到订单后，会在内部系统中检查库存、产能和交期情况。
确认无误后，供应商会生成一份 EDI ORDRSP 报文，将订单的响应结果返回给买方。

ORDRSP 报文中会明确说明：

• 确认的交付数量
• 供应商承诺的交货日期
• 是否存在数量或交期的调整

买方系统接收到 ORDRSP 后，可以据此更新采购订单状态，并作为后续收货、对账和付款的业务依据。

ORDRSP 报文在供应链中有着非常典型的应用场景，包括但不限于：

• 制造业采购：供应商对采购订单进行确认或调整
• 零售补货场景：品牌商下单后，供应商反馈可供数量与交期

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

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

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

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

• BGM：定义报文编号和订单响应的业务属性
• DTM：描述报文层级的日期信息
• NAD（SU / BY / DP）：描述订单响应涉及的各类业务参与方

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

ORDRSP 报文的核心业务内容，集中体现在 Detail（明细信息） 部分。ORDRSP 的明细结构是一个 以 LIN 为起点的循环结构，也就是我们常说的 LIN Loop。每出现一次 LIN，就表示供应商正在对 ORDERS 中的一条订单行进行响应。在结构层面，一个完整的 LIN Loop 通常包含以下内容：LIN标识订单响应的行项目，PIA描述买方和供应商的物料编号，IMD补充物料的文本描述，RFF建立与原始订单或供应商内部订单的引用关系，SCC/ QTY / DTM：描述确认的数量和交期

在系统实现中，一个 LIN Loop 往往对应一条 ORDRSPItem 记录。在很多实际业务场景中，一条订单行可能存在以下情况：

• 同一物料分多次交付
• 同一物料存在多段不同的交期

数量与交期需要组合表达“承诺计划”，在这种情况下，ORDRSP 会在同一个 LIN Loop 下，重复出现 SCC、QTY 与 DTM 的组合。从结构上看，这一层实际上形成了一个 Schedule Loop，在数据库设计中，通常会被拆分成一张独立的 ORDRSPSchedule 表，用于描述：-确认数量、数量单位、对应的确认交期

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

首先是Header部分。BGM 段用于定义订单响应的业务属性。BGM01 表示报文类型代码，用于说明该报文是一条订单响应。BGM02用于唯一标识本次 ORDRSP 报文，是供应商发送订单响应时的核心业务编号。BGM03 用于说明该条数据的状态，9表示原始数据。

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

NAD 段用于描述订单响应中涉及的各类业务参与方信息。当 NAD+SU 出现时，表示该段描述的是供应商信息。NAD0201 用于唯一标识供应商；其他信息依次描述供应商名称、供应商的街道、城市、邮编和国家编码。当 NAD+BY 出现时，表示该段描述的是买方信息。当 NAD+DP 出现时，表示该段描述的是收货方或交付地点信息，用于明确订单最终的交付位置。

接着是Item部分。LIN 段标志着一条订单响应明细行的开始。LIN01 用于表示该行在 ORDRSP 报文中的顺序号，同时也是与原始 ORDERS 行项目进行匹配的关键字段。每出现一次 LIN 段，就表示供应商正在对订单中的一条物料行进行响应。PIA 段用于传递物料在不同系统中的编号信息。当 PIA 使用 IN 限定符时，PIA0201 表示买方物料编码。当 PIA 使用 SA 限定符时，PIA0201 表示供应商内部物料编号。IMD 段用于描述物料的文本信息，用于传递物料的名称、规格或补充说明。

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

最后就是交货明细部分。SCC+12表示Deliver to schedule（按交货计划交付），QTY+66 段用于说明供应商对订单数量的确认结果，表示供应商确认可以交付的数量；QTY0103 对应 CommittedQuantityUOM，用于说明数量单位。DTM 段用于描述供应商确认的交货日期，表示供应商承诺的交货时间。该段通常与 QTY 组合使用，用于明确“多少数量，在什么时候交付”。当一条订单行存在多次交付时，会在同一 LIN 下重复出现SCC、 QTY 与 DTM 组合，从而描述分批交付的业务场景。

综合来看，一份 ORDRSP 报文在结构上可以清晰地拆分为以下层级关系：

• 一次交换中包含一条或多条 ORDRSP 报文；
• 每一条 ORDRSP 报文，只有一个 Header，可以包含多个 LIN 明细行；
• 每个 LIN 行，可以包含多个数量与交期确认记录

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

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

以上就是 ORDRSP 报文的整体结构与字段详解。大家可以结合具体交易伙伴的 ORDRSP 规范，进一步调整字段使用方式。如有疑问，欢迎随时交流。

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