是什么让EDI如此困难？

EDI全称电子数据交换，是用于交换B2B交易的许多不同“标准化”框架的总称。它的历史可以追溯到 1960 年代，从供应链和物流到医疗保健和金融，仍然是每个商业行业的痛点。是什么让它如此困难？为什么尽管经过数十年的大量使用，它仍然是一个未解决的问题？

这些是我们最常从开发人员那里得到的问题 – 无论是希望成为知行客户的开发人员，还是希望加入我们，共同构建知行EDI的开发人员。这些也是我们最喜欢回答的问题——EDI的世界是复杂、不透明和神秘的，但它也非常强大，支撑着世界经济的庞大领域。

问题在于，没有任何好的、以开发人员为中心的资源可以帮助从头开始理解EDI。其结果是，这个奇妙丰富的生态系统被锁定在更广泛的技术世界中正在发生的彻底变化之外。

我们有幸将许多人从零提升到了解整个EDI版图如何组合在一起的扎实工作知识。它有助于从最高级别开始，并随着您的发展变得越来越具体；您现在正在阅读的这篇文章是我们的工程师加入我们的团队时阅读的第一篇文章——对广阔EDI世界的一种定位，我们决定将其公开发布以帮助其他人加速了解EDI。

贸易

在最基本的层面上，地球上有成千上万的企业；这些企业为最终消费者提供各种商品和服务。由于很少有企业拥有完全自给自足的资源或愿望，因此它们必须在彼此之间交换商品和服务才能交付成品。这种机制被称为贸易。

当两家企业希望进行交易时，他们必须交换某些商业文件或交易，其中包含开展手头业务所需的信息。对于各种情况，有数百种可以想象的交易类型;有些在许多行业中很常见，例如采购订单和发票，有些特定于一类业务，例如装载招标或提单，它们仅与物流有关。

企业过去常常交换纸质交易并将这些交易记录到被称为分类账的手写簿中（这就是为什么我们将会计称为“账簿”，而使用会计系统的人称为“簿记员”），但现代企业使用一个或多个软件应用程序，称为业务系统，以促进运营。有许多类型的业务系统，从Oracle，SAP和NetSuite等通用软件套件到服务于某些特定行业的垂直特定产品，例如医疗保健，农业或教育专用系统。

每个业务系统使用不同的内部事务格式，这使得无法将事务从一个业务系统直接导入另一个业务系统;即使两家公司都使用完全相同的SAP版本（例如SAP ERP 6.0），一连串的配置和自定义选项（每个选项都会影响系统的事务格式）使得直接互操作性的可能性变得很低。这些情况要求在将数据从一种格式转换为另一种格式之前，然后再引入新系统。

数据转换

最流行的数据转换方法是人工数据输入。客户 A 在 NetSuite（其业务系统）中创建采购订单 n，并将采购订单 n 的 PDF 通过电子邮件发送给供应商 B。供应商 B 雇用的文员将采购订单 n 中的数据输入 SAP（其业务系统）。店员根据需要将数据从一种格式“映射”到另一种格式 – 例如，如果客户 A 的 PDF 包含名为“PO 编号”的字段，而供应商 B 的业务系统需要名为“采购订单”的字段。

人们很聪明——你可以把一个人想象成人工智能，这种方式确实有效，并且能够在几乎没有训练的情况下即时处理这些映射。但是，手动数据输入成本高昂、容易出错，并且在大量数据下不切实际，因此企业通常选择采用某种事务自动化或贸易合作伙伴集成方法，以便以编程方式引入事务并避免手动数据输入。

由于每个企业都有多个贸易伙伴，并且其每个贸易伙伴在不同的业务系统上运营，因此这些交易的“点对点”集成（即将沃尔玛的内部数据库格式直接映射到QuickBooks JSON API）将需要接收者详细了解许多不同的交易格式。

例如一家公司向在NetSuite上运行的三个客户销售产品，SAP和QuickBooks分别需要理解NetSuite XML，SAP IDoc和QuickBooks JSON。保持对如此多系统的熟悉是不切实际的；为了避免这种复杂性需求的爆炸式增长，企业转而使用普遍接受的中间格式，这些格式被广泛称为电子数据交换—— EDI。

EDI

EDI是用于交换B2B交易的许多不同“标准化”框架的总称，但它通常与两个最流行的标准同义使用——主要在北美使用的X12和在整个欧洲流行的EDIFACT。重要的是要注意，EDI并非旨在解决B2B交易交换的所有问题；相反，它旨在仅消除贸易合作伙伴能够理解其每个贸易合作伙伴的内部语法和词汇的不切实际的要求。

企业不必使用许多不同的语法（例如，JSON，XML，CSV）和词汇表（例如，PO编号和采购订单），像X12和EDIFACT这样的框架提供了高度结构化的，高度成熟的替代方案，旨在减少成功与贸易伙伴集成所需的知识量。符合给定标准的所有文档都遵循该标准的语法，允许该标准的采用者对也采用该语法的所有贸易合作伙伴仅使用一种语法。

此外，这些标准致力于在可能的情况下减少词汇和字段位置的变化。例如，X12 标准有一个元素类型 92，它枚举采购订单类型代码；枚举值 Dropship 反映了 X12 的观点，即可能被通俗地称为 Drop Ship、Drop Shipment 或 Dropship 都将被引用为 Dropship，这限制了接收方可能必须考虑的词汇量。同样，X12 已将 850 采购订单的 BEG03 元素（即 850 采购订单事务集中 BEG 段的第三个位置提供的值）指定为采购订单编号的正确位置。这减轻了将事务映射到接收方的业务系统或将其映射出的一些负担;只需映射一个用于直接运输的值和一个用于采购订单编号的位置。

当然，绝大多数领域都无法标准化到这种程度。以采购订单上行项目的产品标识符为例，虽然 X12 指定应使用 850 采购订单的 PO107 元素来指定产品标识符值，但该标准不可能强制要求应使用哪种类型的产品标识符。一些公司使用 SKU（库存单位），而其他公司则使用零件号、UPC（通用产品代码）或 GTIN（全球贸易项目编号）；总而言之，X12 标准指定了一个包含 544 个不同可能的产品标识符值的字典，这些值可以填充到元素PO106中。

关于标准的问题

我们在这里看到的是，虽然标准可以对文档的结构和字段的命名进行规定，但不能对业务交易的内容有太死板的规定——商业交易的内容是由业务本身的特性决定的。如果标准没有提供足够的灵活性来解释给定业务的细节，企业将选择不加入该标准。因此，像 X12 这样的标准并没有提供交易的过于死板的定义——它提供了所有可能的商业价值的结构化集合。

中间格式（即EDI）通过限制企业必须了解的不同格式的数量，以便与广泛的贸易伙伴合作，使生活更加轻松；向数十家美国零售商销售的美国品牌可能只需要使用 X12 格式。但是，该品牌仍然需要考虑每个零售商使用 X12 的不同方式。同样，X12 只是一个可能值的字典——由于沃尔玛和亚马逊以不同的方式（以及在不同的业务系统上）运营他们的业务，他们对 X12 中间格式的实现也会有所不同。

一个简单的例子可能是，沃尔玛允许客户在订单级别包含礼品信息（“生日快乐 – 圣诞快乐！”），而亚马逊允许其客户在行项目级别指定礼品信息（行项目#1中的“生日快乐！”，行项目#2中的“圣诞快乐！”）。礼品信息实施的这种差异意味着，同时向亚马逊和沃尔玛销售的品牌在将各自的字段“映射”到其业务系统时需要考虑这些差异。

每个贸易伙伴的这种细微差别是无法避免的——因为不同的业务以不同的方式运作，一个单一的、规范的、固执己见的表示，比如采购订单，不太可能存在。换句话说，每个贸易伙伴的设置过程是由固有的复杂性驱动的，也就是说，手头问题的不可避免的情况所需要的复杂性。而且由于诸如此类的字段映射会影响现实世界的交易，因此无法使用概率机器学习方法完成它们；例如，将“发件人地址”映射到“运输地址”将导致订单被运送到发件人自己的仓库，而不是客户各自的地址。虽然有许多方法可以构建企业到企业集成，但任何解决方案都必须考虑涉及每个贸易合作伙伴、人工驱动的字段映射的设置过程。

EDI中还有其他固有的复杂性领域。由于业务会随着时间的推移而变化，因此企业各自业务系统的配置也必须发生变化;一个例子可能是零售商将DHL添加为运输选项，而它以前只提供FedEx。这些变化必须传达给贸易伙伴，以便适当更新字段映射；由于此类通信和更新涉及人类的“最大努力”，因此其中一定比例将被遗漏或错误完成，从而导致后续事务的集成失败。即使没有业务间更改，也会发生错误——例如，业务系统的 API 密钥可能会过期，或者系统可能会经历间歇性停机。需要审查、重试和解决此类错误。正如每个解决方案的设置过程始终需要每个贸易合作伙伴、人工驱动的字段映射一样，每个解决方案还必须提供用于管理控制平面上的配置更改和数据平面上的间歇性错误的功能。

商业物理

因此，商业宇宙的“物理定律”如下：

1.有许多企业，这些企业必须进行企业对企业贸易才能提供最终产品和服务；
2.这些业务在大量但数量有限的业务系统上运行；
3.由于业务实践的异构性，这些业务系统提供的配置选项会导致无限数量的不同配置；
4.配置的异构性使得单一统一格式变得不可能，因此需要每个贸易合作伙伴的设置过程；
5.不正确设置的业务影响要求有人参与设置；
6.业务不是静态的，因此配置会随着时间的推移而变化，再次需要人工输入；
7.业务系统并不完全可靠；
8.由于人工输入和业务系统都不完全可靠，因此间歇性错误将持续发生；
9.必须解决错误以保持可靠的业务流程。

任何通用的业务集成系统都必须考虑所有这些约束。所谓的足够多样性定律很好地总结了这一点：“为了确保稳定性，控制系统必须至少能够代表它所控制的系统的所有可能状态。如果做不到这一点，它必须以某种方式限制范围——比如，只处理交易类型、行业、业务系统或用例的子集。”但是，由于限制范围在定义上意味着限制市场规模，因此任何开发业务集成系统的足够雄心勃勃的努力都不能限制范围：它必须提供机制，以任何格式与任何业务系统的任何配置、任何行业、300+ 企业对企业交易类型配合使用，并为未来可能发展的任何演变做好准备。

这就是开发通用业务集成系统的挑战。

知行软件的方案

知行软件为三种类型的客户提供服务：

• 需要构建集成以支持其自身业务的客户（例如，希望与其供应商交换EDI文件的电子商务零售商）;
• 需要将EDI功能构建到自己的软件产品中的客户（例如，希望将自助式EDI集成嵌入其平台的数字货运代理，运输管理系统或履行提供商）;
• 需要对其技术堆栈进行现代化改造的 EDI 提供商或 VAN（例如，希望替换传统基础设施或工具的零售特定 EDI 软件提供商）。

产品层面，知行软件拥有自主知识产权的中文版EDI系统 – 知行之桥，企业之所以首选知行之桥EDI系统，与我们产品功能丰富，持续迭代，免费试用，有直接关系。

功能层面，知行之桥EDI系统支持所有广泛使用的通信协议及EDI报文标准, 以便企业通过一套系统即可满足所有外部交易伙伴的EDI需求。

价格层面，根据企业的实际需求，可以灵活选择授权模式，以便适应不同类型企业的业务增长；同时也能贴合企业财务部门的需求及规划。更关键的是，官网产品价格公开透明，且无任何隐藏费用，企业可放心选择！

面对新协议、新标准、新安全需求等层出不穷的EDI生态，EDI产品持续的迭代演进显得尤为重要；知行之桥目前处于产品生命周期的青壮年时期，选择我们就意味着企业拥有了未来几年甚至十年在EDI领域的前沿领先技术！

知行软件服务中国700+企业，项目经验丰富，实施周期短。我们的客户，遍布汽车、物流、电子、零售、快消品、能源化工、IT软件服务商等行业。

了解更多 EDI 相关信息，请阅读：EDI是什么？

阅读原文：是什么让EDI如此困难？