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 企业版 AI 建线索为什么不是“让模型随便写一条 CRM lead”而已：available params、public/portal 权限与
ai_crm 并不是给大模型一个 create lead 的任意写权限。它先暴露可用参数，再走受控工具创建流程，并且在 portal 场景明确禁止把已有值随便覆盖，确保
Odoo CRM 自动分配为什么既看 24 小时又看 30 天：assignment_max、daily quota 与成员容量口径讲透
很多团队只盯着 Odoo CRM 里的 assignment_max，以为那就是今天还能分多少线索。源码其实把 30 天平均容量、近 24 小时已分配量和 force_quota 三层逻辑分开了。
Odoo CRM 自动分配为什么会先‘消重再发牌’：team 预分桶、重复合并与 round-robin 前置清洗讲透
很多人以为 Odoo CRM 的自动分配只是按照 team quota 把线索平均塞给销售。源码真正先做的是 team 级别的预分桶、候选线索去重，以及把重复记录先合并，再把干净结果交给后续成员分配。
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 的安全边界：日历默认上下文字段白名单与顾问分配如何生效
预约转商机看似只是多建一个 opportunity，实际上还要解决默认上下文注入的白名单边界与 staff user 强制分配问题。