很多人以为条码盘点只是把 stock.quant.quantity 改一下。企业版不是这么设计的。
这篇文章主要参考：
enterprise/stock_barcode/models/stock_quant.pyenterprise/stock_barcode/controllers/stock_barcode.py
一、条码盘点走的是专门协议，不是普通表单保存
控制器 /stock_barcode/save_barcode_data 在 res_id 为空时，不会对某条 quant 调用常规 write，而是直接把前端传来的命令数组交给 stock.quant.barcode_write()。
这里的输入形态是：
[1, quant_id, {...}]：更新已有 quant[0, 0, {...}]：创建新的 quant 行
这说明移动端盘点界面维护的是一组“待提交操作”，而不是一条记录的同步表单。
二、为什么需要 dummy line
dummy_id 的存在，是为了让前端能先生成临时行，再在后端真正落成 quant。特别是扫描到已有库存但当前并未显示在用户盘点列表里时，系统可能创建/写入后再把结果重新回传给前端。
也就是说，dummy line 不是脏设计，而是移动端增量编辑与后端真实 quant 之间的缓冲层。
三、lot 自动补建不是便利功能，而是保证盘点流不断裂
barcode_write() 里有一段关键逻辑：如果命令里没有 lot_id 但有 lot_name，系统会先创建 stock.lot，再继续后面的 quant 写入。
这解决了现场最常见的问题：操作员先扫商品再录批次，不应该被迫退出盘点流程先去后台建 lot。
但边界也很清楚：自动补建 lot 只是在条码盘点这条受控链路里成立，不代表别的库存写入场景都应该模仿。
四、inventory_mode 和 user 认领为什么重要
barcode_write() 整体在 inventory_mode=True 的环境下执行；新建 quant 后还会补写 inventory_date，必要时把 user_id 认领给当前盘点人，避免页面离开再回来时记录“消失”。
这说明条码盘点真正维护的是“盘点工作区”，不是实时改一张全局库存表。
五、结论
企业版条码盘点的重点不是扫枪本身，而是：前端命令协议、dummy line、lot 自动补建和 inventory workset 共同组成的一条可连续执行的盘点链路。
DISCUSSION
评论区