销售单确认后,Odoo 是怎样一路生成发货与补货动作的
从 sale.order._action_confirm 到 sale.order.line._action_launch_stock_rule,再到 stock.rule.run、_run_pull、_run_buy,讲清楚销售如何触发库存、采购与补货链。
TOPIC PICKS
从 sale.order._action_confirm 到 sale.order.line._action_launch_stock_rule,再到 stock.rule.run、_run_pull、_run_buy,讲清楚销售如何触发库存、采购与补货链。
可以顺着继续读的相邻方向
很多团队把 Optional Products、Accessory Products、网站上的 cross-sell snippet 混成同一种“推荐商品”。但从 sale、sale_management 与 website_sale 源码看,它们出现的时机、承载的数据结构和面向的用户动作完全不同。本文把三者的职责边界讲透。
很多人在 Odoo 里排查价目表时,只盯着公式本身,却没先搞清规则优先级、适用范围和国家组匹配。官方源码显示,真正决定“为什么选到这条价目表、为什么命中这条规则”的,是 pricelist 选择与 rule 搜索顺序的组合。本文把这套逻辑讲透。
很多团队觉得 invoice policy 只是产品上的一个单选项:按订购数量开票,或按交付数量开票。但从源码看,它会直接改写 qty_to_invoice、upselling、费用重计费和服务产品提示语义。本文专门讲清 order vs delivered qty 最容易踩坑的边界。
很多人一说 Odoo 优惠券,就先想到电商结算页或 POS 扫码。但从官方模块依赖和 sale_loyalty 源码看,销售订单上的 loyalty 应用边界非常独立:它有自己的手动领券、奖励线、确认时积分结算和取消回滚逻辑。本文专门讲清 sales order 场景与网站/POS 的边界。
很多人把 Odoo 销售里的 Upselling Opportunity 和订阅续费、服务加量、续签报价混成一件事。可从官方 sale 源码看,sale.order 里的 upsell 本质上只是开票状态和待办活动信号,并不等于 subscription renewal 引擎。本文专门讲清 renewal 场景该怎样与 sales order 协作。
很多团队把报价模板当成“把历史报价复制一份”。但在官方源码里,模板真正继承到销售单的内容,和不会继承、只在模板层生效的内容,边界非常清楚。本文重点讲透条款、可选产品、公司默认模板与电商订单之间的继承边界。