销售单确认后，Odoo 是怎样一路生成发货与补货动作的
从 sale.order._action_confirm 到 sale.order.line._action_launch_stock_rule，再到 stock.rule.run、_run_pull、_run_buy，讲清楚销售如何触发库存、采购与补货链。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 矩阵录单为什么不是前端多一个表格：variant matrix 的服务端落单、冲突保护与报表回填讲透
很多人把 Sales Product Matrix 理解成“销售单上多一个二维表”；但标准 Odoo 明确把矩阵读取、变体生成、数量差异计算和销售行更新都放在服务端完成，原因是前端并不会加载全部订单行。它还会处理 no-variant 属性、重复销售行冲突、草稿/已确认单的删改边界，并支持把已录矩阵反填回报价 PDF。本文把这条链讲透。
Odoo 报价模板为什么不只是“预填几行”：Quotation Template、可选产品与 PDF 附件链路讲透
很多人把 Odoo Quotation Template 理解成复制几条默认行，但官方实现其实把有效期、签署/付款要求、可选产品区、以及报价 PDF 附件一起串成了一套“成交前台”。本文从 sale_management 与 sale_pdf_quote_builder 的源码把这条链路讲清楚。
Odoo 里程碑计费为什么不是“完成一个点就开票”：milestone、销售行与 delivered quantity 到底怎么联动
很多人以为 Odoo 的 milestone billing 只是达到里程碑后允许开票，但源码里真正联动的是 project milestone、sale.order.line 和 qty_delivered。本文把这条链路讲清楚。
Odoo Backorder 为什么会自己冒出来：部分履约、剩余数量和补单逻辑讲透
很多仓库操作里都会遇到 backorder，但很多人并不真正理解它出现的边界。本文把部分履约、剩余数量和 backorder 逻辑讲清楚。
Odoo 联系人和公司为什么老串在一起：commercial_partner_id、伙伴层级和业务归属讲透
很多发票、销售、联系人归属问题，最后都会绕到 commercial_partner_id。本文讲清 Odoo 为什么既保留联系人层，又要有商业主体层。
销售确认后为什么不是直接建发货单：procurement values、stock.rule.run 和 picking 再确认到底怎么串？
很多人知道销售单确认后会触发库存，但容易把这件事理解成“sale 直接生成 picking”。结合 sale_stock 与 stock 源码看，真实主线更像是：订单行先组织 procurement values，再交给 stock.rule.run 分流，最后由 move/picking 链路继续推进。