月度盘点结束后，仓库主管发现结果比账面少了两个货架的库存。现场人员最先怀疑的是扫码枪不灵敏、网络不稳定，但重新走一遍流程后，设备扫码正常，网络也没有中断。真正的问题出在任务分配环节：那两组货架从一开始就没有被纳入任何人的盘点任务。扫码盘点出现漏扫，设备故障只是少数情况，更多时候是任务生成、货架映射和状态回传三个环节存在缺口。排查时按顺序往下走，比在现场反复试设备更有效。
先看盘点任务是怎么生成的
盘点任务通常由系统按仓库、区域或库位范围自动生成。漏扫的第一层原因，往往是生成规则本身就没有覆盖全部货架。核对时要确认任务生成时选择的范围是整仓还是部分区域，筛选条件里是否带了状态、品类或启用标记，导致部分货架被排除在外。还要确认任务生成的时间点，如果生成之后仓库又新增或调整了货架，这些货架不会自动进入已有任务。把任务范围和货架总数做一次比对，数量对不上，问题就定位在生成规则这一层。
再查货架与库位的绑定关系
任务范围没问题，仍然漏扫，就要看货架和库位的对应关系是否完整。常见情况是一个库位绑定了两个货架编码，扫码时只认其中一个；或者部分货架处于空绑定状态，系统里有这个货架，但没有挂到任何库位上，任务生成时自然被跳过。核对方法是导出货架清单和库位绑定清单做交叉比对，重点看重复绑定、空绑定和绑定到已停用库位这三种情况。这一步不需要到现场，在后台数据里就能查清。
然后看扫码端的任务清单展示
后台任务完整，不代表扫码端能看到全部货架。扫码端的任务清单通常有排序和筛选逻辑，如果默认只显示待扫项，或者按库位顺序排列但分页加载，排在后面的货架容易被忽略。核对时要确认清单是否完整加载、筛选条件是否会隐藏部分条目、排序方式是否让某些货架长期排在末尾。让现场人员报出清单首尾各几个货架编码，和后台任务比对，就能判断展示层有没有丢数据。
最后核对完成状态回传
还有一类漏扫是假漏扫：现场确实扫了，但数据没有回传成功。这时要区分未扫和扫了未上传两种情况。核对扫码记录的时间戳和任务完成状态，看是否存在本地有记录、服务端没有收到的情况。网络切换、批量提交失败、重复提交覆盖都可能造成这类问题。把扫码端的本地记录和服务端记录做一次对账，比单纯看完成率更准确。
盘点前的任务分配自查清单
正式盘点前，建议按以下顺序过一遍：确认任务生成范围覆盖全部在用货架；比对货架总数与任务条目数；检查货架与库位的绑定是否有重复、空绑和停用绑定；确认扫码端清单完整加载且筛选条件不会隐藏条目；确认状态回传机制在弱网下不会丢记录。这五项都确认过，漏扫概率会明显下降。
在需求梳理阶段把盘点边界说清楚，能省掉很多事后排查。it数运在承接企业数字化需求时，会先和业务方确认盘点的范围定义、货架编码规则和状态回传方式，把这些前置条件写进方案，后续开发和维护才有明确依据。盘点漏扫看似是现场问题，根子往往在任务分配的设计上，按顺序核对，比反复换设备更接近答案。
