Odoo 企业版项目订阅收益为什么不是“项目挂个 subscription”：利润统计、汇率换算与循环任务讲透

项目与订阅一旦结合，最容易出现两个错觉：一是“有订阅收入就等于项目盈利稳定”，二是“订阅型服务和普通服务项目差不多”。project_sale_subscription 之所以有研究价值，就是因为它把这两件事拆开做了精细处理。

主要参考：

• enterprise/project_sale_subscription/models/project_project.py
• enterprise/project_sale_subscription/models/sale_order_line.py
• enterprise/project_sale_subscription/tests/test_project_profitability.py

一、订阅收入会单独进入项目 profitability 结构

project_project.py 中并不是把 subscription 当成普通 sale item 混在一起，而是为 profitability 单独加入 subscriptions section。这样项目经理在看收入结构时，能区分一次性服务收入与经常性收入，不会把二者混成一个总数自我安慰。

二、多币种与模板期限会直接影响“待开票”金额

测试文件非常值得看：它专门验证跨公司、多币种、不同订阅模板期限下的 to_invoice 计算。也就是说，项目上看到的订阅收益预测，并不是简单把 recurring_monthly 相加，而要考虑汇率和模板持续期。这个口径一旦理解错，项目盈利看板会非常误导。

三、订阅产品还能驱动循环任务

sale_order_line.py 里如果产品本身是 recurring service，并且项目允许 recurring tasks，系统会在生成任务时同步创建 recurrence 规则。这里最容易被忽略：订阅不只是财务节奏，它还会影响项目执行节奏。收费按月、任务按周，或者收费有限期、任务无限循环，都会带来完全不同的交付体验。

四、常见误区

• 把订阅收入混进普通项目收入看总额。
• 忽略多币种与模板期限，只看 monthly 金额。
• 只建了订阅单，却没理解循环任务如何跟着生成。

五、实战建议

1. 订阅型项目单独看 profitability section，不要与固定工时项目混读。
2. 多公司或多币种场景一定要做测试账，确认 to_invoice 符合业务预期。
3. 如果项目要长期重复交付，优先设计 recurring task 规则，而不是靠人工复制任务。

六、结论

项目订阅化的难点，不在“能不能挂一个订阅”，而在收入预测和交付节奏能否同时成立。project_sale_subscription 正是在打通这两件事。