Odoo 企业版招聘 offer 为什么不是“发封邮件就完了”：offer、签署与薪资包配置路由讲透

很多团队把招聘 offer 看成招聘阶段的最后一封邮件，但在 Odoo 企业版里，offer 真正有价值的地方在于它不是孤立文档，而是把 hr_recruitment_sign、sign、hr_contract_salary 与 hr_contract_salary_payroll 串成一条状态链。只要这条链设计得对，候选人的身份、签署角色、附件副本和薪资模拟上下文都会沿着同一条路线流动。

## 1. 招聘对象先被翻译成签署参与者，而不是直接生成合同

在 enterprise/hr_recruitment_sign/models/hr_applicant.py 里，申请人通过 partner_id 与 sign.request.item 关联，open_applicant_sign_requests() 会把招聘对象直接映射到签署请求集合。也就是说，招聘模块并不自己维护一套“待签文件”列表，而是复用 Sign 的请求对象，让候选人状态与签署对象保持一致。这样做的好处，是后续催签、拒签、查看已签文档都不需要再在 Recruitment 里重造状态机。

2. 模板选择与责任角色决定 offer 能否进入签署链

真正的桥在 enterprise/hr_recruitment_sign/wizard/hr_recruitment_sign_document_wizard.py。这里的 _get_sign_template_ids()、_compute_responsible_ids() 与 validate_signature() 会先校验模板里是否存在同一套 signer role，再根据“一人签”或“候选人 + 负责人双签”拼出 sign.request。attachment_ids 还会被复制到每个请求里，避免一份附件被多个签署请求直接共用而打乱后续追踪。换句话说，招聘阶段传过去的不只是文件名，而是角色、责任人与附件副本。

3. 薪资包配置器吃到的不是纯表单，而是签后合同版本语义

到了 enterprise/hr_contract_salary_payroll/models/hr_contract_salary_offer.py 和 controllers/main.py，薪资包配置不再只是前端报价，而是会把 work_entry_source、hourly_wage、wage_with_holidays 等字段折算成合同版本数据，并调用 _generate_salary_simulation_payslip() 做工资模拟。这里最重要的不是“能不能算出净薪”，而是招聘 offer 最终会落回合同版本对象，形成后续 payroll 能接住的结构化上下文。

4. 这条链路最容易出错的点，是把签署当成展示层而不是业务边界

如果模板角色不一致，wizard 会直接卡住；如果候选人没有 partner 或附件复用策略错误，后续 sign request 的可见性与附件访问会变乱；如果薪资包页面只改数字、不把版本字段回写到合同版本，Payroll 看到的还是脱离签署上下文的旧数据。企业版这里的关键设计，是让 Recruitment 只负责推进业务阶段，让 Sign 负责签署状态，让 Salary Configurator 负责把签后条件翻译成 payroll 可计算的合同版本。

## 结论

所以，Odoo 企业版里的招聘 offer 不是“发出去等回签”的单向动作，而是一条从 applicant → sign request → contract version → salary simulation 的跨模块业务链。真正的价值，不是文档看起来正式，而是签署结果能够继续驱动薪资包与合同计算。

主要源码锚点：

- `enterprise/hr_recruitment_sign/models/hr_applicant.py`

• enterprise/hr_recruitment_sign/wizard/hr_recruitment_sign_document_wizard.py
• enterprise/hr_contract_salary_payroll/models/hr_contract_salary_offer.py
• enterprise/hr_contract_salary_payroll/controllers/main.py