EDI 处理工作原理概述

Posted 2023-02-23

【中文标题】EDI 处理工作原理概述

【英文标题】：Overview of how EDI processing works

【发布时间】：2012-09-16 00:30:04

【问题描述】：

我是 EDI 新手，必须在旧系统中实施它。

我想确保我有正确的更高级别的概述：

1) 从我的系统为给定的贸易伙伴生成 EDI 文件 2) 可能 FTP 给他们 3) 响应是 ftp'​​d 给我的，我把它刮回我的系统

我是不是要把这个概念记下来？

我知道大多数贸易伙伴都会调整标准，所以那里有很多工作？

【参考方案1】：

您的工作流程处于非常高的水平

一如既往，魔鬼在细节中。

术语 - 段/元素/分隔符

封装数据（ISA / GS / SE 段）

信封上的控制编号

通信 - 真的是 FTP 吗？清晰或安全？ VAN 或 AS2 协议？

业务逻辑 - 应用程序端还是翻译端？这使得 更有意义？

997 对账

文档审核（必需？达到什么级别？）

合作伙伴测试协议

考虑一下我的供应商面向 EDI 的环境：

850 订单输出 997 给我们 855 联系我们 997 离开我们 856 到我们这里 997 离开我们 810 联系我们 997 离开我们

对于面向客户的 EDI：

850 给我们 997 离开我们 855 离开我们 997 给我们 810 离开我们 997 给我们

如您所见，我们生命周期中的一些文档用于交易。

您正在处理哪些文件？如果是 837，生成 EDI 文件并非易事。即使它在 856 中，您也必须处理在翻译时必须考虑的分层循环（尽管 837 更是如此）。

您是否打算编写自己的解析器/翻译器？如果是这样，为什么？您是否要编写自己的确认核对例程？语法验证？最好的办法是将您的遗留应用程序与商业翻译器连接起来，而不是重新发明 30 年的***。许多可以连接到遗留系统的拖放映射器（Delta 可能是市场上最好的之一，但也有一些高质量的开源替代品，如 BOTS）。 X12 标准对混蛋有一点回旋余地。不过，我似乎有些疯狂的实现。总的来说，更多的合作伙伴顺从而不是做他们想做的事。那些有广泛要求的通常选择 XML，因为它们在文档结构中具有更大的范围并且不受标准的限制。如果您有 4 个合作伙伴，其中 2 个是 4010 版本，2 个是 5010，那么您必须相应地编码（或映射）。有一些工具可以提供帮助，但同样，魔鬼在细节中。

【讨论】：

我有来自合作伙伴的 210 和 214 规格。我们发现的大多数映射器都非常昂贵。不过很有趣……我绝对不想重新发明***，但我必须让我的客户为映射付费，因为我有 10-20 个需要将 EDI 添加到我的桌面软件中。

你看过哪些映射器？ 210 和 214 解析/翻译并没有那么糟糕，但正如我在回复中所说，在翻译过程之外还有很多其他的事情需要考虑（业务逻辑、审计等）。只需不到 2 万美元，我就可以推荐一个通用数据转换器/通信包，它可以让您解决任何集成挑战——但这是否符合“真的很贵”的旗号？在这一点上，BOTS 可能是您更好的解决方案，或者edidev.com（我只是更喜欢功能齐全的端到端解决方案，如 Delta / ECS）

感谢您的帮助，我想我有我需要的东西 Andrew。

他 Andrew，感谢您称 Bots 为优质产品。你一直在使用它吗？ PS：我是主要开发者;-)

@eppye - 你和我都已经存在很长时间了。我最近没有与 BOTS 合作，但一直密切关注开发、here 和 EDI-L。我一直在寻找新的翻译人员，并在商业环境中与超过 10 人合作过。

【参考方案2】：

可以在http://www.rdpcrystal.com/what-is-edi/找到一个很好的教程

它显示了EDI各方之间的基本交互以及消息信息