電子數據交換 (Edi)

甚麼是電子數據交換（EDI）？

電子數據交換（EDI）是指組織之間按照雙方同意的標準，以電腦對電腦方式交換結構化商業文件。在物流、電子商務及國際貿易中，EDI 讓買家、供應商、倉庫、承運商及其他貿易夥伴所使用的系統交換採購訂單、出貨通知、運輸指示及發票等資訊，而無需人工重新輸入每份文件。

EDI 的主要特點並不只是以電子方式傳送資訊，而是將資訊組織成接收軟件可按照雙方同意的規格解讀的欄位、區段及訊息。因此，附加在電郵中的 PDF 發票本身並不是 EDI 發票：在商業系統可以使用其內容之前，仍可能需要由人員或文件處理工具提取相關內容。

EDI 描述的是交換商業資訊的方法，而不是某一種軟件產品、網絡或檔案格式。要建立可運作的安排，必須具備兼容的文件定義、通訊方法、識別碼及業務規則。

物流及電子商務中的 EDI

EDI 連接跨越不同組織界線的活動。零售商的採購系統可以建立訂單，供應商的系統可以確認訂單，而倉庫則可以接收準備貨物的指示。其後，出貨資料及發票可以作為獨立訊息，在相關系統之間傳送。

在電子商務中，EDI 可以支援面向消費者的網上商店背後的企業對企業流程。例如，網上零售商可以使用 EDI 向供應商訂購庫存，或與倉庫交換履行訂單的資訊。消費者的結帳交易與零售商其後發出的 EDI 訊息屬於相關的業務事件，但不一定是同一項交易，也不一定使用相同的技術介面。

在跨境貿易中，EDI 可以傳送國際運輸及商業文件所需的資訊。海關管理機構也可能按照其自身規格使用結構化電子訊息。然而，與供應商或承運商交換 EDI 訊息本身並不構成海關申報，也不代表符合監管要求或授權放行貨物。

常見商業文件

以下例子說明文件的功能，而不是必須遵循的流程。所使用的訊息取決於貿易關係及適用的實施指南。

預先出貨通知通常縮寫為 ASN，用於描述預期出貨；它不能證明貨物已經抵達。同樣，出貨狀態訊息也不會自動成為交付證明。其含義取決於所報告的事件及相關支援資料。

標準、格式及通訊方法

EDI 標準定義商業訊息的結構及其數據元素的含義。兩個成熟的標準系列是 X12，以及聯合國行政、商業及運輸電子數據交換規則，稱為 UN/EDIFACT。GS1 亦維護 EDI 標準，包括以 UN/EDIFACT 為基礎的 EANCOM，以及 GS1 XML。

在 X12 中，例子包括 850 採購訂單、856 出貨通知／艙單及 810 發票。UN/EDIFACT 提供 ORDERS 採購訂單、DESADV 發貨通知及 INVOIC 發票等訊息。這些例子在不同標準中具有相關的業務目的，但其結構及實施要求並不互換。

單靠標準並不能定義貿易關係中的所有細節。合作夥伴還必須就適用版本及實施指南、必要欄位、允許使用的代碼、識別碼及驗證規則達成共識。兩個組織即使支援同一標準系列，在其系統能夠交換可用訊息前，仍可能需要進行資料映射工作。

AS2 是一種透過 HTTP 交換商業數據的通訊規格，並提供安全及回執機制。它不是採購訂單或發票格式。增值網絡（VAN）可以提供中介訊息交換服務；同樣地，它也不同於商業文件標準。

EDI 交換如何運作

1. 業務事件產生數據。例如，買家在企業資源規劃或訂單管理系統中批准採購訂單。
2. 數據被映射至訊息。翻譯軟件會將內部欄位轉換為雙方同意的標準及實施指南所要求的結構。
3. 檢查外發訊息。驗證可能會檢查語法、必要欄位、代碼值及合作夥伴特定要求。
4. 傳送訊息。訊息會經由雙方同意的通訊渠道，傳送至接收方或中介。
5. 接收方驗證並翻譯訊息。接收系統會檢查訊息，並將已接受的資訊映射至其內部應用程式格式。
6. 進行業務處理。接收應用程式可能會建立訂單、記錄預期收貨，或將例外情況轉交審查。
7. 核對回覆。技術回執、確認及業務回覆有助發送方了解交換結果。

這些步驟並不能保證每項交易都會自動處理。即使訊息在結構上有效，未知的產品識別碼、無效的送貨地點、重複的文件編號或不支援的計量單位，仍可能需要人工介入。

接收、驗證及業務接受

EDI 確認在不同層面運作。傳輸回執可以表示訊息已到達通訊端點。功能性或實施確認可以報告結構檢查的結果。業務回覆則可以傳達訂單或其他要求已被接受、拒絕或更改。

這些訊號不應被視為等同。成功傳送並不一定表示訂單已獲接受，或貨物將會出貨。確認的具體含義必須按照相關規格及貿易夥伴協議解讀。

訂單至出貨示例

零售商可能透過 EDI 向海外供應商發送採購訂單。供應商系統會檢查產品識別碼、數量及要求的交付資料。如果貿易安排包括訂單回覆，供應商可以透過獨立訊息傳達接受訂單或提出更改。

貨物準備妥當後，供應商可能會發出預先出貨通知，列明出貨及其內容。接收倉庫可以使用該資訊準備收貨，並將預期數量與實際收到的貨物進行比較。供應商也可能發送發票，以便零售商的財務系統處理。

此例展示 EDI 如何連接不同組織之間的記錄。它不表示所有參與方都使用相同軟件，也不表示每項訊息都會即時送達，或商業文件可以取代運輸及海關要求。要配對採購訂單、出貨參考資料及發票，仍需要一致的識別碼及雙方同意的業務邏輯。

EDI 及相關技術

在所有架構中，EDI 與 API 並不是互相排斥的選擇。組織可以使用 EDI 訊息進行合作夥伴交易，並使用 API 將這些交易連接至內部應用程式。合適的安排取決於文件要求、合作夥伴能力、時間需求及營運控制，而不只是技術名稱。

實施考慮及限制

當系統成功交換及處理兼容訊息時，EDI 可以減少重複的人工數據輸入。它不能修正不準確的來源數據、解決商業爭議，也不能消除處理例外情況的需要。自動化取決於技術兼容性及所交換商業資訊的質素。

在建立 EDI 連接前，貿易夥伴應澄清以下營運事項：

• 文件範圍：需要哪些訊息？哪些業務事件會觸發這些訊息？
• 識別碼：如何識別及配對產品、地點、參與方、訂單及出貨？
• 訊息要求：適用哪些版本、必填欄位、代碼清單及映射規則？
• 通訊及安全：需要哪種連接方法、驗證安排及存取控制？
• 確認：哪些回覆代表已送達、已驗證及已獲業務接受？
• 例外處理：由誰調查被拒訊息、缺失回覆及不一致數據？
• 防止重複：如何區分重新傳送與新的業務交易？
• 測試及變更控制：在變更投入生產前，如何測試映射及合作夥伴要求？

營運監控應區分通訊故障、數據驗證故障及業務例外。重新傳送訊息可能可以處理傳輸失敗，但不能修正無效的產品代碼。在沒有重複控制的情況下，重新傳送已成功處理的訂單也可能造成意外的第二項交易。

常見問題

EDI 在物流中代表甚麼？

EDI 代表電子數據交換，即系統之間結構化地交換商業文件。在物流中，這些文件可以包括出貨通知、運輸指示、發票及出貨狀態訊息。

透過電郵發送的 PDF 是 EDI 文件嗎？

單靠這一點並不是。PDF 可以以電子方式呈現商業文件，但 EDI 需要接收系統能夠按照雙方同意的規格解讀的結構化資訊。

EDI 與 API 是否相同？

不是。EDI 涉及標準化商業文件交換，而 API 定義軟件與其他服務互動的方式。一項整合可以同時使用兩者。

EDI 確認是否代表訂單已獲接受？

不一定。確認可能只代表傳送成功或結構驗證完成，而不是業務接受。其含義取決於訊息類型及貿易夥伴協議。

資料來源

• UNECE：UN/EDIFACT — 行政、商業及運輸數據結構化電子交換的官方框架。
• X12：交易集 — 商業交易集的官方說明，包括採購訂單、發票、出貨通知及確認。
• GS1：電子數據交換 — 商業訊息標準，以及 GS1 EDI、EANCOM 與 GS1 XML 之間的關係。
• RFC 4130：使用 HTTP 的基於 MIME 的安全點對點商業數據交換，即適用性聲明 2 — AS2 傳輸、安全機制及回執通知。