在EDI需求层面，Kromberg & Schubert 和NEXANS几乎完全一致，使用的报文标准也是VDA标准，业务报文类型和NEXANS相比，除了VDA 4905 Call-off需求预测和VDA 4913 发货通知, 还多了一个VDA 4906，也就是发票。
#### 需求解读
- 传输协议：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报文数据解析/生成？》
