读写器产出的是观测，Odoo 需要的是决策。两者之间夹着 RFID 部署里最不出彩、也最要命的一段代码：把几十万条 EPC 读取，转换成少量「有人愿意签字」的库存调整。
这件事做错的症状不会是报错，而是仓库不再相信系统，开始在旁边另开一张表格。
变化了什么：stock.inventory 已移除，模型是 stock.quant
网上大量教程仍在描述一个 Odoo 已经删掉的模型，所以请从当下的事实出发。
- 旧的 stock.inventory 单据已被废弃；从 Odoo 15 起，盘点直接做在 stock.quant 记录上。
- 一条 quant 由产品、库位、批次、包装与货主唯一确定；这个五元组就是导入时必须匹配的主键。
- 盘点就是在库存模式下把 inventory_quantity 写到 quant 上，然后执行「应用库存」。
- 应用会生成标记为库存调整的库存移动；如果产品启用了估值，还会生成估值层。
- 调整向导（stock.inventory.adjustment.name）把一次盘点会话归为一组，并携带会计日期——正是它让盘点变得可审计。
读写器与 ERP 之间的暂存层
绝不要让读写器直接写生产库存；暂存层就是坏数据被拦下的地方。
- 先存原始读取：EPC、天线、读写器、时间戳、RSSI 与会话标识。
- EPC 到产品的解析放在单独一步，这样修正映射不必重盘整个仓库。
- 保留解析结果、置信度与解析来源，因为「我们按前缀猜的」正是审计会追问的信息。
- 暂存表按会话做幂等，重跑同一次盘点不会重复计数。
- 保留每个 EPC 的原始读取次数；重复读是正常的，而它的数量是判断读写器配置好坏的信号。
EPC 匹配到产品、批次与库位
差异大多是在匹配这一步被「制造」出来的，而它完全可以避免。
- 通过显式登记库解析 EPC，不要在读取时直接解析 SGTIN 模式，除非该模式有合同保证。
- 若产品启用批次管理，批次必须来自登记库或包装关系；单凭 EPC 通常拿不到批次。
- 库位来自会话元数据，而不是标签，因为标签不知道自己在哪。
- 若一个 EPC 解析出两个产品，立即停下并隔离该读取；「静默取第一个匹配」正是幽灵库存的来源。
- 把未匹配的 EPC 记下来而不是丢弃；未知标签是发现流程缺陷最快的线索。
应有 vs 实盘：大多数人算错的算术
差异不是「实盘减在手」，它是三方比较，而第三项是预留。
- 在手数量是台账认为物理上存在的数量。
- 预留数量已经被发货单或生产单占用，不能当作「缺失」处理。
- 实盘数量是会话期间读写器看到的数量，经过去重与过滤规则之后的结果。
- 差异等于实盘减在手；当一行有预留却出现负差异，通常意味着货已备好待发，而不是丢了。
- 差异要同时以数量和金额报告，因为运营按件数分流，而财务按金额分流。
安全地应用调整
写入路径必须无聊、批量、并且能在会话窗口内回退。
- 在库存模式下写 inventory_quantity，然后按库位或按会话应用，而不是逐个标签应用。
- 以每批几百条 quant 分块；一条 quant 一个事务，会把十万标签的盘点变成两小时的锁。
- 锁顺序很重要：写入前按产品与库位排序，避免两个并发会话互相死锁。
- 正在调拨或存在未完成拣货的库位一律不调，把这些 quant 推到第二轮处理。
- 把盘点会话的引用写进调整记录，让估值层能追溯回那次盘点。
审批、会计日期与审计轨迹
「调整」与「改数」的区别，就在于谁批准了它、以及它什么时候进了账。
- 超过金额阈值的调整走二级审批；阈值以下可自动应用，但仍要记录操作人。
- 会计日期要刻意设定；30 号盘的、3 号才应用的，属于上一个期间，否则月结的数字就变了。
- 把盘点报告作为附件挂在调整单上，而不是放在一个迟早会被整理掉的共享文件夹。
- 每一行都记录调整前数量、实盘数量、差值以及原因代码。
- 期末把调整合计与估值报表核对一次；两者讲的必须是同一个故事。
未知标签、重复读与重复盘点
这三类情况吃掉了大部分支持工时，而每一类都可以用一条明确的廉价策略处理。
- 未知标签：先放进隔离库位并生成任务，每周复核；绝不要写进真实产品。
- 重复读：按 EPC 单会话去重，但保留原始读取次数，以便识别会话设置错误的读写器。
- 重复盘点：用同一份会话定义跑第二遍，在调整之前比对两次结果，而不是之后。
- 部分盘点：把会话标记为部分盘点，只调整真正走到的库位，否则没走过的货道会被写成零。
- 缺失标签：先在同一货架做一次复扫任务，再做负调整，因为被屏蔽的托盘看起来和一个空托盘一模一样。
能扛过第一个月结的上线方式
在第一次真实调整之前，先在数据库副本上把整条链路演练一遍。
- 在同量级的数据库副本上演练，这样耗时与锁行为才有代表性。
- 跑一次完整盘点但不应用，把算出的差异与当前台账对比；差额就是你的工具误差。
- 然后只对一个库位应用，关一次账期，检查估值报表与库存移动。
- 只有在一次干净的期结之后，才扩展到全站点，并把操作手册交给运营。
- 每月发布各库位的差异趋势；趋势上升是流程问题，不是盘点问题。
工程总结很短：暂存原始读取、确定性解析、三方差异算术、按稳定锁顺序批量写 quant、带明确会计日期地应用、并且把每一个中间数字都留住。做到这些，RFID 就不再是盘点小玩意，而是台账终于变真的原因。
