Введение
В Odoo структура данных задаётся моделями — это шаблоны, по которым система сохраняет и организует всю деловую информацию: от заказов и счетов до карточек сотрудников.
Понимание моделей важно и для разработчиков, и для бизнес‑консультантов: именно через них задаются поля, связи и логика работы системы — фундамент всей архитектуры данных Odoo.
В этой статье мы подробно разбираем одну из базовых HR‑моделей — hr.employee. Если вы настраиваете процессы по приёму на работу, интегрируете расчёт зарплаты или настраиваете учёт рабочего времени, вам придётся работать с этой моделью.
Что такое модель hr.employee
Модель hr.employee — это цифровая карточка сотрудника в Odoo. В ней аккумулируются основные персональные и служебные данные, которые используют другие HR‑компоненты.
Она входит в модуль «Кадры» и служит связующим звеном для учёта посещаемости, отпусков, контрактов, выплат и учёта рабочего времени.
Модель появляется в системе с установкой приложения «Сотрудники». Другие модули расширяют её через наследование: hr_contract добавляет поля для контрактов, hr_attendance — логи прихода/ухода, hr_leave — учёт отпусков. Так каждая часть добавляет своё, не копируя базовую структуру.
Для случаев, когда нужен ограниченный доступ к данным сотрудников, Odoo предлагает hr.employee.public — «облегчённую» версию модели. Это пример, как через паттерны наследования и абстракции реализуется разграничение видимости.
Ключевые поля модели
Ниже — список наиболее значимых полей в hr.employee. Знание их назначения облегчит настройку, отчётность и интеграции.
1. name
Тип: Char. Имя сотрудника — основное отображаемое поле карточки. Чаще всего используется как идентификатор записи в интерфейсе и отчётах.
2. create_date
Тип: Datetime. Дата и время создания записи. Заполняется автоматически и пригодится для аудита и аналитики по потокам найма.
3. write_date
Тип: Datetime. Дата последнего изменения записи. Автоматически обновляется — полезно для отслеживания актуальности данных.
4. active
Тип: Boolean. Флаг «активности» — позволяет архивировать запись без физического удаления. Удобно для бывших сотрудников: скрыть, но не потерять историю.
5. company_id
Тип: Many2one (res.company). В многокомпанийной конфигурации указывает, в какой компании числится сотрудник. Часто обязательно для корректной работы финансовых и HR‑процессов.
6. user_id
Тип: Many2one (res.users). Ссылка на учётную запись Odoo — если сотрудник должен иметь доступ в систему. Влияет на вход в портал, согласования и учёт времени.
7. work_email
Тип: Char. Служебный e‑mail — используется для внутренних уведомлений, рассылок и упоминаний в системе.
8. work_phone
Тип: Char. Рабочий телефон — отображается в карточке и применяется в контактных процессах.
9. mobile_phone
Тип: Char. Мобильный номер для срочных уведомлений и SMS‑уведомлений.
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
Тип: Char. PIN для киоска прихода/ухода и некоторых операций в POS (смена кассира).
23. birthday
Тип: Date. Дата рождения — служебная информация для кадровых записей и, при необходимости, напоминаний.
24. identification_id
Тип: Char. Номер национального удостоверения — важен для соблюдения требований копаний и расчёта налогов.
25. passport_id
Тип: Char. Номер паспорта — нужен для командировок и миграционного учёта.
26. bank_account_id
Тип: Many2one (res.partner.bank). Банковский счёт для выплаты зарплаты.
27. private_email
Тип: Char. Личный e‑mail — используется при отсутствии рабочего почтового ящика.
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 заводит карточку сотрудника: имя, отдел, должность, руководитель, контакты. Поле user_id заполняют только если человек будет работать в системе — это шаг, который даёт доступ к Odoo и разрешениям.
2. Учёт прихода/ухода и трекинг времени
Записи о приходе и уходе создаются в hr.attendance и связываются с hr.employee. Для киоскового режима используются barcode и pin — это упрощает массовый учёт входов/выходов.
3. Отпуска и учёт времени вне работы
Заявки на отпуск ссылаются на карточку сотрудника; поля leave_manager_id и resource_calendar_id определяют, кто утверждает и как считается доступный отпускной лимит.
4. Зарплата и контракты
Расчёт зарплаты опирается на данные сотрудника: структура зарплаты, банковский счёт и активный контракт (contract_id). В contract_ids хранится полная история договоров.
5. Табели и распределение по проектам
При учёте часов по проектам табели привязаны к карточке сотрудника; утверждение контролируется 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
Studio позволяет быстро добавить поля и простую логику без кода — удобно для прототипов. Для сложных процессов и долговременной поддержки лучше писать полноценный модуль.
Рекомендации по использованию
- Не создавайте user_id по умолчанию — назначайте учётную запись только тем сотрудникам, кому действительно нужен доступ в систему.
- Стройте иерархию через parent_id сверху вниз — так проще поддерживать маршруты согласования и оргструктуру.
- Назначайте resource_calendar_id всем штатным сотрудникам, чтобы расчёт отпусков и учёт рабочего времени был консистентным.
- При интеграции через API используйте XML‑RPC или JSON‑RPC: модель hr.employee полностью доступна через API. Внимательно сопоставляйте внешние идентификаторы.
- Для своих полей применяйте префиксы x_ или префикс модуля, чтобы избежать конфликтов с будущими версиями Odoo.
- Поля с доступом только для hr.group_hr_user не должны предзагружаться пользователям без HR‑прав — задавайте группы на уровне определения поля.
Типичные ошибки
- Создание дубликатов при импорте вместо поиска существующих карточек. Для дедупликации используйте work_email или identification_id.
- Путаница между user_id и related_partner_id: user_id — это учётная запись для входа в Odoo, related_partner_id — контакт/партнёр для CRM и документов.
- Забывать задавать employee_type — поле обязательное и влияет на поведение контрактов и учёт налогов.
- Переопределять критические методы без вызова super() — это ломает совместимость с другими модулями и будущими обновлениями.
- Добавлять обязательные кастомные поля без значений по умолчанию — приведёт к ошибкам в существующих записях при обновлении базы.
- Открывать доступ к чувствительным кадровым данным всем пользователям. Четко ограничивайте видимость полей через группы доступа.
Заключение
Модель hr.employee — это сердце HR‑функций в Odoo: она хранит карточки сотрудников и связывает их с контрактами, посещаемостью и отпусками. Понимание полей и способов расширения поможет корректно настроить и интегрировать систему.
Независимо от роли — консультант или разработчик — глубокое знакомство с hr.employee экономит время и снижает риск ошибок при настройке бизнес‑процессов.
Нужна помощь с внедрением Odoo?
Dasolo помогает компаниям внедрять и дорабатывать Odoo: настройка API‑интеграций, разработка модулей и оптимизация архитектуры данных, включая работу с моделями типа hr.employee.
Если нужна помощь с внедрением Odoo, созданием кастомных HR‑модулей или интеграциями — наша команда готова подключиться. Записаться на демонстрацию чтобы обсудить ваш проект.