EDIFACT标准下采购场景的实现（一）：ORDERS 采购订单

ORDERS 是采购订单报文，也是制造业、零售业、汽车行业中最核心、使用频率最高的一类 EDI 报文之一。

本文我们会用一个完整视角，带大家一起从：ORDERS 报文的业务含义，到报文结构和关键段，再到到数据库表设计和字段映射，一次把 ORDERS 讲清楚。

我们以下方ORDERS报文作为示例，来帮助大家更好的理解ORDERS。

一、ORDERS 报文在业务中的角色

在真实业务中，ORDERS 的本质是：买方向供应商正式下达的一份采购订单。

它回答了五个核心问题：

• 谁买？ —— 买方（Buyer）
• 向谁买？ —— 供应商（Supplier）
• 买什么？ —— 物料明细（Item）
• 买多少？多少钱？ —— 数量、价格
• 什么时候送？送多少？送到哪？ —— 交期、收货方

在 EDI 世界里，这些信息被拆分成三层结构：

ORDERSHeader：订单头（整张订单层面，一个订单只会出现一次的数据）
ORDERSItem：订单行项目（每行表示一种物料）
ORDERSSchedule：交付计划（每行表示多次交付）

这个结构，同时也是最合理的数据库设计方式。

我们用一个真实的业务场景来理解 ORDERS：假设一家零售集团在国内有 ERP 系统，供应商在国内或海外，双方通过 EDI 进行采购协同，业务流程是这样的：

• 买方在 ERP 中创建采购订单
• ERP将采购订单内容推送给EDI
• EDI 将订单数据转换为 EDI ORDERS 报文
• ORDERS 通过 EDI 平台发送给供应商

所以可以理解为：ORDERS = 买方发起采购合同的电子版本

在真正进入 ORDERS 报文之前，我们得先了解交换头（Interchange Header），最简单的解释，在交换头中，不关心你买了什么，它只关心：这份 EDI 是谁发的、发给谁、什么时候发。
在 EDIFACT 里，一整份文件，其实分三层：

第一层：交换层，包含UNB / UNZ
第二层：报文层，包含UNH / UNT
第三层：业务层，这一层才是ORDERS 内容本身，ORDERS只是中间那一层里的“业务正文”。

在报文的最前面，有时你会看到一行：

它是干嘛的呢？其实是为了声明分隔符怎么用：

如果通信双方事先约定好了，UNA这一行可以不出现。

真正的交换头从 UNB 开始，它的功能包括：声明 EDI 语法、声明通信双方、声明交换控制信息。而UNZ则是和UNB交换头对应的交换尾。

我们以示例报文为例：

【UNB 第一个信息｜语法】

UNOC：使用字符型语法
3：语法版本

这是在说：“我们用什么规则来解析这份文件”

【UNB 第二个信息｜发送方】

TEST12345678：发送方 EDI ID，也就是谁把这份 ORDERS 发出来的
14: 发送方EDI ID Qualifier，14表示发送方ID是使用发送方的EAN号码定义的。

【UNB 第三个信息｜接收方】

1234567890123: 接收方 EDI ID，也就是这份文件是发给谁的。
14: 接收方EDI ID Qualifier，14表示接收方ID是使用接收方的EAN号码定义的。

【UNB 时间戳】

210223:1543
210223： 2021 年 02 月 23 日
1543：15：43分

用于通信日志、重发、审计等。

【UNB 交换控制号】

0000000000088888：交换控制号
一个 UNB必须对应一个 UNZ，而且控制号必须一致；

【UNB 测试指示符】

1：表示本条报文是测试报文

【UNZ｜交换尾（Interchange Trailer）】

UNZ表示交换结束。系统就是靠它判断文件是否完整。
1：表示本次交换里，包含 1 条业务报文
0000000000088888： 对应 UNB 的交换控制号

【交换头常见坑】

项目里，交换头最容易出问题的地方通常有以下几种情况：

• 发送方 / 接收方 ID 不匹配
• UNB / UNZ 控制号不一致
• 字符集、分隔符不一致

出现这些问题时，可能业务数据完全没错，但文件或许会被拒收。

刚才我们讲了交换头 UNB，很多人看到这里，会以为 UNB 就是“整张订单的头”，其实不是，在 EDIFACT 里，UNB 管的是文件级通信，而 UNH 管的是“一条业务报文”。一个 UNB 里可以包含多条 UNH 。

UNH主要负责三件事：第一，给这条报文一个编号，第二，声明这条报文的类型，第三，声明使用的版本和目录
我们以示例报文为例：

【UNH 第一个字段｜报文参考号】

0000000000088888：报文参考号，必须和 UNT 里的编号一致，系统靠它判断这条报文是不是完整。

【UNH 第二个字段｜报文类型】

ORDERS：表示这是一个采购订单报文

常见的还有：ORDRSP（订单响应）、DESADV（发货通知）、INVOIC（发票）

D： EDIFACT 目录
96A： 版本号
UN： 维护机构是UN

这句话翻译过来就是：“这条 ORDERS按照 D96A 版本来解析”

UNH 决定了解析规则，ORDERS 决定了业务内容。

【UNT 是什么】

UNT是报文尾，是 UNH 的“结束标记”，它用来做完整性校验。

【UNT 第一个字段｜段数量】

19：从 UNH 到 UNT，一共包含多少个段，包括：UNH、ORDERS 所有段、UNT 本身

【UNT 第二个字段｜报文参考号】

0000000000088888：报文参考号，必须和 UNH 的参考号一致

一定要记住，UNH + UNT，是成对出现的。

【UNH / UNT 常见错误】

项目中UNH / UNT最常见的错误：

第一：UNH / UNT 编号不一致
第二：UNT 段数量算错
第三：版本号和实际内容不匹配

以上主要用于 EDI 通信和报文完整性控制，业务系统通常不会直接使用，但在技术实现上必须严格遵守规范。真正承载业务含义的，是 UNH 和UNT之间的内容。

从BGM段开始，就是ORDERS的正文了。我们先来看 ORDERS 的 Header，也就是订单头部信息。ORDERS 的 Header 描述的是整张采购订单层面的信息。

首先是 BGM 段，它用于标识报文类型以及订单号。BGM01 表示单据类型代码，220表示这是一张采购订单。BGM02 是采购订单号，对应买方系统中生成的订单唯一编号，是整条 ORDERS 报文最核心的业务主键，后续 ORDRSP、DESADV、INVOIC 等报文都会引用该值。BGM03 用于表示订单的功能代码，例如原始订单、变更订单或取消订单，9表示原始订单；供应商系统通常会根据 BGM03 来判断是否需要新建订单、更新订单或执行撤单逻辑。。

紧接着是多个 DTM 段，用于描述与订单相关的关键日期。当 DTM =137 时，表示报文创建日期，也就是 ORDERS 报文在 EDI 系统中生成的时间。当 DTM =4 时，表示订单日期，也就是采购订单在买方业务系统中正式创建的日期。当 DTM =2 时，表示请求交货日期，也就是买方希望供应商完成交付的目标日期。

ORDERS 中一个非常重要的部分是 NAD 段，也就是参与方信息。NAD01 表示参与方角色代码，用于区分当前描述的是买方、供应商还是收货方。NAD02 是参与方的唯一识别编码，通常来自双方约定的客户号、供应商号或主数据编号。NAD03 用于说明 NAD02 所采用的编码体系，例如 DUNS、GLN 或双方自定义编码。NAD04 至 NAD08 依次承载参与方名称、街道地址、城市名称、行政区域、邮政编码以及国家代码。通过 NAD 段，ORDERS 可以同时描述买方、供应商以及收货方等多个业务角色。比如 NAD+BY 表示买方，NAD+SU 表示供应商，NAD+DP 表示实际收货方。在实际业务中，收货方有时并不等同于买方本身，可能是买方的某个仓库、门店或第三方物流中心。ORDERS 通过 NAD 段，把这些角色清晰地区分开来，确保供应商能够准确理解货物要交付给谁、交到哪里。

在 Header 中，还会包含币种和交货条件等信息。CUX 段用于描述订单中金额相关的币种信息。在 CUX 段中，最关键的字段是币种代码，它明确告诉供应商，这张采购订单中的所有价格和金额是以哪种币种来计算的，例如 CNY、USD 或 EUR。

TOD 段用于描述订单的交货条件，也就是常说的贸易条款。通过 TOD 中的交货条件代码，ORDERS 可以明确这是 FOB、CIF、DDP，还是其他约定方式。

LOC 段通常与 TOD 段配合使用，用于描述具体的交货地点。比如港口、城市、仓库或工厂。LOC01 表示地点限定符，用来区分这是交货地点、装运地点还是目的地点。LOC02 是具体的地点代码，可能是仓库编号、城市代码或港口代码。LOC03 用于说明地点代码所使用的编码体系。通过 LOC，ORDERS 可以进一步明确，货物是在什么地点完成交付。

看完 Header 之后，我们再来看 ORDERS 的明细行部分。

ORDERS 的明细行用于描述订单中每一项具体采购内容。每一行物料都会以 LIN 段开始，通过行号进行唯一标识。

通过 PIA 段，分别传输买方物料号和供应商物料号，用于解决双方系统物料编码不一致的问题。

IMD 段用于传递物料的文字描述，比如品名、规格或型号；

QTY 段用于描述订单中物料的订购数量。QTY 中的限定符用于说明数量的业务含义，例如12就表示订购数量。数量值本身与计量单位成对出现，用于明确数量的物理意义。这些信息组合在一起，完整地定义了一行采购明细的业务含义。

PRI 段用于描述物料的单价信息。在 PRI 中，价格字段表示的是单位价格，而后续字段则用于说明价格的计算基础，例如是按每件、每箱还是每公斤计算。通过这些字段，ORDERS 可以避免因价格口径不同而产生歧义。

在明细行中，还经常会出现 RFF 和 FTX 段。RFF 段用于传递各种参考编号，例如ON表示采购订单。FTX 段则用于传递物料说明、采购备注或其他补充文字信息。

当一行物料需要分批交付时，ORDERS 还会使用交付计划信息。

通过在行项目下重复出现的 SCC、QTY 和 DTM 段，ORDERS 可以描述每一次计划交付的数量以及对应的交货日期。

SCC+12表示Deliver to schedule（按交货计划交付），QTY+21表示 订购数量（Ordered quantity），DTM+2 表示 Delivery requested date（要求交货日期）。

这样，供应商就可以清楚地知道，同一行物料需要在不同时间点分几次交付，从而更好地安排生产和发运。

从系统设计角度来看，我们通常会将 ORDERS 报文拆分为三个层次来落地实现。

• 第一层是订单头信息，对应 ORDERSHeader，用于存储订单级的数据。
• 第二层是订单行项目，对应 ORDERSItem，用于存储每一行物料的信息。
• 第三层是交付计划，对应 ORDERSSchedule，用于存储分批交付的数据。

通过关联关系，将三层结构清晰地关联起来，既符合 EDI 规范，又方便业务系统使用。

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

以上就是 EDI ORDERS 报文的整体结构和业务含义讲解。理解 ORDERS，不只是理解字段和段的定义，更重要的是理解一张采购订单在系统之间是如何被准确、完整地表达和传递的。

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