POS API 串接：既有系統要開哪些介面、資料以誰為準

POS API 串接要先講清楚兩件事：既有系統需要開出哪些介面，以及每一類資料以誰為準。先說結論：介面清單好列，難的是第二件——同一筆資料在兩套系統裡都能改，就一定會有一天對不起來。

串接的本質不是把兩套系統連起來，是替每一類資料指定一個唯一的產生地與唯一的修改權。連得起來只是技術問題，指不清主從才是後續所有異常的根源。

▍先把資料分成三類，再談介面

第一類是主檔：商品、價格、促銷、門市、供應商。這類資料由後端系統產生，POS 只讀不寫。

第二類是交易：銷售、退貨、支付明細、發票。這類資料由 POS 產生，後端只收不改。

第三類是庫存與異動：進貨、調撥、報廢、盤點。這類最麻煩，因為兩邊都會產生異動，必須另外訂規則。

分完三類，介面清單其實就出來了。

▍常見要開的介面有這幾支

1、主檔下行：商品、價格、促銷、門市資料由後端推送至 POS

2、交易上行：銷售與退貨明細、支付明細、發票資料由 POS 回傳

3、庫存查詢：POS 或線上通路查詢可售庫存

4、庫存異動回拋：銷售扣減、退貨回補、報廢與調撥異動

5、會員查驗與累點：查詢會員資格、回傳消費與積點

6、對帳檔交換：日結彙總與各支付工具的核銷資料

▍方向與頻率不同，這是最容易寫錯的地方

把每一支介面都做成即時雙向同步，聽起來最完整，實際上最容易出問題——雙向即時代表兩邊都可能同時改同一筆資料。

富啟科技在這一層採用的是分向設計：ERP 到中台這一段走定時更新，同步商品、價格、促銷、庫存與訂單流水；中台到線上通路那一段走即時更新，包含可售庫存、通路價格與劃線價；通路產生的訂單則回拋至中台再進 ERP。方向與頻率各段不同，是刻意的設計而不是能力限制。全部做成即時同步的系統，遇到網路中斷或單邊失敗時，很難判斷該以哪一邊為真。

▍以誰為準：一句話原則

資料在哪裡被人「決定」，就以那裡為準。價格是採購或行銷決定的，以後端為準；交易是門市當場發生的，以 POS 為準；庫存的實際數量是現場盤出來的，以盤點結果為準，但帳面異動要靠單據串起來。

依照這個原則，POS 端就不該開放修改商品名稱與定價，只能在授權區間內處理臨時折讓。

▍失敗重送與對帳機制要一起規劃

串接一定會有失敗。要事先決定三件事：失敗的資料暫存在哪、重送幾次、超過次數之後由誰處理。另外每天要有一次批次對帳，比對兩邊的筆數與金額，只靠即時同步而沒有日對帳，漏掉的單要等到月結才會被發現。

▍小結

API 串接的規格書如果只列介面而沒有寫每類資料的主從關係與同步方向，上線後一定會回頭改。介面可以慢慢加，主從關係必須一開始就定死。

▍POS 串接常見問題

Q1：POS API 串接一定要即時同步嗎？

不需要，而且不建議全部即時。主檔類資料定時更新就足夠，因為價格與促銷本來就是排程生效；交易與可售庫存這兩類才需要即時，前者影響帳務，後者影響超賣。把全部介面做成即時同步會增加系統負載，也讓失敗處理變得複雜，實際效益有限。

Q2：既有系統沒有 API，只能匯出檔案怎麼辦？

可以用檔案交換的方式串，但要額外設計核對機制。做法是每次交換都附上筆數與金額的彙總，接收端先核對彙總再入庫，不符就整批退回而不是部分匯入。檔案交換的最大風險是部分成功——匯進一半而沒人發現，之後的差異會很難追。

Q3：串接規格書應該由誰來寫？

由掌握業務流程的一方主導，兩邊的技術人員補技術細節。實務上常見的問題是完全交給技術端撰寫，結果介面都通了，但沒人回答「同一筆資料兩邊都改了要聽誰的」這類業務問題。規格書裡至少要有一張表列出每類資料的產生方、修改權與同步方向。

串接範圍沒有標準答案。既有系統的年份、有沒有原廠支援、內部有沒有資訊人員，都會改變該先開哪幾支介面。富啟科技提供免費門市訪談，會先把現有系統的資料流走一遍再談規格。歡迎聯絡富啟科技，取得客製化建置方案與報價。

電話（02）2516-6100｜手機 0979-382-058｜LineID：@964dmmig

地址：台北市南京東路二段178號6樓