第6章 电子数据交换

学习目标

1. 说明EDI的定义、核心要素和适用边界。
2. 区分EDI与传统手工单据、电子邮件、API等交换方式。
3. 描述EDI系统的组成、报文结构、标准体系和通信协议。
4. 说明EDI在供应链、零售、汽车、医疗、金融和海关等领域的典型应用。
5. 概述EDI项目实施的主要步骤。

引言

电子数据交换（EDI）是企业之间以标准格式自动交换商业文档的技术体系。它自20世纪60年代出现以来，一直是供应链、零售、制造、医疗和金融等领域的底层交易基础设施，也是许多大型零售商和制造商对供应商提出的准入条件。学习EDI，有助于理解现代供应链协同运转的信息基础，掌握企业之间机器对机器、应用对应用的自动化数据交换方式。本章从EDI的定义与价值出发，依次介绍其产生背景、与传统通讯方式的比较和应用优势；然后阐述EDI系统的三大构成要素——标准、软件与通信网络，以及点对点、增值网络和互联网三种连接方式；接着讲解报文结构与语法，包括数据元、数据段、分隔符与信封机制；再介绍ANSI X12与UN/EDIFACT两大标准体系、行业专用标准及其选择；之后剖析EDI软件的映射、翻译、通信等功能模块与选型考量，以及XML/EDI的三种架构思路；随后讨论从VAN到AS2等现代通信协议的演进；最后结合物流供应链、零售、汽车、医疗、金融与海关等典型应用场景，说明EDI项目的实施规划、安全管理和运维要点。EDI与普通电子文件传输的区别不在于是否使用计算机网络，而在于是否遵循双方约定并由标准组织认可的报文格式，以及是否由计算机应用系统直接处理。

6.1 电子数据交换概述

6.1.1 EDI的定义

电子数据交换（Electronic Data Interchange，简称EDI）是按照统一规定的标准，将商业或行政事务处理中涉及的数据，以标准化、机器可处理的结构化报文格式，在计算机与计算机之间自动交换与处理的技术体系。

EDI所交换的文档在业务上可统称为EDI报文，在ANSI X12语境中通常称为事务集（Transaction Set），包括采购订单、发票、功能确认、电子目录、询价文件、合同和金融单据等。并非所有电子化交易都是EDI。例如，信用卡刷卡和条码扫描虽然也是电子数据交换，但其数据格式通常不由标准组织定义，不属于标准EDI业务文档。

EDI的本质是机器对机器、应用对应用的自动化数据交换。其核心特征包括：

(1) 单证格式化

EDI处理的是企业间具有固定格式的商业单据，如采购订单、报价单、发票、货运单、装箱单、报关单和收据。信件、公函等非格式化文件不属于EDI的处理范畴。

(2) 报文标准化

EDI报文必须符合国际标准或行业标准。国际上最广泛使用的标准是UN/EDIFACT和ANSI X12。

(3) 处理自动化

EDI信息传递路径为：发送方业务系统、格式转换、翻译、网络传输、接收方翻译、接收方业务系统。全程由计算机系统处理。

(4) 软件结构化

EDI软件通常由用户界面模块、内部信息系统接口模块、报文生成与处理模块、标准报文格式转换模块和通信模块组成。

(5) 运作规范化

EDI报文在商业、法律和审计语境中具有明确的记录效力，但各国对电子记录的证据规则存在差异，通常需要贸易伙伴协议加以确认。

6.1.2 EDI产生的背景与演进

EDI的产生主要受以下因素推动：

1. 贸易文件数量激增：全球贸易增长带来单证数量急剧上升，纸张处理成本高、周期长。
2. 差错率居高不下：同一批数据在多个系统中反复录入，导致错误、纠纷和延误。
3. 业务处理周期过长：纸质单证的人工传递延长了供货周期、库存周期和资金周转周期。
4. 市场竞争形态转变：客户对响应速度、交货准时率和信息透明度的要求提高，企业需要更快、更准确的信息交换方式。

EDI的发展大致经历以下阶段：

表6-1 EDI发展阶段

我国EDI应用模式主要包括：

• 行业应用模式：以特定行业为载体，围绕行业流程和标准规范构建EDI网络体系。该模式通常由行业主管部门、行业协会或龙头企业牵头，统一报文格式、业务流程和节点职责，确保上下游企业能够通过共同标准进行电子单证交换。例如，海关EDI通关系统通过电子报关单、放行通知、税单处理等报文实现海关与企业、物流企业之间的自动化信息交换；国际集装箱运输EDI示范工程则将船公司、货代、港口、堆场、车队和海关等参与方连接起来，实现订舱、装箱、提箱、换单、放行等环节的信息同步。这种模式的优势在于标准较集中、业务协同程度高，适合行业内大规模重复交易场景，能够显著降低单证处理成本和流程摩擦。
• EDI中心模式：以区域性EDI服务中心为枢纽，集中提供标准转换、报文处理、通信接入、节点管理和业务监控等服务。企业无需分别与众多贸易伙伴建立多对多的点对点连接，而是只需接入中心，中心再负责向各成员单位转发和协调交易信息。广东EDI中心、上海港航EDI中心等典型案例体现了这种模式：它们通过行业专网或公共网络为成员企业提供统一的报文交换平台，支持贸易、交通、港口、仓储和金融等多类业务协同。EDI中心模式有利于降低企业接入门槛、提高网络覆盖率、强化信息安全与可信度，同时能统一实施标准版本、接口规范和服务质量管理，适合区域性、产业链型和多企业协同场景。

6.1.3 EDI与传统通讯方式的比较

传统手工方式下，贸易单证通常经过人工填单、邮寄或传真、人工录入、内部审批和回复确认，每个节点都可能出现重复录入和延误。电子邮件虽然也是电子传输，但接收者通常是人工，报文多为自由文本，难以自动进入业务系统；EDI的接收者是计算机应用系统，报文格式严格，能够直接与ERP、WMS等系统集成。EDI方式下，业务系统生成数据，翻译软件转换为标准报文，通过网络传输后由接收方系统自动处理。整个流程以分钟计。

表6-2 手工方式、电子邮件与EDI方式对比

6.1.4 EDI的优势

企业采用EDI最直接的动机是成本。纸质单据从打印、装订、邮寄到归档，每一个环节都要占用人力和场地，而人工录入又天然带有出错的可能，一旦订单数量、货号或金额录错，后续的核对、退换和索赔往往要花费远高于录入本身的成本去弥补。EDI Basics网站援引的行业数据显示，把这些单据改为电子交换后，交易成本和差错处理成本都会明显下降，这是许多企业推行EDI最先看到的收益。

成本之外，EDI带来的另一层价值体现在业务节奏上。订单从下达到确认、发货、开票、付款，原本依赖人工传递的每一步都会引入等待时间，累积起来往往是几天甚至更久的周期；换成EDI后，报文的生成、发送和接收都由系统在后台完成，处理周期可以压缩到几分钟到几小时，企业的现金流也因此更加顺畅。这种效率提升在供应链协同场景中尤为明显：准时制生产（JIT）需要供应商按精确的时间窗口交货，供应商管理库存（VMI）需要供应商实时掌握下游的库存和销售数据，电子报关、电子报税等政府对企业的业务也越来越依赖标准化的电子单证，而这些协同模式如果离开EDI提供的自动化数据交换，几乎无法在现实的业务节奏下运转。

对不少企业而言，EDI已经从一种可选的效率工具变成参与特定供应链的准入条件。大型零售商和制造商在选择供应商时，常常把是否具备EDI收发能力作为硬性要求，不具备这一能力的供应商即便产品和价格有优势，也可能因此被排除在核心供应链之外。

不过，EDI的这些收益并不是安装软件就能自动获得的，它高度依赖企业内部系统与EDI软件之间的集成程度。如果企业只是用EDI系统把报文打印出来，再由人工重新录入到自己的业务系统里，那么虽然表面上完成了电子单证的收发，实际上仍然保留了手工方式的全部弱点，录入环节该出的错误一个都不会少，前面提到的成本和效率优势自然也无从谈起。

6.2 EDI系统的构成要素

6.2.1 EDI系统的三大核心支柱

一个完整的EDI系统由标准、软件和通信网络三部分构成，如图6-1所示。

图6-1 EDI系统的三大核心支柱

EDI标准规定商业文档的表示规则，使不同企业、不同计算机平台的数据能被双方准确理解。一个合格的EDI标准需要做到语义无歧义、平台无关、应用无关、通信方式无关，只要遵循同一份标准，报文就应当能够被正确解析。EDI软件承担的是内部格式与标准EDI格式之间的双向转换工作，通常由映射软件、翻译软件和通信软件三个部分组合而成。通信网络则是EDI报文传输的通道，可以是企业间的直接连接、增值网络（VAN），也可以是互联网。需要注意的是，EDI标准本身通常并不规定通信方法，传输协议是业务伙伴之间需要另行约定的内容。

6.2.2 EDI的工作原理与流程

EDI的核心工作是把业务文件翻译成标准化的电子格式，从而实现计算机之间的自动交换与处理。这个过程可以概括为五个环节：企业内部系统（如ERP、财务系统）先生成采购订单、发票等业务文档；映射软件把内部格式转换为平面文件，翻译软件再把平面文件转换为ANSI X12或EDIFACT等标准EDI报文；报文通过VAN、AS2、SFTP等通信协议安全地发送给交易伙伴；接收方系统自动解析报文，把标准格式还原为自己的内部格式，直接导入ERP、WMS等业务系统；最后，接收方发送功能确认或业务确认报文，确保传输的完整性得到双方确认。整个过程完全由计算机系统自动触发，省去了人工录入、传真和扫描等低效环节，交易的成本、准确性和处理速度都因此得到改善。

以一次采购订单交换为例，可以更具体地理解这个流程：买方系统先生成采购数据，翻译软件将其转换为标准采购订单，比如ANSI X12的850报文或EDIFACT的ORDERS报文；报文经网络传输到卖方后，卖方的翻译软件对其进行解析，并生成功能确认予以回执；随后卖方产生订单确认，买卖双方再通过状态报告、发货通知和发票等报文继续自动交换信息；最终财务系统根据这些EDI数据自动处理应付和应收账款。整条链路虽然由系统自动触发，但这并不意味着业务决策也完全交给了机器，采购员仍然需要结合新产品发布或市场需求的变化，对系统给出的订单建议进行人工调整。

6.2.3 EDI的连接方式

企业接入EDI网络主要有三种方式，各自适应不同的业务规模和技术条件。

点对点连接方式是企业之间建立专属的通信关系，各自维护与伙伴的连接参数，适用于交易量大、伙伴数量少、技术能力较强的企业。这种方式的优点是连接直接、过程可控、时效性强，缺点是一旦贸易伙伴数量增多，需要维护的连接数量和协议参数也随之膨胀，管理复杂度会明显上升。

增值网络（VAN）方式则通过第三方运营的电子邮局进行通信。发送方把报文投递到接收方在VAN上的电子邮箱，接收方按自己的节奏定时或实时取件。VAN提供的核心服务包括电子邮箱的存储与转发、面向多个贸易伙伴的统一接入、协议转换和网络互联、传输审计和消息通知，以及数据的安全与备份。VAN通常按报文的字符数或千字节数计费，也可能附加连接时间费或月服务费；如果贸易双方使用的是不同的VAN，还可以通过VAN之间的互联完成报文交换，但这往往需要额外签订VAN服务协议。

互联网连接是近年来增长最快的方式，企业通过FTP、SFTP、FTPS、AS2、HTTP/S等协议在公共互联网上交换EDI报文。这种方式的初期投入和运营费用都比较低，代价是企业需要自行配置加密、回执和监控等安全机制，不能像使用VAN那样把这部分工作外包出去。

企业在选择时通常需要综合考虑贸易伙伴数量、交易规模和自身的IT运维能力。

表6-3 三种EDI连接方式对比

6.2.4 EDI在通信协议体系中的位置

在OSI参考模型中，EDI处于应用层，它借助TCP/IP、X.400/MHS等底层通信协议完成传输，自身专注于商业语义的标准化表达。早期的VAN大量依赖X.400系列的报文处理系统（MHS）来实现存储转发；进入互联网时代后，HTTP、HTTPS、FTP、SFTP、AS2和OFTP等协议逐渐取代了这些专有传输方式，成为EDI报文流转的主要通道。

6.3 EDI标准体系

6.3.1 ANSI X12标准

ANSI X12由美国国家标准学会（American National Standards Institute，ANSI）认可的认证标准委员会X12（ASC X12）制定，该委员会成立于1979年，其交易集结构吸收了运输数据协调委员会（TDCC）等早期标准的成果。

X12用数字代码标识每一种事务集，并采用三层信封结构对报文进行封装：最外层是交换控制层，由ISA和IEA标识发送方、接收方和控制号；中间是功能组层，由GS和GE把同类事务集打包在一起；最内层是事务集本身，由ST和SE包裹，对应一份具体的商业文档。

表中列出了物流和供应链场景中最常用的一批X12事务集。850对应采购订单，855是卖方对订单的确认回复，856即发货通知（ASN），810是发票，820用于付款指令或汇款通知，830传递计划排程信息，846报告库存状况，214反映运输承运状态，而997和999则分别是功能确认和实施确认，用于告知对方报文是否被正确接收和解析。

表6-4 常用ANSI X12事务集

6.3.2 UN/EDIFACT标准

UN/EDIFACT全称为United Nations/Electronic Data Interchange for Administration, Commerce and Transport，由联合国相关机构制定。1987年，UN/EDIFACT的语法规则获得ISO认可，成为ISO 9735标准，这也是它区别于ANSI X12的一个重要特点。UN/EDIFACT从一开始就带有国际标准的身份，而不只是某一国家的行业规范。

围绕这套语法规则，UN/EDIFACT还配套了应用语法应用指南、报文设计指南、数据元目录（EDED）、复合数据元目录（EDCD）、代码表（EDCL）、段目录（EDSD）以及标准报文格式（UNSM）等一整套文档体系。EDIFACT报文的层级结构自下而上依次是数据元、数据段、报文、功能组和交换，一份完整的交换按以下方式逐层封装：

UNB（交换头）
  UNG（功能组头，可选）
    UNH（报文头）
      ...
    UNT（报文尾）
  UNE（功能组尾，可选）
UNZ（交换尾）

在物流和贸易场景中，几种EDIFACT报文出现的频率较高：ORDERS用于传递采购订单，ORDRSP是卖方对订单的响应，DESADV对应发货通知，INVOIC是发票，REMADV传递汇款通知，CUSDEC和CUSRES分别用于海关申报和海关回执，DELFOR和DELJIT分别传递交付预测和准时制交付指令，CONTRL则是功能确认报文。

表6-5 常用EDIFACT报文

6.3.3 行业特定EDI标准

在ANSI X12和UN/EDIFACT这两套基础标准之上，不同行业组织还根据自身业务特点制定或维护了一批专用标准，它们大多是在通用标准的语法框架内进行行业化的裁剪和扩展。

零售行业最具代表性的是EANCOM，它基于UN/EDIFACT，由GS1维护，最初面向零售业设计，如今已扩展到医疗、建筑和出版等多个行业，其特点是使用EAN/GTIN和GLN对商品与参与方进行唯一标识。北美的普通商品零售业则更多使用VICS标准，这是ANSI X12的一个子集，自1988年起由GS1 US管理，并深度参与了快速响应和CPFR等供应链协同模式的发展。英国零售业则长期沿用TRADACOMS标准，它源于UN/GTDI语法，虽然该标准的开发工作基本已经停止，但英国零售EDI流量中仍有相当一部分继续运行在这套标准之上。

医疗行业受美国HIPAA法规约束，要求电子交易采用基于X12的标准格式，主要交易集包括837（医疗理赔）、835（理赔支付）、834（福利登记）、820（保费支付）、270/271（资格查询与响应）、276/277（理赔状态查询与响应）、278（医疗服务审查）和997（功能确认），零售药房的理赔则另外使用NCPDP标准。

汽车行业的标准体系呈现出明显的区域分化：ODETTE服务于欧洲汽车行业，开发了OFTP/OFTP2通信协议、MMOG/LE物流评价体系以及一批汽车专用文档；VDA则服务于德国汽车行业，为大众、奥迪、博世、大陆和戴姆勒等企业开发了30多种消息格式。此外，面向计算机、消费电子、半导体和通信行业的RosettaNet采用了基于XML的技术路线，其核心是伙伴接口流程（PIP）；金融行业则依赖SWIFT运营的银行间消息网络，通过SWIFTNet和FIN、InterAct、FileAct等传输方式，覆盖支付、贸易服务、证券和交易等业务。在企业应用层面，SAP通过IDoc类型映射DESADV、INVOIC、DELFOR等EDI消息，Oracle的EDI网关则支持POI、POAO、ASNI、INI、PYO等交易类型。

6.3.4 标准的选择

ANSI X12和UN/EDIFACT虽然功能上高度相似，但在制定机构、应用地区和技术细节上存在明显差异。X12由ANSI/ASC X12制定，主要通行于北美，属于美国国家标准体系；EDIFACT由联合国相关机构制定，在欧洲、亚洲和国际贸易中应用更广，并获得ISO 9735的国际标准地位。两者在信封结构上也不相同：X12使用ISA/IEA作为最外层信封，EDIFACT则使用UNB/UNZ；报文标识上，X12用数字代码，EDIFACT用六字母代码；分隔符的处理方式上，X12需要在ISA段中显式声明，EDIFACT则可以使用默认分隔符或通过UNA段声明；版本管理上，X12以4010、5010这样的版本号发布，EDIFACT则以D96A、D01B这样的目录版本进行管理。表6-6对这些差异进行了归纳。

表6-6 ANSI X12与UN/EDIFACT对比

除了这两套公共标准，企业之间也常常会约定一些专有格式。严格意义上，只有经标准组织认可的格式才被视为标准EDI，专有格式虽然也能完成数据交换，却需要额外的转换和维护工作，长期来看会增加系统的维护负担。1992年，ASC X12和UN/EDIFACT曾经启动过一项对齐计划，试图缩小两套标准之间的差异，但从实际发展结果看，市场最终选择了双轨并行的格局，X12在北美依然占据主导地位。在实践中，企业通常会根据贸易伙伴所在的地区和行业要求来选择标准，遇到跨标准交换的情况，则借助翻译软件完成格式转换。值得说明的是，XML/EDI和API的出现并没有取代这两套传统标准，而是作为补充手段，在特定场景下降低了实施门槛。

6.4 EDI报文结构与语法

6.4.1 基础概念

EDI报文的组织方式类似于自然语言的构词规则：从最小的信息单元开始，逐级组合成更大的结构，具体路径是数据元、数据段、循环或段组，最终构成一份完整的报文或事务集。

数据元是EDI报文中最小的信息单位，可以是简单数据元，比如一个日期、一笔金额或一个数量，也可以是复合数据元，由多个语义相关的成分组合而成，例如1:USD:4这样的表达。每一个数据元都有自己的编号、名称、格式、长度以及必选或条件的属性设定。

数据段则由一个段标识符和若干按顺序排列的数据元组成。以DTM+137:20260311:102'为例，DTM是日期/时间/期限段的标识符，137是限定符，表示这个日期的具体含义，20260311是日期本身，102则是日期的格式代码。

循环，也称段组，用来表达一对多的关系，比如一份发票中包含的多个行项目，或者一份发货通知中涉及的多个货箱，都需要用循环结构来重复表达同一类数据段。而报文或事务集则是最上层的容器，对应一份完整的商业文档，由头段、主体段和尾段共同组成。

6.4.2 分隔符与信封机制

EDI报文使用一组特殊字符来区分不同层级的数据，这些字符的作用类似于自然语言中的标点符号。以UN/EDIFACT的默认分隔符为例，冒号:用来分隔复合数据元内部的各个成分，加号+用来分隔数据元，句点.是小数点标记，问号?是释放字符，用于转义特殊字符，单引号'则用来结束一个数据段。当报文内容本身恰好包含某个分隔符字符时，就需要借助释放字符对其进行转义，例如用?+来表示字面意义上的加号，避免被误判为数据元分隔符。

信封机制是EDI报文能够被准确寻址和校验的关键。下面这段EDIFACT报文展示了一份采购订单的完整信封结构：

UNB+UNOA:3+SELLER_ID:14+BUYER_ID:14+260311:1200+000000001'
  UNH+1+ORDERS:D:96A:UN'
    BGM+220+PO-20260311-001+9'
    DTM+137:20260311:102'
    LIN+1++1234567890123:EN'
    QTY+21:100:PCE'
    PRI+AAA:25.50:CA'
    UNT+7+1'
  UNE+1+1'
UNZ+1+000000001'

同样一份采购订单，用ANSI X12格式表达则是这样：

ISA*00*          *00*          *ZZ*SELLER_ID      *ZZ*BUYER_ID       *260311*1200*^*00501*000000001*0*P*>~
  GS*PO*SELLER_ID*BUYER_ID*20260311*1200*1*X*005010~
    ST*850*0001~
      BEG*00*NE*PO-20260311-001**20260311~
      N1*BY*BUYER COMPANY*92*5412345~
      N1*SE*SUPPLIER COMPANY*92*4098765~
      PO1*1*100*EA*25.50*PE*MG*1234567890~
    SE*6*0001~
  GE*1*1~
IEA*1*000000001~

对比这两段报文，尽管具体的分隔符和段标识符不同，信封层承担的功能却是一致的：标识发送方和接收方身份、保证交换控制号在双方系统中的唯一性、校验报文包含的段数量是否正确，以及记录交换发生的日期和时间，为后续的审计留下依据。

以下是一份简化的EDIFACT商业发票报文：

UNB+UNOA:3+EXPORTER_CN:14+IMPORTER_EU:14+260311:0900+000000002'
UNH+1+INVOIC:D:96A:UN'
BGM+380+INV-2026-0088+9'
DTM+137:20260311:102'
CUX+1:USD:4'
PAT+1++95:3:D:30'
TDT+20++1+13'
LOC+5+:139:SHANGHAI'
LOC+8+:::TEPLICE'
TOD+3+CIF'
PAC+25++PF'
UNT+11+1'
UNZ+1+000000002'

逐段来看，UNB是交换头，标识了发送方和接收方；UNH是报文头，说明这是一份类型为INVOIC、版本为D96A的报文；BGM+380表明这是一份商业发票，发票号为INV-2026-0088；DTM给出的文件日期是2026年3月11日；CUX说明发票以美元计价；PAT表示付款条件为提单日期后30天；TDT显示运输方式为海运；两段LOC分别标注了发运地点上海和目的地TEPLICE；TOD+3+CIF说明交货条款为CIF；PAC则记录了包装数量为25个托盘。

6.5 EDI软件功能与模块

6.5.1 数据格式转换

EDI软件是内部业务系统与外部EDI网络之间的转换和传输桥梁，它通过映射和翻译两道工序，实现内部系统文件与标准报文之间的相互转换。发送方向和接收方向的数据流程互为镜像：发送时，ERP、WMS或OMS系统先产生内部格式文件，经映射软件转换为平面文件，再经翻译软件转换为标准EDI报文，最后交由网络传输出去；接收时，报文从网络进入，翻译软件先把标准报文还原为平面文件，映射软件再把平面文件转换为内部格式文件，最终导入接收方的ERP、WMS或OMS系统。

图6-2 EDI的数据处理流程

6.5.2 映射与转换软件

映射是建立内部数据格式与平面文件之间字段对应关系的过程，所谓平面文件，指的是采用固定宽度或分隔符分隔的中间文本格式。映射软件承担的工作包括定义字段之间的映射关系、完成数据格式转换、进行代码转换、执行必要的数学计算，以及处理条件逻辑，并且这些映射通常需要同时支持发送和接收两个方向。设置映射的根本目的是减少针对每个贸易伙伴单独定制接口程序的工作量，使系统在伙伴数量增加时依然易于维护。

6.5.3 翻译软件

翻译是把平面文件按照EDI标准语法转换成标准报文，或者反过来把标准报文解析回平面文件的过程。翻译软件内置了标准规则库，能够完成数据元格式和长度的校验、必填字段的检查、业务规则的验证，以及信封的自动生成与解析。一般来说，数据库中的原始数据应当先由映射软件转换为平面文件，再交给翻译软件处理，这种分层设计的好处是降低了映射逻辑和翻译逻辑之间的耦合，任何一方需要调整时都不会牵动另一方。

6.5.4 通信软件与接口管理

通信软件负责维护伙伴的标识和通信地址，自动完成报文的发送和接收，管理传输日志、MDN回执和功能确认，并在出现异常时自动重传或告警。EDI软件与企业内部系统的集成方式并不唯一，常见的集成路径包括：文件轮询方式，实现简单，适合批量处理场景；数据库直连方式，实时性更高，但需要更严格的访问控制；API/Web Service方式，更适合云ERP和现代应用架构；消息队列或企业服务总线（ESB）方式，则能够解耦系统之间的依赖关系，适合大型企业集成平台。

6.5.5 EDI翻译系统的内部模块

一套完整的EDI翻译系统通常由若干模块组合而成：标准库负责维护标准报文、段目录和数据元目录；代码库维护货币、国家、港口和运输方式等各类代码；翻译算法库维护具体的转换逻辑；用户与伙伴信息模块维护贸易伙伴的身份和参数；映射模块和翻译模块分别承担前面提到的映射和翻译工作；成组/分组模块负责批量信封的组装和拆分；通信模块则负责报文的实际收发。这些模块各司其职，又通过统一的标准库和代码库保持数据口径的一致。

6.5.6 EDI软件的选型考量

企业在选择EDI软件时，需要评估的因素包括标准支持的范围是否覆盖自身业务所需的报文类型、是否提供与主流ERP的预建连接器、能够管理的伙伴数量和管理能力、支持的通信协议是否满足贸易伙伴的要求、部署方式是本地部署还是云端/SaaS模式，以及软件在监控、告警、审计和合规方面的能力是否充分。对于自身IT资源有限的企业，选择EDI服务局或托管服务也是一条可行路径，但需要留意的是，如果服务局提供的报文最终仍然只是打印出来交由人工录入，而不能与企业内部系统建立有效接口，那么EDI本应带来的自动化收益就无法真正实现。

6.6 XML/EDI技术

6.6.1 XML在数据交换中的角色

XML/EDI技术要解决的核心问题，是传统EDIFACT/X12语法过于封闭、只能依赖专用翻译软件才能读写。这种封闭性把报文的开发、调试和维护工作绑定在了少数几家EDI软件商提供的专用工具上，也让新加入的中小型贸易伙伴因为搭建门槛过高而望而却步。此外，EDI专业软件和实施成本较高，语法学习曲线陡峭，标准修订和扩展的周期较长，与Web技术栈的集成也不够顺畅。XML的出现，把EDI报文的语法从一套专有的、只有翻译软件能理解的符号体系，替换成了一套通用的、几乎所有编程语言和开发工具都能原生解析的标记语言。它具有自描述、层次结构清晰、平台无关、可扩展并支持标准化校验等特性，使得报文的开发、调试和跨系统集成都变得相对容易，缩短新贸易伙伴的接入周期。

以采购订单为例，EDIFACT格式表达如下：

UNH+1+ORDERS:D:96A:UN'
BGM+220+PO-2026-001+9'
DTM+137:20260311:102'
LIN+1++1234567890:EN'
QTY+21:100:PCE'
PRI+AAA:25.50:CA'
UNT+6+1'

换成XML格式后，可读性明显提升：

<?xml version="1.0" encoding="UTF-8"?>
<PurchaseOrder>
  <MessageReference>PO-2026-001</MessageReference>
  <DocumentDate>2026-03-11</DocumentDate>
  <LineItems>
    <LineItem lineNumber="1">
      <GTIN>1234567890</GTIN>
      <OrderedQuantity unit="PCE">100</OrderedQuantity>
      <UnitPrice currency="USD">25.50</UnitPrice>
    </LineItem>
  </LineItems>
</PurchaseOrder>

XML版本即便不熟悉EDI语法的人也能大致读懂其中的字段含义，这也是它在开发调试阶段更受欢迎的原因之一。

6.6.2 XML/EDI架构设计

XML与传统EDI的结合并不是单一的技术路线，而是围绕"报文语法由谁定义、是否需要保留EDIFACT/X12"这个问题，逐步演化出三种不同的架构思路。

第一种思路是把XML作为内部的中间格式。这种思路并不改变企业对外交换的报文标准，贸易伙伴之间收发的仍然是标准的EDIFACT或X12报文，变化发生在企业内部：报文进入企业后，翻译软件先把EDIFACT/X12报文转换成结构清晰的XML文档，再用XSLT样式表把这份XML转换成企业内部系统（ERP、WMS等）所需要的具体格式；报文对外发送时，则走相反的路径，内部格式先转换成XML，再由翻译软件转换回EDIFACT/X12。这样做的好处是，内部系统的开发人员完全不需要接触EDIFACT或X12的分隔符、信封结构这些细节，只需要面对一份结构良好、语义清晰的XML，开发和维护成本因此明显降低。它的代价是企业仍然要维护一套完整的EDIFACT/X12翻译能力，因为对外交换的语法本身并没有改变，XML只是内部的过渡形式，并没有减少与贸易伙伴对接时的复杂度。

第二种思路是双方直接采用XML Schema交换。这种思路更彻底：贸易双方干脆抛开EDIFACT/X12，直接约定一份XML Schema（XSD）来定义报文结构，此后双方系统直接生成和解析符合这份Schema的XML报文，不再需要专门的EDI翻译引擎。这种方式的准入门槛较低，只要具备基本的Web开发能力就可以生成和解析XML，特别适合双方都是新建系统、不需要兼容既有EDI基础设施的场景。它的局限也很明显：每一对贸易伙伴都可能各自定义一份Schema，如果没有行业层面的协调，同一份业务语义（比如"采购订单"）在不同伙伴之间可能对应完全不同的字段结构，反而制造出新的碎片化问题，这也是第三种思路要着力解决的问题。

第三种思路是采用标准化的XML体系。为了避免上述碎片化，UN/CEFACT、OASIS等国际组织制定了一批面向B2B的标准化XML框架，其中最具代表性的是ebXML（Electronic Business using eXtensible Markup Language）。ebXML并不只是一份报文格式规范，而是一整套B2B协作基础设施：业务流程规范（BPSS）描述交易双方之间的业务流程和消息交换顺序；协作方描述文档（CPP）和协作方协议（CPA）分别描述单个企业的技术能力，以及双方达成一致的交互协议；注册与存储库（Registry/Repository）则供企业发布和查找Schema、业务流程定义等公共资源。与ebXML并行发展的还有UBL（Universal Business Language），它提供了一套开箱即用的通用商业单据XML Schema，覆盖订单、发票、收据等常见文档，不少国家的电子发票系统都以UBL为基础进行本地化扩展。

无论采用哪一种架构，具体实现都离不开两项核心的XML技术：XML Schema（XSD）负责定义报文的结构约束——哪些元素是必需的、数据类型是什么、出现次数有什么限制——并在报文接收时用来校验其是否合规；XSLT则负责完成不同格式之间的转换，无论是EDIFACT到XML、XML到内部格式，还是不同版本Schema之间的映射，都可以通过编写相应的样式表来实现，而不需要为每一种转换单独编写解析代码。三种架构思路的对比如下：

表6-7 XML/EDI架构思路对比

6.6.3 XML/EDI应用案例

某国际货运代理企业需要同时对接多家航运公司的EDIFACT系统，以及多个客户使用的XML接口。该企业的做法是建立一条XML集成总线，把内部数据统一维护为XML格式，再通过XSLT把内部数据转换为EDIFACT的IFTMIN/IFTMAN报文，并使用AS2完成安全传输。这一方案把原本分散、重复的格式适配工作集中到了一条统一的转换链路上，也让新增贸易伙伴时的对接周期明显缩短。当然，具体能缩短多少，还是要取决于企业原有系统结构和接口的复杂程度。

6.7 现代EDI通信协议

6.7.1 从VAN到互联网

20世纪80年代到90年代，绝大多数EDI流量都跑在VAN之上，VAN之下则普遍依赖X.400系列的报文处理系统（MHS）以及专线、拨号连接等相对封闭的传输通道。这套体系在当时有其合理性，彼时公共互联网尚不具备企业级的安全性和可靠性，VAN通过专有网络和存储转发机制，为贸易伙伴提供了一个相对可控、可审计的交换环境。

但VAN按报文流量或连接时间计费，企业业务规模越大，通信费用往往同比例甚至更快地增长；不同VAN运营商之间的协议、信箱格式和互联规则并不统一，企业一旦需要对接使用不同VAN的贸易伙伴，往往要额外签订互联协议、承担转接费用；X.400这类传统协议在公共互联网环境下部署复杂，也没有为后来出现的Web应用、云平台预留接口。进入20世纪90年代中后期，随着公共互联网的普及和TCP/IP、HTTP等协议的成熟，这些局限开始被视为不必要的负担，产业界开始寻找一种既能保留EDI原有安全性和可靠性、又能利用互联网降低成本的新方案，这直接催生了AS2协议的诞生。

6.7.2 AS2的普及

AS2由EDI软件厂商联合组成的Drummond Group牵头制定，2005年由IETF正式发布为标准，编号RFC 4130。它诞生的初衷十分明确：既然HTTP/HTTPS已经是一种成熟、廉价、几乎无处不在的传输协议，那么只需要在HTTP之上叠加一层S/MIME提供的加密、签名和回执机制，就足以达到VAN多年来提供的安全保障，而不必再支付高昂的VAN流量费用。

21世纪初，沃尔玛向其数以千计的贸易伙伴发出通知，要求所有供应商在规定期限内把EDI传输方式从传统VAN迁移到AS2，逾期未完成迁移将影响订单和结算的正常处理。对沃尔玛这样体量的零售商而言，VAN按流量计费的模式意味着极其庞大的年度通信支出，而AS2把这部分成本转移到了边际成本几乎为零的公共互联网上；与此同时，AS2提供的MDN回执机制也能满足沃尔玛对海量报文送达状态进行实时追踪和审计的需求。由于沃尔玛在零售供应链中的核心地位，这一要求产生了明显的连锁反应：沃尔玛的供应商为满足要求转向AS2，这些供应商的上游供应商又被进一步要求跟进，AS2由此在数年内从一份新协议迅速扩散为北美零售和消费品行业的主流传输方式，此后也逐步被汽车、医疗、物流等行业采纳。沃尔玛把AS2从一份技术规范推向真正的行业事实标准。

6.7.3 AS2的技术实现与交易流程

AS2的技术实现建立在几项成熟技术的组合之上：用HTTP或HTTPS完成实际的数据传输，用S/MIME对报文进行数字签名和加密，用MDN（Message Disposition Notification）向发送方确认报文已经被完整接收。三者结合，使AS2既具备互联网传输的低成本和高可达性，又不逊色于VAN在机密性、完整性和不可否认性上的保障水平。

一次完整的AS2交易通常按以下步骤展开：发送方业务系统先生成标准EDI报文（EDIFACT、X12或XML均可）；AS2模块对报文进行数字签名并加密，封装成S/MIME格式；随后通过HTTPS POST请求，把这个加密包发送到接收方预先公开的AS2服务地址；接收方的AS2服务器接收到请求后，先用发送方的公钥验证签名，确认报文确实来自可信的贸易伙伴且未被篡改，再用自己的私钥解密还原出原始报文，交给内部的翻译软件做进一步解析并导入业务系统；处理完成后，接收方生成MDN回执，说明报文已被成功接收（或因校验失败而拒收），这份回执可以在同一个HTTP连接中同步返回，也可以稍后异步发送；发送方收到MDN后，还会对其中的签名进行验证，确认这份回执确实出自接收方，至此整个交易才算真正闭环。

图6-3 AS2交易的完整数据传输流程

在这个流程中，MDN回执由接收方用自己的私钥签名，发送方据此可以证明对方确实收到了这份报文、且报文内容与发出时完全一致，这正是AS2具备不可否认性的技术基础。MDN分为同步和异步两种：同步MDN在同一个HTTP连接中直接返回，异步MDN则由接收方稍后单独发送。无论哪一种，MDN都应当妥善保存，作为报文传输完成和不可否认性的证据。此外，接收方的AS2服务器需要持续在线监听请求，如果企业不具备这样的运维能力，也可以委托VAN来提供AS2的接入服务。

6.7.4 AS2的应用

经过二十余年的发展，AS2已不再局限于沃尔玛这样的零售巨头，而是成为北美和欧洲零售、消费品、制造和物流行业事实上的默认EDI传输协议，绝大多数主流EDI软件和云集成平台都内置了AS2收发能力。对于长期在这些供应链体系中运作的企业而言，AS2基础设施往往是既有投资，新增贸易伙伴时，直接复用AS2连接比重新搭建VAN接入或另起一套API集成更为经济；也正因如此，即便近年来API、XML等更"现代"的技术不断涌现，AS2依然凭借其成熟的安全机制和广泛的行业基础，在传统EDI报文的传输环节保持着主流地位。

6.7.5 其他协议或方式

除了AS2，还有几种传输协议在特定行业中被广泛使用。OFTP由ODETTE开发，在欧洲汽车行业应用广泛，其后续版本OFTP2进一步支持互联网传输、加密、数字证书、压缩和大文件传输。EBICS则是德国、法国等地区企业与银行之间常用的金融报文传输协议，同样基于HTTP/HTTPS，并支持数字签名和不可否认性。

除了这些系统对系统的传输协议，还有两种面向不同参与方或不同交互模式的补充方式，同样是EDI体系向现代化演进的一部分。

Web-EDI通过浏览器表单来完成EDI报文的交换：大型采购方建立一个门户网站，规模较小的供应商登录后在表单中填写订单或发票信息，后台系统再自动把这些信息转换成标准EDI报文。这种方式的吸引力在于供应商不需要购买专门的EDI软件，便于大型企业快速接入大量IT能力有限的小型供应商。它的局限也很明显，人工录入的比例仍然较高，无法实现完全自动化，一旦业务量增大，效率就会明显受限，系统集成和管控能力也相对薄弱。因此，Web-EDI在实践中通常被当作供应商进入EDI供应链体系的一种过渡方案，而不是长期的终点。

EDI更适合处理批量的、结构化的、异步或准实时的业务文档交换，而API则更擅长实时数据查询和系统之间的即时调用。API的实现方式往往更灵活，但每当新增一个贸易伙伴、约定一套新的数据规范时，仍然需要重新进行标准化的工作，这一点和EDI并没有本质区别。因此，这两种技术之间与其说是替代关系，不如说是分工合作，企业通常用EDI处理采购订单、发票这类核心业务文档，同时用API来补充实时数据查询、库存状态同步和云ERP集成等场景。

6.8 EDI应用场景

6.8.1 现代物流与供应链

在现代物流与供应链体系中，EDI把供应商、制造商、分销商、零售商、物流服务商和海关连接在一起，支撑着采购、库存、运输和结算等一系列业务流程。准时制生产（JIT）和供应商管理库存（VMI）是EDI报文体系最典型的应用场景。在JIT模式下，制造商通过830或DELFOR报文向供应商共享生产计划，再通过862或DELJIT报文发送精确的发货指令，供应商据此通过856或DESADV报文安排到货时间；在VMI模式下，供应商则依据下游企业共享的库存和销售数据主动补货，从而减少缺货和库存积压。这两种模式如果离开EDI提供的自动化数据流转，几乎无法在现实的生产节奏下持续运转。

6.8.2 零售与电子商务

零售行业往往把EDI能力作为供应商准入的前提条件，常见的要求包括提交850采购订单、返回855订单确认、发送856提前发货通知（ASN）和810发票，并对每一份报文回复997功能确认。其中，ASN对配送中心的收货安排影响尤其直接，一份合格的ASN应当包含商品明细、包装层级、SSCC条码、承运人信息和预计到货时间，配送中心据此才能提前安排好收货计划，而不是等货物到达后再临时调度。在财务环节，零售企业普遍采用“三单吻合”的自动化对账方式：系统把采购订单、ASN和发票三份单据自动比对，只有三者一致时才会触发付款，这样既减少了人工核对的工作量，也降低了错误付款的风险。

6.8.3 汽车制造

汽车行业使用EDI已有四十多年的历史，其核心目的是支撑准时制生产和精益生产模式。这个行业的供应链结构通常分为主机厂（OEM）、一级供应商、二级供应商乃至更多层级的供应商，报文需要在这条多层级的链条上顺畅流转才能维持生产节奏。由于历史和区域的原因，汽车行业的EDI标准呈现出明显的地域特征：欧洲汽车行业普遍使用OFTP/OFTP2协议和ODETTE文档，德国企业则使用VDA制定的消息格式，北美企业更多采用基于X12的AIAG规范，而区域性的私有网络如ANX、ENX和JNX则分别为北美、欧洲和日本的汽车供应链提供专用的传输通道。

6.8.4 医疗保健

美国医疗行业的电子交易受HIPAA法规约束，必须采用统一的标准格式。837用于医疗理赔，835对应理赔支付和汇款通知，834用于福利登记，820处理保费支付，270/271完成资格查询与响应，276/277完成理赔状态的查询与响应，278用于医疗服务审查，997则是通用的功能确认。零售药房的理赔业务另外使用NCPDP标准。除了报文格式本身，医疗EDI还受到隐私规则、安全规则和违规通知规则的约束，这些法规层面的要求同样是医疗信息系统设计时必须考虑的因素。

6.8.5 金融与海关

金融服务业依靠EDI处理付款、应收应付、现金管理和证券交易等业务，常用的传输协议包括FTP、FTPS、AS2、OFTP、EBICS和FIX，常用的报文格式则包括ISO 20022、NACHA、BAI2、SWIFT和ISO 15022。在海关领域，CUSDEC、CUSRES等EDIFACT报文承担着电子报关的核心功能。一些国家已经建立起覆盖全国的贸易平台，把海关、港务和政府许可审批整合到同一个EDI网络中，新加坡的TradeNet就是这方面较早也较成熟的案例。

6.9 EDI项目实施规划

6.9.1 实施前的准备

启动一个EDI项目之前，首先是需求分析，收集贸易伙伴要求的报文类型、版本、字段和协议细节，以及上线的时间要求；其次要梳理业务流程，识别出EDI将要自动化的具体环节，并把现状流程和目标流程做对比，找出差距所在；同时还需要评估企业内部系统，判断ERP、WMS和财务系统的数据能力，以及接口需要改造的范围；在此基础上按业务重要性和贸易伙伴的要求确定各类报文的上线优先级；最后再结合企业自身情况选定实施方案。

6.9.2 实施方案选择

EDI建设实施方案，可以是自研EDI系统、采购商用EDI软件、基于开源EDI组件自行搭建，或者直接使用ERP配套的EDI模块。各实施方案对比如下：

表6-8 EDI实施方案对比

6.9.3 贸易伙伴协议与测试

在正式收发报文之前，交易双方通常要签订一份贸易伙伴协议（TPA），把双方各自的EDI标识符、报文类型和版本要求、通信协议及具体的URL、端口和证书信息、加密和签名等安全要求、测试程序和验收标准、电子报文的法律效力、数据归档期限和访问要求，以及出现错误、欺诈或赔偿责任时的争议解决方式，还有配置变更需要提前通知的时限，都明确下来。如果企业选择通过VAN接入，还需要另外审阅VAN服务协议，了解其服务范围、责任划分、安全措施、数据保存期限和终止条件。协议签订之后，双方还需要经过连通性测试、测试报文发送、功能性测试和合规性认证这几个环节，逐步验证报文能够被正确生成、传输和解析，才能正式切换到生产环境。

6.9.4 安全与证书管理

EDI的安全防护需要覆盖传输、处理和存储三个阶段。在传输环节，加密可以防止报文被未授权方读取，数字签名用来验证发送方身份并确认报文完整性，MDN或功能确认则为报文送达提供证据；这一切都建立在完善的密钥管理之上，涵盖密钥的生成、存储、交换、归档和销毁，同时还需要通过CA或X.509证书目录来验证公钥的真实性。

6.9.5 EDI运维管理

EDI系统正式上线并不意味着工作的结束，后续的运维同样需要持续投入：实时监控传输状态并对异常及时告警，检查是否存在迟迟未收到MDN或功能确认的报文，对报文进行完整归档并定期审计，维护标准版本和伙伴版本的台账，跟踪证书有效期和通信参数的变更情况，并及时响应贸易伙伴提出的查询和问题。

本章小结

EDI是企业间以标准格式自动交换业务文档的技术体系，其价值来自标准化格式、计算机自动处理和内部系统集成三者的结合，其核心特征体现为单证格式化、报文标准化、处理自动化、软件结构化和运作规范化。EDI系统由标准、软件和通信网络三大要素构成，报文则以数据元、数据段、报文和信封逐级组织。在标准体系中，ANSI X12和UN/EDIFACT是两大基础标准，各行业又在此基础上衍生出HIPAA、ODETTE、VDA、RosettaNet、SWIFT等专用规范；XML/EDI则借助XML Schema和XSLT降低了报文开发与集成的门槛。在传输层面，VAN曾长期占据主导地位，AS2凭借数字签名、加密与MDN回执机制，在互联网上实现了低成本且不可否认的报文传输，已成为零售、制造等行业的主流协议，Web-EDI和API则是面向不同场景的补充方式。在应用层面，EDI支撑着JIT准时制生产、VMI供应商管理库存等供应链协同模式，以及零售业基于提前发货通知和三单吻合的自动化对账。EDI的实施不只是安装一套软件，企业需要在自研系统、商用软件等方案之间做出选择，并完成贸易伙伴协议、上线测试、安全证书管理和长期运维等一系列工作。

课后习题

1. 简述EDI的定义，并说明EDI与电子邮件的本质区别。
2. 为什么信用卡刷卡和条码扫描通常不被视为标准EDI交易？
3. 绘制一次采购订单EDI交换的数据流，并标出映射软件、翻译软件和通信软件的作用。
4. 以EDIFACT发票报文为例，解释数据元、数据段、报文头和信封的作用。
5. 说明VAN、点对点直接连接和互联网直接连接各自的适用场景。
6. 结合JIT或VMI案例，分析EDI在供应链协同中的作用。
7. 企业在EDI实施方案选择时，应重点评估哪些因素？

参考文献

[1] Stultz R A. Demystifying EDI: A Practical Guide to Electronic Data Interchange Implementation, Transactions, and Systems[M]. Plano: Wordware Publishing, 2001.

[2] EDI Basics. EDI professional tutorial and related pages[EB/OL]. https://www.edibasics.com/

[3] IETF. RFC 4130: MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)[S]. 2005.

[4] UN/CEFACT. UN/EDIFACT Syntax Rules (ISO 9735) and related standards[S].

[5] ANSI ASC X12. Transaction set standards and implementation guides[S].

[6] OASIS. AS4 Profile of ebXML Messaging Service 3.0[S].

[7] U.S. Department of Health and Human Services. HIPAA Administrative Simplification Standards (45 CFR Parts 160 and 162)[S].