先決定資料由誰管理，再討論API
網站與ERP串接，是讓系統依約定交換資料。開始前最重要的問題是「哪個系統的資料為準」，以及何時交換、誰能修改、失敗後如何處理。API串接是可能的交換方式之一，並不代表所有資料都適合雙向即時同步。
若ERP沒有適合的介面，也可能需要評估檔案匯入、排程交換或中介服務。實際方式取決於既有系統、資料品質及維護能力，不能只看到有API就假定可以直接整合。
| 資料 | 先確認的責任 | 驗收問題 |
|---|---|---|
| 商品與規格 | 哪個系統建立商品編號、規格和上下架狀態？ | 修改或停用後，網站是否依規則更新？ |
| 訂單 | 網站何時將訂單送入ERP？付款狀態由誰更新？ | 重送是否產生重複訂單？取消或退款怎麼處理？ |
| 庫存 | 帳面庫存與可售量是否相同？同步方向是什麼？ | 多人同時購買、缺貨與保留量如何處理？ |
| 會員 | 哪些欄位需交換？是否有一致的識別方式？ | 資料更新、權限限制與重複資料如何處理？ |
不要只測試正常成功的情況
實務需求應包含介面逾時、欄位缺漏、資料格式不符、重複送出與外部服務暫停。對每一種情況，先約定是否重試、如何記錄、誰收到通知，以及何時需要人工介入。
例如訂單已建立但ERP回覆逾時，直接重新送出可能造成重複資料。應依實際介面設計識別與重送規則，再用測試資料驗證；這是需要討論的設計情境，不代表每種ERP都有相同功能。
權限與環境要分清楚
串接帳號應只取得必要的資料和操作範圍。測試與正式環境也應分開管理，避免測試訂單進入正式出貨或通知流程。紀錄需要有助於追查問題，同時避免不必要地保存密碼或完整敏感資料。
上線前應確認誰保管介面設定、如何更新存取憑證、系統異動由誰通知，以及備份與回復的責任。這些分工會影響日後維護成本，應與功能一起討論。
先挑一條完整流程做驗收
可先選「建立訂單→確認付款→送入ERP→更新處理狀態」等核心流程，逐步核對每個欄位、狀態與例外情況，再擴大至其他資料。是否即時交換，應依業務需要及介面限制確認。
- 列出來源欄位、目的欄位與格式轉換規則。
- 確認重複、漏送、逾時和取消的測試案例。
- 安排必要的角色與通知窗口。
- 確認上線切換、觀察期及異常回復方式。
- 約定外部ERP或網站改版後的相容性與維護責任。
既有ERP串接與從零開發，範圍不同
若既有ERP已能處理內部作業，重點可能是整理介面與網站資料交換；若主要流程仍沒有適合的系統，則需要先評估內部系統或ERP開發。兩者可在同一專案搭配，但應分別確認範圍與驗收。
把「不重複建單」寫成可驗收的情境
假設網站送出訂單後未收到ERP回覆，測試人員重送同一筆資料，應核對是否只建立一筆對應訂單、能否查到處理結果，以及通知窗口是否清楚。實際防重方式需依介面設計，不能只改HTTP方法名稱就認定資料不會重複。此處是驗收示例，不是已實作的客戶系統。
若真正的問題是現有系統無法支援內部作業，可再比較客製化與套裝ERP的選型方式，將開發需求和單純串接分開確認。
常見問題與補充說明
網站與ERP一定要即時雙向同步嗎？
不一定。應依業務需要、介面能力與資料責任，選擇單向、雙向、事件觸發或排程交換；兩邊同時可改同一欄位時，也要定義衝突處理。
ERP沒有現成API，還能評估串接嗎？
可以先向原系統供應商確認允許的介面、資料匯出入及維護條件，再評估檔案或其他交換方式。不能在未確認授權、資料格式與責任前，直接承諾可以無限制串接。
下一步：把問題整理成可討論的需求
可先了解企業系統整合、資料庫與API串接、客製ERP開發，或提供目前狀況與目標。龍心以台中為據點服務全台，可視專案安排到場，實際合作內容與方式依需求確認。
技術依據與延伸閱讀
本文由龍心數位科技整理，協助企業準備需求與比較方案。封面為 AI 製作的概念示意，非客戶專案畫面。