主页%『创世注册』%主页美国得而达有限公司（后面简称为得而达Delta）是世界500强MASCO的核心企业，一九二九年成立于美国的MASCO，是全球家居及装饰产品领导者，更是美国水龙头市场品牌知名度和购买率最高的品牌。

　　近年来积极拓展中国市场，誓言为中国建设者和消费者提供全球最优质的水龙头和卫浴产品，创作不同凡响的产品使用体验。

　　通过EDI方式来直接对接，能大幅提高信息自动化水平，提高供应链上各级合理安排明确生产需求计划的效率，首先需要和得而达（Delta）建立EDI连接通道，进行数据的交互；其次需要通过知行之桥EDI系统来实现业务数据的解读和处理。

　　知行之桥EDI系统集成方式有很多种，但本次项目案例中的企业A因只接收850采购订单数据及864错误通知，发送810发票，且频率和数据量较低，客户想低成本、快速接入EDI，所以选择了Excel方式查看订单、错误通知及进行发票数据录入，之后待业务量扩大后再考虑与业务系统进行无缝集成，实现业务流程完全自动化。

　　出于数据安全的考虑，企业A选择本地化部署。本地化部署是将知行之桥EDI系统部署在企业A的本地服务器，可以在正常使用知行之桥EDI系统的同时有效地保障数据的安全，防止数据泄露。

　　企业A从得而达（Delta）接收850采购订单数据/864错误通知数据如下图所示：

　　知行之桥EDI系统部署：在企业A本地服务器安装、配置知行之桥EDI系统（比较重要的是AS2的端口信息配置）。

　　AS2连接测试：双方交换AS2信息，企业A在知行之桥EDI系统的AS2端口配置得而达（Delta）的连接信息，双方互发测试文件进行验证连接是否成功，根据项目不同，也可以进行一些特定场景的文件测试。

　　①企业A通过AS2（命名为Delta_AS2）端口接收到得而达（Delta）发来的850采购订单数据/864错误通知

　　②通过X12（命名为Delta_X12ToXML）端口把接收到的X12文件转换为标准的XML文件。（转换类型选为X12转换成XML）

　　④如果不符合850/864的匹配条件，则会到Notify（命名为Delta_Notify）端口，进行报错。

　　⑤如果符合850/864的匹配条件，则会把输出的Excel格式的订单文件，通过Email Send（命名为Delta_EmailSend）端口发送到企业A的业务邮箱。

　　⑥在处理完商务流程（处理订单文件-打包包装-物流发货）等一系列流程之后，企业A会生成发票然后通过业务邮箱发送发票数据到Email Receive（命名为Delta_EmailReceive）端口。

　　⑧接着通过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信息，进行数据结构调整，并重新发送。

　　①沟通初期，因得而达（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的发票，每张发票里面包含一个订单号，问题解决。