Odoo CRM 丢单原因为什么“停用不等于消失”：lost reason 的 active、统计口径与历史可追溯边界讲透

先说结论

在 Odoo CRM 里，crm.lost.reason.active=False 的语义是：

• 以后少用或不再给新记录选它；
• 不是删除历史，也不是让历史报表失忆。

源码里两个细节很关键：

• _compute_leads_count() 用 with_context(active_test=False) 统计；
• action_lost_leads() 也带 active_test=False 打开相关线索。

所以一个丢单原因即使停用了，历史上挂着它的线索仍然会被看到、被计数、被分析。

一、为什么 Odoo 不把“停用”做成“抹除”

如果停用一个 lost reason 就把历史也一起抹掉，会立刻出现两个问题：

1. 历史分析断层；
2. 旧报表口径前后不一致。

Odoo 显然不想这么做。

在 CRM 里，丢单原因属于过程解释字段。 你可以优化未来字典，但不应该篡改过去发生过什么。

二、active 的真实含义是什么

对很多配置型主数据来说，active=False 更接近：

• 从当前可选清单里淡出；
• 不建议继续给新业务使用；
• 但历史引用仍保留。

crm.lost.reason 也是这套哲学。

所以如果你把“价格太高”这个原因停用，历史输给价格的商机仍然会算在这个原因下面。系统是在保护时间线，不是在跟你唱反调。

三、为什么统计时要显式关闭 active_test

源码不是偷懒，它是刻意这么写的。

因为如果不关 active_test：

• 已停用的 lost reason 可能不会被正确计入；
• 管理者点开原因卡片时，会觉得数量和实际历史不符；
• 你永远无法平滑重构原因字典。

所以 _compute_leads_count() 和 action_lost_leads() 都把历史可见性保住了。

四、实施里应该怎样改丢单原因字典

正确方式通常是：

1. 新增更清晰的原因；
2. 旧原因停用，但不删除；
3. 如确有必要，再做一次明确的数据迁移，把旧数据映射到新原因；
4. 在报表解释里说明口径切换时间点。

最糟糕的做法是：

• 直接删除旧原因；
• 或期待“停用后历史自动消失”。

五、最容易误会的地方

1. 以为停用 = 历史不算

错，历史仍然算。

2. 以为原因卡片数量只统计当前启用项

错，源码专门把停用项也纳入历史统计。

3. 以为看到旧原因是系统没刷新

未必，很可能是设计如此。

六、排错顺序

如果你发现“这个原因都停用了，为什么还有数量”，先查：

1. 该原因是否只是 active=False 而非删除；
2. 历史商机是否仍挂着它；
3. 当前动作是否带 active_test=False；
4. 业务上是否其实需要做一次原因映射迁移。

一句话记忆

Odoo CRM 里的 lost reason 停用，只是停止未来继续选，不是抹掉过去为什么输。