EDI 是什麼？API VS EDI?EDI 方案EDI優勢EDI 標準 EDI HA部署
EDI的概念
EDI，英文全稱：
Electronic Data Interchange。中文名稱電子資料交換，也稱為“無紙化貿易”。
EDI 旨在實現兩個企業之間核心資料的交換。
幫助企業與交易夥伴傳輸業務資料，如，訂單、發貨通知、發票、物流資訊等。較之傳統的郵件及紙質單據方式，
EDI
更安全、自動、高效，能快速處理大批次業務資料。
EDI 工作過程
1，傳送方準備要傳送的檔案，檔案通常是平面檔案，也可以是圖片、PDF等
2，將平面檔案轉換為標準EDI報文，圖片、PDF通常不需要經過格式轉換，直接傳送給接收方
3，傳送方將標準EDI報文傳送至接收方的EDI系統
4，接收方EDI系統收到EDI報文
5，接收方將收到的EDI報文取出並翻譯成平面檔案
6，接收方將轉換後的資料同步到業務系統中進行處理
EDI的優勢是什麼？
縮短處理時間：短時間大批次處理業務資料，縮短每檔案處理週期
提升資料精準性：資料精準抵達客戶，內容完整無篡改
減少人工誤差：自動化 EDI 取代人工手動上傳，降低人工錄入誤差
節省業務成本：提供供應鏈效率，減少人力成本
降低庫存：用資訊換庫存，減少庫存積壓
促進客戶關係： EDI 系統回執明確業務程序，避免扯皮糾紛
標準化程度高：貫穿全球業務，使用同種協議及標準溝通，方便供應鏈管理。
EDI的 應用場景？
EDI 已廣泛用於汽車、物流、零售、醫藥、電子、化工等行業，EDI的快速發展，其影響已波及全球。小至個體零售商，大至汽車主機廠、國際物流樞紐等，凡是企業間需要傳輸資料，都可以使用 EDI 技術。
我們來盤點下，EDI在多個行業的典型應用。
汽車行業：各大主機廠，比如寶馬 BMW，沃爾沃 Volvo，大眾
Volkswagen，特斯拉 Tesla，保時捷 Porsche等，已經在大範圍內與全球的交易夥伴建立 EDI 連線，
可以有效地在統一平臺管理與上游採購商、下游供應商、倉庫、物流承運商以及代工廠等合作伙伴之間商業資訊的傳遞。比如與下游供應商
使用 EDI 技術對接，主要傳輸的是物料需求預測、ASN 發貨通知，以及發票等資料，甚至還在傳 CAD 圖紙。
物流行業：以VMI為例，VMI具有快速響應、及時補貨的優點，同時VMI 對資訊系統的要求很高，提高資訊化水平，使用EDI技術，VMI 倉庫直連需求方、供貨方的資訊系統，拿資訊換庫存，透過更充分、更快的共享資訊，來降低庫存水平，在VMI環境裡尤其重要。
以運輸為例，在透過EDI 接收到託運方的運輸訂單後，需要及時的透過EDI反饋派車、在途資訊等。
消費類電子： 以蘋果 Apple 為首，透過 EDI 方式貫穿上下游供應商，傳輸訂單、庫存、發票、ASN等資料。使用AS2協議，ANSI X12標準。眾所周知，蘋果 Apple 的成功依賴的是產品的成功以及供應鏈管理的成功，產品是不可複製的，但供應鏈管理使用的EDI技術，是可以複製及間接學習的。
半導體行業：以TI德州儀器為例，在產品和市場佔有率領先的背景下，逐漸在取消代理模式轉為直供模式，進一步提升產品的利潤率，完成德州儀器的長遠目標。當前TI為客戶提供EDI和API兩種方式來整合，傳輸預測、訂單、發票、ASN等資料。使用的是AS2協議，支援多個標準，比如ANSI X12，EDIFACT，RosettaNet。
電商平臺：亞馬遜Amazon、沃爾瑪 Walmart 也在力推 EDI 技術，以適應全球業務的發展。
醫藥行業：國內醫藥行業對接最多的CDE，該標準要求申請人透過Gateway to Gateway（閘道器對閘道器）方式，向國家藥品審評機構提交符合ICH E2B（R3）規範的藥物臨床試驗期間個例安全性報告。其對接的協議就是AS2。
除此之外，部分銀行，也在使用 EDI 技術傳輸付款指令和回執等資料。
EDI是為數不多，可以橫跨多個行業的技術，只要企業間需要傳輸資料，都可以透過EDI來實現。無論是哪個行業使用EDI，都是嘗試透過 EDI，加快資訊流傳輸，更充分、更快的共享資訊。
EDI 檔案傳輸協議
AS2：
AS2是當今業界最流行的B2B協議，而且是傳輸電子資料交換（EDI）檔案的標準協議。AS2 旨在透過Internet安全可靠地傳輸商業文件，並透過資料加密和數字簽名生成資料包，然後基於HTTP（或HTTPS）透過網際網路或任何TCP/IP網路進行安全可靠的資料交換。
AS4：
AS4是一種新興的B2B訊息傳輸協議。它類似於AS2協議，旨在透過網際網路進行連線、資料傳遞、身份驗證以及資料安全傳輸。
OFTP2：
OFTP2是Odette File Transfer Protocol V2的縮寫，一種安全可控檔案傳輸協議。它廣泛的應用於汽車行業的EDI/B2B專案中，旨在實現企業資訊系統之間的資料傳輸。該協議是由Odette OFTP2專家組提出，並且支援資料加密、認證和EERP等重要功能。
SFTP：
SFTP是全球IT專業人士青睞的一種安全檔案傳輸協議，其配置簡單且比較安全。與FTP不同，SFTP可透過單個埠連線，輕鬆穿過防火牆，進行密碼和公鑰認證，並支援強大的資料加密。知行之橋
EDI系統的SFTP 埠是一款全功能SFTP客戶端，能夠透過各種SFTP伺服器的身份驗證，並安全傳輸檔案。
FTP：
知行之橋
EDI系統的FTP 埠使用純文字FTP或啟用SSL與FTP servers進行檔案傳輸。只需提供FTP server的埠及認證方式，知行之橋
EDI系統將與遠端的FTP server的進行自動化檔案傳輸。
SCP：
類似於SFTP，SCP是一種安全傳輸協議，用於上傳或下載SSH server上的檔案。SCP 埠是依賴SCP（Secure Copy Protocol），在知行之橋
EDI系統與SSH Server之間進行檔案傳輸。
EDI 國際報文標準
EDI擁有標準化的商業文件，最常見的有X12和EDIFACT等。X12是由美國國家標準委員會在1979年創立的認可標準委員會（ASC）X12制定的EDI報文標準，而EDIFACT則是聯合國歐洲經濟委員會（UN/ECE）為簡化貿易程式促進國際貿易活動，公佈的一套用於行政、商業和運輸業的EDI國際標準。
EDI標準定義了 EDI 報文中每個資料段以及相應的格式，如檔案的型別、資料欄位、欄位格式。注，不同的行業、地區使用EDI，因版本的同步會略有差異，因此EDI通訊雙方必須使用相同的EDI標準和版本，除了X12 和 EDIFACT，經常還會碰見VDA、Odette標準等。
常用的X12 和EDIFACT報文型別對比：
如何讀懂X12 報文
首先我們先來了解一下X12報文的結構，如下圖所示：
一次EDI傳輸包含一段Interchange，Interchange中會包含一個或多個Functional Group（下文簡稱FG），FG 中會包含一個或多個Transaction。舉例來說，如果需要在一次傳輸中傳輸3個850，以及4個846檔案，那麼就會有2個FG，在850的FG中會有3個Transaction，846的FG中有4個Transaction。
對報文結構有了基本的瞭解之後，我們再來看下如何從報文中獲取資料。以下是一段示例的850報文，每一行開頭（2-3個字元組成）叫做segment節點，代表了特定的業務含義，例如BEG代表報文的開始以及一些主資訊，DTM代表時間資訊，N1代表實體資訊（ship-to、ship-from、bill-to等等）。
我們再進入到某一行來具體看一下，其中*是每個資料元素的分隔符（也可按照實際情況設定為其他符號，120是這一行的物料數量，它的位置是PO102，有一些程式碼代表了特殊的業務含義，例如EA本身在報文裡面就代表了物料的單位，類似的還有PCS、KGM等，除此之外，還有一些不是單獨出現的程式碼，我們把它叫做限定符，於限定右側資料的含義，例如這個地方的VN，它的意義是限定右邊的資料意義為供應商物料編碼，我們一看到VN後面的一串資料就知道供應商物料編碼為 AB3542。
瞭解瞭如何去閱讀資料，我們再來詳細地解析一下這一條850資料，假如我們要獲取以下資料（該表格可由EDI檔案規範中整理獲取）：
例如要獲取訂單號，那麼我們就找到BEG這一行，從左向右數第三個資料元素即08292233294 就是我們要找的訂單號，再比如我們需要找請求交付日期，按照規範我們需要找到DTM這一行，且條件是DTM01=002，取DTM這個元素，那麼就是20101214這一串，就是要找的資料。以此類推，我們可以獲取到報文中的關鍵資訊，如下圖：
如何讀懂EDIFACT報文
首先，我們先來了解一下EDIFACT報文的結構，如下圖所示：
一次EDI傳輸包含一段Interchange（必須有），Interchange中會包含一個或多個Functional Group（簡稱FG），FG段是否出現並不做強制要求，一個FG中可能會包含一個或多個Message。舉例來說，如果需要在一次EDI傳輸中傳送3個ORDERS採購訂單，那麼報文結構為一個Interchange下包含3個Message。
對報文結構有了基本的瞭解之後，我們再來看下如何從報文中獲取資料。以下是一段示例的ORDERS採購訂單報文，每一行開頭由3個字元組成，叫做Segment節點，代表特定的業務含義，例如BGM代表報文的開始以及一些主資訊，DTM代表時間資訊，NAD代表實體資訊（buyer、seller、bill-to等），RFF代表一些參考資訊，LIN代表訂單行物料資訊，QTY代表數量等。
接下來，以LIN行為例，LIN表示Segment起始資訊，+是資料元素Element分隔符（也可根據情況設定為其他符號），：是子元素Subelement分割符，’是段Segment分割符。再來看業務含義：001為訂單行號，0000057G3454為物料號，BP是有固定含義的限定符Qualifier，限定該物料號為買方物料號，如果限定符為VP即為銷售方物料號。類似的限定符還有QTY段的PCE，限定物料數量單位。
最後我們來詳細地解析這一條ORDERS資料，假如我們要獲取以下資料（只列舉了部分資訊段）：
例如，我們要從報文中獲取訂單號以及訂單日期，根據以上表格可以得知會出現在BGM以及DTM段，我們直接在報文中定位到該行，便可得知訂單號為K12345、訂單日期為19980626。其他的資訊可以使用同樣的方法獲取，如下圖：
綜上，就是基本的閱讀X12 / EDIFACT 報文以及獲取業務資料的方法，雖然我們可以直接從
X12 / EDIFACT
報文中讀取到資料，但相信大家可以感受到人工閱讀
X12 / EDIFACT
報文，並從中提取資料是非常麻煩的。報文設計的初衷是為了方便計算機處理，不過直接閱讀報文對於開發人員來說也是有意義的，可以用來對比收到的資料與原始資料是否一致。但對於ERP使用者或者業務團隊來說，很顯然並不需要去讀原始的
X12 / EDIFACT
報文，只需閱讀EDI供應商解析後的資料。EDI在整個資料交換的流程中扮演的更多的是一個傳輸、轉換的角色。
企業級 EDI 解決方案
基於以上 EDI 相關資訊的瞭解，本地化部署EDI，實現與後端業務系統整合時，可考慮以下幾種方案：
tRFC呼叫
（
SAP系統整合
） - IDoc（SAP）埠
，
支援raw IDoc和XML IDoc
，
介面
簡單
配置
即可連線
SAP
系統
資料庫整合
-
連線型別
ODBC， ADO。NET， JDBC；
資料庫
MySQL， SQL Server， Oracle， SQLite， DB2， PostgreSQL，。。。
Web Service
- 透過Internet進行基於HTTP協議的網路應用間的互動
本地路徑檔案傳輸
-
檔案路徑共享，輕鬆互動電子檔案
REST API
-
規範介面
，輕鬆訪問
知行
EDI系統
SFTP/FTP
-
無需程式碼，即可完成訊息的自動上傳
/
下載
高可用
（High-availability cluster）
方案
EDI 系統的單個示例已經能輕鬆地滿足大多數企業的自動化傳輸需求，但是對於資料日處理高達十萬次的大型企業，知行 EDI 系統可以被整合到更復雜的系統中。
知行EDI系統
是一個能夠處理海量連線的企業級應用程式，透過利用可用的系統資源來處理收到的請求併發送訊息。計算機的可用 RAM、CPU 速度、網路頻寬和磁碟空間是知行EDI系統最大吞吐量的主要限制因素。當日處理量達到成千上萬次時，解決方法不是在一個知行EDI系統中處理所有的傳輸，而是建立一個伺服器叢集。
高可用叢集方案的優點：
高可用：故障轉移，服務不掉線
高效能：負載均衡，降低延遲，提高併發
可擴充套件：彈性計算，應對突發業務需求
安全性：多層次安全防護，靈活高效
知行之橋 EDI 系統 是中國製造的擁有自主智慧財產權的中文版EDI系統。知行之橋EDI系統功能主要分為三大部分：
安全可控檔案傳輸：可對接任意EDI系統，比如 Cleo、Axway、IBM等。支援各種通訊方式，如：AS2， AS3， AS4， OFTP/OFTP2， FTP， FTP Server， SFTP， SFTP Server，。。。
資料格式轉換：支援將各種EDI標準報文轉為CSV，XML，Excel等，如X12， EDIFACT， Odette， VDA， RosettaNet， Carogo-IMP， Edig@s，。。。
整合業務系統：可整合 金蝶， 用友， 鼎捷， SAP， Oracle， Infor， QAD， QuickBook， Salesforce，…以及各種MES、WMS系統等等，常用的整合方式有以下集中：
tRFC呼叫（SAP系統整合） - IDoc（SAP）埠，支援raw IDoc和XML IDoc，介面簡單配置即可連線SAP系統
資料庫整合 - 連線型別ODBC， ADO。NET， JDBC； 資料庫MySQL， SQL Server， Oracle， SQLite， DB2， PostgreSQL，。。。
Web Service - 透過Internet進行基於HTTP協議的網路應用間的互動
本地路徑檔案傳輸 - 檔案路徑共享，輕鬆互動電子檔案
REST API - 規範介面，輕鬆訪問知行之橋EDI系統
SFTP/FTP - 無需程式碼，即可完成訊息的自動上傳/下載
知行之橋EDI 系統案例 - Amazon EDI 工作流
藉助知行EDI系統直連Amazon Vendor Central供應商中心&Amazon Fulfillment第三方物流中心的閘道器，實時互動業務資料。
EDI不僅滿足了Amazon供應鏈資訊化要求，增強供應商綜合評估競爭力。同時，消除了手工錄入和處理資料工時和誤差，業務處理效率提升約85%。
視覺化流程設計器，僅需拖拽搭建工作流，無需程式碼 依賴web 介面視覺化配置，即可完成EDI 與 內部系統整合，輕鬆搭建企業級EDI解決方案。
