【发布时间】:2013-05-19 09:47:18
【问题描述】:
我们公司正在销售医疗用品,我们有一个网站可以在线销售我们的产品。我们正在与供应商合作,当我们收到新订单时,他们会将产品发送给我们的客户。目前我们是手动处理的。我们在我们的网站上收到订单,并通过电话/传真/电子邮件向产品供应商订购,他们将产品发送给客户,并通知我们运输信息,我们通知客户。
这个过程最近越来越难处理。到目前为止,我们还没有使用任何 B2B 解决方案,但我们现在需要实施 EDI 解决方案。我们最大的供应商正在使用 EDI 标准。
据我了解,流程如下;
- 当我们收到订单时,我们会创建 X12 文档,并通过 FTP、SFTP 或 VAN 发送此文档。
- 我们的供应商收到 X12 文件并进行处理。并发送格式为 X12 的发票。
- 我们收到发票并将其解析到我们的系统。
- 我们的供应商在向客户发货时会发送格式为 X12 的发货信息。
- 我们收到运输信息文件并对其进行解析。
我对这个过程有一些疑问。
- 第一个也是最重要的问题:我理解对了吗? :)
- 作为开发人员,我需要哪些程序/工具?
- 我知道编写我们自己的 X12 解析器是不明智的。我们需要一个外部应用程序。但是我们需要什么样的应用程序?我们是否需要像 BizTalk 这样的大型应用程序?或一些帮助库,如
- 我们的供应商支持FTP、SFTP和VAN进行数据通信,我们应该选择哪种通信方式?哪一种更简单、更容易理解?
对不起,我知道,我有很多问题 :) 任何帮助将不胜感激。
【问题讨论】:
-
我不建议自己做。如果他们支持 cXML 或类似的东西(如 Richard 提到的),也许 - 但只要您支持一个 EDI 文档,他们就会要求另一个。还有一个。然后你会得到一些人要求 UN/EDIFACT(另一个标准),然后是 cXML,然后是不同的连接协议/网络......我会购买商业软件或与 VAN 签订合同。
-
我认为威尔在这里提出了一个很好的观点。
-
谢谢威尔,你是对的。如果我自己做,以后可能会很痛苦。我是 .net 开发人员,如果我会选择 Microsoft BizTalk 进行 EDI 流程,这是一个不错的选择吗?
-
@arunes - 我不推荐 BizTalk 用于您的场景。它相当昂贵,恕我直言,UX/UI 很糟糕。如果您正在寻找基于 Microsoft 的翻译产品,请查看 Liaison 的 Delta (liaison.com/products/transform/delta)。将其与他们的 ECS 产品相结合,您将拥有一个可靠的应用程序集成框架,可以轻松地与 BizTalk 竞争,而成本/学习曲线只是其中的一小部分。
-
为了完整起见,有一个名为 Edi.Net 的开源库可以执行此操作,它的构建支持 .Net 完整框架以及 netstandard 1.0 及更高版本。 免责声明我是该库的作者