Odoo 企业版波次条码为什么不是“把几张 picking 合在一起扫”：batch picking 的确认、取消与包裹边界讲透

把多张拣货单塞进一个 batch，不等于系统就能“顺便支持波次扫描”。

这篇文章主要参考：

• enterprise/stock_barcode_picking_batch/models/stock_picking_batch.py
• enterprise/stock_barcode/wizard/stock_barcode_cancel_operation.py
• enterprise/quality_control_picking_batch/models/stock_picking.py

一、batch picking 先解决的是“可加入哪些单”

新建 batch 后，如果还没有 picking，_get_stock_barcode_data() 返回的不是 move line 数据，而是 allowed_pickings、用户、伙伴、picking type 等候选上下文。

这说明 batch 客户端的第一阶段是“选单并确认”，不是直接进入拣货明细。

二、确认动作不是前端拼接，而是受约束的后端写入

action_confirm_batch_picking() 先把选中的 picking 写入 batch_id，再调用 action_confirm()。如果 picking type 不一致、状态不允许、父类报错，整个确认都会被阻断。

也就是说，batch 不是前端视图聚合，而是真实的业务容器。

三、取消入口为什么单独做成向导

无论是单 picking 还是 batch picking，条码端取消都不是直接按钮写状态，而是经由 stock_barcode.cancel.operation 向导返回 infos.cancelled。

原因很简单：移动端需要一个稳定、可确认、可回传状态的交互协议，而不是隐式地把取消动作塞进任意写入请求里。

四、最容易忽略的边界：batch 之后仍然保留 picking 粒度

即使 stock.picking.batch 会把 picking 汇总到一处，系统仍会按 picking 名称排序、保留 picking_ids，并在质量、拆单、包裹等后续链路上继续以 picking 为单位处理。

这就是为什么 batch picking 更像“统一调度层”，而不是“把 picking 合并成一张超级单”。

五、结论

企业版波次条码真正难的不是界面，而是：候选 picking 过滤、确认写入、取消协议和后续 picking 粒度保持一致。理解这点，才能看懂 batch 为什么既像合集，又始终不是合单。