人才库为什么不是“把候选人打个标签”就完事：Odoo Talent Pool 的去重、复制与复用边界
很多团队以为人才库就是在候选人身上挂个 pool 标签。Odoo 源码其实做得更细：有直接入池、复制成 talent、通过邮箱/电话/LinkedIn 间接识别同人，以及专门避免重复加池的搜索逻辑。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 企业版 360 反馈为什么不是“多找几个人打分”而已：周期、匿名性与参与人扩展链路讲透
基于 hr_appraisal 源码，讲清 Odoo 企业版 360 反馈如何把 appraisal 周期、员工/经理视图、反馈可见性与参与人扩展串成一条真正可落地的评估链。
Odoo 企业版内推为什么不是“发条招聘链接”而已：专属 UTM Source、阶段积分回滚与奖励账本讲透
很多人把 Odoo 企业版 Employee Referral 理解成员工把职位链接转发给朋友，系统记一次来源、招到人后发点奖励。但看 hr_referral 官方源码会发现，它其实做了三层拆分：每个员工有独立 UTM source，每个职位有独立 campaign，候选人推进过程形成可加可减的积分流水，而等级成长与礼品消费又是两本不同账。
Odoo 考勤不只是打卡时长：开放考勤、自动签退、技术性缺勤到底在管什么
很多人以为 Odoo Attendance 只是在记录 check in 和 check out。源码显示，它还在防重叠、防忘签退、补技术性缺勤，并把这些结果送进加班逻辑。真正管理的是“出勤事实的可计算性”。
请假批准后，Odoo 为什么要“盖掉”原工时：看懂 Leave 与 Work Entry 的覆盖、冲突与重建
很多用户以为批准请假只是把状态改成已批准。实际上，Odoo 还会重算这一段时间里的 work entries：哪些保留，哪些归档，哪些变成请假工时，取消后又怎样恢复。
Odoo 企业版排班打卡为什么不能各算各的：Planning、Attendance 与 Payroll work entry 优先级讲透
基于 hr_work_entry_planning_attendance、planning_attendance 与 hr_payroll_attendance 源码，讲清排班、打卡和工资工时怎样在同一条 work entry 链上消解冲突。
Odoo 企业版薪资考勤为什么不是“工资单抓一下打卡”而已：工资期窗口、时区归属与 overtime worked days 边界讲透
基于 hr_payroll_attendance 源码与测试，讲清工资单如何匹配考勤区间、为什么按 check_in:day 聚合会影响跨时区归属，以及 overtime 如何进入 worked days 但不应被算成半天。