为啥仍然使用EDI，如何处理？

Posted 2023-02-23

【中文标题】为啥仍然使用EDI，如何处理？

【英文标题】：Why is EDI still used, and how to deal with it?为什么仍然使用EDI，如何处理？

【发布时间】：2010-10-05 17:11:20

【问题描述】：

为什么面对更易于使用的技术仍然使用这种古老的格式？它是否提供了一些我没有看到的好处？似乎大量供应商仍然只提供这种格式的数据，而不是像 XML 这样更易于管理和使用的东西；至少提供这两种格式对我来说是有意义的。

此外，当您别无选择只能使用 EDI 时，有哪些好的方法可以处理和使用它？像 BizTalk 这样的东西是不可能的，因为它太贵了。是否有任何免费/开源应用程序可以使 EDI 更易于使用？

【问题讨论】：

主观和论证：参见“神秘”、“对我来说零意义”，其他系统“更高效”、“解析头痛”、“过时”、“更容易使用”、“阅读中文” .

@Gortok：是的，他是主观的，但在咆哮中隐藏了一个问题：EDI 格式的优缺点是什么？

EDI 代表电子数据交换，而不是人类数据交换。它并不意味着人类可读。它紧凑且定义明确。我已经将 7MB EDI 文件转换为 XML，它们最终变成了 45MB+。转换大小不是线性的。较大的 EDI 文件可能会变得很大。

@L_7337 XML 也可以实现同样的效果，使用一些没有人需要看到的标准压缩算法。

我们使用 QWERTY 键盘的相同原因

【参考方案1】：

一种解决方案（虽然会花费您的费用）是去像 ADX 这样的公司，该公司有工具可用于将 EDI 格式转换为更令人愉悦的格式，如 CSV。根据您正在进行的交易量和类型，这既可以负担得起，又可以减轻很多压力。我过去使用过他们的产品，虽然设置起来有点麻烦，但它们确实工作得很好，而且非常稳定。由于 EDI 的历史，您可能会找到数百家提供类似服务的其他公司。

【讨论】：

很遗憾，我的预算是 0.00 美元。不过，我会记住它，以备不时之需。

他们付给你 0.00 美元来做这项工作吗？因为如果他们不是，你真的应该争辩说，只需向其他人支付解决方案的总成本，它就可以以更少的总成本完成。

【参考方案2】：

您可能对以下项目感兴趣：

http://bots.sourceforge.net/en/index.shtml Google code archive

【参考方案3】：

我在 2 个有关海运物流的项目中使用了 EDI（ANSI X12 和 EDIFACT），发现它们非常有用，因为大多数海运承运人和贸易伙伴都接受它们作为不同系统之间通信的标准方式。

因此，EDI 格式仍在使用并将继续使用，因为它是一个已建立的标准，并且有数千家公司围绕它们开发了系统，替换它们确实是一件大事。

【参考方案4】：

可以通过 EDI 交换哪些类型的信息？

可通过 EDI 进行各种类型的业务信息交换，包括：

-•预订信息

-•提单信息

-•发票

-•电子转帐

-•到货通知信息

-•发货状态信息

选择 EDI 对我的公司有何好处？ -•它简化了您和 APL 之间的沟通过程

-•无需重新键入数据，从而消除错误和重新检查信息的需要

-•它消除了纸张处理和文档存储的需要

-•提高数据的周转时间和准确性

-•无需传真

【参考方案5】：

因为它是一个正式制定的标准（实际上是一套非常庞大而全面的标准）。这就是标准所声称的好处之一 - 您不需要在很长一段时间内更改任何内容。

要改变它，需要两个或更多（通常是成千上万）贸易伙伴（可能包括您的所有竞争对手）之间达成一致。

EDI 格式具有更高的信噪比（因为它们是在被认为很重要的时候设计的。）了解并理解 EDI 的人会查看您的 XML 并说“牛肉（数据）在哪里？”

很少有开发人员编写自己的解析器。有许多优秀的映射器可用（并且内置了许多遗留和企业应用程序）。因此，有很多方法可以缓解您的痛苦（包括 SourceForge 上的至少一个开源应用程序）。

【参考方案6】：

Edifact 是文档交换的最佳标准之一。 大多数问题来自贸易伙伴发送的非标准化文件。

是的，这是一种有点奇怪的格式，如果您不知道来龙去脉，使用起来会很乏味，但 XML 也是如此。

您真的想要 XML 而不是 Edifact？看看 peppol（泛欧在线公共采购）正在制定的臃肿、难以阅读的 XML 标准。

是的，如果您在系统中没有任何错误，它会很好地工作，一旦您习惯了这种格式，排除故障就会比故障排除 UBL 文档容易得多。

您说您有 0.00 美元可用于该项目？ 您真的应该调查一下贵公司完成的手动工作量，EDI 可以提供的成本效益分析非常方便。

【讨论】：

看看 edidev、stylusstudio 或 liaison Liaison 有一个免费程序 EDI Notepad，如果你不熟悉 edifact，它会非常方便。如果它必须是开源的，也有很多 java 解析器 同意BizTalk 有点贵，但大型 ERP 系统也必须如此，在这种情况下看看奖品 :-)

【参考方案7】：

恕我直言，EDIFACT 存在几个问题。

从中解析或生成对象模型并不容易。这可能不再是一个大问题，因为现在有很好的系统可以为你做这件事，例如smooks.org 不容易阅读。你习惯了，但 XML 更容易阅读 验证没那么容易（与验证 XML 相比） 有太多不同的版本和口味，D95B、D96B、D00A、D00B 等。 但我认为最大的问题是每个人使用标准的方式不同。它们使用相同的“格式”，但字段的定义不同。我们使用 EDIFACT 从集装箱码头发送和接收消息，它们都有细微的差别。他们会例如都使用 D95B CODECO，但对于某些终端，某个段是强制性的，而对于另一个，它是可选的，甚至不允许存在。那么你就有了使用相同但内容不同的段。

总结起来就是：脖子疼。

【参考方案8】：

另一个原因是订单等业务消息。发票、信用票据等交易中有很多财务价值，它们需要安全，但也许更重要的是，它们需要具有端到端的验证和验证以及不可否认性。

例如，我向您发送了价值 1/2 百万欧元的商品的订单，您将商品发送给我，然后我“丢失”了订单信息并告诉您我没有付款。标准和 VANS 的结合使这几乎是不可能的，或者至少有如此多的审计线索，以至于可以跟踪问题。这就是为什么“哦，让我们使用 xml 和互联网而不是 EDIFACT 和 VANS”往往会失败的原因。正如其他人回答的那样，惯性，但它是建立在稳定有效、安全、可靠且易于理解的系统中的惯性。

廉价地做这件事并不总是一种选择。

如果我在 87 年第一次实施 EDI 时有什么安慰的话，当时几乎没有软件，所以我得到了 Interbridge 表，并使用 Cognos 软件和 HP Mini 为英国 TRADACOMS 标准编写了自己的解析器，它工作正常美好的。假设您与其他 EDI 合作伙伴进行交易，成本可能来自需要使用 VAN。

【参考方案9】：

切换到 XML 会给您带来什么——更容易调试的行格式？

通常你设置好然后离开它，没有太多需要使用原始 EDI 提要，当然还不足以放弃标准并重新开始。 有很多标准，例如 FAX，可以提高可读性，但没有真正迫切需要更改它们。

【讨论】：

您是否曾经查看过 EDI 格式，甚至是像 EDIFACT 订单这样简单的格式？有什么工具可以轻松使用和扩展它？可能有一些，但我们正在谈论几位数的货币来获得 XML 免费提供的东西。

+1 安东尼琼斯。正是我的 EDI 问题——解析起来非常困难，而 XML 易于使用和扩展。

这不是一件容易的事。 EDI 比 XML 更难正确执行。

@AWJ 我经常查看它们（或习惯于，现在大部分都被过滤掉了）。我很难找到嵌入在 XML cruft 中的数据。使用 EDI，我可以在分段符处插入换行符，并且在屏幕宽度内或多或少地垂直排列。这是你习惯的。

【参考方案10】：

为所有感兴趣的人提供一些信息。 EDI 基本上是由委员会设计的数据交换格式，它不仅规定了数据格式（如 XML）的规则，而且还开始定义可能在 2 家公司之间发送的每个文档。因此，对于可以在公司之间交换的任何数据，他们提出了每个文件中应该包含的内容的确切定义。当然，没有人能预见到两家公司想要交换的每一条数据。因此，您最终会发现公司使用为一件事定义的字段，用于其他一些信息。

您最终得到的是一种极其复杂的数据格式，其中许多使用它的人不遵守标准，因为他们需要发送自定义信息，而标准没有考虑到这些信息。因此，最后，您仍然需要与您想要处理的每家公司交谈，并找出他们实现的所有小特性，就像您与拥有自定义 XML 接口的人一样。除了在 EDI 的情况下，格式很难解析，甚至更难写好，所以你最终会做一大堆工作只是为了发送一个文档，而在使用自定义 XML 解决方案进行同样的思考时会减少很多倍的问题。

【讨论】：

但是您会得到贸易伙伴，他们为相同的数据和相同的目的以截然不同的方式扩展 XML 格式，因此结果相同。我们都比其他人更喜欢我们自己的锤子，但他们有时都会把钉子打得半弯。

我的全部观点是，您不能尝试标准化整个行业发送的文件。相反，如果每个人都只使用 XML 并定义自己的 DTD 以供其他人遵守，而不是试图让每个人都同意一个 DTD 或数据格式，每个人都会变得更好。

不能仅仅因为 100% 的消息交换要求无法标准化而投票支持免费的所有方法。

【参考方案11】：

EDI 在许多行业中非常多产。用更新的技术替换已经在使用的技术会非常昂贵。

考虑到这一点，沃尔玛使用 EDI 与其供应商、商店、分销链等进行通信。我猜他们与数以万计的供应商打交道。他们每个人都在 EDI 技术上投入了数千美元。如果 Walmart 决定改用 XML，那么这个决定会影响成千上万的公司，而不仅仅是 Walmart。

这适用于任何 EDI 用户。毕竟，这是贸易伙伴之间使用的标准。

我同意，使用 EDI 很痛苦。但“回到过去”，这就是我们所拥有的一切。

【讨论】：

愿意推荐任何东西来减轻处理它的痛苦，然后呢？我的挫败感是因为我的公司更换了供应商，而这个新的仅提供 EDI 格式的数据（旧的也提供文本格式的数据），所以我正在努力想办法整合它使用我们的系统

@WayneM 我可能遗漏了一些东西，但您不能使用 XSLT 将您的 XML 转换为 EDI 吗？ XML->XSLT->EDI 似乎比 EDI->CustomeParser->XML 容易得多......我可能过于简化了。

我没有使用 XML；我只需要提取数据 - 我希望供应商使用 XML 而不是 EDI，因为 XML 更容易解析我需要的数据。

@WayneM，有几家公司提供 EDI 映射软件，可以将 EDI 文档翻译成用户定义的格式。我们曾经使用 Sterling Commerce 的产品，但老实说，这是一种爱恨交织的关系。

【参考方案12】：

EDI 早在 XML 之前就已经存在。除了双方可以预先协商适用于他们双方的 EDI 格式这一事实之外，您还必须考虑 VAN（增值网络）的部分。

在某些情况下，VAN 对消息进行验证，甚至读取消息并对其执行操作，例如根据其内容将其复制到其他方。

真正使用 EDI 的唯一原因是因为“它一直都是这样做的”，因此有很多现有的基础架构可以支持它。为什么在不需要的时候切换到 XML？又如何说 XML 不会被 JSON 取代，而 JSON 会被其他东西取代？

【讨论】：

JSON 用于数据，XML 用于文档。这是一个重要的区别。

请解释一下你的意思。

【参考方案13】：

我也不得不使用 EDI，我同意。我们使用 BizTalk 对其进行映射，效果很好。许多系统都建立在 EDI 之上（远在 XML 之前）。

【讨论】：

如果我使用 BizTalk，也许我不会遇到这个问题......但不幸的是，它的价格太高了，甚至懒得考虑作为解决方案。

【参考方案14】：

EDI 是一种非常紧凑的格式，通常用于尽可能减少数据交换中的带宽使用量。例如，德国海关在其 ATLAS 系统中使用它来每天交换大量数据。

它难以解析且难以阅读，但如果结果数据的大小很重要，它可能是一个不错的选择，并且受到大多数大型业务应用程序的支持。

【讨论】：

在这一点上，许多增值网络 (VAN) 仍然收取千字符费率。字符越多，成本越高。

【参考方案15】：

“如果它没有坏，就不要修理它。”

这些组织中的大多数都在使用 EDI 处理大量数据，并且不会在没有令人信服的理由的情况下更改为更现代的东西。遗憾的是，为第三方开发者提供便利通常并不符合条件。

【参考方案16】：

一旦您熟悉了它使用的分隔符，EDI 就不难理解了。您可能还会问自己，为什么仍然有人使用 CSV 或制表符分隔的数据。

答案可能是这些格式是由委员会定义并在某个行业标准化的“领域特定语言”，并且已经投入了大量资金来支持这些格式。再次抛出这些的商业案例在哪里？

【讨论】：

我发现 EDI 很容易读入。困难的部分是编写其他系统不会抱怨的 EDI 文档。似乎即使您遵循规范，他们仍然会抱怨。

事实上，我已经创建了一个 DSL 来映射 EDI 事务集（双向）。这几乎是微不足道的。

@Kibbee：听起来像是为 Internet Explorer 开发网站！

【参考方案17】：

一个词，惯性。由具有不同议程的各种公司和组织之间的委员会开发 EDI 格式是一场噩梦（遗憾的是我曾去过那里）。

要求他们放弃这些，让另一轮委员会同意 Web 服务 API 标准将需要更长的时间，您如何向非技术委员会推销将一种电子格式替换为另一种电子格式的想法？它给了他们什么可能的商业优势。最初，电子交换的好处是显而易见的，但以另一种替代的好处却不是。我们在这里谈论的是真正的大公司。

【讨论】：

没错。供应商不是软件开发公司。他们没有看到切换到新系统的价值。他们没有做任何事情的内部专业知识，雇用某人会非常昂贵。

不是真正的“惯性”；这是由于“网络效应”en.wikipedia.org/wiki/Network_effect

【参考方案18】：

旧版支持