简介
在 Odoo 中，模型决定了数据如何在数据库中组织与存储。每一条业务信息——从订单、发票到员工档案——都是以模型记录的形式存在系统里。
无论是开发人员还是业务顾问，理解模型是使用 Odoo 的基石。模型定义了字段、实体之间的关系以及与之关联的业务逻辑，是构建系统行为的核心。
本文聚焦 HR 模块下的核心模型之一：hr.employee。如果你要设计员工入职流程、对接工资系统或配置考勤与请假，都会频繁接触到这个模型。
什么是 hr.employee 模型
hr.employee 负责在系统中表示一名员工，是存放人员信息的中心记录。
此模型属于人力资源（HR）应用的范畴，被考勤、请假、合同、工资单与工时等模块广泛引用。
当启用员工（Employees）应用后会自动安装该模型。其他模块通常通过 Odoo 的模型继承机制扩展它：例如 hr_contract 为它添加合同相关字段，hr_attendance 增加打卡记录，hr_leave 管理请假信息。各个模块只补充所需内容，而不会重复核心结构。
Odoo 还提供了 hr.employee.public 这样的受限视图，用来在权限较低的场景下显示员工信息。这体现了 Odoo 通过抽象模型与继承来控制数据可见性的设计思路。
模型中的关键字段
下面列出 hr.employee 中常用且重要的字段，熟悉这些字段有助于你更有效地操作与定制员工记录。
1. 员工姓名（name）
类型：Char。用于保存员工的姓名，是大多数视图中显示的主要标识。
2. 创建时间（create_date）
类型：Datetime。记录何时创建该条记录，由 Odoo 自动维护，常用于审计和报表。
3. 最后修改时间（write_date）
类型：Datetime。记录最后一次更新的时间，同样由系统管理，便于追踪数据变更。
4. 有效标记（active）
类型：Boolean。软删除/归档开关。置为 False 时记录在默认视图中隐藏，但不会被物理删除，适用于离职人员的处理。
5. 所属公司（company_id）
类型：Many2one（res.company）。在多公司环境中指明员工所属公司，许多记录需要该字段以便多公司隔离。
6. 关联用户（user_id）
类型：Many2one（res.users）。将员工与 Odoo 用户绑定，设置后该员工可登录系统，影响门户权限、工时填报与审批流程。
7. 工作邮箱（work_email）
类型：Char。用于内部沟通与系统通知的企业邮箱地址。
8. 办公电话（work_phone）
类型：Char。办公联系方式，显示在员工表单并参与业务流程的联络环节。
9. 手机（mobile_phone）
类型：Char。员工移动电话，常用于短信提醒或紧急通知。
10. 部门（department_id）
类型：Many2one（hr.department）。员工所属部门，用于组织结构、报表与审批流路由。
11. 岗位（job_id）
类型：Many2one（hr.job）。关联岗位记录，管理职位定义与招聘需求。
12. 职称（job_title）
类型：Char。自由文本的职位名称，可在未使用 job_id 或需自定义职称时填写。
13. 上级（parent_id）
类型：Many2one（hr.employee）。表示汇报关系，构建组织层级，用于审批链与组织图。
14. 培训/辅导人（coach_id）
类型：Many2one（hr.employee）。记录负责员工发展或绩效辅导的人选，默认不赋予特殊权限。
15. 资源链接（resource_id）
类型：Many2one（resource.resource）。用于排班、容量规划和日历集成，连接人力资源规划模块。
16. 工作联系人（work_contact_id）
类型：Many2one（res.partner）。指向对外或对内的工作联系人，用于文档与通信。
17. 工作地址（address_id）
类型：Many2one（res.partner）。办公地点地址，关联到伙伴记录以便发票与通知使用。
18. 家庭住址（address_home_id）
类型：Many2one（res.partner）。私人地址信息，常用于工资单和紧急联系人处理。
19. 日历（resource_calendar_id）
类型：Many2one（resource.calendar）。定义员工的工作时间与排班规则，影响考勤与请假天数计算。
20. 员工类型（employee_type）
类型：Selection。员工分类（例如正式员工、自由职业者、实习生等），该字段影响合同与薪酬逻辑。
21. 工牌条码（barcode）
类型：Char。用于考勤闸机或扫码识别的员工条码。
22. PIN 码（pin）
类型：Char。在考勤自助机（Kiosk）模式或收银切换时用于验证的数字密码。
23. 出生日期（birthday）
类型：Date。员工生日信息，可用于 HR 记录或提醒功能。
24. 身份证号（identification_id）
类型：Char。国家/地区身份证明编号，涉及合规与工资发放所需。
25. 护照号码（passport_id）
类型：Char。用于出差、签证和工作许可的护照信息跟踪。
26. 银行账户（bank_account_id）
类型：Many2one（res.partner.bank）。员工工资发放的收款账户。
27. 私人邮箱（private_email）
类型：Char。个人邮箱地址，当工作邮箱不可用时备用使用。
28. 私人电话（phone）
类型：Char。与工作联系方式区分的私人联系电话。
29. 当前合同（contract_id）
类型：Many2one（hr.contract）。指向正在生效的合同记录，关联薪酬结构与条款。
30. 合同历史（contract_ids）
类型：One2many（hr.contract）。与该员工关联的所有合同，一览历史与变更记录。
31. 头像（image_1920）
类型：Binary。员工照片或头像，系统会存储不同尺寸，用于表单、报表与员工名录展示。
32. 关联伙伴（related_partner_id）
类型：Many2one（res.partner）。将员工与 CRM/业务往来使用的伙伴记录关联，便于统一联系人管理。
33. 请假审批人（leave_manager_id）
类型：Many2one（res.users）。负责审批员工请假的用户，未设置时由管理员或指定审批人处理。
34. 报销审批人（expense_manager_id）
类型：Many2one（res.users）。负责审批费用报销的用户权限字段。
35. 工时审批人（timesheet_manager_id）
类型：Many2one（res.users）。负责工时记录审批的负责人字段。
该模型在日常业务流程中的用途
1. 员工名录与入职流程
创建员工时，HR 在 hr.employee 表中录入姓名、部门、岗位、上级与联系方式。只有在员工需要登录系统时，才会为其设置 user_id。
2. 考勤与工时记录
员工通过考勤应用打卡，打卡记录保存在 hr.attendance 并关联到 hr.employee。条码与 PIN 配合可启用自助机打卡模式。
3. 请假与休假管理
请假申请会引用员工记录，leave_manager_id 决定审批人，resource_calendar_id 决定可用的休假天数与计算规则。
4. 薪资与合同管理
工资单系统使用 hr.employee 的薪资结构、银行账户与合同信息。contract_id 指向当前合同，contract_ids 保存历次合同记录，便于审计与计算补偿。
5. 工时表与项目分配
员工将时间记录到项目中的工时表，记录会关联 hr.employee。timesheet_manager_id 控制审批流程，resource_id 与排班工具配合用于资源规划。
开发者如何扩展该模型
开发者通过多种方式扩展 hr.employee，其中最常见的是利用 Odoo 的模型继承机制。
模型继承概念
在自定义模块中使用 _inherit = 'hr.employee' 来扩展模型。你可以新增字段、重写方法或添加校验。通过继承把修改放到独立模块里，便于后续升级与维护。
添加字段
在继承模型中定义新字段时，选择合适的字段类型（Char、Many2one、Boolean、Integer、Text、Selection 等）。如果系统为多公司环境，考虑将字段设置为公司依赖（company-dependent）。
Python 层扩展
可以重写 create、write、unlink 等方法来加入业务逻辑，但务必使用 super() 调用父类实现。对计算字段要注意依赖关系与刷新时机，避免性能问题。
Odoo Studio 的使用
Odoo Studio 能在无需编码的情况下快速新增字段与视图调整，适合临时或轻量级定制；但对复杂逻辑或需要长期维护的功能，建议通过自定义模块实现。
最佳实践建议
- 只有当员工需要登录或接收系统通知时才分配 user_id，并非所有员工都需要对应的系统用户。
- 合理使用 parent_id 构建自上而下的组织架构，确保审批与汇报链路清晰。
- 为员工设置 resource_calendar_id 可以保证工时与请假计算的一致性，避免排班与休假冲突。
- 与外部系统做 API 集成时，推荐使用 XML-RPC 或 JSON-RPC 接口。hr.employee 在 Odoo 中可以通过标准 API 访问，外部系统需谨慎映射 ID 与外部唯一标识。
- 为自定义字段使用 x_ 前缀或模块前缀，能有效降低与未来 Odoo 版本字段名冲突的风险。
- 将包含敏感信息的字段加上 hr.group_hr_user 或其他权限组限制，避免在无权限用户会话中被预取或暴露。
常见错误与陷阱
- 重复创建员工记录是常见问题。集成或批量导入时，应先根据 work_email、identification_id 等唯一属性去重。
- 不要混淆 user_id 与 related_partner_id：前者对应可登录的 Odoo 用户账户，后者是用于通信与业务往来的联系人记录。
- 别忘了设置 employee_type，该字段是必填并会影响合同与薪资相关的处理逻辑。
- 在重写核心方法时若不调用 super()，容易造成其他模块功能中断或日后升级出现兼容问题。
- 为必填的自定义字段没有提供默认值将导致老数据在模块升级或安装时校验失败，需谨慎设计迁移策略。
- 避免将敏感的 HR 字段开放给没有 hr.group_hr_user 权限的用户，严格按角色与权限控制可见性。
总结
hr.employee 是 Odoo 人力资源体系的核心，承担员工信息存储并与合同、考勤、请假等模块紧密关联。熟悉其字段与扩展方式，有助于更稳定地配置、定制与集成 Odoo 系统。
无论你是负责业务流程梳理的功能顾问，还是编写自定义模块的开发者，掌握 hr.employee 的设计与使用细节都能节省大量时间并降低错误风险。
需要我们协助您的 Odoo 实施吗？
Dasolo 帮助企业实施、定制与优化 Odoo，我们在 API 对接与 Odoo 开发方面有丰富实践经验，对 hr.employee 等核心模型非常熟悉。
如果您需要 Odoo 实施支持、定制 HR 模块或系统集成服务，我们可以提供专业帮助。 预约演示 以便讨论您的项目需求。