人才库为什么不是“把候选人打个标签”就完事：Odoo Talent Pool 的去重、复制与复用边界
很多团队以为人才库就是在候选人身上挂个 pool 标签。Odoo 源码其实做得更细：有直接入池、复制成 talent、通过邮箱/电话/LinkedIn 间接识别同人，以及专门避免重复加池的搜索逻辑。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 请假为什么不只是“申请几天假”：Allocation、Accrual 和剩余额度到底怎么算
很多人把 Odoo 请假理解成填一张申请单，但 Time Off 真正难的是额度来源、累计规则和审批边界。本文把 allocation 和 accrual 讲清楚。
Odoo 企业版请假为什么不会直接“少发几天工资”：休假、work entry 与薪资输入链路讲透
基于 hr_payroll_holidays、hr_work_entry_holidays_enterprise 与 hr_payroll 源码，讲清休假如何切分 work entry，并最终影响 payslip 的 worked days 与输入。
Odoo 企业版出勤生成工时为什么不是“打卡一保存就结束”：attendance、overtime intervals 与 validated work entry 防线讲透
基于 hr_work_entry_attendance 源码，讲清打卡如何触发 work entry、加班区间如何映射，以及为什么 validated entry 会锁住修改和删除。
Odoo 候选人转投多个岗位为什么不是改一改 job_id：复制申请、初始阶段重算与 talent pool 解绑讲透
很多团队看到“把候选人加到别的岗位”时，第一反应是直接改 job_id。Odoo 的 job_add_applicants 向导并不这么做：它会复制 applicant 数据，为每个目标岗位新建一条申请，按岗位可用阶段重新选最早的非 fold stage，并显式清空 talent pool 关联，避免把人才池语义和真实岗位申请混成一条记录。
Odoo 批量请假为什么不会粗暴覆盖原记录：冲突拒绝、拆分旧假与时区换算讲透
很多团队以为批量生成 time off 就是选一批员工、选一个区间、点创建。Odoo 的 hr.leave.generate.multi.wizard 源码明显更谨慎：它会先按公司日历时区把日期转成 UTC 区间，检查并拒绝无法自动拆分的小时假，对整天冲突假单做拒绝或拆分，再带着一组特殊 context 批量创建新假单并验证。
Odoo 企业版面试预约为什么不是“给候选人一个日历链接”：booking、阶段路由与面试官可用性讲透
基于 appointment_hr_recruitment 与 appointment 源码，讲清候选人专属 invite code、面试预约 booking、阶段流转与面试官可用性是如何绑在一起的。