跳至主要内容
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 与诊断服务各收取固定费用，费用在方案中列明。