元器件商城ERP對接怎麼做：庫存價格同步、API介面與RFQ報價回傳如何落地？

適用對象與前置輸入：先明確誰負責什麼

本文適用於正在建置或改造電子元器件商城、並需要與ERP（或進銷存、WMS、財務系統）打通的組織，包括商城產品負責人、ERP實施顧問、後端與整合開發人員、維運與資料品質人員。若商城僅為展示站、無庫存與報價業務，則不在本文範圍內。

前置輸入至少包括：主數據歸屬清單（物料/型號、品牌、封裝、庫存、價格、客戶、報價單分別以哪一端為準）；兩端系統的介面能力說明（是否提供REST/SOAP API、是否支援增量查詢、是否有Webhook或訊息佇列、介面權限與呼叫配額）；欄位字典與單位約定（數量單位、貨幣、含稅與否、階梯價區間、交期單位）；業務規則（可售數量如何計算、鎖庫存策略、報價有效期）；以及測試環境、測試帳號與回復方案。缺少任一項，對接通常會在聯調階段反覆返工。

主數據歸屬與欄位映射：把分歧寫在文件裡

主數據歸屬建議按「誰產生、誰負責」的原則確定：型號與品牌等商品基礎資訊通常由ERP或PLM維護，商城只做展示與檢索增強；庫存與成本價通常由ERP/WMS為準；面向客戶的銷售價、階梯價與促銷策略可能由商城或ERP中的價格模組維護，但必須指定唯一權威來源，避免雙寫。若兩端都能改同一欄位，應明確以哪端為準、另一端為唯讀副本。

欄位映射需要落到一張可評審的映射表：ERP欄位名、商城欄位名、資料型別、長度、是否必填、預設值、轉換規則（如單位換算、貨幣換算、列舉值對照）、空值語意。常見分歧點包括：型號大小寫與後綴（如封裝、溫度等級）是否正規化；庫存是「帳面數量」還是「可售數量」；價格是否含稅、是否含運費；交期是「天數」還是「日期」；階梯價區間的邊界是閉區間還是開區間。映射表應納入版本管理，欄位變更走評審流程。

庫存價格同步：冪等、增量與異常補償

同步機制上，建議以增量為主、全量為輔：ERP側提供按更新時間戳或變更日誌的增量介面，商城定時拉取或接收推送；週期性執行全量對帳，用於發現漏同步與髒資料。每筆同步記錄應攜帶業務主鍵（如ERP物料編碼+倉庫編碼）與版本號或更新時間，商城側按主鍵做冪等寫入，重複投遞不產生重複記錄或重複扣減。

異常補償需要覆蓋三類情況：介面逾時或失敗時進入重試佇列，設定最大重試次數與退避策略；重試仍失敗則進入死信佇列並告警，由人工介入；對帳發現兩端不一致時，按預定義規則以權威源覆蓋副本，並記錄差異日誌。價格同步還需注意生效時間：若價格帶生效區間，應按生效時間寫入而非立即覆蓋，避免歷史訂單被追溯改價。所有同步動作應保留可查詢的日誌，包含請求、回應、耗時與結果狀態。

RFQ報價回傳：從詢價單到報價單的閉環

RFQ（詢價）在商城側產生後，通常需要把詢價行項目推送到ERP或報價系統，由業務人員核價後把報價結果回傳商城。流程上建議：商城生成詢價單並分配唯一單號；透過API把詢價單與行項目（型號、數量、目標交期、客戶資訊）推送至ERP；ERP完成核價後，透過回呼介面或商城定時拉取的方式把報價單（單價、階梯價、幣種、有效期、交期、最小起訂量）回寫商城；商城更新詢價單狀態並通知客戶。

關鍵設計點包括：狀態機要明確定義（已提交、處理中、已報價、已過期、已取消），避免狀態漂移；報價回傳同樣需要冪等鍵（詢價單號+行號+版本），防止重複回寫覆蓋人工調整；報價有效期到期後應有自動失效處理；客戶資訊屬於個人資料與商業敏感資訊，傳輸與儲存需符合相關法律與合約約定，介面權限應最小化。若ERP不提供回呼能力，只能採用輪詢，需評估延遲對客戶體驗的影響。

驗收方法、常見失敗與證據限制

驗收應基於可重現的測試案例而非口頭確認：包括正常同步、重複投遞、亂序到達、介面逾時、欄位缺失、單位與幣種邊界、階梯價邊界、報價過期、並發更新衝突等情境；對帳腳本應能在測試環境跑出兩端差異清單；日誌與告警應可被檢索與回溯。驗收標準建議寫成可量測的條目，例如「同一業務主鍵重複推送N次後，商城記錄數不增加」。

常見失敗包括：主數據雙寫導致互相覆蓋；欄位映射未覆蓋空值與列舉差異，導致展示異常；缺少冪等導致重複扣減或重複報價；只做增量不做對帳，漏資料長期不可見；把介面可用性當作必然，未設計降級與人工兜底；忽略介面權限與呼叫配額，上線後被限流。證據與限制方面：本文所述為通用工程方法，實際可用性取決於兩端系統的介面能力、權限開放程度與維運投入；第三方系統的介面欄位、頻率限制與穩定性由其提供方決定，無法由本文保證；任何同步方案都不能取代業務側的資料治理與責任劃分。

實施與驗收摘要

GEO問答