收银很简单？其实最容易出错。本文结合实际业务场景，复盘收银系统的功能细节与逻辑搭建，帮产品人绕开那些隐藏在“交付、折扣、分账、挂账”中的踩坑点，把复杂的运营逻辑设计得清清楚楚。

最近公司业务扩展，由线上业务发展需要做到线下门店实体的业务，对应需要设计一套收银系统，也购置了一套SaaS平台作为过渡。因为整套线下收银的产品设计跟线上商城下单还是2种场景不一样的交互设计，所以也是需要再去学习研究门店业务的流程。

一、自研收银系统

这似乎是一件吃力不讨好的事情，用已经购入的SaaS平台使用，功能齐全也无需开发。但是从长久看，自研系统跟购入其他系统，存在的最大冲突就是数据源的不一致。一套数据需要分为2个渠道管理，增加了管理成本的同时，出错率也是更大了。

还考虑到现在的零售门店，都是需要支持在线配送到家的情况，所以如果是购入了收银系统，再开通其他平台的在线下单。

二、收银机背景

针对市面上的收银机进行调研，收银机的款式也是各种各样的。从一开始的带现金抽屉的机械收银机，逐步进化成具备计算与实时库存管理、移动支付集成等的智能收银机，到当下各大商超普及的自助收银机。

不断提升用户体验的同时，也迭代了双屏收银机，主屏供收银员操作，副屏面向顾客展示交易明细、促销广告等等。提升交易整体的透明度，减少交易过程中的金额争议。

AI时期，收银机也紧跟时代，迭代了刷脸支付收银机及AI视觉秤。

所以在软件产品的需求规划、交互设计阶段，根据需求选取收银机。

一般收银系统，核心模块主要就是收银，像订单、会员积分、或者是交接班这种，可以在原有系统的基础上，进行拓展。由于之前是做线上商城的，所以对于收银机的收银模式的设计过程中，还是发现了一些跟线上下单的差异：

所以针对以上的点，对应输出了对收银模块的细化需求。

收银机支持离线似乎是约定俗成的功能，在开发前就需要详细写清，这也涉及开发的底层设计。

1) 商品下载到本地

在登录或者设置页面，都需要将商品最近的数据下载到本地。主要用于断网或者弱网的情况下，确保收银或者商品查询流程可顺畅进行，减少重复网络请求的同时，还能提高收银销量。
这里就需要注意在收银的时候，对于商品库存的校验是可以忽略的。因为本地的商品数据、库存是实时动态变化的，所以在提交添加商品或者收款的操作的时候，无需强制校验库存。

2) 订单数据暂存

进入收款的时候，订单数据暂存到本地，这里就涉及了收银经常出现的挂单跟取单这2个操作。收银经常会遇到的场景，在付款的时候顾客经常会出现一些异常情况导致暂时无法正常付款。这个时候后面大排长队，就需要将这个订单暂时挂起先为下一个顾客提供收银服务。直到挂起订单的顾客可以正常支付，则将订单取出去收款，无需将该顾客的所有商品重新扫码录入（这种场景不适用于自助收银的场景）。
还有一种也是针对弱网或者断网的情况，将未完成交易的订单数据暂存在本地，也避免了网络差的情况导致营业中断。

3)订单数据上传

这里会分为几种情况：第一种是现金支付，离线的情况下可正常操作，有网之后上传订单数据。第二种情况是扫码支付，如果双方都是断网的情况下，则可以通过NFC硬件安全芯片完成交易，交易数据暂存本地，后续联网补传数据。
但是如果是微信或者支付宝扫码支付的情况，仅支持顾客断网的情况下生成付款码，但是收银机必须联网才可以验证支付成功。
收银机的订单支持可查询、可补打小票，可操作退款等。

打称的流程看似简单，跟普通商品没有什么差异，这种情况主要就是在细节上需要去注意交互。这里说明下，我们购入的是收银打称一体机，如果是传统商超的单独划分人工打称贴票的机器，则需要涉及预包装标签贴标+识别的交互，对应识别出品名及售价，下单数量计算为1。

AI秤使用的前提需要同步商品信息：如商品名称、商品编码、售价、计重单位(kg等)、商品更新时间、门店等等。
识别：进入称重之后，对应根据导入的商品信息对应识别出商品，回显商品信息+商品重量，通过商品售价对应计算出小计金额。
数据回传：AI秤识别成功后，对应返回一串数字，其中包含了商品编码信息+商品重量，对应回显收银机的收银列表。
数据解析回显：根据返回数量，对应在收银明细回显商品信息、称重重量，商品售价，计算小计金额。点击支持修改重量(修改数量非标品直接修改数量，而是根据称重修改重量信息)。