库存质检最容易被低估的地方，是大家总以为“把检查项显示出来”就算完成集成。企业版远不止如此。
这篇文章主要参考：
enterprise/quality_control_picking_batch/models/stock_picking_batch.pyenterprise/quality_control_picking_batch/models/stock_picking.pyenterprise/quality_control_picking_batch/models/quality_check.py
一、batch 上的 quality_check_todo 只是结果，不是根因
batch 级别的 quality_check_todo 只是把各 picking 的待检状态聚合出来，让波次界面知道当前是否仍有未完成检查。
所以它本质上是一个调度信号，不是质检记录本身。
二、真正复杂的是 split 之后如何处理旧检查项
_add_to_wave_post_picking_split_hook() 很关键：当 move 因拆分、转移或重建而离开原 picking 时，旧的 operation/product 检查可能已经失去业务意义。
官方做法不是“尽量复用旧检查”，而是：
- 先找出
quality_state == 'none'的旧检查 - 如果 operation 级别已失效，或 product 级别对应产品已经不在 picking 内，就删除
- 再对新的 move 重新
_create_quality_checks()
这体现了一个很清晰的设计边界：检查项依附的是当前操作事实，不是历史 UI 痕迹。
三、为什么这一层放在库存而不是制造
因为这里讲的是 picking / wave / batch 维度的收货与出库控制，核心对象还是 stock.picking。即使制造也会触发质量机制，波次场景里的阻塞与重建逻辑仍然首先属于库存执行层。
四、结论
企业版 batch 质检的重点不是“多显示几个质检按钮”，而是在批量执行、拆分和重新分配之后，系统如何保证检查项仍然精确绑定到当前可执行的库存事实。
DISCUSSION
评论区