销售单确认后，Odoo 是怎样一路生成发货与补货动作的
从 sale.order._action_confirm 到 sale.order.line._action_launch_stock_rule，再到 stock.rule.run、_run_pull、_run_buy，讲清楚销售如何触发库存、采购与补货链。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 企业版 Shopee 发货为什么不是“拿到单号就结束”：processing pickings、label 状态与 tracking 回填链讲透
sale_shopee 先筛 eligible pickings，再取 tracking，接着请求和轮询 label 状态；平台履约是多段异步链，而不是拿到单号就完。
Odoo 企业版 Lazada 发货为什么不是“打印面单就算出库”：pack、shipping label 与 RTS 状态回跳讲透
sale_lazada 把发货拆成打包、下载面单、设为 Ready to Ship 三段，package_extern_id、label 和平台状态彼此约束，不能一步跳过。
Odoo 企业版 Amazon 履约为什么不是“订单进来、发货出去就完了”：sale line 完成度、承运商合规与 feed 回执链讲透
sale_amazon 会在 stock.picking 进入同步前先校验销售行是否完整发出、承运商与 tracking 是否合规，再把发货交给 Amazon feed；履约不是单一 done 动作。
Odoo 企业版销售：订阅门户里改地址、绑支付方式和提前扣款，为什么都得沿着同一份合同权限走
sale_subscription 门户并不是把地址修改、支付交易和 token 绑定拆成三个互不相干的小功能；它们都先校验同一份 subscription access，再决定谁能改地址、谁能绑 token、以及提前扣哪一期。
Odoo 企业版销售：订阅升级、续费或关闭时，项目里的周期任务为什么要跟着换代或解绑
project_sale_subscription 并没有把项目任务当作订阅的静态副产品；renew、upsell、close、cancel 都会决定 project_id 是否继承、task recurrence 是否解绑，以及下一代合同还能不能继续沿用项目执行上下文。
Odoo 企业版销售：订阅服务接项目工时后，已交付数量、续费窗口与盈利看板如何互相回写
sale_subscription_timesheet 把“本期开了多少工时”映射成订阅交付数量，project_sale_subscription 再把订阅收入回投到项目盈利视图；于是 timesheet、开票周期和项目看板不再各说各话。