跳至主要內容
XSIS
客戶專區索取方案

企業與整合

POS 到 ERP 的銷售、庫存與價格同步

POS 到 ERP：銷售、庫存與價格保持一致

每筆銷售與退貨從各門市傳入，庫存與價格變更回傳，日結合計完成對帳。

與工程師交流檢視合作模式

藍圖

POS 到 ERP：每筆銷售只記一次銷售以事件形式從收銀台流向 ERP，價格與庫存回傳。離線門市繼續銷售，恢復連線後再補齊。入帳失敗會重試，然後交人工處理。POSPOS 終端機每家門市的每台收銀機資料儲存門市或 POS 雲端伺服器離線時繼續銷售XSIS整合層事件佇列、對映、重複保護ERPERP銷售、庫存與財務服務重試佇列退避重試，然後進入死信佇列人員門市營運團隊12REST/JSON3OData · REST/JSON4REST/JSON5REST/JSON678

POS 到 ERP：每筆銷售只記一次

銷售以事件形式從收銀台流向 ERP，價格與庫存回傳。離線門市繼續銷售，恢復連線後再補齊。入帳失敗會重試，然後交人工處理。

  • 主流程
  • 非同步
  • 異常路徑
8 步流程

流程逐步說明

  1. 從 POS 終端機 到 門市或 POS 雲端伺服器：銷售、退貨與作廢（主流程）。
  2. 從 門市或 POS 雲端伺服器 到 整合層：銷售事件與日終彙整，透過事件佇列，經由 REST/JSON（非同步）。
  3. 從 整合層 到 ERP：銷售與庫存變動已入帳，經由 OData · REST/JSON（主流程）。
  4. 從 ERP 到 整合層：價格、促銷與商品資料，透過 API 或檔案匯出，經由 REST/JSON（主流程）。
  5. 從 整合層 到 門市或 POS 雲端伺服器：價格與庫存更新，經由 REST/JSON（主流程）。
  6. 從 整合層 到 重試佇列：入帳失敗（異常路徑）。
  7. 從 重試佇列 到 整合層：已重試（異常路徑）。
  8. 從 重試佇列 到 門市營運團隊：仍然失敗：附上詳情的警示（異常路徑）。

概述

這是您門市收銀台與背後 ERP 之間的流程。銷售、退貨與作廢向上匯入 ERP。價格、促銷、商品資料與庫存向下回傳。兩者一旦脫節，門市就會以錯誤價格銷售，庫存數字不再可信，財務則要把月底時間花在對帳上。

參考設計將每筆門市交易作為事件，經由帶佇列的整合層傳送。該層把每個事件對映為 ERP 的銷售與庫存單據，並確保恰好入帳一次。反方向上，ERP 中的變更會傳送到需要的門市，使每個收銀台都基於同一套資料工作。

門市斷網是預料之中的情況。門市或 POS 雲端伺服器會繼續銷售，並在連線恢復後追平。入帳失敗會重試，持續失敗的會連同明細交由人工處理，而不是消失。

流程如何運作

  1. 在收銀台銷售

    每筆銷售、退貨與作廢都在 POS 終端機記錄，包含唯一識別碼、門市、收銀台與時間。

  2. 在門市暫存

    門市或 POS 雲端伺服器收集交易並作為事件傳送，在門市離線期間安全暫存。

  3. 入帳至 ERP

    整合層把每個事件對映為銷售與庫存變動並入帳至 ERP，同時驗證其識別碼，確保不會重複入帳。

  4. 推送價格與商品

    商品資料、價格與促銷在 ERP 中變更時發布，並附上生效日期與適用門市。

  5. 更新每家門市

    該層把每項變更推送至適用門市，並記錄哪些門市已確認。

出現故障時

  • 入帳失敗

    臨時故障會以遞增的延遲重試。仍然失敗的入帳進入死信佇列，並向門市營運團隊發出警示，附上交易與錯誤資訊。

  • 門市離線

    門市依靠本機資料繼續營業。交易被暫存，並在連線恢復後依順序傳送；門市長時間無回應會觸發警示。

  • 交易重複到達

    每筆交易都帶有唯一識別碼。該層識別重複並忽略，因此斷網後的重發絕不會讓銷售翻倍。

  • 門市與 ERP 合計不一致

    每家門市的日結合計會與 ERP 收到的資料進行比對。出現差異時開啟複核，列出缺失或多餘的交易。

標準與系統

資料與分析
  • Apache Kafka
ERP 系統
  • SAP S/4HANA
  • Oracle NetSuite
  • Microsoft Dynamics 365 Business Central
  • Odoo
整合
  • REST
  • Webhooks
  • RabbitMQ

問題與解答

銷售應該即時入帳還是批次入帳？

通常以接近即時的事件方式入帳，這樣庫存與銷售數字在日間保持最新。部分 ERP 或授權模式使頻繁入帳成本較高，因此該層也可以按門市和時段把事件彙總。我們會根據哪些決策需要即時資料、以及 ERP 擅長處理什麼，與您共同選擇。

連結到此問題

日結合計如何對帳？

每家門市按付款類型和部門傳送日結合計。該層將其與 ERP 收到的同一門市、同一天的交易進行比對。若一致，當日即結案；若不一致，複核會列出缺失或多餘的交易，使您的團隊能夠解決根因，而不是做調整分錄。

連結到此問題

促銷與價格變更可以提前排定嗎？

可以。每項價格或促銷變更都會提前連同生效日期與適用門市傳送，使收銀台在正確時點切換，無需門市人員操作。該層記錄哪些門市已確認變更，並標記未確認的門市。

連結到此問題

如何在多家門市上線？

我們先在少數門市試點，每天將其合計與現有流程比對。合計一致後，我們分批上線，節奏以您的門市營運團隊能夠支援為準。在新流程得到驗證之前，每家門市都可以繼續使用舊流程。

連結到此問題

這適用於哪些 POS 與 ERP 系統？

該設計適用於任何能透過 API、事件或檔案匯出交易的 POS，以及 SAP S/4HANA、Oracle NetSuite、Microsoft Dynamics 365 Business Central 與 Odoo 等 ERP。我們在開始時確認您特定 POS 與 ERP 的介面。提及某項產品，並不代表與該產品供應商存在合作關係。

連結到此問題

上線後由誰處理失敗的入帳？

這在上線前約定。通常由您的門市營運或財務團隊從複核清單中處理業務錯誤，例如未知商品；技術團隊處理流程本身的技術故障。我們可以作為持續性合約的一部分提供該技術支援，並與您的團隊分享操作手冊。

連結到此問題

相關

從對話開始，而不是從合約開始。

告訴我們您需要建置、串接與防護什麼。架構師會與您逐項討論，然後建議從何處入手。

預約免費會談索取方案

後續流程

  1. 約定時間

    我們的團隊會透過電子郵件與您約定會談時間。

  2. 諮詢前會談

    一次免費 30 分鐘線上預諮詢：我們盤點您的目標、系統與限制條件。

  3. 就緒評估

    在免費 48 小時就緒評估中，首席架構師對照 6 項就緒定義檢查您的專案，並建議合適的路線。

  4. 選擇路線

    範圍就緒的專案會收到一份有約束力的方案 3–5 個工作天內。概念階段的專案從 Blueprint Studio 開始。已上線系統若出現故障、缺乏文件或需要整合，則先進行 1–2 週 的診斷。Blueprint Studio 與診斷服務各收取固定費用，費用在方案中列明。