交易伙伴提到EDI应该如何应对？

经常有国内客户咨询小知：“我们国外的客户最近开始通知我们要做EDI，可是EDI是什么，我们要怎么做，这完全没有头绪呀”。不要慌，今天在小知课堂上，小知就为你梳理梳理，一一道来。

首先，要做EDI，我们得先知道，EDI到底是什么。

EDI，全称Electronic Data Interchange，又称为电子数据交换，是在国际上流行的一种数据交换方式，供应商、零售商、制造商和客户等在其各自的业务系统之间通过技术实现自动交换和处理商业文档的过程中，使用的技术就叫做EDI。既然是数据交换，那么要交换哪种数据呢？事实上，通过EDI可以做任何数据的交换，比如供应链的采购订单，发货通知，发票，库存等信息，以及第三方物流运输状态更新，还有医药行业病例报告的提交等等。

EDI覆盖的行业多种多样，无论是汽车行业，零售行业，电子行业，医疗行业，金融行业还是保险行业等，都能够使用EDI。

1. EDI标准

为了实现各公司计算机系统间传递贸易单据，必须保证这种贸易单据具有标准格式并能够为各公司的计算机所识别。正如语言在人类交流中的媒介作用一样，EDI标准是实施EDI必不可少的，它是计算机系统之间的语言。作为EDI标准，应达到以下目的：

（1） 提供一种任何贸易伙伴都可使用的语句，这种语句是无歧义的，可以使使用者明白其含义的；　　
（2） 这种标准不受计算机机型影响，既适用于计算机间的数据交换，同时又独立于计算机之外。　　
（3） EDI传递的贸易单据是电子单据，目的是为了以电子手段完成传统贸易单据的传递，从而加速单据的周转，缩短贸易进程。

目前常用的EDI标准包括：

• ANSI X12标准，常用于北美地区

• EDIFACT标准，常用于欧洲

• VDA标准，常用于德国汽车行业

此外，还有一些不常见的标准，例如ODETTE，RosettaNet等，小知在这里就不一一说明了。

2. EDI报文

所有符合EDI标准的数据格式，我们称之为EDI报文。

每一个EDI报文都与一种或一类的贸易单据相对应，例如采购订单，对应的X12标准报文是850，对应的EDIFACT标准报文是ORDERS；而发货通知，对应的X12标准报文是856，对应的EDIFACT标准报文是DESADV。

以采购订单为例，小知给大家展示一下EDI报文的实际格式：

X12标准-850采购订单：

EDIFACT标准-ORDERS采购订单：

由以上示例EDI报文我们可见，EDI报文可读性很低，除非EDI专业人员，不然很难看得懂里面传递的业务信息。我们收到了贸易伙伴发来的EDI报文，但是业务人员看不懂，这可怎么办？别急别急，接着往下看，小知要开始画重点了。

3. EDI系统的功能

EDI系统功能主要分为三大功能模块，分别是数据传输模块，报文翻译模块和业务系统集成模块。

3.1 数据传输模块

顾名思义，数据传输模块的功能就是实现数据传输，也就是要和贸易合作伙伴通过Internet网络建立数据通道，使得相互之间的业务数据能够通过数据通道进行传输。说到这里，一定有同学会有疑问，我们经常和国外客户通过邮件发送业务数据，难道这样不行吗。 答案当然是不行的。要知道，在邮件传输数据的过程中，所有的业务信息都是明文在网络上传播的，这就是说，只要有人想，他随时都可以拿到发送的所有数据，尤其是一些数据涉及到企业敏感信息，例如金额，物料，数量等，如果这些数据不慎泄露，或被竞争对手知晓，可能会对企业造成不可弥补的损失。此外，使用电子邮件传送文件还存在很多弊端，在这里我们就不一一赘述了，有兴趣的同学可以点击什么！你还在用电子邮件传订单？详细了解。

而EDI的数据传输和我们日常普通的邮件传输区别还是很大的。EDI传输要使用传输协议，在做数据传输之前，双方要互相交换自己的配置信息和证书，例如ID，证书，IP等。然后在我们的EDI系统中配置贸易合作伙伴的信息，而贸易合作伙伴需要在他们的EDI系统中配置我们的信息，这样才能在双方的服务器上建立一个点对点的数据通道，并且在数据传输的过程中会使用证书对数据进行签名加密处理，以保证数据的安全性。通俗来讲，这就相当于在你家和我家之间挖了一个隧道，这个隧道只能从你家到我家，并且除了隧道之外，我们双方还有一个约定好的口令（这个口令就是证书），这个口令只有你我知晓，如果有人从这个隧道来我家，并且我验证口令正确，就说明是这个人是你，我就会让你进入我家。这样来说，有没有觉得EDI数据传输安全很多呢？

EDI数据传输除了安全性有保证之外，还有许多其他普通传输没有的功能，比如断点续传，就是在传输过程中，如果因为网络或是其他原因导致传输中断，下次连接成功时会从接着上次的传输继续发送数据，避免已发送数据重复发送。再比如回执确认，在使用EDI传输协议进行数据传输时，我们发出文件后，如果对方系统收到了我们发出的文件，会自动的给我们回复一个回执，这样我们就能确认对方收到了这个文件，这个回执可以作为对方收到文件的证明，同样的，对方给我们发送文件也会收到我们的回执，这样就能避免以后出现问题后相互扯皮的情况发生。

目前EDI数据传输中常见的传输协议有以下几种：

• AS2传输协议
• OFTP2传输协议
• SFTP传输协议

如果贸易伙伴这些传输协议都支持，小知建议优先选择AS2传输协议。因为OFTP2传输协议合作伙伴可能会有其他要求，比如使用第三方机构认证授权的证书(Odette证书)和OFTP ID（Odette ID），这可能会产生额外的费用，所以从节约成本的角度来看，小知更建议使用AS2传输协议。

更多关于传输协议技术信息可参考： EDI传输协议列表

3.2 报文翻译模块

在上文中我们留了一个思考问题，EDI报文的可读性太低，业务人员看不懂怎么办？现在小知要揭晓答案啦！

答案就是：既然原始EDI报文看不懂，那就翻译成大家都能看懂的格式呀！

一定有同学说，说的容易，谁来翻译呀？（小知默默的举起了手）

说回正题，报文翻译确实是EDI处理过程中很重要的一环，EDI报文有各种标准，而且涉及到许多业务数据，企业不可能让所有业务人员花费太多时间去学习EDI的各种专业知识，所以，就需要让专业的人（小知顾问）来做专业的事情（EDI）了。报文翻译就是把原始EDI报文按照企业要求翻译为可读性较高的格式，例如XML，Excel，CSV，Flatfile等，也可以将指定格式的文件翻译为EDI报文。

至于具体想要翻译成哪种格式，这个就看企业自身需求了。

我们在上文提到，EDI报文都符合国际EDI标准，每种业务报文中包含的信息量一定是非常大的，所以各个企业都会根据自己的实际业务，整合出EDI报文对应的商业文档，这种文档，我们称之为EDI规范。 一般情况下，每个企业都会有自己的EDI规范。不过由于国外EDI已经发展的较为完善了，而我们国内才开始普及EDI，所以一般和国外客户做EDI对接的话，都是由国外客户提供EDI规范。 另外一种情况是，如果两个企业要做EDI连接，并且双方都有自己的EDI规范的情况下，一般是使用比较强势一方的EDI规范。

报文翻译就是基于EDI规范的，在EDI规范中，会给出报文中节点位置和业务数据的对应关系，例如850报文中，PO1节点的第一个位置表示订单行号，第二个位置表示采购订单编号等。在EDI实施顾问做报文翻译的过程中，就会参考EDI规范建立映射关系。

3.3 业务系统集成模块

在做完EDI报文翻译后，有些企业客户可能还会有更进一步的需求，比如：“我想让我的业务系统和EDI系统集成起来，这样我通过EDI收到的业务数据就能直接进入我们的业务系统中”。 没错，有这种想法的同学就需要使用EDI系统的业务系统集成模块了。业务系统集成，就是通过某种形式，打通EDI系统和业务系统之间的数据通道，使得两个系统中的数据能够相互传输。EDI系统收到贸易伙伴的业务数据，经过翻译后能够进入业务系统，业务人员直接在业务系统中操作处理，处理完成后，业务系统的数据也能够回传给EDI系统，经过EDI系统翻译为EDI报文，再回传给贸易合作伙伴。

事实上，一个完整的EDI系统就应该是这样的，小知也是非常推荐这种做法。在和业务系统集成的情况下，才能最大体现出来EDI的优势：

• 缩短处理时间：短时间大批量处理业务数据，缩短每文件处理周期
• 提高数据精准性：数据精准抵达客户，内容完整无篡改
• 减少人工误差：自动化EDI取代手动上传，降低人工录入误差
• 节省业务成本：提高供应链效率，减少人力成本
• 增大双方利润：减少库存积压，提高业务利润率
• 促进客户关系：系统回执明确业务进程，避免扯皮纠纷

知行EDI系统支持集成金蝶、用友，SAP，INFO等多种常见的业务系统，集成方案也是多种多样的，小知稍后在“方案选择”中会做详细介绍。

4. 方案选择

在上文中，同学们应该已经对EDI系统有了大概的了解，那么在实施EDI系统的过程中，应该怎么挑选适合自己企业的实施方案呢？

4.1 无需集成业务系统的方案：

• Excel方案，实现方式：将EDI收到的贸易伙伴的数据翻为Excel格式，发送到指定邮箱。再从指定邮箱中读取到需要回传的Excel文件，翻译为EDI报文，通过EDI传输给贸易伙伴。需要注意的是，Excel回传需要业务手动填写，若业务数据较多，可能会导致工作量增加。所以Excel方案适合业务量不大，并且没有自己业务系统的中小型企业。（CSV方案同Excel方案）

• LIP方案，实现方式：LIP是小知自家研发的一款小型业务系统，提供了可视化操作界面，业务人员可以直接在界面上查看和维护业务数据，也可以看到以往处理过的业务数据。该方案适用于业务数据量较多，并且没有自己业务系统的中小型企业，也可以作为大型企业集成自己ERP系统之前的过渡方案。

4.2 集成业务系统的方案：

• 数据库中间表方案，实现方式：EDI将收到的业务数据写入数据库中间表中，业务系统从中间表中读取数据并处理，处理完成后，将要回传的数据再写入中间表中，EDI定时轮询并将数据发出。知行EDI系统支持sqlserver, mysql, oracle, sqlite等多种数据源，只需要简单的界面配置即可连接到数据库并从指定表读写数据。所以数据库中间表方案是多数企业客户的选择。

• webservice方案：实现方式：通过http调用webservice get和post业务数据。需要企业提供调用接口。

• IDOC方案，实现方式：根据客户提供的IDOC Schema，EDI将收到的数据翻译成IDOC格式，通过知行系统IDOC端口直接和SAP系统连接，将IDOC文件数据直接写入SAP系统中；SAP系统通过IDOC端口导出IDOC文件，EDI将IDOC文件翻译为EDI报文，回传给贸易伙伴。该方案适用于SAP业务系统。

• XML方案，实现方式：EDI将收到的数据翻译为指定XML格式，交给业务系统处理；处理完成后，将回传XML文件，EDI将XML翻译为EDI报文，回传给贸易伙伴。

以上都是常见的实施方案，如果其他实施要求或是方案，可以按照底部的联系方式联系小知噢~

听到这里，还有同学提问了：那我们和贸易合作伙伴的EDI系统是不是得是一样的？

EDI系统供应商有很多，相应的，也存在多种不同的EDI系统，不同的EDI系统在功能上几乎没有区别，只是在一些细节的实现会有些微差异。不同的EDI系统之间是可以相互通信的，这个大家不用担心。所以无论我们的EDI系统和贸易合作伙伴的EDI系统是否一致，只要是EDI系统，都是可以做EDI连接的。

5. 总结重点

到这里，我们本节课的内容就讲完了，接下来小知为大家整理一下本节课的知识点，大家可以关注下，在做EDI之前，我们都需要知道什么~

5.1 上EDI需要先了解哪些？

• 要使用哪种EDI传输协议，例如：OFTP，AS2等
• 贸易合作伙伴是否给我们提供了相应的配置信息
• 贸易合作伙伴是否提供了EDI规范
• 要使用哪种EDI报文标准，例如：X12，EDIFACT等
• 需要传输哪些业务数据，例如：采购订单，发货通知，发票等

5.2 我们需要做什么准备？

• 一台具有固定公网IP的服务器，最好有域名
• 联系小知沟通需求，确定解决方案
• 一套稳定的EDI系统和一支专业的EDI团队:-)

好了，今天的小知课堂到这里就结束了，不知道本节课对于大家了解EDI有没有什么帮助呢。如果同学们还有什么疑问的话，欢迎按照最下方的联系方式联系小知~

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