我是 EDI 新手,必须在遗留系统中实现它。
我想确保我有正确的更高级别的概述:
1) 从我的系统为给定的贸易伙伴生成 EDI 文件 2) 可能 FTP 给他们 3) 响应是 ftp'd 给我的,我把它刮回我的系统
我是不是要把这个概念搞砸了?
我知道大多数贸易伙伴都会调整标准,所以那里有很多工作?
您的工作流程处于非常高的水平
一如既往,魔鬼在细节中。
术语 - 段/元素/分隔符
封装数据(ISA / GS / SE 段)
信封上的控制号码
通信 - 真的是 FTP 吗?清晰或安全?VAN 或 AS2 协议呢?
业务逻辑 - 应用程序端,还是翻译端?哪个
更有意义?
997 和解
文件审核(必需?达到什么级别?)
合作伙伴测试协议
考虑我面向 EDI 的供应商的环境:
对于面向客户的 EDI:
如您所见,我们生命周期中的一些文档用于事务。
您正在处理哪些文件?如果是 837,生成 EDI 文件并非易事。即使它在 856 中,您也必须处理在翻译时必须考虑的分层循环(尽管 837 更是如此)。
您是否打算编写自己的解析器/翻译器?如果是这样,为什么?您是否要编写自己的确认核对例程?语法验证?最好的办法是将您的遗留应用程序与商业翻译器连接起来,而不是重新发明 30 年的轮子。许多可以连接到遗留系统的拖放映射器(Delta可能是市场上最好的之一,但也有一些优质的开源替代品,如 BOTS)。X12 标准对混蛋有一点回旋余地。不过,我似乎有些疯狂的实现。总的来说,更多的合作伙伴顺从而不是做他们想做的事。那些有广泛要求的通常选择 XML,因为它们在文档结构中具有更大的范围并且不受标准的限制。如果您有 4 个合作伙伴,其中 2 个是 4010 版本,2 个是 5010,那么您必须相应地编码(或映射)。有一些工具可以提供帮助,但同样,魔鬼在细节中。
可以在http://www.rdpcrystal.com/what-is-edi/找到一个很好的教程
它显示了 EDI 各方之间的基本交互以及消息信息