在跨国供应链里，一笔订单从下达到交付，往往要经过采购方、供应商、承运商、仓储服务商、财务系统等多个环节。
问题随之出现：各方使用不同的ERP、WMS或TMS系统，但订单编号、物料、数量、交付日期和结算金额等关键信息，必须在传递过程中保持一致。
如何让这些来自不同国家、不同企业和不同系统的数据，按照统一的业务含义被识别和处理？这正是EDI（电子数据交换）标准解决的问题。
在众多EDI标准中，UN/EDIFACT凭借国际化的标准体系和丰富的业务消息，长期应用于制造、零售、物流、海关及国际贸易等领域。
UN/EDIFACT（以下简称EDIFACT）的全称是United Nations Rules for Electronic Data Interchange for Administration, Commerce and Transport，中文通常译为“联合国行政、商业和运输电子数据交换规则”。它由联合国欧洲经济委员会框架下的联合国贸易便利化与电子业务中心（UN/CEFACT）制定和维护，其应用级语法规则对应ISO 9735系列标准。
EDIFACT是一套由语法规则、消息目录、服务段、业务段、复合数据元、简单数据元和代码表共同组成的标准体系。企业可以使用不同的EDIFACT消息，分别表达采购订单、订单响应、发货通知、电子发票、运输指示等业务单据。
借助这套标准，不同企业的业务系统无需采用相同的数据结构，也能够完成数据交换和自动处理。
EDIFACT如何组织一份报文
EDIFACT报文具有明确的语法边界和封装层级。除了交换、消息、段和数据元之外，它还通过复合数据元和限定符表达具体业务含义。以下是一段经过简化的ORDERS采购订单报文：为方便展示，示例将不同段分别换行。实际传输的EDIFACT报文不一定包含这些换行符。- 服务字符定义：服务字符的约定决定了解析器如何拆分报文内容。报文开头的
UNA是可选的服务字符串通知，用于声明复合数据元分隔符、数据元分隔符、小数标记、释放字符、保留字符和段终止符等服务字符。在上述示例中，+用于分隔数据元，:用于分隔复合数据元中的成分，'表示一个段结束，?用于释放紧随其后的特殊字符，?之后的空格则为保留字符。
- 交换与消息边界：
UNB/UNZ构成一次数据交换的外层边界，记录语法标识、发送方、接收方、生成时间和交换控制参考号等信息。一份交换中可以包含一条或多条业务消息，每条消息再由UNH/UNT标识开始和结束。根据实际约定，交换中还可以使用UNG/UNE对同类消息进行功能分组。 - 业务段与限定符：EDIFACT中的段通常承担一类通用功能，段内的限定符则进一步说明数据用途。例如，
NAD段用于表示业务参与方，NAD+BY中的BY表示买方，NAD+SU中的SU表示供应商；QTY+21中的21表示订购数量。只有结合段名和限定符，才能完整理解数据的业务语义。 - 复合数据元结构：复合数据元由多个成分数据元组成，各成分之间通过
:分隔。以DTM+137:20260713:102'为例，137用于说明日期的业务含义，20260713为日期值，102表示日期格式为CCYYMMDD。这种结构使EDIFACT能够在较为紧凑的报文中表达多层信息。 - 消息目录标识：
UNH段中的ORDERS:D:96A:UN说明该消息为ORDERS采购订单，并采用D.96A目录定义。D.96A、D.01B等目录版本可能采用不同的段结构、数据元和代码值，因此交易双方除了确认消息类型，还需要明确所使用的目录版本。由此看出，EDIFACT报文不仅依靠段和数据元的位置关系组织数据，还通过语法层级、限定符和代码值共同构建业务含义。
EDIFACT如何连接上下游业务单据
在企业应用中，各类EDIFACT消息通常不会孤立存在，而是围绕同一笔业务形成连续的数据链路。以采购订单履约为例，从订单下达到收货结算，可以由多种标准消息共同完成。
订单下达与确认（ORDERS & ORDRSP）
买方通过ORDERS采购订单消息向供应商发送订单号、物料、数量、价格、交付地点和交期等信息。供应商完成库存、价格及交期校验后，可以通过ORDRSP订单响应消息反馈接受、修改或拒绝等处理结果。相比普通技术回执，ORDRSP表达的是供应商对订单的业务处理意见。
发货与收货协同（DESADV & RECADV）
供应商完成备货并安排出库后，可以通过DESADV发货通知消息提前发送交货单号、包装层级、物料明细、发货数量和预计到货信息。买方完成收货或验收后，再通过RECADV收货通知消息反馈实收数量及收货差异，为库存更新和后续对账提供依据。
开票与核销处理（INVOIC & REMADV）
供应商可以通过INVOIC发票消息发送开票方、收票方、税额、金额、币种和付款条件等数据。买方财务系统收到后，可以将发票与采购订单、收货记录进行自动匹配。REMADV汇款通知消息则用于说明付款与发票或贷项之间的核销关系，但并不等同于银行已经实际执行付款。
运输过程协同（IFTMIN & IFTSTA）
在物流环节，货主或相关业务方可以通过IFTMIN运输指示消息下达运输任务，传递托运方、承运方、起运地、目的地及货物要求等信息。运输过程中，IFTSTA运输状态消息可以用于同步提货、在途、延误、到达和交付等状态。这些消息连接采购、交付、物流和财务信息，使企业能够以业务单据为主线，建立端到端的自动化流程。不同系统能够根据报文中的标准语义，自动完成单据创建、状态更新和后续处理。
EDIFACT项目实施的关键基础
EDIFACT提供了较为完整的标准框架，同时也为不同行业和业务场景保留了较大的选用空间。因此，企业在实施过程中，还需要将通用标准进一步转化为交易双方能够共同执行的伙伴规范。
目录版本与消息规范
项目通常需要形成明确的消息实施指南，规定必填项、可选项、重复次数和业务校验规则。交易双方需要明确使用哪个EDIFACT目录版本，以及具体采用哪些段、数据元和代码值。即使使用相同的ORDERS消息，如果目录版本或字段约束不同，报文仍可能无法兼容。
行业子集与伙伴要求
不同行业可能基于EDIFACT形成更具体的实施规范。例如，EANCOM是零售和消费品领域常见的EDIFACT子集。部分大型企业也会发布自己的EDI规范，在标准目录基础上增加业务约束。因此，企业接入新伙伴时，应以双方确认的实施指南为依据开发。
限定符与代码表管理
EDIFACT广泛使用限定符和标准代码表示参与方角色、日期类型、数量类型、计量单位和币种等信息。相同的数据值在不同限定符下可能具有不同含义。因此，代码值校验和内部代码转换是报文实施中的重要环节。
字符集与服务字符约定
UNB中的语法标识用于说明报文采用的字符集及语法版本，UNA则可以定义服务字符。如果交易双方对字符编码、分隔符、小数标记或释放字符的处理方式不一致，可能导致报文被错误拆分或出现乱码。
主数据口径一致性
物料编号、合作伙伴编号、地点代码和计量单位等数据，通常需要在双方系统之间建立映射关系。很多报文能够通过语法校验，却无法进入业务系统，原因往往在于主数据无法识别或业务代码不匹配。多种工具沉淀连接能力## 现实中，企业每个业务部门会陆续提出自己的智能体需求。如果每个Agent都单独对接核心系统，单独处理权限，单独封装接口，后面一定会重复建设。
EDIFACT集成的关键环节
在企业内部，EDIFACT报文需要经过接收、校验、转换和业务投递等多个环节，最终与ERP、WMS、OMS、TMS或财务系统形成完整集成。
- 接入与预处理：EDI系统接收到报文后，需要识别交易伙伴、传输通道、字符集和服务字符，并保留未经修改的原始报文。原始数据是后续问题排查、重新处理和合规审计的重要依据。
- 多层规则校验：报文校验通常包括交换结构校验、EDIFACT语法校验、消息目录校验、实施指南校验和业务规则校验。系统既需要检查
UNH/UNT是否匹配、段计数是否正确，也需要判断订单物料、币种和交付地点是否符合内部业务要求。 - 语义映射与数据转换：EDIFACT报文与企业内部数据模型之间通常并非简单的一一对应。转换过程中可能涉及代码映射、单位换算、默认值补充、条件判断、税额处理以及明细和包装层级转换。映射规则需要与报文模板和业务规则统一维护。
- 业务投递与幂等控制：完成转换后，EDI平台需要将数据可靠地写入目标业务系统。同时，应结合交换控制参考号、消息参考号和业务单据号建立幂等机制，避免报文因网络重试或重复发送而在ERP中生成重复单据。
- 回执与状态追踪：
CONTRL消息主要用于报告交换或消息在语法及服务层面的处理结果，APERAK可用于反馈应用层错误或确认。技术回执并不必然表示订单、发票等业务已经被接受，因此还需要结合ORDRSP等业务响应消息建立分层状态管理。 - 异常处理与重新执行：对于无法自动处理的报文，系统需要准确记录异常所处的环节，并根据实际处理机制进行告警、问题修正和重新投递，避免单个错误影响后续消息或整个业务批次。
