为什么 Odoo 不会在候选人一进流程就创建员工：Applicant 到 Employee 的真正边界

先说结论

在 Odoo 里，候选人（Applicant）不是“还没激活的员工”。

它们是两种不同对象：

• hr.applicant：招聘流程中的候选记录
• hr.employee：正式的人力主数据

源码里真正把候选人变成员工的关键动作，不是“进入某个阶段”，而是显式执行 create_employee_from_applicant()。

这说明 Odoo 的设计态度很明确：招聘流程可以很长，但员工主数据必须晚一点、慎一点创建。

为什么 Applicant 不能太早变成 Employee

如果系统一有简历就立刻创建员工，会马上带来三类问题。

1. 招聘记录会被“主数据化”得太早

一个人可能只是：

• 投了简历
• 参加了初筛
• 进入人才库
• 暂时不合适但未来可能再联系

这些状态都还是“招聘对象”，不是“在职员工”。

源码里 hr.applicant 保留了大量招聘语义字段，比如：

• stage_id
• job_id
• refuse_reason_id
• application_status
• interviewer_ids
• talent_pool_ids

这套结构说明 Applicant 的核心任务是推进、比较、筛选、回收，而不是承载劳动关系。

2. 员工对象会触发更多权限与组织逻辑

hr.employee 不是一个轻量联系人。它连着：

• 组织架构
• 工作联系人与工作邮箱
• 工作日历
• 合同版本
• 私人信息字段
• 账号联动

一旦过早创建员工，很多本不该太早落地的信息都会被迫进入主数据层。

3. 一个人可以有多个申请，但通常不该有多个“预备员工”

候选人可能对多个岗位投递，甚至被放入人才池继续孵化。Applicant 可以多条，但 Employee 通常应该更克制。

所以 Odoo 把“能投很多次简历”和“成为一位员工”分开，是很合理的。

源码到底在创建员工时做了什么

create_employee_from_applicant() 这段逻辑非常值得看，因为它直接暴露了 Odoo 的边界设计。

大意是：

1. 先检查执行者权限（面试官不一定有权创建员工）
2. 若候选人还没有 partner_id，先补一个联系人
3. 调用 _get_employee_create_vals() 生成员工初始值
4. 创建 hr.employee
5. 复制候选人附件到员工档案
6. 再补写岗位、部门、工作邮箱、工作电话等字段

这说明一个关键事实：

Applicant 并不会天然等于 Employee，系统是在“确认需要入职档案”时，做一次受控的数据搬运。

哪些字段会从 Applicant 进入 Employee

源码里的 _get_employee_create_vals() 会带过去的，主要是“入职档案的起始材料”，比如：

• 姓名
• 工作联系人 work_contact_id
• 岗位与岗位名称
• 部门
• 私人地址
• 私人电话、私人邮箱
• 语言
• 公司地址
• 工作邮箱、工作电话
• applicant_ids 反向关联

这很有意思：

• 招聘阶段字段没有整体复制过去
• 与人员档案直接相关的字段才会进入员工对象

换句话说，Odoo 不是在“升级一条记录”，而是在“基于招聘结果，生成一份员工主档”。

为什么附件也要复制，而不是继续共用

源码会把 Applicant 上的附件复制到 Employee。

原因很实际：

• 简历、证件、证明材料，后续仍可能属于员工档案的一部分
• 员工档案需要独立存在，不应该永远依赖招聘单
• 即便以后招聘记录归档，员工资料仍应保留自己的附件上下文

这体现的不是技术洁癖，而是对象生命周期分离。

为什么创建员工不是靠阶段自动触发

很多实施项目喜欢问：

能不能把“Offer Accepted”或“Hired”阶段设成自动创建员工？

技术上可以做定制，但源码默认没有这么干，背后有三层考虑：

1. 阶段是流程语义，不一定等于主数据落地时机

招聘阶段更多是业务沟通状态，不一定代表：

• 证件齐了
• 入职日期确定了
• 部门与工作邮箱准备好了
• 用户账号该创建了

2. 创建员工通常需要更高权限

源码里有 _check_interviewer_access()，说明不是所有能推进候选人的人，都能把人正式落进员工库。

3. 招聘通过不等于已入职

现实里常见这些情况：

• 候选人接受 offer 后又爽约
• Offer 通过，但入职日期延后
• 同时推进多个 legal entity 或部门安排

所以“通过某阶段”与“创建 Employee”之间，最好保留一个人工确认点。

实施时最容易犯的误区

误区一：把 Applicant 当成轻量员工表

这样会导致招聘、入职、合同、权限全混在一起。

误区二：一过终面就自动建员工

短期省事，长期会让员工库充满“未真正入职”的记录。

误区三：员工主数据还没准备好，就急着建 user

更稳妥的顺序通常是：

1. 候选人推进到明确录用
2. 人工确认要建员工档案
3. 建 Employee
4. 再处理账号、合同、排班、设备、薪酬等后续对象

一句话记忆

Applicant 是招聘流程对象，Employee 是人力主数据对象；Odoo 默认在“确认入职建档”这一刻，才跨过这条边界。