电子数据交换（EDI）

什么是电子数据交换（EDI）？

电子数据交换（EDI）是指组织之间使用约定标准，以计算机对计算机的方式交换结构化业务文档。在物流、电子商务和国际贸易中，它可以让买方、供应商、仓库、承运商及其他贸易伙伴运营的系统交换采购订单、装运通知、运输指令和发票等信息，而无需人员重新录入每份文档。

EDI 的定义性特征并不只是以电子方式发送信息。信息会被组织成字段、段和消息，接收软件可以根据约定的规范对其进行解释。因此，将发票以 PDF 形式附加到电子邮件中，本身并不构成 EDI 发票：在业务系统能够使用其内容之前，仍可能需要人员或文档处理工具先提取内容。

EDI 描述的是一种交换业务信息的方法，而不是某种软件产品、网络或文件格式。一个可运行的安排取决于兼容的文档定义、通信方式、标识符和业务规则。

物流和电子商务中的 EDI

EDI 连接跨越组织边界的各项活动。零售商的采购系统可能生成订单，供应商的系统可能确认订单，仓库则可能收到准备货物的指令。随后，装运信息和发票可以作为独立消息在相关系统之间传递。

在电子商务中，EDI 可以支持面向消费者的店铺背后的企业对企业流程。例如，在线零售商可以使用 EDI 向供应商订购库存，或与仓库交换履约信息。消费者的结账交易和零售商随后发送的 EDI 消息属于相关的业务事件，但不一定是同一笔交易，也不一定使用相同的技术接口。

在跨境贸易中，EDI 可以承载国际运输和商业文档所需的信息。海关管理部门也可能根据自身规范使用结构化电子消息。但是，与供应商或承运商交换 EDI 消息本身并不构成海关申报，也不代表符合监管要求，或授权放行货物。

常见业务文档

以下示例说明的是文档功能，而非强制性的流程顺序。所使用的消息取决于贸易关系和适用的实施指南。

预先装运通知通常缩写为 ASN，用于描述预计的装运；它并不能证明货物已经到达。同样，装运状态消息也不会自动构成交付证明。其含义取决于所报告的事件及支持信息。

标准、格式和通信方式

EDI 标准定义业务消息的结构及其数据元素的含义。两个成熟的标准系列是 X12，以及联合国行政、商业和运输电子数据交换规则，称为 UN/EDIFACT。GS1 也维护 EDI 标准，包括基于 UN/EDIFACT 的 EANCOM 和 GS1 XML。

在 X12 中，示例包括 850 采购订单、856 装运通知/舱单和 810 发票。UN/EDIFACT 提供 ORDERS 采购订单消息、DESADV 发运通知消息和 INVOIC 发票消息。这些示例在不同标准中具有相关的业务目的，但其结构和实施要求并不通用。

单独的标准并不能定义贸易关系中的每个细节。合作伙伴还必须就适用版本和实施指南、必填字段、允许的代码、标识符及验证规则达成一致。两个组织即使支持同一标准系列，在系统能够交换可用消息之前，仍可能需要进行映射工作。

AS2 是一种通过 HTTP 交换业务数据的通信规范，并提供安全和回执机制。它不是采购订单或发票格式。增值网络（VAN）可以提供中间消息交换服务；同样，它也不同于业务文档标准。

EDI 交换的工作方式

1. 业务事件生成数据。例如，买方在企业资源规划系统或订单管理系统中批准采购订单。
2. 数据被映射为消息。转换软件将内部字段转换为约定标准和实施指南所要求的结构。
3. 检查传出消息。验证过程可能检查语法、必填字段、代码值和合作伙伴特定要求。
4. 传输消息。消息通过约定的通信渠道发送至接收方或中间方。
5. 接收方验证并转换消息。接收系统检查消息，并将已接受的信息映射到其内部应用程序格式中。
6. 进行业务处理。接收应用程序可能创建订单、记录预计收货，或将异常转交审核。
7. 对响应进行核对。技术回执、确认和业务响应帮助发送方确定交换发生了什么。

这些步骤并不能保证每笔交易都能自动处理。即使消息在结构上有效，未知的产品标识符、无效的交付地点、重复的文档编号或不支持的计量单位仍可能需要人工干预。

回执、验证和业务接受

EDI 确认在不同层级运行。传输回执可以表明消息已到达通信端点。功能确认或实施确认可以报告结构检查的结果。业务响应可以传达订单或其他请求是否被接受、拒绝或修改。

这些信号不应被视为等同。成功传输并不一定意味着订单已被接受，也不意味着货物将会发运。确认的具体含义必须根据相关规范和贸易伙伴协议进行解释。

订单到装运的示例

零售商可能通过 EDI 向海外供应商发送采购订单。供应商系统会检查产品标识符、数量和要求的交付信息。如果贸易安排包含订单响应，供应商可以通过单独的消息传达接受订单或提出变更。

货物准备好后，供应商可能发出预先装运通知，标明装运及其内容。收货仓库可以利用这些信息准备收货，并将预期数量与实际收到的货物进行比较。供应商还可能发送发票，以便在零售商的财务系统中处理。

该示例展示了 EDI 如何连接不同组织之间的记录。它并不意味着各方都使用相同的软件，也不意味着每条消息都能实时送达，或商业文档可以取代运输和海关要求。匹配采购订单、装运参考信息和发票仍需要一致的标识符和约定的业务逻辑。

EDI 与相关技术

在每种架构中，EDI 和 API 并不是相互排斥的替代方案。组织可以使用 EDI 消息进行合作伙伴交易，并使用 API 将这些交易连接到内部应用程序。适合的安排取决于文档要求、合作伙伴能力、时间需求和运营控制，而不只是取决于技术名称。

实施注意事项和局限性

当系统成功交换并处理兼容消息时，EDI 可以减少重复的人工数据录入。但它不能纠正不准确的源数据、解决商业分歧，也不能消除异常处理的需要。自动化取决于技术兼容性以及所交换业务信息的质量。

在建立 EDI 连接之前，贸易伙伴应明确以下运营事项：

• 文档范围：需要哪些消息？哪些业务事件会触发这些消息？
• 标识符：如何识别和匹配产品、地点、各方、订单和装运？
• 消息要求：适用哪些版本、必填字段、代码列表和映射规则？
• 通信和安全：需要哪种连接方式、身份验证安排和访问控制？
• 确认：哪些响应表示已送达、已验证和已被业务接受？
• 异常处理：谁负责调查被拒消息、缺失响应和不一致数据？
• 防止重复：如何将重传消息与新的业务交易区分开？
• 测试和变更控制：在变更进入生产环境之前，如何测试映射和合作伙伴要求？

运营监控应区分通信故障、数据验证故障和业务异常。重新发送消息可能解决传输失败，但无法修复无效的产品代码。如果没有重复控制，重新发送已成功处理的订单还可能创建意外的第二笔交易。

常见问题

EDI 在物流中是什么意思？

EDI 是电子数据交换的意思，即系统之间结构化交换业务文档。在物流中，这些文档可以包括装运通知、运输指令、发票和装运状态消息。

通过电子邮件发送的 PDF 是 EDI 文档吗？

仅凭这一点不是。PDF 可以以电子方式呈现业务文档，但 EDI 要求接收系统能够根据约定规范解释结构化信息。

EDI 和 API 是一回事吗？

不是。EDI 涉及标准化业务文档交换，而 API 定义软件与另一项服务交互的方式。一种集成可以同时使用两者。

EDI 确认是否意味着订单已被接受？

不一定。确认可能只是确认消息已传输或结构验证通过，而不是业务接受。消息类型和贸易伙伴协议决定其含义。

来源

• UNECE：UN/EDIFACT — 行政、商业和运输数据结构化电子交换的官方框架。
• X12：交易集 — 对业务交易集的官方说明，包括采购订单、发票、装运通知和确认。
• GS1：电子数据交换 — 业务消息标准，以及 GS1 EDI、EANCOM 和 GS1 XML 之间的关系。
• RFC 4130：使用 HTTP 的基于 MIME 的安全点对点业务数据交换，适用性声明 2 — AS2 传输、安全机制和回执通知。