零售EDI：Metro EDI项目案例

麦德龙Metro 总部位于杜塞尔多夫，在全球范围内经营批发和零售业务。在2018/2019 财年，麦德龙Metro 的全球销售额约为 270 亿欧元。从2016年开始，麦德龙Metro就开始对其当时约230家门店和20,000多家分销合作伙伴进行数字化整合，借助其内部IT服务提供商Metro-Systems的IT支持，实现与合作伙伴的EDI通信。

近期我们成功帮助家居行业客户对接Metro，客户原本使用的是国外某EDI供应商的EDI软件产品，由于国外的EDI产品价格高昂，并且由于语言以及时差等问题导致项目进度缓慢。因此客户选择和我们合作，将其EDI业务切换至知行之桥EDI系统中。

麦德龙Metro EDI 需求

麦德龙Metro选择使用AS2传输协议以及EDIFACT国际报文标准，通过EDI与其供应商传输的所有文件都必须符合这个标准。

麦德龙Metro支持的符合EDIFACT标准的业务报文类型如下：

供应商接收方向：ORDERS采购订单 供应商发送方向：DESADV发货通知 供应商发送方向：INVOIC发票

基于知行之桥EDI系统实现与Metro 之间的EDI对接

实现与Metro的EDI对接需要在知行之桥EDI系统中搭建如下所示的工作流：

由于企业同时使用知行之桥EDI系统对接多个交易伙伴，为了使数据处理流程更加简洁明了，且尽可能为用户节省工作流中使用的付费端口数。可以单独创建一个工作区，用于从企业的ERP系统中获取数据以及将EDI接收到的数据提供给ERP。然后借助免费端口：Workspace Receive以及Workspace Send端口，实现文件的跨工作区传输。

扩展阅读：Workspace Receive 以及 Workspace Send 端口介绍

以下是实现从ERP中获取数据，并传输至不同工作区的工作流：

如果企业需要对接第三方仓库，也可以专为第三方仓库创建一个工作区，搭建如下所示的工作流：

通过Workspace Receive从ERP中获取Packing list数据，无需进行报文格式转换，可直接通过FTP等传输协议提供给第三方仓库即可。

以下是将EDI系统中，不同客户发来的订单数据传输到ERP中的工作流：

项目回顾

1.Metro EDI 项目中出现不同的发送方和接收方ID

发送方ID和接收方在EDI中主要用于区分发送方和接收方的身份，具体到对接Metro的EDI项目中，则是在EDIFACT端口的设置选项卡下进行交换头配置。如下图示：

以往的EDI项目中，发送报文方向的发送方ID以及接收方ID是一致的。但在对接Metro的EDI项目中，需要向Metro发送DESADV发货通知以及INVOIC发票，在进行交换头配置时，发送方ID填写用户自己的ID即可，但接收方ID需要根据Metro提供的信息，分别配置用于发货通知以及发票的ID。

2.替换项目的连接测试和业务测试

本次EDI项目替换了用户原有的国外某EDI软件产品，用户此前已经通过旧EDI系统与Metro建立了EDI连接。Metro方提出对于一个供应商仅开放一个连接通道，因此需要调整连接测试和业务测试的顺序，通过邮件先完成业务测试部分关于EDI报文结构以及业务数据的验证，测试无误后，再进行连接测试。

3.用友 ERP系统的对接

企业内部的ERP系统使用的是用友的产品，EDI系统需要完成与用友ERP系统的集成。用友内部具有标准化的订单接口，但其中必填字段较多，Metro通过EDI发来的订单数据中不能提供接口中要求的所有必填字段，需要用友根据Metro提供的字段信息，修改接口。

实现知行之桥 EDI 系统与用友ERP对接的过程中，使用到了动态 token，需要获取并放到指定文件夹中。点击了解获取token的操作流程

接下来需要在 REST 端口中放置获取到的URL，需要在高级设置选项卡下勾选允许在 URL中使用ArcScript。如下图所示：

4.ERP系统中需要的信息在EDI系统中的实现

用友系统中对企业不同客户分配了不同的客户编码（BP code），例如对接Metro EDI 项目中可能会涉及到多个 Metro 工厂的信息。EDI系统处理订单的映射关系时，需要新增一个字段用于存放EDI报文中的 Shipto NO.，提供给ERP系统，从而区分不同的BP code。如下图所示：

5. DESADV发货通知的注意事项

对接 Metro 的EDI项目中，企业发出的 DESADV发货通知没有使用到包装信息，只需要提供物料+数量即可。

扩展阅读：EDI是什么？

阅读原文：零售EDI：Metro EDI项目案例