店舗、オンラインチャネル、ERPがずれていく理由
小売業者は、互いに一致しなければならない多くのシステムで動いています。レジ、Webショップ、倉庫、決済プロバイダー、ERPです。これらがずれると、在庫が狂い、チャネル間で価格が異なり、経理は何日も照合に追われます。
夜間バッチ同期
レジ、Webショップ、ERPのデータ交換が数時間遅れ、ピーク時に在庫を売り過ぎます。
遅い精算
アクワイアラごとのカード精算の照合が遅れ、不一致がコストになります。
チェックアウトを止めるピーク
セールやイベントは、遅いシステムが処理しきれないトラフィックをもたらします。
変わること
すべての売上の一つの版
店舗端末、オンラインレジ、ERPの元帳がリアルタイムに一致します。
信頼できる在庫
SKUごとの在庫数を、変化に応じて店舗とECサイト間で同期します。
照合された精算
精算ファイルを取り込み、手数料を自動で監査します。
支援領域
構築するもの
- POS拡張、バックオフィスアプリ、店舗ダッシュボード
- 店舗サーバーと本部間のオフライン対応同期
構築するもの
- ECフロントエンドと注文サービス
- 店舗受取、返品、注文追跡
代表的な連携
- ECプラットフォーム、マーケットプレイス、運送会社、ERP
構築し、つなぎ、守るもの
POSとERPの連携
売上、返品、日次締め集計をERPに計上し、価格、販促、商品データを各店舗へ送り返します。
在庫の可視化
店舗、倉庫、オンラインをまたぐ在庫を一つの画面で把握し、売上や納品に応じて更新します。
オンライン・モバイルコマース
店舗と商品、価格、在庫を共有するWebショップとアプリ。
ロイヤルティと販促
どのチャネルでも同じように機能するロイヤルティプログラム、クーポン、販促ルール。
店舗運営ツール
棚卸、移動、納品、スタッフ作業のためのアプリ。店頭での利用に合わせて構築します。
スーパーアプリと統合コマース
複数ブランドをまたぐ買い物、決済、ロイヤルティを一つの高同時接続アプリに。
POSプラットフォーム
レジとPOSクラウドサービスを、API、出力ファイル、店舗サーバー経由で連携します。
カード決済
端末、ゲートウェイ、アクワイアラを連携し、精算ファイルを売上に照合します。
ERP
商品、在庫、財務のために、SAP S/4HANA、Microsoft Dynamics 365、Oracle NetSuite、Odooなどと連携します。
倉庫と運送会社
フルフィルメント、配送、返品のための倉庫システムと運送会社API。
カードデータを対象外に
カードデータは決済プロバイダーに保持し、トークン化と、利用可能な場合は端末間暗号化通信を用いることで、PCI DSSの対象範囲を小さく保ちます。
顧客データ
ロイヤルティと注文のデータは同意を得て収集し、必要な期間だけ保持し、GDPRと適用される各国法に従って扱います。
税務・会計規則
国が税務レシートや電子インボイスを求める場合は、義務付けられた認定デバイスやプラットフォームに接続し、必要な記録を保持します。
私たちの進め方
売上、在庫、価格、決済がシステム間を確実に移動するよう接続し、その周囲に顧客向けアプリとバックオフィスツールを構築します。ネットワーク障害時も店舗は販売を続け、復旧後に追いつきます。
フローを整理
売上、返品、価格、在庫、決済が、各システム間をどう流れるかを把握します。
バッチを置き換える
POS、ECサイト、ERP間をイベントでストリーミングし、失敗用のデッドレターキューを用意します。
ピークで実証
本番稼働前に、セール時のトラフィックで負荷テストを行います。
横にスクロールすると図全体を確認できます。
POSからERPへ：すべての売上を一度だけ計上
売上はイベントとしてレジからERPへ流れ、価格と在庫は逆方向に流れます。オフラインになった店舗も販売を続け、復旧後に追いつきます。計上に失敗した場合は再試行し、それでもだめなら担当者に引き継ぎます。
- 主要フロー
- 非同期
- 例外経路
8ステップのフロー
フローを順に示す
- POS端末から店舗またはPOSクラウドサーバーへ：売上、返品、取消（主要フロー）。
- 店舗またはPOSクラウドサーバーから連携レイヤーへ：売上イベントと日次締め集計。イベントキュー経由、REST/JSON経由（非同期）。
- 連携レイヤーからERPへ：売上と在庫移動を計上、OData · REST/JSON経由（主要フロー）。
- ERPから連携レイヤーへ：価格、販促、商品データ。APIまたはファイル出力、REST/JSON経由（主要フロー）。
- 連携レイヤーから店舗またはPOSクラウドサーバーへ：価格と在庫の更新、REST/JSON経由（主要フロー）。
- 連携レイヤーから再試行キューへ：計上失敗（例外経路）。
- 再試行キューから連携レイヤーへ：再試行（例外経路）。
- 再試行キューから店舗運用チームへ：それでも失敗：詳細付きのアラート（例外経路）。
横にスクロールすると図全体を確認できます。
カード決済：レジでオーソリ、後日精算、ERPで照合
端末またはオンラインレジがゲートウェイに問い合わせ、ゲートウェイがアクワイアラに、アクワイアラがカードスキームと発行会社に振り分けます。精算ファイルは後から届き、ERPで売上と手数料に照合されます。タイムアウト時は自動で取り消し、顧客が二重に請求されないようにします。
- 主要フロー
- 非同期
- 例外経路
8ステップのフロー
フローを順に示す
- EMV端末またはオンラインレジから決済ゲートウェイへ：オーソリゼーション要求、EMV · REST/JSON経由（主要フロー）。
- 決済ゲートウェイからアクワイアラへ：オーソリゼーション、ISO 8583経由（主要フロー）。
- アクワイアラからカードスキームと発行会社へ：発行会社へルーティング、ISO 8583経由（主要フロー）。
- アクワイアラから決済ゲートウェイへ：承認または否認、ISO 8583経由（非同期）。
- アクワイアラから連携レイヤーへ：精算・手数料ファイル、SFTP経由（非同期）。
- 連携レイヤーからERPへ：精算済みの売上、手数料、入金、REST/JSON経由（主要フロー）。
- 決済ゲートウェイからEMV端末またはオンラインレジへ：時間内に応答なし：自動取り消し、ISO 8583 0400経由（例外経路）。
- 連携レイヤーから決済運用チームへ：精算の不一致またはチャージバック（例外経路）。
実績
掲載している企業ブランドは、XSIS、KONG GROUP、当社CEOおよびプリンシパルエンジニアリングリーダーが、それぞれの経歴の中で設計または提供した、過去および現在のシステム、プラットフォーム、デジタル製品を表します。第三者商標はすべて各所有者に帰属し、事実に基づく実績の識別のみを目的として記載しています。
始め方
今後の流れ
日程の調整
セッションの日程を調整するため、当社チームからメールをお送りします。
事前コンサルティングセッション
無料の30分オンライン事前相談です。目標、システム、制約を伺います。
準備状況レビュー
無料の48時間準備状況レビューで、プリンシパルアーキテクトがプロジェクトを6項目のDefinition of Readyに照らして確認し、適切なトラックを提案します。
トラックの選択
スコープが確定したプロジェクトには、拘束力のある提案書を3–5営業日以内にお渡しします。構想段階のプロジェクトはBlueprint Studioから始まります。稼働中のシステムに障害がある場合、文書化されていない場合、連携が必要な場合は、1–2週間の診断から始まります。Blueprint Studioと診断はそれぞれ固定料金で、提案書に記載します。
AIネイティブなプロダクトチーム
シニアエンジニアによるマネージドのクロスファンクショナルなポッド。エージェント型コーディング環境とQA環境を装備します。
固定成果型プロジェクトと24時間365日のマネージドサービス
氏名を明示したデリバリーリードによる固定スコープ・マイルストーン型のデリバリーと、SLAガバナンスのもとで24時間365日運用するアプリケーションマネージドサービス。
最短の入口は、迅速なエンゲージメントパッケージの一つである義務化対応の電子インボイス・ERP準備スプリントパッケージです。
始め方よくある質問
店舗の接続が切れたらどうなりますか。
店舗は販売を続けます。売上はローカルに保存され、接続が戻ると送信されます。各売上には一意の識別子が付くため、二重計上は起きません。価格と在庫の更新も同じようにキューに入ります。どの店舗がどれだけ遅れているかを運用側が把握できるため、長時間の障害は月末に発覚するのではなく、すぐに気づかれます。
どのPOSシステムと連携できますか。
POSプラットフォームが提供する手段（クラウドAPI、店舗サーバー、データベース出力、ファイル）を通じて連携します。見積もりの前に、POSのドキュメントとデータのサンプルを確認します。方式はそれで決まるからです。本サイトでPOSプラットフォームやERPの名称を挙げることは、そのベンダーとのパートナーシップを意味しません。
ERPと店舗の在庫がなぜ一致しないのですか。
通常は、タイミング、単位、何を移動とみなすかでシステム間の解釈が異なるためです。返品、移動、破損品、棚卸中の売上がよくある原因です。差異を追跡し、移動の種類ごとに一つのルールを合意し、すべての変更を発生源とともに記録するよう同期を構築します。残った不一致は積み上がらず、確認リストに回ります。
小売連携のコストは何で決まりますか。
システム、店舗、チャネルの数、POSとERPがデータをどれだけ適切に公開しているか、チャネルをまたぐ返品や分割決済など、ルールが必要な例外の数です。店舗ごとの展開にもテスト工数がかかります。システムと実際の取引サンプルを確認したうえで見積もります。
店舗を閉めずに展開できますか。
はい。パイロット店舗から始めて段階的に稼働し、合計値が一致するまで新しい連携を現行プロセスと並行して運用します。店舗での変更は可能な限り営業時間外に計画し、各段階に、想定どおりに動かない場合の戻し方を用意します。
本番稼働後、連携は誰がサポートしますか。
サポート契約のもとで当社が監視・支援することも、ドキュメント、アラート、ランブックとともにお客様のチームへ引き継ぐこともできます。いずれの場合も、失敗したメッセージは理由とともにキューに入るため、失われるのではなく修正して再処理できます。