[案例] 快速对接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报文数据解析/生成?》

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

了解更多EDI,请您电话 150-0298-3180 / 177-8250-8152 或邮件 edi@kasoftware.cn 联系我们,获取 30 天全功能 免费试用 版本EDI软件。
标签: , , , , , , ,
文章分类 edi 电子数据交换, EDI实施案例, edi方案工作流, mft 管理文件传输, oftp(2.0), share 知识分享, 动态