[EDI 案例] 快速对接Kromberg & Schubert EDI

在EDI需求层面，Kromberg & Schubert 和NEXANS几乎完全一致，使用的报文标准也是VDA标准，业务报文类型和NEXANS相比，除了VDA 4905 Call-off需求预测和VDA 4913 发货通知, 还多了一个VDA 4906，也就是发票。

扩展阅读： 汽车电缆行业EDI整体解决方案

需求解读

• 传输协议：OFTP2.0 连接
• 报文标准：VDA
• 报文类型：VDA 4905（需求预测）, VDA 4913（发货通知）, VDA 4906（发票）
• 实施方案：XML方案，集成SAP系统

方案分析

在Kromberg & Schubert 需求中，依然采用的是自定义XML集成SAP系统方案。

接收方向，在OFTP收到Kromberg & Schubert 发来的VDA 4905报文后，会被转发到EDIToXML端口，将EDI报文转换为标准XML文件，然后进入XML Map端口，将标准XML文件映射为自定义XML文件，并存入指定的共享文件夹目录中，SAP读取后，将文件移送至另外一个目录。

发送方向：

EDI从指定的共享文件夹目录中读取自定义XML，并将文件移送至另外一个已读取目录。将自定义XML经过XML Map端口，映射为标准XML，然后经过XMLToEDI端口，转换为EDI报文，通过OFTP端口发出。

报文解读

我们在上一篇《快速对接耐克森/NEXANS EDI》中，详细讲了VDA 4905 和 VDA 4913报文，本文中我们就不再过多的赘述此部分了，有兴趣的同学可以前往《快速对接耐克森/NEXANS EDI》查看更多。

另外，在Kromberg & Schubert 和Nexans的VDA 4913报文中，比较重要的一点区别在于，Kromberg & Schubert 要求VDA 4913报文中必须包含包装信息，而Nexans对此则没有硬性要求。

接下来，我们着重来讲VDA 4906报文。

VDA 4906，表示发票，是某汽车电缆行业客户发送给Kromberg & Schubert ，用于结算账务。主要包含以下业务数据：

传输头部数据

• Customer Code：客户编码
• Supplier Code：供应商编码
• Transfer Number (old)： 上一次传输编号
• Transfer Number (new)： 本次传输编号
• Transfer Date： 传输日期
• VAT Id Number Receiver (VAT Id No.)： 接收方税号
• VAT Id Number Sender (VAT Id No.)： 发送方税号

发票头部数据

• Invoice Number: 发票号
• Invoice Date: 发票日期
• VAT Amount: 税额
• Final Invoice Value: 最终发票金额
• Unit Of Currency: 货币单位
• VAT Rate: 税率
• Customer Plant: 客户工厂
• Net Price: 净价

发货明细数据

• Delivery Note Number ： 发货单号
• Shipping Date ： 发货日期
• Unloading Point ： 卸货点
• Mode Of Shipment ： 发货方式
• Contract/order Number ： 订单号
• Shipping And Handling ： 发货包装
• Packing Charges ： 包装费用
• Code Means Of Transport ： 运输方式

物料明细数据

• Customer Item Number： 客户物料编号
• Supplier Item Number： 供应商物料编号
• Delivery Quantity： 发货数量
• Price Unit： 单价
• Unit Price： 价格单位
• Total Price： 总价
• Country Of Origin： 原产国
• VAT Preference： 增值税优惠
• Advance Payment In Percent： 预付款比例

实施问题

在本次项目实施中，因为NEXANS和Kromberg & Schubert 差不多是同期实施的，这也是我们首次接触到VDA标准的EDI报文，同时贸易合作伙伴提供的EDI规范并不全面，里面有一些信息缺失，而且对于字段的类型解释也不清楚，在实施的时候也走了许多弯路。比如，对于VDA报文来说，每个字段长度都是固定的，如果是数字类型的数据，长度不够的需要在左边补0 ，补足位数；如果是字符类型的数据，长度不够的需要在右边补空，补足位数。还有，有些合作伙伴发来的VDA报文是自带换行的，而有些则是不会换行。另外，因为是接触的第一个VDA标准的EDI报文，当时的知行EDI产品还没有专门的端口可以对VDA报文进行处理，实施工程师只能将VDA报文当做一个平面文件来处理，根据字段长度去从报文中截取业务数据，产生了很大的代码量，而且代码逻辑复杂，难以维护。

不过，现在知行EDI平台已经有VDA端口，可以实现VDA报文和标准XML格式文件之间的相互转换，现在处理VDA报文是十分方便的。关于为什么要把XML作为知行EDI系统中一种常用的中间格式，可以参考文章《为什么工作流中围绕XML做EDI报文数据解析/生成？》

前往知行软件官网主页，了解更多。