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 预测报表为什么不能只看 expected revenue：prorated revenue、lost reason 与 Pipeline Analysis 口径讲透
很多团队拿 Odoo CRM 报表时只盯着 expected revenue，结果越看越乱。官方报表真正更依赖的是 stage、deadline、prorated revenue、won_status 与 lost reason 这些维度；如果你不先分清预测值和原值，漏斗、forecast 与丢单复盘都会失真。
Odoo CRM 为什么“看起来重复”不等于“马上合并”：重复提示、可操作重复集与 merge 入口边界讲透
很多团队看到 Odoo CRM 的 duplicate 提示，就以为系统已经确认这几条线索应该合并。源码其实分得很开：界面提示用的是更宽的启发式集合，真正拿来处理、分配和 merge 的重复集更保守，而且会明确排除部分历史记录。
Odoo CRM 的概率为什么会自己跳：automated_probability、阶段赢单和 expected revenue 的边界讲透
很多人以为 Odoo CRM 里的 expected revenue 会跟着概率一起“改金额”。源码其实不是这么设计的：系统自动算的是概率，金额本体通常不动，真正被联动的是 prorated revenue、won/lost 语义和关闭时间。
Odoo CRM 自动概率为什么有时很聪明、有时很怪：PLS 频次表、团队样本与 Naive Bayes 边界讲透
很多人知道 Odoo CRM 有 automated probability，却不知道它背后依赖的是一套频次表和 Naive Bayes 估计。真正决定概率好不好用的，不只是当前阶段，还包括团队样本、字段值覆盖度、0.1 平滑以及你有没有手动脱离自动模式。
Odoo CRM 为什么一合并线索就“只剩一个来源”：dedup、merge 主记录与 UTM 归因边界讲透
很多人以为 Odoo CRM 的 merge 只是“把两条重复线索收纳到一起”。源码其实更像“选一个主记录，再把其他记录的依赖搬过去”。一旦你把不同来源的线索合并，campaign / medium / source 往往只会保留主记录那一套。
Odoo CRM 线索补全不是“点一下 enrich 就完了”：IAP 补全、字段保守写入与批处理边界讲透
很多人把 Odoo CRM 的 lead enrichment 理解成“自动查公司资料并填满线索”。源码其实保守得多：它会过滤邮箱类型、控制批量与锁、尽量只补空字段，还会用 iap_enrich_done 和 reveal_id 避免重复补全。