离线扫码怎样同步：断网不丢单，重复上传不重复出库

仓库网络不稳定时，允许先采集再上传可以减少等待，但离线并不代表设备掌握全局最新状态。同一个箱可能被另一台设备先出库，单据可能已关闭，产品也可能临时被冻结。建议把“本机已保存”“服务端已接收”“业务已确认”设计为不同状态，让操作员知道当前实物能否放行。

每次业务动作要有自己的身份

建议离线记录包含事件号、设备号、操作人、业务单号、码清单、动作、采集时间、上传时间和规则版本。同一个码连续扫两次，可能是误扫，也可能对应出库与退货两个动作，不能仅凭码去重。重复上传同一事件应返回同一处理结果；事件号相同但内容不同，应进入冲突处理。

时间也不能混成一列。EPCIS 的数据模型区分事件发生时间与记录时间，这有助于表达先发生、后上传的情况。来源：GS1 EPCIS 标准工程实现中还应记录设备时间可信程度，不能把手持机上可随意修改的时间直接当作唯一排序依据。

离线前下载什么，离线时允许做什么

建议仅向设备下发当前任务所需的单据、产品规则和允许范围，并带上有效期及版本。某些动作可以离线采集，另一些如高价值商品最终放行、跨仓调拨确认或奖金兑现，可能需要在线校验。权限边界由业务决定，不应为了宣称“全离线支持”而隐藏无法确认的状态。

操作界面应持续显示待上传数量和最早未完成时间。若设备存储已满、登录已过期或缓存任务过期，应明确提示并引导处理。不能继续发出成功声音却没有保存数据。交接班时也要交接未完成记录，避免操作员退出账号后下一班看不到前班遗留任务。

恢复网络后按业务处理冲突

建议上传时逐事件返回结果，区分成功、重复确认、暂时失败和业务冲突。整批里九条成功、一条被拒，客户端应保留那一条，并解释原因；不能整批再次记账，也不能把十条一并标成成功。重试机制需要控制频率，让网络恢复后不会被大量设备同时反复请求压垮。

遇到码已经出库、单据数量不足或箱关联已变化，应保留本机原始采集和服务端冲突说明，由有权限的人复核。不要“以最后一次上传为准”覆盖前一笔业务。对于实物已经离库的情况，更需要补充单据与责任记录，不能只让操作员删掉红色报错。

验收要刻意制造不完整情况

建议在提交前断网、提交后返回前断网、上传一半断电、同事件多次重试、两设备处理同一码、服务器拒绝单据等场景下测试。每次核对设备待办、后台事件、库存账和实物状态。真正值得确认的是最终只发生一次正确的业务，而不只是恢复后页面变绿。

还需演练设备损坏后的恢复办法。未上传数据存在本机时，服务器备份并不能恢复它；是否需要设备侧受控备份，应根据业务风险与信息保护要求确定。丢失设备应能够撤销访问权限，避免继续读取与本机任务无关的数据。

交付物建议包含离线动作清单、冲突处理表、操作员交接规范和断网演练记录。衡量离线能力时，应看丢单、重复记账与悬而未决记录能否被发现并处理，而不只是“没有网络也能扫码”。