sftp端口（重摩之王EDI案例）

一、企业简介

重摩之王系“中国企业500强”，总部设立于重庆，员工9000余名，在全国各地拥有20余家控股公司和参股公司。聚焦摩托车、通机等主营业务,产品畅销全球100多个国家和地区，各业务销售规模均处于行业前列，与BMW、TORO、Cummins等全球500强企业建立了战略合作伙伴关系。

二、项目背景

海外合作伙伴 STIHL提出了EDI请求，通过EDI实现业务流程自动化，保证与STIHL之间的订单、发货等信息快速高效的同步，重摩之王找到了知行软件作为第三方EDI服务商来与STIHL进行EDI对接。

三、EDI需求

数据传输。STIHL要求通过SFTP客户端连接其SFTP服务器，上传/下载业务数据。上传/下载的业务数据包含DESADV(发货通知)、ORDERS(订单)，文件结构需满足EDIFACT标准，详情如下：

业务代码

业务含义

业务报文

传输方向

DESADV

Dispatch advice message

发货通知

重摩之王上传

ORDERS

Purchase order message

订单

重摩之王下载

数据安全。出于对数据安全的考虑，重摩之王选择本地化部署。本地化部署是将知行之桥部署在重摩之王的本地服务器，可以在正常使用软件的同时有效地保障数据的安全，防止数据泄露。

ERP系统集成。重摩之王要求与自身的ERP系统做集成，实现业务流程的自动化。重摩之王本身就有ERP系统，产品信息均在ERP系统中，EDI系统与ERP系统集成可以有效地在数据填写过程中减少人工参与，提高数据的准确度和正确率。

四、解决方案

针对以上需求，我们提供了知行之桥电子数据交换（EDI）系统，将其部署在客户本地服务器中，使用EDI系统内置的SFTP端口与STIHL的服务器进行连接，在SFTP端口中设置文件上传、下载路径以及服务器等信息，并通过中间数据库方式与重摩之王的ERP系统集成，从而满足需求。

方案详述

文件下载：通过内置的SFTP端口从SFTP服务器下载ORDERS订单文件，将EDI文件转换为XML文件，随后将XML文件中的数据存储到重摩之王本地数据库，此时重摩之王就可以在ERP系统中查询ORDERS信息了。SFTP端口：下载STIHL上传的EDI文件。格式转换：将EDI文件转换为方便数据库读取的X12格式的文件。数据存储：将EDI系统处理过的STIHL发送的数据，同步到重摩之王的本地数据库中。ERP系统：重摩之王本地数据库的信息同步到ERP系统。

文件上传：重摩之王将DESADV所需的数据填写到本地数据库中，EDI系统设置每间隔60分钟搜索一次数据，将数据转换为XML文件转换为EDI文件，并通过内置的SFTP端口上传EDI文件给STIHL的SFTP服务器，此时一个订单交易就结束了。ERP系统：将ERP系统中的DESADV所需数据同步到本地数据库中。数据调用：EDI系统搜索数据库中的数据，将状态为0（未读取）的数据同步到EDI系统中，并将数据状态回写为2（已读取）。格式转换：将EDI系统读取到的X12格式的文件转换为符合STIHL要求的EDI文件。SFTP端口：将EDI文件上传给STIHL。

五、方案实现

方案实施

·软件安装：在重摩之王本地服务器安装、配置知行之桥。·SFTP连接测试：通过内置SFTP端口，使用了Password加密方式，测试与STIHL的SFTP服务器的安全连接。

注：SFTP服务器的配置中会包含上传、下载路径配置，示例如下：

上传路径

/In

下载路径

/Out

·EDI项目实施：使用EDI系统内置的端口实现：EDI文件的上传/下载、EDI文件和XML文件的互相转换、数据存储和提取。

内容测试

与STIHL进行文件格式测试，保证在正式运行的过程中不会出现由于文件格式的问题，影响交易正常进行。

·下载测试：STIHL上传测试的ORDERS报文到SFTP服务器，EDI系统下载ORDERS，正确读取STIHL发送的报文信息并存储到重摩之王的数据库中。·上传测试：重摩之王在ERP系统中填写测试的DESADV信息并同步到本地数据库，EDI系统读取并转换格式后，上传到SFTP服务器，STIHL按照规范正确读取DESADV报文信息。

方案实现过程中的挑战及解决方案

1.STIHL提供的EDI规范简单，实施难度增加

我们的顾问在实施过程中发现STIHL给的DESADV规范较为简单，例如：

规范中并未提及数据的字符长度、字段必要性条件，顾问参照之前的实施经验，整理出完整的Mapping，减少重摩之王与STIHL关于字符长度和字段必要性条件的核对时间。

2.重摩之王与STIHL关于EDI字段信息的内容填写沟通有误差

DESADV中重摩之王提供的发货船号信息超过了STIHL的字段长度要求，经过多次沟通发货船号信息字段长度的问题双方均无法修改，最后通过添加新字段80/8212来填写本应在80/8213的数据，字段信息对比如下：

原始字段及报文：

添加字段及修改后的报文：

3.DESADV中的包装格式不确定

我们的顾问按照规范设置的包装格式在与STIHL核对时出现错误，但是重摩之王却无法向顾问提供正确的包装格式，最后通过发送两种包装格式进行比对，STIHL回复只有最外层包装的格式才是正确的。实际的包装格式：托盘+外包装+内包装+物料。发送的包装格式：最外层包装。与实际的包装格式相比发送的包装格式发送最外层包装即可，并不影响实际的产品包装。

4.数据填写错误

重摩之王在DESADV中实际发送Serial Number数据不符合之前与STIHL商定的数据要求，在接到STIHL的报错提示后，调整发送数据，随后将应发数据上传给STIHL进行再次确认。

数据名称

实际发送

应当发送

Serial Number

2021010201

0080004099

5.对应的采购商编号提取

重摩之王提出在他们的系统中拥有两个不同的STIHL采购商编号，需要将报文中的该信息提取出来作区分，我们的顾问使用Script端口将EDI文件中的采购商编号提取出来，并用Branch端口加以区分，实现重摩之王的要求。

以上就是我们关于重摩之王对接STIHL的案例分享，如果大家有关于对接STIHL的EDI需求或者希望了解更多的EDI案例，欢迎交流。

更多EDI信息，请参阅EDI全解指南 | EDI通信专家