博澤Brose EDI項目案例
Brose 是一家德國的全球性汽車零部件供應商，主要為全球汽車制造商提供機電一體化系統和組件，涵蓋車門、座椅調節系統、空調系統以及電動驅動裝置等。Brose 以其高質量的創新產品聞名，在全球擁有多個研發和生產基地，是全球第五大家族企業，也是全球領先的汽車零部件供應商之一。
梳理需求文檔
EDI項目開始前，Brose 將會向交易伙伴提供本次對接中需要的EDI規范文檔，包括 DELFOR物料需求計劃（版本號：D04A）、DESADV發貨通知（版本號：D20B）。本案例中，Brose作為采購商，向其供應商汽車行業A公司采購。因此A公司需要接收Brose發來的DELFOR物料需求計劃，向Brose發送DESADV發貨通知。
EDI連接測試
Brose支持的傳輸方式包括：OFTP2以及SFTP，由于Brose更推薦交易伙伴使用OFTP2，因此本案例將以OFTP2為例，為大家介紹如何建立OFTP2連接通道。
Brose與供應商需要交換包含OFTP2配置信息的文檔，包含SSID、SFID、服務器、IP地址、端口號等信息。通過知行之橋EDI系統搭建對接Brose的OFTP2連接通道，需要先在 個人設置 選項卡下，配置A公司自己的OFTP連接信息。
接下來在 工作流 選項卡下創建一個OFTP端口（功能模塊），點擊下圖左上方的OFTP端口，在右側彈窗的 設置 選項卡下配置Brose的OFTP連接信息。
在測試階段，向Brose發文件時，可以在OFTP 端口的 輸入 選項卡下，點擊 更多，上傳測試文件。
接收來自Brose的文件時，可以點擊 輸入 選項卡旁邊的 輸出 選項卡，查看EDI系統收到的文件。
實施方案
A公司的EDI系統與Brose的EDI系統之間可以通過OFTP2傳輸通道建立連接，那么A公司應該如何將業務數據提供給EDI系統呢？
如果A公司內部有ERP系統或者其他業務系統，則可以選擇與EDI系統進行集成。知行之橋EDI系統支持的集成方案包括：[中間數據庫方案][]、[REST API][]、WebService、SFTP或共享文件夾等，用戶可以根據實際需求進行選擇。以REST API方案為例，基于知行之橋EDI系統，通過REST API 來集成A公司的ERP系統，EDI和ERP通過對方提供的接口調用文檔，使用REST API來調用對方的接口，以JSON或者XML格式來進行業務數據的傳輸。
主要過程包括：
1.EDI整理所需業務字段
2.EDI實施顧問、ERP顧問以及A公司的業務負責人進行業務字段和結構確認
3.EDI和ERP各自進行接口的開發，提供給對方各自的接口調用文檔
4.集成測試，API集成測試一般是與EDI業務測試同步進行的，便于驗證能否將Brose發來的DELFOR數據解析進A公司的ERP系統，以及A公司ERP系統中提供的發貨通知數據在被EDI系統進行格式轉換后生成的DESADV報文能否順利被Brose處理。
項目成果
根據以上需求，在知行之橋EDI系統中搭建如下所示的工作流:
知行之橋EDI系統將不同的功能封裝至一個個成熟的功能端口中，實現低代碼操作。通過藍色連接線連接各個功能端口，清晰展示數據流向，方便用戶快速定位問題。
EDI 業務測試
DELFOR 物料需求計劃
A公司需要接收Brose發來的DELFOR物料需求計劃，在知行之橋EDI系統中，通過搭建如下所示的工作流即可實現：
物料需求計劃的處理流程
1.通過OFTP連接通道收到Brose發來的DELFOR報文
2.借助EDIFACT、XML Map以及JSON端口將DELFOR報文轉換為Json格式
3.借助REST端口調用A公司提供的接口，將包含物料需求計劃數據的Json文檔推送至A公司的業務系統中。在REST端口的 設置 選項卡下，配置必要的信息：將 方法&URL 設置為 POST，URL和認證類型由A公司的IT部門提供，正文類型設置為 raw，Content Type為application/json。
4.A公司的業務系統將會根據數據的接收情況回復不同的response，結構如下所示：
5.通過在Notify端口補充自定義腳本實現釘釘通知
為了及時提醒A公司的相關人員，Brose發來的物料需求計劃在進入業務系統時保存失敗，可以在Script端口添加代碼，設置釘釘通知。
代碼如下：
<arc:set attr="json.uri" value="[FilePath]" />
<arc:set attr="json.jsonpath" value="/json" />
<arc:call op="jsonDOMSearch" in="json" >
<arc:set attr="response.status" value="[jsonpath(RTYPE)]" />
</arc:call>
<arc:if exp="[response.status|equals('E')]">
<arc:set attr="check.sslcert" value="*"/>
<arc:call op="httpGet" in="check">
<arc:catch code="*">
<arc:set attr="notify.url" value="https://oapi.dingtalk.com/robot/send?access_token=52f30b4d79a6dae6d34d6e0ceb627de91ec33033a59a8bb955ec6c0137730476"/>
<arc:setm item="notify">
url = https://oapi.dingtalk.com/robot/send?access_token=52f30b4d79a6dae6d34d6e0ceb627de91ec33033a59a8bb955ec6c0137730476
postdata = {"at": {"isAtAll":false},"text": {"content":"業務警報：知行之橋REST端口調用A公司ERP接口失敗，請檢查！"},"msgtype":"text"}
contenttype = application/json
</arc:setm>
<arc:call op="httpPost" in="notify" />
</arc:catch>
</arc:call>
</arc:if>
配置成功之后，在釘釘中的通知效果如下：
DESADV 發貨通知
A公司需要根據Brose發出的DELFOR物料需求計劃回復DESADV發貨通知，在知行之橋EDI系統中，通過搭建如下所示的工作流即可實現：
DESADV發貨通知的處理流程
1.首先A公司的ERP系統通過調用EDI系統的接口，將Json格式（知行的EDI顧問將會提前設計好Json模板，A公司只需要據此模板填充對應的業務數據即可）的發貨通知數據傳入知行之橋EDI系統的 Webhook端口。需要在Webhook端口中配置請求格式為json,還需配置 用戶 以及受信任的ip地址：
2.借助JSON端口、XML Map端口以及EDIFACT端口，將包含發貨通知數據的Json文件轉換為Brose要求的DESADV報文。 3.通過OFTP端口，將DESADV報文發送給Brose。
DESADV發貨通知的測試注意事項
對于接收到的DESADV發貨通知，Brose會通過郵件回復一個PDF格式的VDA 4987錯誤報告，詳細列出了DESADV報文中的每一個字段信息，如果驗證成功會在第一列用綠色高亮標記，如果驗證失敗則會在第一列用紅色高亮標記。
1.DESADV報文的協會指定代碼為固定值
UNH02的位置需要寫入固定值：GAVF30，并且是EDI報文的必填值。示例：
UNH+1+DESADV:D:20B:UN:GAVF30'
2.測試過程中使用的測試數據需要盡可能貼近實際生產數據，以日期格式為例，Brose支持以下兩種格式：
當DTM01值為102 時，日期格式為：YYYYMMDD，例如：20241202； 當DTM01值為203時，日期格式為：CCYYMMDDHHMM，例如：202412021539
示例：
DTM+137:202412021539:203'
3.當RFF01的值為ANK時，表示當前傳輸的數據為由9位數字組成的DUNS編號。示例如下：
RFF+ANK:310010022'
4.LOC字段傳輸卸貨點信息，卸貨點ID必須是由5位字符組成的，示例如下：
LOC+11+RAUKC::92'
5.LIN字段傳輸物料信息，物料編號必須由10位字符組成，示例如下：
LIN+++A62404-110:IN'
6.訂單編號必須由10位字符組成，示例如下：
RFF+ON:5508856298'
DESADV發貨通知的包裝信息
不同版本號的DESADV報文規范中對于包裝的描述和規定有很大區別，因此開始EDI項目實施前請務必與Brose確認DESADV報文的版本號。
基于Brose提供的版本號為D20B的EDI報文規范，需要考慮將相同規格的托盤進行合并，這里的相同規格是指：每托箱數相同，每箱數量相同，物料相同。
確認托盤結構：與Brose以及企業內部業務人員確認當前發貨通知中有無空箱、蓋子或者其他輔材。以下是一個包裝示例：
如果您希望了解有關EDI對接的相關信息，歡迎交流。
浙公網安備 33010602011771號