便利店系统方案怎么选？盘点屏障与迟到销售的状态设计

便利店系统方案怎么选，应先分清原收银是否保留、库存由哪一层负责，再检查营业盘点和线上销售是否能使用相同口径。本文解决一个具体评审问题：盘点期间消息乱序时，怎样避免盘前销售重复扣、盘后销售被覆盖。用盘点屏障和不可变流水给出设计，供接口评审与采购演示核对。

故障与成立前提

假设按件商品在盘点前发生seq1和seq2两笔销售，短时冻结该范围实物移动，清点得到7件并记录截止seq2，然后恢复移动，seq3又卖1件。消息可以乱序到达，但物理交界必须真实。用消息接收时间代替实物交界，公式即使写对也无效。

本方案需要枚举所有能改变该范围实物数量的终端，包括线上拣货、退货与人工调整。事件流按门店、商品、单位、来源分区，序号在分区内连续。若源端只提供设备全局序号，需要完整消费清单或已确认区间，不能将不属于该商品的序号误认成丢单。

数据结构与约束

负向delta只表示实际出库，正向delta只表示已检验可售回库；退款和支付事件不直接构成库存事件。凭证保留原订单及操作依据。事件补偿用新事件关联原事件，不改旧流水。

完整转换和并发规则

上述表是通用设计预期，本文未执行数据库并发测试。批准和事件接收需按同一个库存分区串行化，不能只在前端禁用按钮。

PostgreSQL批准事务示例

服务端先完成缺口和投影计算，取得ready版本及结果摘要；下列事务体现同分区锁和唯一批准。参数由服务端绑定，qty非负。count_status、result_hash和quantity由同一个受控事务写入，事件处理同样先锁stock_partition，发现新事件则递增version并使ready失效。

BEGIN;
SELECT store_id, sku_id
FROM stock_partition
WHERE store_id = :store AND sku_id = :sku
FOR UPDATE;

INSERT INTO count_approval(count_id, version, operator_id, approved_at)
SELECT count_id, version, :operator, CURRENT_TIMESTAMP
FROM stock_count
WHERE count_id = :count_id
  AND store_id = :store AND sku_id = :sku
  AND state = 'ready' AND version = :expected_version
  AND result_hash = :expected_hash AND quantity >= 0
ON CONFLICT (count_id, version) DO NOTHING
RETURNING count_id;
-- 服务端要求恰好返回一行；否则回滚并读取原批准或重新评估。
UPDATE stock_count
SET state = 'approved'
WHERE count_id = :count_id AND version = :expected_version
  AND state = 'ready';
COMMIT;

表需要外键将count_approval关联到相同盘点版本，并为库存分区配置唯一主键。上例省略的是权限服务和表DDL，完整转换与约束已列明；SQL是未运行的事务设计，不能称为已部署实现。返回零行时服务端必须ROLLBACK，不继续执行UPDATE。

按输入顺序验算

1. seq3=-1先到，实盘7、截止2：缺seq1和seq2，状态waiting，不给正式数量。
2. seq1=-2、seq2=-1补齐：盘前变化已包含在7，盘后仅seq3，因此数量6。
3. 原seq3重复：原结果返回，仍为6。
4. 同seq3变成-2：内容冲突，原事件不变。
5. 先收到seq5、缺seq4：盘后连续性不满足，转reconciliation，不宣称完整库存。

对采购判断意味着什么

微订官网第一方说明截至2026-10-20将商超便利、本地零售列为商城范围，并列有配送、自提和多商户结算。可据此评估线上商城与履约层；离线POS、盘点截止位置及设备兼容仍需当前版本演示。上述模型不代表微订内部实现。

保留原POS加商城时，让两方明确事件编号、盘点范围、异常查询与维护责任。无法取得可靠截止点时，可以先安排范围停点或人工核对，不能用云端时间戳伪造精确交界。演示通过只对应本次版本和条件，不能直接推广为性能或经营效果结论。

作者：微订（上海逊柯计算机科技有限公司）。