再讲EDI之三

昨天说到Oracle脑子有没有瓦特。

答案嘛当然是么瓦特!!觉得瓦特的小伙伴赶快放下手上的工作去医院哦亲,身体可是上线的本钱哦亲。

为什么这么说呢?

假设,我们已经收到了EDI中间商传输过来的鬼一样的报文,下一步就是读。首先每个客户可能用的都是不同的EDI标准,发送的文件类型也不止一种。如果人肉解析的话....

其次,既然是数据交换,那就不只是接收数据,还要发送数据,比如当我们对客户的订单进行了发运之后,通常客户都需要我们返回ASN(Advanced Shipment Notice),表示我们发出了货物,

因此我们还需要对不同的客户生成不同格式的报文。

第三,客户发送的数据可能发生变更,比如某C汽车公司,今天做计划的时候说12/18号要480个A,明天说12/18只要360个A,后天说还是要480个,结果到了12/18号发货前两小时,说只需要240个。因此对于我们来说,存在着新数据替换旧数据的逻辑。

好吧,听起来似乎是必须要用ECE和RLM了。那这两个模块就能直接对原始报文进行翻译和进一步的分析处理么?

嘿嘿,不能。

这两个模块使用的前提就是需要一个EDI Translator把标准格式的报文转换成Oracle可以识别的Flat File,大概长这样:

下面这张图是ASC X12与EDIFACT两种报文标准对不同文件的命名:

F公司和客户之间进行了这些文件的对接:

Purchase Order, Planning Schedule和Shipping Schedule都是由F公司的客户发送的,可以简单粗暴的理解成:

来自客户的850/ORDERS:进入到Oracle之后就是我们的销售订单

来自客户的830/DELFOR:进入到Oracle之后就是我们的预测(FOR就是forecast的意思)

来自客户的862/DELJIT:进入到Oracle之后对应Sales Agreement Release(JIT就是Just in Time的意思)

Ship Notice则是F公司在发运后返回给客户的文件,返回我们的实际发运信息。

I公司收到这些原始报文之后,会将客户的报文解析为Flat File后发送给我们,反过来,也会接收Oracle发送的Flat File并生成报文传递给客户。而ERP和I公司间文件的传输则是通过SFTP来完成的。

即,I公司负责把翻译后的文件放到服务器上,Oracle端开发请求抓取服务器上的文件,并且把这些文件存放在Oracle的服务器上。反向流程大家可以自行脑补。

对于收到的文件,Oracle是怎么处理的呢?ECE和RLM到底扮演了什么角色呢?

我们下期再说咯,白白~

  • 发表于:
  • 原文链接:http://kuaibao.qq.com/s/20171213B0D41G00?refer=cp_1026

相关快讯

扫码关注云+社区