收银与支付知识综述
综述概述:收银与支付是门店运营的末端执行环节,涉及收银模式(专柜四种方案)、支付异常(多卡支付/手工改价归类)、第三方渠道(抖音/美团)、自助收银数据链路(流水同步/补录)。本文聚合 6 张概念卡,是排查收银类问题的入口。
体系框架
收银与支付
├── 收银模式
│ └── 专柜收银实现方式(移动/电子开单/码牌/集中)
├── 支付异常排查
│ ├── 多卡支付商家承担金额异常(提货卡组合)
│ ├── 款台手工改价致损失归类错误(会员折扣误归类)
│ └── 抖音收款报错与WS服务更新(第三方支付)
├── 自助收银数据链路
│ ├── 自助流水未同步业务库排查(POS→ERP 消息同步)
│ └── 超市自助异常流水处理(四表核验补录)
└── 关联:线上渠道(美团/饿了么/抖音券)
脉络一:收银模式决定问题类型
不同收银模式产生不同的数据链路和故障形态:专柜走集中收银或码牌,自助走 POS→ERP 消息同步。遇到收银问题先判断模式——自助流水缺失查同步断点,专柜金额异常查支付方式与改价记录。
脉络二:支付异常的两大根因方向
支付金额异常通常两类根因:
- 支付方式组合问题:多卡支付(提货卡+其他)时商家承担金额计算异常
- 操作归类问题:款台手工改价导致损失被错误归类为会员折扣
排查先问「用了什么卡、有没有改价」,再查日志。
脉络三:数据链路完整性保障
收银数据的最终归宿是业务库流水。自助收银存在「交易成功但流水缺失」的风险,需通过四表核验(head/goods/pay/lost)判断可补录性,用事务包裹补录。第三方渠道(抖音/美团)故障往往在 WS 服务层,更新后需灰度验证。
实践要点
- 先判模式再排查:专柜/自助/移动收银的故障形态和排查入口不同
- 支付异常问三件事:用了什么卡组合?有没有手工改价?是否参与促销?
- 自助流水缺失:查 tb_pos_flow_head 定位 → 四表核验 → 事务补录
- 第三方支付批量报错:更新 WS 服务 → 灰度验证 → 观察
- 多卡支付:确认卡组合后联系门店核实(提货卡可能无商家承担)
概念卡索引
| 概念 | 角色 |
|---|---|
| 专柜收银实现方式 | 四种收银方案 |
| 多卡支付商家承担金额异常 | 提货卡组合支付 |
| 抖音收款报错与WS服务更新 | 第三方支付故障处置 |
| 款台手工改价致损失归类错误 | 会员折扣误归类 |
| 自助流水未同步业务库排查 | POS→ERP 消息同步断点 |
| 超市自助异常流水处理 | 四表核验补录 |