为什么面对更易于使用的技术仍然使用这种古老的格式?它是否提供了一些我没有看到的好处?似乎大量供应商仍然只提供这种格式的数据,而不是像 XML 这样更易于管理和使用的东西;至少提供这两种格式对我来说是有意义的。
此外,当您别无选择只能使用 EDI 时,有哪些好的方法来处理和使用它?像 BizTalk 这样的东西是不可能的,因为它太贵了。是否有任何免费/开源应用程序可以使 EDI 更易于使用?
为什么面对更易于使用的技术仍然使用这种古老的格式?它是否提供了一些我没有看到的好处?似乎大量供应商仍然只提供这种格式的数据,而不是像 XML 这样更易于管理和使用的东西;至少提供这两种格式对我来说是有意义的。
此外,当您别无选择只能使用 EDI 时,有哪些好的方法来处理和使用它?像 BizTalk 这样的东西是不可能的,因为它太贵了。是否有任何免费/开源应用程序可以使 EDI 更易于使用?
一旦您熟悉了 EDI 使用的分隔符,就不难理解 EDI。您可能还会问自己,为什么还有人会使用 CSV 或制表符分隔的数据。
答案可能是这些格式是由委员会定义并在某个行业标准化的“领域特定语言”,并且已经投入了大量资金来支持这些格式。再次抛出所有这些的商业案例在哪里?
一个词,惯性。由具有不同议程的不同公司和组织之间的委员会开发 EDI 格式是一场噩梦(很遗憾我曾去过那里)。
要求他们放弃这些,让另一轮委员会同意 Web 服务 API 标准将需要更长的时间,你如何向非技术委员会推销用另一种电子格式替换的想法?它给了他们什么可能的商业优势。最初,电子交换的好处是显而易见的,但以另一种替代的好处却不是。我们在这里谈论的是真正的大公司。
您可能对以下项目感兴趣:
切换到 XML 会给您带来什么——更容易调试的行格式?
通常你设置它然后离开它,没有太多需要使用原始 EDI 提要,当然不足以放弃标准并重新开始。
有很多标准,比如传真,可以变得更具可读性,但没有真正迫切需要改变它们。
因为它是一个正式建立的标准(实际上是一套非常庞大和全面的标准)。这就是标准所声称的好处之一——你不需要在很长一段时间内改变任何东西。
要改变它,需要两个或更多(通常是成千上万)贸易伙伴(可能包括你的所有竞争对手)之间达成一致。
EDI 格式具有更高的信噪比(因为它们是在被认为重要的时候设计的。)了解并理解 EDI 的人会看着您的 XML 并说“牛肉(数据)在哪里?”
很少有开发人员编写自己的解析器。有许多优秀的映射器可用(并且内置了许多遗留和企业应用程序)。因此,您的痛苦可以得到很多缓解(包括 SourceForge 上的至少一个开源应用程序)。
一点信息给所有感兴趣的人。EDI 基本上是一种由委员会设计的数据交换格式,它不仅规定了数据格式(如 XML)的规则,而且还开始定义可能在 2 家公司之间发送的每个文档。因此,对于可以在公司之间交换的任何数据,他们提出了每个文件中应该包含的内容的确切定义。当然,没有人能预见到两家公司想要交换的每一条数据。因此,您最终会发现公司使用为一件事定义的字段,用于其他一些信息。
您最终得到的是一种极其复杂的数据格式,其中许多使用它的人不遵循标准,因为他们需要发送标准不考虑的自定义信息。所以最后,您仍然需要与每家您想打交道的公司交谈,并找出他们实现的所有小特性,就像您去找具有自定义 XML 接口的人一样。除了在 EDI 的情况下,格式很难解析,甚至更难写好,所以你最终会做一大堆工作只是为了发送一个文档,而在使用自定义 XML 解决方案进行同样的思考时会导致少很多倍的问题。
“如果它没有坏,就不要修理它。”
这些组织中的大多数都在使用 EDI 处理大量数据,并且不会在没有令人信服的理由的情况下更改为更现代的东西。遗憾的是,为第三方开发人员提供便利通常并不符合条件。
恕我直言,EDIFACT 存在几个问题。
所以总结一下:这是一种颈部疼痛。
EDI 是一种非常紧凑的格式,通常用于使数据交换中的带宽使用尽可能小。例如,德国海关在其 ATLAS 系统中使用它来每天交换大量数据。
它难以解析且难以阅读,但如果结果数据的大小很重要,那么它可能是一个不错的选择,并且大多数大型业务应用程序都支持它。
旧版支持
EDI 在许多行业中非常多产。用更新的技术替换已经在使用的技术将会非常昂贵。
考虑到这一点,沃尔玛使用 EDI 与其供应商、商店、分销链等进行通信。我猜他们与数以万计的供应商打交道。他们每个人都在 EDI 技术上投入了数千美元。如果 Walmart 决定切换到 XML,它的决定会影响成千上万的公司,而不仅仅是 Walmart。
对于任何 EDI 用户来说都是如此。毕竟,这是贸易伙伴之间使用的标准。
我同意,EDI 使用起来很痛苦。但是“回到过去”,这就是我们所拥有的一切。
在文档交换方面,Edifact 是最好的标准之一。大多数问题来自贸易伙伴发送非标准化文件。
是的,这是一种有点奇怪的格式,如果您不知道来龙去脉的话,使用起来会很乏味,但 XML 也是如此。
您真的想要 XML 而不是 Edifact?看看 peppol(泛欧在线公共采购)正在制定的臃肿、难以阅读的 XML 标准。
是的,如果您在系统中没有任何错误,那么它工作得很好而且花花公子,一旦您习惯了这种格式,排除故障就会比故障排除 UBL 文档容易得多。
你说你有 0.00 美元可用于该项目?您确实应该调查公司中完成的手动工作量,EDI 可以提供的成本效益分析非常方便。
哪些类型的信息可以通过 EDI 交换?
通过 EDI 可进行多种类型的业务信息交换,包括:
-•预订信息
-•提单信息
-•发票
-•电子转帐
-•到达通知信息
-•发货状态信息
选择 EDI 对我的公司有何好处?-•它简化了您与 APL 之间的通信流程
-•无需重新键入数据,从而消除错误和重新检查信息的需要
-•它消除了纸张处理和文件存储的需要
-•它提高了周转时间和数据的准确性
-•无需传真
一种解决方案,虽然会花费您,但要找像ADX这样的公司,该公司拥有可用于将 EDI 格式转换为更令人愉悦的格式(如 CSV)的工具。根据您正在进行的交易量和类型,这既可以负担得起,也可以减轻很多压力。我过去使用过他们的产品,虽然设置起来有点麻烦,但它们确实工作得很好,而且非常稳定。由于 EDI 的历史,您可能会找到数百家提供类似服务的其他公司。
EDI 在 XML 之前就已经存在。除了双方可以预先协商适用于他们双方的 EDI 格式这一事实之外,您还必须考虑 VAN(增值网络)的部分。
在某些情况下,VAN 执行消息验证,甚至读取消息并对其执行操作,例如根据其内容将其复制到其他方。
真正使用 EDI 的唯一原因是因为“它一直都是这样做的”,因此有很多现有的基础设施来支持它。为什么在不需要的时候切换到 XML?又如何说 XML 不会被 JSON 取代,而 JSON 会被其他东西取代?
另一个原因是订单等业务消息。发票,信用票据等交易中有很多财务价值,它们需要安全,但也许更重要的是,它们需要端到端的验证和验证以及不可否认性。
例如,我向您发送价值 1/2 百万欧元的商品订单,您将商品发送给我,然后我“丢失”订单信息并告诉您我没有付款。标准和 VANS 的结合使这几乎是不可能的,或者至少有如此多的审计线索,以至于可以跟踪问题。这就是为什么“哦,让我们使用 xml 和互联网而不是 EDIFACT 和 VANS”往往会失败的原因。正如其他人回答的那样,惯性,但它是建立在稳定有效、安全、可靠且易于理解的系统中的惯性。
以便宜的价格做这件事并不总是一种选择。
如果我在 87 年第一次实施 EDI 时有什么安慰的话,那么几乎没有任何软件,所以我得到了 Interbridge 表,并使用 Cognos 软件和 HP Mini 为英国 TRADACOMS 标准编写了我自己的解析器,它运行良好。假设您与其他 EDI 合作伙伴进行交易,成本可能来自需要使用 VAN。
我在 2 个关于海运物流的项目中使用了 EDI(ANSI X12 和 EDIFACT),发现它们非常有用,因为大多数海运承运人和贸易伙伴都接受它们作为不同系统之间通信的标准方式。
因此,EDI 格式仍在使用并将继续使用,因为它是一个已建立的标准,并且有数千家公司围绕它们开发了系统,替换它们确实是一件大事。
我也不得不使用 EDI,我同意。我们使用 BizTalk 对其进行映射,效果很好。许多系统都建立在 EDI 之上(远在 XML 之前)。