出库时的 stock.move.line 是如何确定的
用通俗但不失源码细节的方式，讲清楚 Odoo 出库时 stock.move.line 的生成逻辑：从 stock.move、stock.quant、移除策略到 lot/serial 拆行。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 补货日期为什么总感觉不准：供应商提前期、规则 Lead Time 与可见天数的倒排链
很多团队觉得 Odoo 的补货日期像在“随缘”，今天建议下单，明天又提前几天。真去看 stock_rule、stock_orderpoint 和相关日期字段后会发现，系统并不是乱算，而是在把需求日期沿着规则提前期、供应商提前期和 visibility days 一层层倒排。
Odoo Cross Dock 为什么不是“收货单直接变出库单”：Input→Output 的中转语义和 xdock picking type 到底在表达什么
很多人把 cross-dock 理解成“货不入库存，直接发走”。这句话方向没错，但太粗。Odoo 真正表达的是：货虽然不进入 Stock 储位，但仍然要经过一个明确的 Input→Output 中转链路，而且系统专门为此预留了 xdock picking type。本文把这层语义讲透。
销售改数量后为什么不会重复生成发货单：`_get_qty_procurement()` 的防重复逻辑
从 sale_stock 源码看，Odoo 怎样先统计已履约数量，再决定要不要重新发起 procurement，避免确认、改数量、补单时重复造 move。
Odoo 项目为什么能直接看到收发货：project_stock 的关联字段、嵌入动作与 picking 上下文边界讲透
很多人以为 project_stock 会自动帮项目生成领料单或把库存流程深度嵌进任务里，但官方源码做得其实很克制：它先在 stock.picking 上补一个 project_id，再给项目页挂上指向收货、发货和全部调拨的嵌入动作，并通过 restricted_picking_type_code、default_project_id 和 default_partner_id 把打开后的列表与新建行为限制在项目语义里。
Odoo 采购收货为什么不是“一行采购一张收货单”：已有 picking 复用、move 挂接与 qty_received 真实链路
很多人以为采购确认后，Odoo 会按采购行机械地一行生成一张收货单。但从 purchase_stock 的 _create_picking、_create_or_update_picking 与 _prepare_qty_received 看，系统真正维护的是“订单级收货容器 + 行级 stock.move + 已完成 move 反推收货数量”的模型。
Odoo Pull Rule 为什么总像“上一张单据凭空出现”：目标库位找规则、来源库位建 move 与上游补货链讲透
很多人第一次看 Pull Rule，会觉得系统像“倒着长单据”：明明只是下游库位缺货，怎么上一段调拨、采购或制造动作就自己冒出来了？从 stock_rule.py 看，Pull Rule 的关键不是“货往哪走”，而是“哪里产生需求、系统就去哪里找能把货拉过来的规则”。