人才库为什么不是“把候选人打个标签”就完事：Odoo Talent Pool 的去重、复制与复用边界
很多团队以为人才库就是在候选人身上挂个 pool 标签。Odoo 源码其实做得更细：有直接入池、复制成 talent、通过邮箱/电话/LinkedIn 间接识别同人，以及专门避免重复加池的搜索逻辑。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 员工档案为什么要分“私人信息”和“工作联系人”：看懂 private 字段、work contact 与同步边界
很多团队把员工档案当成一个大表，电话、邮箱、银行、住址都往里堆。Odoo 源码其实刻意拆开了私人信息、工作联系信息和 partner 对象，还限制谁能看、谁能同步、什么时候自动建联系人。它要解决的不是“字段多不多”，而是“哪些数据应该进 HR，哪些应该进协作和会计链路”。
Odoo 企业版工资单为什么不是“算完直接发 PDF”：Payroll、Documents 与签收留痕链路讲透
基于 documents_hr_payroll、documents_hr 与 hr_payroll 源码，讲清工资单 PDF 如何入档、路由到员工文件夹并保留长期访问上下文。
Odoo 企业版工时为什么不是“填完 timesheet 就进工资”：Timesheet、请假与工资小时类型桥接讲透
基于 timesheet_grid_holidays、project_timesheet_holidays、hr_work_entry_enterprise 与 hr_contract_salary_payroll 源码，讲清项目工时、休假工时与工资小时类型如何桥接。
Odoo 招聘问卷为什么不是发封邮件那么简单：partner 补建、answer 复用与 applicant 消息留痕讲透
很多团队把招聘问卷理解成“给候选人发一个 survey 链接”。Odoo 的 hr_recruitment_survey 源码处理得更细：发送前要先补齐 partner、已有答卷可能复用或重发、问卷动作和邮件正文还要回写到 applicant chatter，打印时也优先挑最近已完成的那份答卷。
Odoo 企业版请假累计为什么不是“按月加几天”：carryover cap、等级切换与分段累计讲透
结合 hr_holidays 累计源码与企业版人事场景，讲清 accrual level 的 carryover、上限、transition mode 与分段累计为什么会让余额看起来不像“连续直线”。
Odoo 企业版 Offer 与合同签署为什么不是“发个 PDF 给候选人”：request template、合同版本与入职绑定链路讲透
基于 hr_contract_salary 与 sign 相关源码，讲清 offer 生成、合同模板选择、签署请求与候选人转员工之间真正的绑定关系。