门店网络中断时，POS 能否继续录单只是表层问题。更重要的是支付结果能否确认、库存和会员权益是否重复变化，以及网络恢复后能否沿原交易编号完成同步与对账。一、先确认离线开单范围
终端在断网前通常需要保存商品、价格、促销和权限数据。测试时应检查这些数据的版本号、生效时间和适用门店，避免离线状态继续使用过期规则。
离线开单不等于离线支付。现金不依赖在线授权；百货代收则取决于商场收银系统是否可用。扫码支付、银行卡、储值、积分和优惠券要按照支付渠道逐项验证。
如果终端尚未登录、必要数据未下载或本地数据已经失效，能否继续操作应以项目配置和门店制度为准。
二、库存与会员动作要单独验证
断网期间的本地库存只能反映中断前状态。多台终端同时离线时，彼此暂时看不到对方扣减，项目中可以提前约定库存下限、限量商品限制以及超过离线时长后的处理方式。
会员积分、优惠券、储值余额和跨店权益可能需要实时校验。对无法实时确认的动作，系统可以转入待处理，门店也应知道暂停原因和后续处理入口。
离线期间的改价、折扣、撤单等操作仍需记录操作人、终端和时间，以便恢复联网后追溯。
三、支付结果不明的处理路径
“顾客已经扣款，POS 却没有收到结果”是最需要重点演练的场景。测试时先保留原销售单号、支付请求号、金额和支付方式。
支付请求确认成功后，将结果关联回原销售单；确认失败或请求关闭后，才允许重新发起支付；渠道仍返回未知时，保持待确认状态并进入对账或人工处理。
收银端不宜只提示“请重新支付”。更清晰的提示应引导店员查询原支付或联系值班人员，避免同一消费出现支付状态重复变化。
四、恢复同步要使用稳定交易标识
恢复联网后，离线订单应保留原交易时间、原价格和原促销版本。可用门店、终端、营业日期和本地流水号组成业务键，作为服务器去重依据。
同一笔交易重复上传时，后台应返回原处理结果，而不是再生成销售单。验收项目可拆成四类：支付状态重复变化、销售单重复生成、库存重复变化、积分或优惠券重复发放。
冲突交易也不适合直接删除。商品停售、优惠券已使用、会员余额变化和库存不足等情况，应保留原销售与支付事实，再通过异常单、库存调整、权益补记或退款流程处理。
五、建议用双终端演练完整链路
准备同一门店的 A、B 两台 POS、两个测试商品和一位测试会员。先记录商品库存、会员积分和终端最后同步时间，让 A 端断网，B 端保持联网。
A 端使用已下载的商品和促销生成离线销售单，分别验证允许和限制使用的支付方式。通过测试支付环境形成“渠道成功、POS 待确认”的状态，恢复通信后查询原支付请求。
连续重传同一笔离线交易，检查后台是否只生成一张销售单，库存和积分是否只变化一次。再让 B 端使用同一会员权益或销售同一商品，观察冲突是否进入处理队列。
最后结束门店日结，沿同一交易编号核对销售、支付、库存、会员权益和同步日志。验收证据包括本地交易编号、支付流水、首次与重复同步结果、库存流水和日结结果。
六、把门店操作口径纳入项目验收
项目除了测试系统，还要形成门店操作口径：谁判断进入离线状态，哪些支付方式暂停，支付结果不明时找谁处理，何时允许退出离线状态。
在同步和对账完成前，不宜删除本地记录，也不宜用新订单覆盖原订单。系统提示、操作日志和异常处理结果，都是验收时需要留存的材料。
离线能力的判断重点，不是一个简单的功能开关，而是交易状态能否从开单延续到支付、同步和日结。不同品牌的支付结构、库存规则和接口条件存在差异，具体方案需结合项目配置确认。
本文所涉测试逻辑参考公开行业实践及多门店系统稳定性验证场景，具体范围需结合门店实际配置确认。
作者：秉坤 PEKON 零售数字化团队
本文由 PEKON 内容团队基于公开资料、行业观察与 PEKON 项目实践经验撰写，部分内容经 AI 辅助整理，并已完成人工审核。具体功能与方案以项目实际需求为准。
