我在我的日子里使用过许多API,但最近才开始与需要通过EDI订购信息的第三方合作.请原谅新手问题,因为我在线阅读了大量信息,但我仍然没有得到它.
我有几个问题:
1 - EDI有什么好处？我似乎只是将特定结构中的文本文件发送到远程位置.我一直以编程方式为非EDI文件类型执行此操作.
2 - 为什么有些供应商想要使用VAN？我不能简单地将它发送到某个地方的FTP位置吗？
3 - 关于EDI翻译软件的全部内容.这不能简单地使用多种语言进行解析吗？
4 - 我的ASI是什么？一位供应商问我,但我不确定这是否是我或其他人的唯一ID.
5 - 使用第三方提供商的任何理由？我有我的交易数据,是否难以创建EDI文件(在我的情况下是850文件类型)并将其发送到某个FTP位置？这是否过度或者他们真的提供了有用的服务.如果我需要向他们提供我的数据,我是否应该直接将其发送给供应商并跳过中间人？
总之,我只是没有得到EDI.我已经习惯了API,你会得到非常详细的文档.有了EDI,供应商告诉我,我必须提供符合我要求的文档.似乎倒退了.
感谢您的耐心等待.
以下是我的答案/我的立场(开发EDI解决方案超过15年):
1 - EDI提供标准.ANSI X12和EDIFACT都在框架不可用时提供框架,并且有许多不同的系统(Unix,AS/400,Windows等).当然有人在那里混淆标准,但在大多数情况下,这是每个人的共同点.
2 - VAN仍然存在的原因有很多:遗留应用程序,供应商锁定,SaaS EDI平台(翻译即服务).许多公司都支持FTP,AS2(EDI通过HTTP发送加密/签名).您的贸易伙伴可能会支持它.VAN通常会有最长的通信费用(通常以千克每千字节为单位),因此在2014年,通常最好避免它们,除非您获得真正的增值服务.
3 - 翻译软件存在是有原因的.你能写自己的解析器吗？是的,但你要重新发明一个30岁以上的车轮.有超越EDI的成熟,优美的工具.如此多的任何映射器不仅可以处理EDI挑战,还可以处理ETL,A2A,B2B,文本文件等.与编写映射相比,您可能需要编写数千行代码.这是一个不同的范例.我在目前的环境中使用Liaison的翻译软件,从面向供应商和面向客户的EDI到ETL功能,以及将翻译软件与温度传感器连接起来.它是我们IT计划的基石,每天处理超过4000批数据,并且只需要很少的支持资源.
4 - ASI？我会理解AS2 ID,或Sender限定符和ID.这些是正常的X12术语.是否有任何其他背景？是否有可能是与EDI无关的内部标识符,如帐户ID？
5 - 那里有工具可以提供帮助.像EDIDev.com这样的.NET库.像BOTS这样的Python软件.EDI面临挑战 - 包络,合作伙伴管理,功能确认生成和协调,通信协议和脚本.第三方可用于设置地图,但您必须长时间仔细研究投资回报率,尤其是如果您的解决方案必须扩展.它还取决于您正在集成的软件.一些第三方对这些包具有广泛的专业知识.我总是使用我认为合适的工具构建内部部署解决方案.我发现SaaS通常在长期内更加昂贵,并且觉得该型号具有镍和硬币的倾向.
你正在做850,这通常很简单.如果您正在使用SDQ段(商店标记),则会变得稍微困难一些.你可以编写自己的解析器,但我提到了一些陷阱.您提到与API相关的文档.我相信我们都可以同意并非所有API都能很好地记录下来.如果您的贸易伙伴拥有成熟,强大的EDI基础架构,他们应该能够为您提供样本数据,以及准确说明每个领域(细分/元素)的实施指南.这应该会缩短您的开发时间.你还应该定价一些EDI软件(任何对任何一个),至少可以看到它的外观.您可能会对成本的能力感到惊讶.我通常提到Liaison Delta是一个很好的起点(基于Windows,很棒的映射器,内置EDI字典).对于X12,你不会找到很多免费软件,因为标准不公开发布的(这不是EDIFACT标准的真),所以保持标准库免费是不是大多数开发商想做的事情.
出于各种原因,EDI应该被XML取代.在一天结束的时候,EDI仍然生存,因为既定的标准,传统的支持,VAN活动(你永远不会通过VAN发送XML就像一个EDI文件,它太冗长)等沃尔玛要求EDI和AS2 .我看到他们拒绝供应商,如果他们不能/不会遵守或在他们的沙箱中玩得很好.他们推动了许多零售EDI计划.
希望这可以帮助.