一份完整可落地的《多公司多门店 · 仓储式超市 · POS 收银系统》方案

一份完整可落地的《多公司多门店 · 仓储式超市 · POS 收银系统》方案，满足你这两条硬要求：

• ✅ 支持离线开单（断网也能卖、能收款、能出小票）

• ✅ 支持离线仓库管理（入库/出库/盘点/报损/报溢/上架/下架/移库在门店本地也能做）

• ✅ 有网实时同步（订单/库存/成本/会员权益/价格等双向同步）

• ✅ 多公司多门店（老板可看全局，门店只管自己）

• ✅ 可审计、可回滚（幂等、ACK、冲突策略明确）

我按“终局蓝图 + 关键表 + 同步协议 + 冲突策略 + 离线运行机制”一次给全。

---

1）总体架构（离线优先 Offline-First）

1.1 三端形态

• 云端（Platform+Company）：统一商品来源、会员资产、权益引擎、报表汇总、审计与风控

• 门店端（Shop Server，可选）：门店内网网关/同步代理（可不独立部署，直接由 POS 做网关也行）

• 收银机/POS（Android）：本地 SQLite 数据库 + 本地业务引擎（离线也能跑）

1.2 核心思想

• 门店端本地库是“可运行的真系统”：断网时不降级成“只能看不能做”

• 云端是权威账本：网络恢复后，所有操作以事件流方式补齐，做到可追溯、可反向补偿

---

2）系统功能域（与离线强相关的部分）

2.1 POS（离线可用）

• 商品检索/扫码

• 购物车/离线开单

• 会员识别（本地缓存/脱机）

• 权益计算（本地规则快照）

• 多支付方式：现金/银行卡/扫码（断网时支持“离线记账”）

• 退款（分场景：离线退款记账、联网后补齐第三方退款）

• 班次交接、门店日结（离线可做）

2.2 门店 WMS（离线可用）

• 入库/出库/盘点/报损/报溢

• 上架/下架/移库

• 审核/反审核（离线可以做，但要标记“待上云确认”）

2.3 同步域（必须）

• 主数据下发：商品/价格/会员权益/门店配置

• 业务事件上行：订单/支付/退款/WMS 单据/库存成本过账结果

• ACK/对账/重放/修复

---

3）离线门店本地数据库（SQLite）建议分区

你云端已用 hwms/hinv/hcost，门店 SQLite 建议保持同名表结构（字段可以精简），减少同步映射成本。

3.1 本地主数据（只读为主）

• sh_product / sh_product_sku_unit / sh_product_category / sh_product_unit

• pos_price_snapshot（价格快照）

• mem_member_snapshot（会员快照，含等级/权益版本）

• ben_rule_snapshot（权益规则快照）

3.2 本地业务单据（可写）

• pos_order / pos_order_item / pos_order_payment / pos_refund

• hwms_stockin/out/stocktake/loss/overflow/putaway/pick/move（门店离线仓库）

• hinv_inventory(_bin)/hinv_inventory_flow（离线库存数量账）

• hcost_stock/hcost_flow/hcost_fifo_layer（离线成本金额账，可选：只做简化移动加权）

3.3 同步队列与状态（关键）

• sync_outbox_event：本地待上行事件

• sync_inbox_event：云端下行事件缓存

• sync_ack：ACK 结果与对账表

• sync_checkpoint：每个表/每种事件的同步水位

---

4）离线同步的“唯一正确模型”：事件 Outbox + ACK

4.1 为什么必须用事件

离线期间可能发生：

• 多笔订单

• 多张仓库单据

• 多次审核/反审核

• 退款/冲正

若用“直接同步表”，必然出现：

• 丢单

• 重复单

• 冲突无法判定

• 无法回放审计

4.2 事件表（门店本地）DDL（SQLite/MySQL 通用写法）

 

CREATE TABLE sync_outbox_event (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    company_id BIGINT NOT NULL,
    shop_id BIGINT NOT NULL,
    device_id VARCHAR(64) NOT NULL,
    event_id VARCHAR(64) NOT NULL,          -- 全局唯一：device_id + local_seq
    event_type VARCHAR(60) NOT NULL,        -- POS_ORDER_CREATED / HWMS_STOCKOUT_AUDIT ...
    biz_key VARCHAR(80) NOT NULL,           -- order_no / stockout_no ...
    payload TEXT NOT NULL,                  -- JSON
    event_time BIGINT NOT NULL,
    retry_count INT NOT NULL DEFAULT 0,
    state TINYINT NOT NULL DEFAULT 0,       -- 0待发送 1已发送待ACK 2已ACK 3失败待人工
    UNIQUE(event_id)
);

　　

 

 

云端收到后：

• 幂等：按 event_id 去重

• 落库：写业务表 + 写云端事件日志

• 回 ACK：event_id + 处理结果 + 云端时间戳

---

5）断网时系统如何“还能卖还能管仓”

5.1 离线开单必备能力

1. 本地商品库（SQLite）

2. 本地价格快照（可按门店/老板下发）

3. 本地权益快照（等级折扣/券规则/积分抵现规则）

4. 本地会员快照（可选）

   • 断网仍可识别常客、做会员价

   • 但“余额支付/积分扣减/券核销”需分级策略（见下）

5.2 离线支付策略（分层，避免财务炸裂）

• 现金：离线可100%完成（最安全）

• 银行卡/扫码：

  • 如果设备能独立走通道（非依赖云端），可离线完成

  • 否则只能做“离线记账”，联网后补收/补确认

• 会员余额/积分/券（最敏感）：

  • 推荐策略：离线时 只允许使用“离线额度”（上次同步时下发）

  • 例如：余额最多可离线抵扣 50 元、积分抵扣最多 10 元、券只能用“可离线券”

  • 超过额度必须联网或走“店长特批”

这一块你之前已经做过“特批放行/审批链路”，离线时正好用上。

---

6）离线仓库管理（HWMS/HINV/HCOST）怎么跑

6.1 门店离线 WMS 的“账务口径”

离线期间允许：

• 创建单据（hwms_*）

• 审核（影响 hinv/hcost）

• 反审核（回滚 hinv/hcost）

但所有这些需要：

• 记录 local_audit_state、cloud_confirm_state

6.2 推荐增加两个字段（本地&云端都保留）

• sync_state：0未同步 1已同步 2冲突 3待人工

• cloud_confirm_state：0未确认 1云端确认 2云端拒绝

断网时门店可以先“本地确认”，但云端可能因规则拒绝（比如总部锁价、负毛利拦截），这时需要补偿处理（见第8节）。

---

7）有网实时同步：双向同步的内容清单

7.1 云端 → 门店（下发）

• 商品/分类/单位（平台→老板→门店授权后的可售集合）

• 价格（含价格保护期、改价 MQTT）

• 权益规则版本（折扣/券/积分）

• 会员快照（门店常客/最近消费）

• 门店配置（税率、抹零、离线额度等）

7.2 门店 → 云端（上报）

• POS 订单、支付、退款

• 门店 WMS 单据及审核/反审核

• 离线期间产生的库存/成本流水（可选：也可由云端重算）

• 班次交接、日结数据

---

8）冲突处理（离线系统最核心）

离线恢复网络后，常见冲突：

8.1 价格冲突（你之前问过）

• 门店下单时用的是旧价

• 云端发现该商品在“强制刷新”名单内

策略：

1. 云端拒绝该订单事件 → 返回 ACK=REJECT + reason

2. 门店将订单置为“待处理”

3. 提供三种处理：

   • 补差价（重新支付/补收）

   • 取消订单（反审核出库/库存回滚）

   • 走特批（上传审批单）

8.2 权益冲突（券/积分/余额）

云端校验不通过（余额不足、券已用、积分不够）：

策略：

• 按差异金额生成 补收单 或 补退单

• 必要时走审批

8.3 库存冲突（离线超卖）

离线门店库存为本地估计，云端汇总后发现不够：

策略（推荐顺序）：

1. 云端将差异转为“欠货”并生成补货/调拨建议

2. 或对订单做部分发货+部分退款

3. 必要时触发报损/报溢/盘点纠错流程

---

9）对账与修复（你要的“可长期运营”）

必须具备：

• sync_ack：云端处理结果回执

• sync_reconcile_job：每日对账（订单数、支付额、退款额、WMS出库额）

• sync_replay：支持重放某时间段事件

• sync_fix_task：人工修复台（运营/财务用）

---

10）建议落地路线（不空谈，给你可实施步骤）

第1阶段（2~4周可上线最小闭环）

• 离线 POS：商品/价格快照 + 现金支付 + 订单上行

• 云端 ACK + 幂等 + 对账报表

第2阶段（4~8周）

• 离线会员（等级折扣/部分券）

• 离线 WMS（出库/入库/盘点）本地过账

• 同步冲突处理台

第3阶段（8~12周）

• 离线成本（FIFO/移动加权）本地或云端重算

• 全链路审计、补偿与自动修复

---

11）你要的“完整定义”，我最后给一张最关键的清单

离线系统必须满足的 10 条验收标准

1. 断网能开单、能收现金、能打印

2. 断网能做出库/入库/盘点并形成本地台账

3. 网络恢复后自动补传，不丢单不重复

4. 云端幂等（event_id 去重）

5. ACK 可追溯（成功/拒绝/原因）

6. 冲突可处理（补收/取消/特批）

7. 报表口径一致（门店日结→老板汇总）

8. 门店权限隔离（shop_id 强约束）

9. 可重放（按时间段重传事件）

10. 可审计（每次变更有日志）