项目背景
美国得而达有限公司（后面简称为得尔达Delta）是世界500强MASCO的核心企业，一九二九年成立于美国的MASCO，是全球家居及装饰产品领导者，更是美国水龙头市场品牌知名度和购买率最高的品牌。 近年来积极拓展中国市场，誓言为中国建设者和消费者提供全球最优质的水龙头和卫浴产品，创作不同凡响的产品使用体验。
需求分析和方案
1.连接方式
得尔达（Delta）支持通过AS2传输和供应商EDI对接。
2.业务报文
通过EDI方式来直接对接，能大幅提高信息自动化水平，提高供应链上各级合理安排明确生产需求计划的效率，首先需要和得尔达（Delta）建立EDI连接通道，进行数据的交互；其次需要通过知行之桥EDI系统来实现业务数据的解读和处理。
方案：通过Excel方案查看及数据录入
那么根据企业A提出的需求，如何通过知行之桥EDI系统的集成方式实现呢？
知行之桥EDI系统集成方式有很多种，但本次项目案例中的企业A因只接收850采购订单数据及864错误通知，发送810发票，且频率和数据量较低，客户想低成本、快速接入EDI，所以选择了Excel方式查看订单、错误通知及进行发票数据录入，之后待业务量扩大后再考虑与业务系统进行无缝集成，实现业务流程完全自动化。
出于数据安全的考虑，企业A选择本地化部署。本地化部署是将知行之桥EDI系统部署在企业A的本地服务器，可以在正常使用知行之桥EDI系统的同时有效地保障数据的安全，防止数据泄露。
业务流程
企业A从得尔达（Delta）接收850采购订单数据/864错误通知数据如下图所示：
企业A向得尔达（Delta）发送810发票数据如下图所示：
方案实施
知行之桥EDI系统部署：在企业A本地服务器安装、配置知行之桥EDI系统（比较重要的是AS2的端口信息配置）。
AS2连接需要双方提供以下信息：
- AS2 ID：是AS2数据传输中唯一的身份标识
- 交易伙伴URL：接收URL
- 加密证书：发送消息时，用于加密的公钥证书
- TLS服务器证书：如果是https开头的，需要配置TLS服务器证书
AS2连接测试：双方交换AS2信息，企业A在知行之桥EDI系统的AS2端口配置得尔达（Delta）的连接信息，双方互发测试文件进行验证连接是否成功，根据项目不同，也可以进行一些特定场景的文件测试。
方案详解
①企业A通过AS2（命名为Delta_AS2）端口接收到得尔达（Delta）发来的850采购订单数据/864错误通知
②通过X12（命名为Delta_X12ToXML）端口把接收到的X12文件转换为标准的XML文件。（转换类型选为X12转换成XML）
③再通过Branch（命名为Delta_850Branch/Delta_864Branch）端口通过匹配值850/864，筛选出对应的文件，如果匹配值符合850/864，则到下一个端口Excel（命名为Delta_850ToExcel/Delta_864Excel）输出为Excel格式的文件。
④如果不符合850/864的匹配条件，则会到Notify（命名为Delta_Notify）端口，进行报错。
⑤如果符合850/864的匹配条件，则会把输出的Excel格式的订单文件，通过Email Send（命名为Delta_EmailSend）端口发送到企业A的业务邮箱。
⑥在处理完商务流程（处理订单文件-打包包装-物流发货）等一系列流程之后，企业A会生成发票然后通过业务邮箱发送发票数据到Email Receive（命名为Delta_EmailReceive）端口。
⑦然后通过Excel（命名为Delta_810ToXML）端口把接收到Excel文件转换成XML文件。
⑧接着通过X12（命名为Delta_XMLToX12）端口把转换得到的XML文件转成X12文件格式。
⑨XML转X12的端口中记得要勾选功能性ACK（这里勾选的997回传表示当企业A发送成功后会保持Pending ACK状态，直到收到得尔达Delta回复的状态为Accepted的997文件，状态会自动修改为Sent，表示发送的文件数据结构完全满足客户需求）
⑩转换成X12文件之后通过AS2（命名为Delta_AS2）端口即可把810发票信息发送给得尔达（Delta）。回写的997数据也会传到X12（命名为Delta_X12ToXML）端口，经过X12端口（命名为Delta_X12ToXML）将997 edi转为997xml后，会通过工作流的虚线方向，进入Delta_XMLToX12，修改状态为Pending ACK的记录，如果收到的997 状态为Accepted，则状态改为Sent，表示成功；如果997的状态为Rejected，则状态会改为Send Error，表示之前发出去的数据结构不符合Delta的要求，这时就需要根据997反馈的error信息，进行数据结构调整，并重新发送。
AS2端口配置界面:
项目回顾
业务层面：
①沟通初期，因得尔达（Delta）在美国，在沟通开会时间上比较难协调，只能多次邮件先确认双方的时间，后续此类项目可以先做排期，排除掉双方假期的情况下，提前做一个交易伙伴对接周期（类似于项目实施周期）。
②在跟进810数据错误问题时，企业A负责对接EDI项目的项目经理离职，新的业务不是很清楚情况，沟通情况之后，延期一周正式交接才继续对接，中途得尔达（Delta）因不知道这个信息，也询问过我们，但企业A内部的情况我们也不是很清楚，之后在此类项目中，因为涉及到三方对接，建议可以选择更稳妥的人选，这样对双方的对接有积极推进效果。
③企业A在项目初期给了一版Excel文档格式，在临上线时，想要更换方案，但因为此操作会涉及到代码全部重写及各种返工环节，权衡之后，企业A选择沿用现有Excel方案。建议之后在选择方案时，可以提前做好规划，或可以联系知行软件的项目经理帮您做出对应的方案。
技术层面：
①企业A与得尔达（Delta）做连接测试的时候，正式环境是没问题的，测试环境一直报700的错，后来尝试在企业A服务器上访问Test2环境的URL时，发现企业A环境的出站IP和提供给得尔达（Delta）的不一样，终于找到了问题所在：企业A的出站IP设置的是企业A自己的电脑，而不是提供给得尔达（Delta）的IP，导致我们的IP不在得尔达（Delta）的白名单内，导致一直连不上得尔达（Delta），修改后连接成功。
②企业A的发票是一张发票中有多个订单号的，但是得尔达（Delta）的系统是不支持一张发票多个PO的，经过讨论之后，我们的实施顾问用代码实现了拆分取值，即一个TransactionSet对应一个810订单（详见下图），这样企业A还是发送一张含有多个订单号的发票，但得尔达（Delta）则会收到多个810的发票，每张发票里面包含一个订单号，问题解决。
以上就是我们关于企业A对接得尔达（Delta）的案例分享。
更多EDI信息，请参阅: EDI是什么？
阅读原文
