コンテンツへスキップ
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であれば対応し、ERPはSAP S/4HANA、Oracle NetSuite、Microsoft Dynamics 365 Business Central、Odooなどに対応します。開始時にお客様のPOSとERPのインターフェースを確認します。製品名の記載は、そのベンダーとの提携を意味するものではありません。

この質問へのリンク

稼働後、計上失敗には誰が対応しますか。

本番前に合意します。通常は、未知の商品など業務上のエラーは店舗運用または財務チームが確認リストから処理し、フロー自体の障害は技術チームが対応します。継続契約の一環として当社が技術支援を提供し、ランブックをお客様のチームと共有することもできます。

この質問へのリンク

関連

契約ではなく、対話から始めましょう

構築、接続、保護のどれが必要かを教えてください。アーキテクトが内容を一緒に整理し、どこから始めるべきかを提案します。

無料相談を予約提案を依頼

今後の流れ

  1. 日程の調整

    セッションの日程を調整するため、当社チームからメールをお送りします。

  2. 事前コンサルティングセッション

    無料の30分オンライン事前相談です。目標、システム、制約を伺います。

  3. 準備状況レビュー

    無料の48時間準備状況レビューで、プリンシパルアーキテクトがプロジェクトを6項目のDefinition of Readyに照らして確認し、適切なトラックを提案します。

  4. トラックの選択

    スコープが確定したプロジェクトには、拘束力のある提案書を3–5営業日以内にお渡しします。構想段階のプロジェクトはBlueprint Studioから始まります。稼働中のシステムに障害がある場合、文書化されていない場合、連携が必要な場合は、1–2週間の診断から始まります。Blueprint Studioと診断はそれぞれ固定料金で、提案書に記載します。