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