首页 / 客户案例 / 连锁门店 POS 收银系统
B级 · 脱敏真实案例

连锁门店 POS 收银与经营协同系统

面向约 120 家连锁便利店,以 Android 平板重构收银终端,连接商品、库存、会员、促销、支付和总部经营数据,并通过 Local-First 架构保障网络波动下的核心收银能力。

Android POS离线可用会员促销库存协同总部数据同步
连锁门店POS收银系统中文终端界面
B级 · 脱敏真实案例

本案例依据真实项目实施资料整理,客户名称、业务细节及部分经营数据已做脱敏处理。指标采用正式上线3个月后的脱敏统计口径,结果受门店类型、客流和运营规则影响,不构成对其他项目效果的承诺。了解案例证据分级

项目职责与事实边界

知华职责:完成门店调研、终端交互、Local-First交易架构、服务端能力、硬件适配、数据同步、试点发布和运维交接。

客户职责:确认商品、促销、会员和退换货规则,提供门店试点环境、设备与支付渠道授权,并组织收银员参与实店验证。

能力边界:现金可按离线流程处理;在线支付仍受网络和支付通道状态约束,系统不承诺断网状态下完成在线扣款。

披露边界:客户品牌、合同金额、门店地址、交易明细、支付参数和生产环境信息不公开;页面只展示脱敏后的架构、过程和汇总指标。

项目背景与核心挑战

客户是一家拥有约 120 家门店的连锁便利店品牌。原有 Windows 收银软件虽然具备基础功能,但设备投入高、启动与维护成本大,断网后无法完成基本收银;会员权益和促销规则依赖收银员记忆,总部经营数据也只能在每日收班后汇总。

客户希望在控制硬件成本的同时,让门店在网络波动时仍可持续营业,并把收银、会员、促销、库存和经营分析整合为统一体系。项目采用 Android 平板作为主要终端,但最终目标并不是简单“换设备”,而是重构门店交易与总部协同方式。

先进入门店,再确定系统边界

需求阶段连续两周在门店跟班,完整观察早班开店、午间高峰、交接班、退换货、日结与设备异常处理,避免只根据管理层描述设计操作流程。

业务环节一线真实需求系统设计重点
高峰收银操作步骤少、扫码反馈快常用商品快捷入口、键盘与扫码兼容
会员与促销不依赖收银员记忆复杂规则会员识别、优惠叠加与规则自动计算
网络异常断网时仍能完成核心营业动作本地商品、库存与交易队列
设备接入不同门店设备能够稳定工作扫码枪、打印机、钱箱的适配层
总部管理及时掌握销售、库存与异常增量同步、经营看板与异常追踪

业务功能与技术架构

门店终端

Kotlin 原生 Android 应用,采用 MVVM 与 Repository 分层,Jetpack Compose 构建适合触控终端的中文收银界面。

本地数据层

Room / SQLite 保存商品、促销规则、会员必要信息、交易单据和待同步任务,支持门店网络异常时继续处理核心业务。

服务端

Go + Gin 承载交易、商品、库存和同步服务,PostgreSQL 按门店组织业务数据,Redis 缓存高频规则和状态。

总部能力

统一维护商品、价格、促销和门店配置,汇总销售与库存数据,支持经营分析、异常监控和多门店权限管理。

Local-First:离线不是缓存一个页面

01

基础数据本地化:商品、价格及有效促销规则按版本同步到门店,网络不可用时仍能完成查价、扫码和规则计算。

02

交易本地落单:订单先写入本地数据库和待同步队列,再异步上传服务端,避免网络抖动阻塞收银动作。

03

幂等与冲突处理:每笔订单使用全局唯一编号,服务端按订单号保证幂等,并对库存、撤单与重复提交建立明确规则。

04

状态可见:终端持续展示网络、同步进度与待上传任务,异常进入人工可处理队列,而不是静默丢失。

支付边界需要单独设计

现金可按离线流程处理;微信、支付宝等在线支付仍依赖支付通道与网络状态。系统通过状态校验、重试和人工应急流程避免重复扣款,不把“断网后自动扣款”作为默认承诺。

落地过程中解决的关键问题

扫码识别速度:相机扫码适合作为备用方案,高峰门店仍优先适配硬件扫码枪,并统一条码输入事件,降低设备差异对业务代码的影响。

促销计算性能:将门店有效规则预加载到本地,在后台线程执行匹配与重算,减少复杂叠加规则对收银界面的阻塞。

蓝牙打印稳定性:建立设备能力检测、断线重连、打印队列和补打机制,并对主流机型进行实店测试,而不是只依赖模拟环境。

操作习惯迁移:保留收银员熟悉的商品搜索、快捷键和结算顺序,用培训门店的反馈逐步调整交互,降低系统切换成本。

分阶段上线与运营保障

第 1-2 周2 家门店试运行
第 3-4 周扩大至 10 家门店
第 5-8 周逐批覆盖约 120 家
第 9-12 周驻场支持与问题收敛
持续运营版本、设备与规则迭代

上线后的业务变化

正式上线 3 个月后的脱敏统计口径,数据受门店类型、客流和运营规则影响。

平均单笔收银18 秒上线前约 28 秒
单店硬件投入约 ¥2,800上线前约 ¥5,500
促销规则生效约 5 分钟上线前约半天
经营数据时效< 5 秒上线前为 T+1 汇总
指标上线前上线后第 3 个月
平均单笔收银时间约 28 秒约 18 秒
网络异常下核心收银不可用离线流程可用
单店硬件投入约 5,500 元约 2,800 元
促销规则下发生效约半天约 5 分钟
经营数据时效T+1 汇总正常网络下小于 5 秒
新员工上手时间3 至 5 天约 1 天

统计口径与可核验材料

页面指标为正式上线3个月后的脱敏汇总,比较基线来自原系统和试点门店记录;门店类型、客流、设备型号与运营规则会影响结果。经客户授权或签署保密协议后,可在不披露交易隐私和商业秘密的前提下核验以下材料。

VERIFICATION门店调研记录与确认流程
VERIFICATION终端、服务端与同步架构说明
VERIFICATION扫码、打印、钱箱设备适配清单
VERIFICATION离线交易、幂等与冲突测试记录
VERIFICATION试点批次、上线检查和问题台账
VERIFICATION指标统计、部署与运维交接材料

项目经验沉淀

必须观察一线真实动作。门店高峰期的操作节奏、设备摆放和异常处理,往往不会完整出现在需求文档里。
硬件兼容需要实测。扫码、打印、钱箱和蓝牙稳定性直接影响营业,测试清单应覆盖设备型号与异常恢复。
Local-First 是完整业务能力。本地规则、交易队列、同步、幂等和冲突处理缺一不可,不能只理解为页面缓存。
逐批上线比一次切换更稳妥。从少量门店验证到扩大范围,每一批都沉淀问题和操作手册。
尊重收银员的肌肉记忆。系统升级应减少操作负担,而不是为了界面新颖改变所有熟悉流程。

可交付成果

PROJECT OUTPUT门店业务调研与流程蓝图
PROJECT OUTPUTAndroid POS 收银终端
PROJECT OUTPUT商品、库存、会员与促销服务
PROJECT OUTPUT离线交易与数据同步机制
PROJECT OUTPUT设备适配、测试与部署方案
PROJECT OUTPUT总部经营后台与运维手册