Introducción
En Odoo, los modelos son la forma en que se organiza y almacena la información en la base de datos. Cualquier dato empresarial —pedidos, facturas, empleados— tiene su propio modelo que define su estructura y comportamiento.
Tanto los desarrolladores como los consultores funcionales deben dominar los modelos de Odoo. Son la base de la arquitectura: determinan campos, relaciones y la lógica que gobierna los datos.
Aquí nos centramos en uno de los modelos centrales del módulo de Recursos Humanos: hr.employee. Si trabajas en flujos de alta de personal, nómina, control horario o ausencias, acabarás manipulando este modelo.
¿Qué es el modelo hr.employee?
El modelo hr.employee representa a cada trabajador dentro de Odoo. Es donde se centraliza la información de la plantilla: datos personales, contactos, puesto y enlaces con otros procesos.
Forma parte de la aplicación de Recursos Humanos y se reutiliza en funcionalidades como control de presencia, ausencias, contratos, nómina y partes de trabajo.
Se instala al activar la app Empleados y es habitual que otros módulos lo amplíen mediante la herencia de modelos. Por ejemplo, hr_contract añade los campos de contrato; hr_attendance gestiona los registros de entrada/salida; hr_leave añade la lógica de permisos. Así cada módulo aporta lo necesario sin duplicar la estructura básica.
Odoo también expone hr.employee.public, una vista con acceso limitado de los mismos datos para usuarios con visibilidad restringida. Es una técnica habitual para controlar permisos y presentar solo la información pertinente.
Campos clave del modelo
A continuación verás los campos más relevantes de hr.employee. Conocerlos te ayudará a gestionar registros de personal con mayor seguridad y eficacia.
1. name
Tipo: Char. Nombre del empleado. Es el campo que suele mostrarse como identificador principal en listas y formularios y sirve para localizar el registro.
2. create_date
Tipo: Datetime. Fecha y hora de creación del registro. Odoo la gestiona automáticamente; es útil para auditorías e informes.
3. write_date
Tipo: Datetime. Fecha y hora de la última modificación. También automática; permite saber cuándo se actualizaron los datos.
4. active
Tipo: Boolean. Indicador de archivo (soft delete). Si se marca como False, el empleado queda archivado y oculto en vistas por defecto sin eliminarse físicamente.
5. company_id
Tipo: Many2one (res.company). En entornos multiempresa identifica a qué compañía pertenece el empleado. Es obligatorio en muchos casos y condiciona reglas contables y de nómina.
6. user_id
Tipo: Many2one (res.users). Vincula el empleado con un usuario de Odoo. Si está definido, el empleado puede iniciar sesión y recibir permisos, notificaciones y accesos a portales.
7. work_email
Tipo: Char. Correo corporativo. Se emplea para comunicaciones internas y alertas automáticas.
8. work_phone
Tipo: Char. Teléfono de trabajo. Visible en fichas y útil para flujos de contacto internos.
9. mobile_phone
Tipo: Char. Móvil laboral. Frecuentemente usado para SMS o avisos urgentes.
10. department_id
Tipo: Many2one (hr.department). Departamento al que pertenece el empleado. Sirve para organigramas, informes y rutas de aprobación.
11. job_id
Tipo: Many2one (hr.job). Puesto formal dentro de la empresa. Enlaza con el catálogo de puestos y vacantes.
12. job_title
Tipo: Char. Título del puesto en texto libre. Se usa para denominaciones personalizadas cuando job_id no aplica.
13. parent_id
Tipo: Many2one (hr.employee). Jefe directo o responsable. Permite construir la jerarquía organizativa y definir cadenas de aprobación.
14. coach_id
Tipo: Many2one (hr.employee). Mentor o coach asignado. Se utiliza en procesos de desarrollo y evaluación; por defecto no concede permisos especiales.
15. resource_id
Tipo: Many2one (resource.resource). Relación con el recurso de planificación. Importante para asignaciones, calendarios y capacidad de programación.
16. work_contact_id
Tipo: Many2one (res.partner). Contacto de trabajo vinculado. Se usa para documentos y comunicaciones laborales.
17. address_id
Tipo: Many2one (res.partner). Dirección de la oficina o centro de trabajo. Enlaza con un partner para gestión de ubicaciones.
18. address_home_id
Tipo: Many2one (res.partner). Domicilio particular. Se emplea en nómina, emergencias y comunicaciones personales.
19. resource_calendar_id
Tipo: Many2one (resource.calendar). Calendario laboral. Define horarios y jornadas; afecta al cálculo de ausencias y presencia.
20. employee_type
Tipo: Selection. Clasificación: Empleado, Autónomo o Becario. Es un campo requerido y condiciona cómo se gestionan contratos y carga legal.
21. barcode
Tipo: Char. Identificador de tarjeta o código de barras. Utilizado en quioscos de asistencia y lectores físicos.
22. pin
Tipo: Char. PIN para registro en modo kiosco del módulo de Asistencia. También se usa en cambios de cajero en el TPV.
23. birthday
Tipo: Date. Fecha de nacimiento. Valor para registros HR y para posibles notificaciones o celebraciones.
24. identification_id
Tipo: Char. Número de identificación nacional. Necesario para cumplimiento legal y nómina.
25. passport_id
Tipo: Char. Número de pasaporte. Útil para gestiones de viaje y permisos de trabajo.
26. bank_account_id
Tipo: Many2one (res.partner.bank). Cuenta bancaria destinada al pago de nómina.
27. private_email
Tipo: Char. Correo personal del empleado. Alternativa cuando no hay correo corporativo.
28. phone
Tipo: Char. Teléfono particular. Diferenciado del teléfono de trabajo.
29. contract_id
Tipo: Many2one (hr.contract). Referencia al contrato activo del empleado.
30. contract_ids
Tipo: One2many (hr.contract). Historial de contratos vinculados al empleado.
31. image_1920
Tipo: Binary. Fotografía o avatar del empleado. Odoo genera tamaños distintos y se muestra en ficheros y listados.
32. related_partner_id
Tipo: Many2one (res.partner). Partner asociado al empleado. Facilita la integración con CRM y otros módulos que usan partners.
33. leave_manager_id
Tipo: Many2one (res.users). Usuario responsable de aprobar permisos. Si está vacío, la aprobación recae en un administrador o aprobador configurado.
34. expense_manager_id
Tipo: Many2one (res.users). Usuario que autoriza gastos. En ausencia de configuración, se delega a un administrador o aprobador.
35. timesheet_manager_id
Tipo: Many2one (res.users). Responsable de validar partes de horas. Si no se define, lo gestiona el administrador de partes.
Cómo se utiliza este modelo en los flujos de negocio
1. Directorio de empleados y alta
Al crear un empleado se completan los datos básicos en hr.employee: nombre, departamento, puesto, responsable y contactos. Sólo cuando el empleado necesita acceso a Odoo se vincula user_id y se le asignan permisos.
2. Presencia y control horario
Los registros de entrada y salida se guardan en hr.attendance y enlazan con hr.employee. Campos como barcode y pin permiten operar en modo kiosco para registrar asistencia de forma rápida.
3. Ausencias y permisos
Las solicitudes de baja se relacionan con el empleado. Campos como leave_manager_id y resource_calendar_id determinan quién aprueba y cómo se computan los días de permiso.
4. Nómina y contratos
La nómina toma datos de hr.employee para estructuras salariales, cuenta bancaria y contrato vigente (contract_id). contract_ids mantiene el historial contractual del trabajador.
5. Partes de trabajo y recursos
Al registrar horas en proyectos, los partes se asocian al empleado y al resource_id para planificación. El timesheet_manager_id controla las aprobaciones de esas horas.
Cómo amplían los desarrolladores este modelo
Los desarrolladores tienen varias formas de ampliar hr.employee; la herencia de modelos de Odoo es la herramienta principal.
Herencia de modelos
En tus módulos usa _inherit = 'hr.employee' para ampliar el modelo: añadir campos, modificar métodos o añadir restricciones. Mantener las extensiones en módulos separados facilita actualizaciones y mantenimiento.
Añadir campos
Declara nuevos campos en el modelo heredado usando los tipos adecuados: Char, Many2one, Boolean, Integer, Text, Selection, etc. En setups multiempresa valora si los campos deben ser dependientes de la compañía.
Extensiones en Python
Sobrescribe create, write o unlink para incorporar lógica propia, siempre llamando a super() cuando corresponda. Ten especial cuidado con campos computados y sus dependencias para evitar inconsistencias.
Odoo Studio
Odoo Studio permite añadir campos y modificar vistas sin programar: útil para prototipos o cambios rápidos. Para lógica compleja o soluciones a largo plazo, los módulos personalizados ofrecen mayor control y robustez.
Buenas prácticas
- Asigna user_id sólo si el empleado necesita acceder a Odoo; no todos los empleados requieren una cuenta de usuario.
- Construye la jerarquía con parent_id correctamente: diseña la estructura organizativa de arriba hacia abajo para que las aprobaciones y reportes funcionen bien.
- Define resource_calendar_id para estandarizar horarios y que los cálculos de ausencias y horas trabajadas sean coherentes.
- Para integraciones con terceros utiliza XML-RPC o JSON-RPC. hr.employee está disponible vía API; mapea con cuidado los identificadores externos para evitar duplicidades.
- Para campos personalizados usa prefijos (x_ o el prefijo de tu módulo) y nombres únicos que eviten colisiones con futuras versiones de Odoo.
- Campos con acceso restringido (por ejemplo a hr.group_hr_user) no deben prefetcharse para usuarios sin permisos. Protege los campos sensibles mediante grupos en la definición.
Errores comunes
- Crear registros duplicados en lugar de buscar existentes. Para evitarlo, utiliza work_email o identification_id como criterios de deduplicación al importar o sincronizar.
- Confundir user_id con related_partner_id. user_id sirve para iniciar sesión en Odoo; related_partner_id es el contacto (partner) asociado para CRM y facturación.
- Olvidar definir employee_type. Es obligatorio y condiciona cómo se gestionan los contratos y ciertos procesos legales.
- Sobrescribir métodos base sin llamar a super(). Esto puede romper la funcionalidad de otros módulos o complicar futuras migraciones.
- Añadir campos obligatorios sin proporcionar valores por defecto. Al actualizar o instalar el módulo, los registros existentes pueden fallar validaciones.
- Exponer datos sensibles a usuarios sin permisos HR. Usa los grupos de acceso para proteger información personal y de nómina.
Conclusión
hr.employee es una pieza clave del ecosistema HR de Odoo: centraliza datos del personal y conecta contratos, presencia y ausencias. Comprender sus campos y la forma en que otros módulos lo extienden facilita configurar, personalizar e integrar Odoo correctamente.
Tanto si eres consultor funcional modelando procesos de RR. HH. como desarrollador construyendo módulos, dominar hr.employee te ahorrará tiempo y evitará errores comunes.
¿Necesitas ayuda con tu implantación de Odoo?
Dasolo acompaña a las empresas en la implantación, personalización y optimización de Odoo. Nos especializamos en integraciones por API y desarrollo a medida, con experiencia profunda en la arquitectura de datos y modelos como hr.employee.
Si necesitas apoyo con la implantación de Odoo, módulos HR personalizados o integraciones, podemos ayudarte. Solicita una demo para hablar de tu proyecto.