网站卖订阅最难的不是展示月付价格，而是购物车到底允许什么组合、什么时候必须先拿到客户地址、改计划后价格又怎么实时刷新。
这篇文章主要参考了以下企业版源码与测试入口：
enterprise/website_sale_subscription/models/product_template.pyenterprise/website_sale_subscription/models/sale_order.pyenterprise/website_sale_subscription/tests/test_website_sale_subscription.py
一、这个模块真正解决的不是表面动作，而是跨模块语义对齐
website_sale_subscription 真正处理的是电商购物车边界：订阅计划怎样进入 combination info，同一购物车里 one-time 与 recurring 什么时候允许混卖，客户地址又何时成为下单前置条件。
如果只看 UI，很容易把它理解成一个按钮、一张表或一个新视图。但从 website_sale_subscription 的模型、测试和桥接关系看，官方真正关心的是：前台动作发生以后，后端主链路能不能继续保持同一套业务语义。
二、核心机制链路
1. 前台价格展示先看 recurring pricings
_get_recurring_pricings()、_get_additionnal_combination_info() 与 tests 里的 multi pricelist 场景说明，前台不是只显示一个标价，而是根据 plan 和价目表动态组合。
2. 购物车不是任何商品都能混放
_cart_add(..., plan_id=None)、_has_one_time_sale() 以及 test_cart_add_one_time_then_recurring_not_allowed 说明一次性商品与订阅商品的混卖是受约束的。
3. 地址决定税务与是否能继续下单
_needs_customer_address() 与 test_subscription_requires_partner_country / recompute_taxes_on_address_change 说明订阅订单的税务计算需要足够的客户地址上下文。
三、最容易被误解的边界
- 把订阅当普通网站商品，不在前台区分 plan 价格。
- 购物车随便混 one-time 和 recurring 产品，后续订阅单语义混乱。
- 客户地址不完整就让其结账，结果税务与 fiscal position 失真。
这些误解之所以常见，往往是因为大家只看见“入口动作”，却没有继续追到模型方法、状态切换、聚合口径和测试场景里去看 Odoo 究竟把什么当成事实、把什么当成辅助信息。
四、实施与排查时，建议按这个顺序看
- 先查 combination info 返回了哪些 recurring pricing。
- 再验证 _cart_add 对混卖场景的限制。
- 最后检查地址变化是否触发 fiscal position / tax recompute。
对企业版功能来说，排查顺序非常重要。很多看似是“结果不对”的问题，真正根因往往更早：字段上下文没带过去、桥接对象没建、状态机没推进、或者权限/公司边界一开始就错了。
五、结论
网站订阅真正重要的，不是“能卖月付产品”，而是把购物车、计划、税务地址三件事同时拉回同一条订阅语义线上。
DISCUSSION
评论区