首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >[EDI 案例] 快速对接Kromberg & Schubert EDI

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

原创
作者头像
EDI顾问-杨欢
修改2020-04-16 10:25:32
5790
修改2020-04-16 10:25:32
举报

在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报文数据解析/生成?》

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档