「檔案有傳到了。」

做 EDI 整合時，聽到這句話，我還會想繼續確認：格式有通過嗎？資料轉好了嗎？業務單據建立了嗎？從收件到完成，中間每一步都需要有清楚的狀態。

本篇名詞小筆記

• EDI：電子資料交換（Electronic Data Interchange），讓企業與合作夥伴依約定格式交換商業文件。
• B2B：企業對企業（Business-to-Business），指企業與外部夥伴之間的系統或商業流程整合。
• ACK：確認訊息（Acknowledgement），用來告知對方文件已接收或業務處理已完成；實際語意必須由雙方約定。
• Checksum：檢查碼，依文件內容計算固定值，用來確認傳輸前後的資料是否一致。
• DLQ：死信佇列（Dead Letter Queue），用來存放無法順利傳遞或處理的訊息，等待人工接手。

今天要解決的問題

如果只留下成功或失敗，後面就很難說明。外部夥伴（以下簡稱夥伴）看到已傳送，我們看到已接收，但單據還沒建立，這時最需要的，就是能查到中間卡在哪一步。

所以我會把一份交換文件分成四步來看：收到、格式驗證、內部資料對應、業務處理。哪一步失敗，處理方式也不同。有些需要夥伴修正內容，有些則要由內部追查原因。

架構師視角：分階段狀態與可追蹤欄位

每份資料，我會保留 interchangeId、partnerId、documentType、version、receivedAt、checksum、correlationId 與 processingStatus。原始檔也要依資料分類安排加密、存取權限與保留期限，之後才能在受控範圍裡查閱。

圖 Day 20-1：EDI／B2B 處理流程。

為了讓後面有人知道怎麼接手，圖上把格式失敗、業務失敗與成功分開。格式不符先到隔離區，業務失敗進 DLQ 等待人工處理；至於 ACK，還要依雙方約定的階段與意思回覆。

缺少 checksum 與 interchangeId，對帳只能靠日期與金額比對，遇到重送或部分處理就無法釐清。前者證明收到的內容與夥伴送出的一致，後者讓雙方可以指同一份文件，兩者的組合是爭議處理的基礎。

ACK 如果在接收時就回，對方可能以為整筆交易已經完成，所以 processingStatus 我會把已接收和業務成功分開，也要先和夥伴講好，ACK 目前只代表收件。

工程師視角：分離傳輸、驗證與業務處理

實作也跟著分成傳輸、格式驗證與業務處理。每一段保留自己的狀態，重試時就只需重做失敗的那一段，不必讓夥伴每次都重新傳送整份文件。

夥伴之間是系統對系統交換，沒有真人可以被導去登入畫面輸入帳密，使用者導向的登入流程因此不適用。來源與內容完整性又都要驗證，所以實務上會採用夥伴專屬憑證加上訊息簽章：以預先交換的金鑰對內容計算簽章，接收端重新計算並比對。

不過簽章正確不代表這是第一次送來：有人在傳輸途中複製了整包請求，稍後原封不動送出，簽章一樣會過——他不需要知道金鑰。所以簽的內容還要帶上時間戳與一次性的隨機值，接收端記下用過的值，同一個不收第二次。

夥伴的格式與欄位用法可能調整，之後要能找回某份文件當時是照哪一套規則處理，所以對照表帶版本號，每筆中繼紀錄都記下當時用的是第幾版；規則改了，舊單據還是查得到自己是照哪一版處理的。

人工重送的 API 一定要填原因，操作者則由登入身分自動帶入，兩者一起寫進那則訊息的處理紀錄；沒填原因就拒絕。對外 ACK 的意思寫進介面規格，雙方理解一致，後面對帳才不會各說各的。

策略取捨與限制

重試之前，先看看是哪一種錯誤。暫時性問題可以等待後再試，格式或內容有問題，就需要修正或請人確認。先分清楚，才不會讓同一個錯誤一直重跑。

驗證方式與衡量指標

未結文件數也值得持續看。處理中的文件本來就會計入，但如果越積越多，就要往下查哪些文件等待太久，以及下一步由誰接手。

今天先整理到這裡

我希望 EDI 驗收時，每份文件都查得到狀態、結果與負責人。能夠一路說明它怎麼被處理，這份整合才比較完整。下一篇，轉到仍在 PoC 驗收的 RAG，先從用途與風險開始整理。

參考資料

1. ASC X12, ASC X12 Transaction Sets，查閱日期：2026-10-03。
2. NIST, NIST SP 800-53 Audit and Accountability，查閱日期：2026-10-03。