Odoo 企业版招聘分析为什么不是“漏斗看板”而已：SQL 视图、meeting 计数与 recruiter leaderboard 口径讲透

招聘分析很容易被做成一堆花哨图表：阶段人数、转化率、招聘官排行，看上去都很像 BI。但 /home/ubuntu/odoo-temp/enterprise/hr_recruitment_reports 的思路更克制：先把招聘事实收敛成稳定的 SQL 视图，再谈图表和排行。

参考入口：

• enterprise/hr_recruitment_reports/report/hr_recruitment_report.py
• enterprise/hr_recruitment_reports/report/hr_recruitment_stage_report.py

一、为什么官方单独建 _auto = False 的分析模型

hr.recruitment.report 不是普通 ORM 表，而是 _auto = False 的 SQL view。原因很现实：招聘分析要同时汇总 applicant、meeting、medium、source、refuse reason、process duration 等字段，纯靠界面临时聚合会又慢又不稳定。

因此官方先在 _query() 里定义统一口径，再通过 init() 重建视图。这样图表、透视、列表用的都是同一套分析事实。

二、状态口径不是直接读 stage，而是读 applicant 的业务状态

视图里 state 的 CASE WHEN 很关键：

• active IS FALSE → refused
• date_closed IS NOT NULL → hired
• 否则 → in_progress

这说明招聘分析里的“状态”不是简单把当前 stage 名字拿来做枚举，而是根据 applicant 的生命周期字段重算业务状态。也正因为如此，招聘阶段变化和最终 hiring/refusal 统计可以并存而不冲突。

三、meeting 数量被视作过程强度，不只是活动明细

calendar_event 左连接进来后，count(m.id) 变成 meetings_amount。这让招聘分析不仅能看结果，还能看过程投入：同一个招聘官到底推进了多少面试、哪些岗位流程更重、流程时长是否和面试次数同步增长。

很多人只看 hired ratio，会忽略“转化高但面试轮次极多”的低效问题。官方把 meeting 计数放进分析模型，就是为了避免只看结果不看代价。

四、leaderboard 为什么不用现成 group by，而要单独跑 SQL

get_leaderboard() 直接执行 SQL，再用 nlargest() 取前 3 名，分别输出：

• Total applicants
• Total Meetings
• Total Hired
• Hiring ratio

这样做的好处是榜单口径很明确，而且可以在同一函数里按 allowed_company_ids 控制多公司边界。它不是随手从图表里截个排序，而是单独为管理看板准备的聚合结果。

五、最容易误解的点

• count 不代表数据库行数，而是按 applicant 生命周期口径定义的有效申请数。
• hiring_ratio 在这里是 applicant 级别的 100 / 0 聚合平均值，不是阶段转化矩阵。
• process_duration 是 date_closed - create_date 的天数，反映流程闭环速度，不等于 offer 接受时长。

六、实战建议

• 如果你想扩展招聘分析，优先在 SQL view 层新增稳定字段，再谈前台图表。
• 招聘负责人评估团队时，不要只看 hired 数，还要结合 meetings_amount 和 process_duration。
• 多公司场景一定要检查 allowed_company_ids，否则 leaderboard 很容易串公司数据。

七、结论

hr_recruitment_reports 的核心不是做一套漂亮图，而是先把招聘事实标准化。SQL 视图、业务状态重算、meeting 聚合和排行榜口径，决定了你看到的是“可管理的招聘分析”，还是“会误导的图表拼盘”。