销售单确认后，Odoo 是怎样一路生成发货与补货动作的
从 sale.order._action_confirm 到 sale.order.line._action_launch_stock_rule，再到 stock.rule.run、_run_pull、_run_buy，讲清楚销售如何触发库存、采购与补货链。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 企业版订阅按工时计费为什么不是“timesheet 填了就能开票”而已：postpaid line、delivered qty 与发票回链讲透
sale_subscription_timesheet 解决的是订阅、项目工时和开票三者之间的精确衔接：哪些订阅行算 postpaid、哪些 timesheet
Odoo 企业版租赁为什么不是“开始日期 + 结束日期 = 一个价格”而已：pricing rule、overnight period 与 late
企业版 sale_renting 真正困难的地方不是租出去，而是如何把时长、夜间计费、延迟归还、部分取还货和价格更新规则统一成一套可解释的租赁语义。
Odoo 企业版可排班服务销售为什么不是“确认订单后生成几个班次”而已：role 匹配、hours_to_plan 与 unassign deadline
sale_planning 处理的是服务销售和排班系统之间的契约：什么产品能计划、按什么 role 找人、已售工时如何拆成 slot、何时还能取消或回收未分配班次。
Odoo 企业版销售提成为什么不是“按订单金额乘系数”而已：plan 区间、target 保留与多币种 achievement 边界讲透
企业版 sale_commission 处理的不是一个简单公式，而是一整套计划管理：计划周期拉长或缩短时 target 怎么保留、不同销售或经理视角下
Odoo 销售 Combo 为什么不是 Kit 换个名字：组合商品定价、子项展开与发票表现讲透
很多人看到 Odoo 的 combo product，会把它和 phantom kit 或可选产品混在一起。但标准销售源码里，combo 更像一种前台成交结构：主行价格归零、子项按 base price 分摊、开票时还能折叠显示。本文把这套定价与展示机制讲透。
Odoo 优惠券为什么不是“打个折就完了”：Reward Line、Coupon 与 Loyalty Program 的真实协作机制
很多人把 Odoo 优惠券和忠诚度计划理解成销售单上自动多一行折扣，但官方源码里的实现更像一套“奖励编排引擎”：先算资格，再决定 reward，再落成 reward line，并持续回写积分与历史。本文把这套机制讲透。