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 里选了公司为什么不一定立刻挂成联系人：commercial_partner_id 预选、联系方式比对与 partner 真正落链边界讲透
很多人以为在线索上选了商业公司就等于 partner_id 已经定了，但源码把 commercial_partner_id 当成 UX 辅助字段。创建时若电话或邮箱和该公司不一致，系统宁可只保留 partner_name，也不会强行挂错 partner。
Odoo CRM 为什么邮箱和电话会显示“质量正确/错误”：标准化、校验库与字段边界讲透
很多人把 Odoo CRM 的 Email Quality 和 Phone Quality 当成营销评分，其实源码只是在做格式与可解析性校验：邮箱走 normalize + mail_validate，电话走国家码上下文和 phone_parse。
Odoo CRM 丢单原因为什么“停用不等于消失”：lost reason 的 active、统计口径与历史可追溯边界讲透
很多团队以为把某个 lost reason 停用后，历史报表就不会再看到它，但 crm.lost.reason 的 active 只影响继续使用，不会抹掉历史线索；统计和跳转还会在 active_test=False 下把旧数据算进去。
Odoo CRM 为什么一换 team 阶段就可能‘跳回去’：stage 作用域、默认阶段回退与 company 连贯性讲透
很多人以为把商机从一个 sales team 转给另一个 team，只是改个 team_id。源码里 stage、company 甚至 date_last_stage_update 都可能一起联动，因为阶段本身带 team 作用域，跨 team 后旧阶段未必还合法。
Odoo CRM 安排会议为什么总像‘懂你的下一步’：opportunity 上下文、smart calendar 与 reschedule 取时逻辑讲透
很多人觉得 Odoo CRM 的 Schedule Meeting 只是打开日历窗口。源码里它会把商机、客户、team、标题和最相关的时间范围一起塞进上下文，Reschedule 还会优先锚定当前用户的下一活动会议。
Odoo CRM 为什么‘标记赢单’不只是把概率改成 100：won stage 选择、date_closed 与 rainbowman 反馈链路讲透
很多人把 Mark Won 理解成一个把 probability 改成 100 的按钮。源码里它还会找最合适的 won stage、处理 date_closed 语义，并在满足条件时生成与 team、来源、国家相关的庆祝反馈。