Odoo CRM 预测报表为什么不能只看 expected revenue：prorated revenue、lost reason 与 Pipeline Analysis 口径讲透
很多团队拿 Odoo CRM 报表时只盯着 expected revenue，结果越看越乱。官方报表真正更依赖的是 stage、deadline、prorated revenue、won_status 与 lost reason 这些维度；如果你不先分清预测值和原值，漏斗、forecast 与丢单复盘都会失真。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo CRM 联系人为什么有时会被“顺手改掉”：lead 与 partner 的邮箱、电话和地址同步边界
很多人以为 Odoo CRM 里的 lead 联系方式只是临时填写，不会影响客户主数据。源码其实不是这么保守：一旦 lead 已经挂上 partner，邮箱、电话、语言、地址会进入一套‘有条件同步’机制。
Odoo CRM 里的 Sales Team 不是‘分组标签’：team_id、默认阶段和邮箱入口到底怎么连
很多人把 Sales Team 当成报表维度或看板分组，但源码里的 team_id 远不止这个作用。它会影响默认 team、默认 stage、stage 可见范围，甚至邮件别名进来的线索会落到哪条 pipeline。
Odoo CRM 里 Lead 和 Opportunity 为什么不能混着看：阶段、概率和赢单语义到底怎么串起来
很多人把 Odoo CRM 里的线索和商机当成同一类记录，只是名字不同。其实 type、stage、probability 和 won/lost 语义是连在一起的。
Odoo 企业版预约转 CRM 的安全边界：日历默认上下文字段白名单与顾问分配如何生效
预约转商机看似只是多建一个 opportunity，实际上还要解决默认上下文注入的白名单边界与 staff user 强制分配问题。
Odoo 企业版 CRM 订阅商机为什么不是“成单后等续费”：商机、订阅任务与收入上下文桥接讲透
订阅商机真正复杂的地方，是 recurring revenue、项目任务和 postpaid 工时要在销售赢单后持续保持一条上下文链。
Odoo 企业版工单转商机为什么 team 和负责人不是简单复制：helpdesk team 配置、partner 默认值与 action 返回讲透
crm_helpdesk 真正难的不是“把 ticket 变成 lead”，而是决定客户、销售团队、负责人和返回动作该跟谁走。