同一批货连扫三次，系统库存凭空多出两倍，多数人的第一反应是扫码枪坏了或者网络卡了。但真正的症结往往不在硬件，而在于入库合并逻辑与幂等规则没有对齐：业务侧怎么定义“同一笔入库”，系统侧怎么判定“重复提交”，两套标准各说各话，重复数据就会一路滚进库存。
先看业务单据层
入库单号是否全局唯一？供应商批次号是否随货同行？物料编码是否允许一单多行？同批次是否允许分次到货？这四个问题划定了“重复”的业务边界——分次到货是正常经营，重复提交才是异常。如果业务上本来就允许分批到货，系统就不能简单按物料编码判重，否则会把真实入库误合并掉。建议先把单据类型、到货方式、批次管理要求整理成一张判定表，写清楚哪些场景允许重复出现、哪些必须拦截。
再看扫码采集层
条码是否唯一？是否携带批次与序列号？连续扫描有没有防抖间隔？离线补传是否保留原始时间戳？不少重复入库的源头在于离线模式下同一个码被反复缓存，联网后集中补传，系统只看到多条相同记录，却看不到它们本是同一次扫描。采集层要保证每条记录都能追溯到扫描时刻和设备来源，补传时携带原始时间而非上传时间。
然后看系统合并层
幂等键怎么设计？常见做法是单号加物料加批次加时间窗组合判重。重复提交是覆盖还是累加，必须有明确约定；冲销与红冲有没有独立入口，不能靠删除原单了事。如果幂等键只用物料名称，同名不同规格的物料就会被误判为重复；如果重复提交默认累加，库存虚高几乎躲不掉。
最后看对账与复盘层
库存流水与入库单应做双向核对，差异台账至少记录单据号、物料、批次、数量差、发生时间、处理人和处理方式。日结看当日入库笔数与流水条数是否一致，月结看差异是否清零、冲销是否有据可查。在需求梳理阶段把合并规则写成可验收条目，例如“同一单号同一物料同一批次在十分钟内重复提交，系统只保留一条并记录拦截日志”，规则才可测试、可回溯。
几个常见坑值得提前避开
用物料名称当幂等键；离线补传不带时间戳；重复单据直接删除不留痕。上线前应准备测试用例，覆盖正常单次入库、同批次分次到货、连续快速扫描、离线补传、重复提交、冲销后重新入库等场景，逐条验证系统行为是否符合业务定义。
重复入库的根因多在规则定义，不在设备。把合并规则、冲销规则和核对频率写进交付文档，库存数字才有稳定的解释口径。
