Introdução
No Odoo, os modelos definem a forma como a informação é guardada na base de dados. Cada entidade de negócio — faturas, encomendas, contactos ou colaboradores — tem um modelo que organiza campos, relações e regras.
Compreender os modelos do Odoo é fundamental tanto para consultores funcionais como para programadores. Eles são a espinha dorsal dos dados: estabelecem campos, ligações entre registos e a lógica que valida e processa a informação.
Este artigo centra‑se num modelo essencial do módulo de RH: hr.employee. Se estiver a configurar processos de admissão, integrar o sistema de vencimentos ou gerir presenças, este modelo será um dos pontos-chave que vai manipular.
O que é o modelo hr.employee
O hr.employee representa os colaboradores dentro do Odoo — é o registo principal onde se concentram os dados pessoais, contratuais e organizacionais de cada pessoa.
Este modelo faz parte da aplicação Recursos Humanos e é consumido por várias funcionalidades: presenças, férias, contratos, folha de salário e folhas de tempo.
O modelo é carregado ao instalar a aplicação Empregados. Outros módulos estendem‑no através da herança de modelos: hr_contract acrescenta campos contratuais, hr_attendance trata registos de entrada/saída e hr_leave gere os pedidos de tempo livre. Cada módulo acrescenta a sua peça sem duplicar a estrutura central.
Existe também o hr.employee.public, uma visão com permissões reduzidas pensada para expor apenas informação pública dos colaboradores. É um exemplo de como o Odoo usa modelos abstratos e herança para gerir acessos e visibilidade.
Campos principais do modelo
A seguir descrevemos os campos mais relevantes do hr.employee — conhecê‑los ajuda a trabalhar corretamente com registos de pessoal.
1. name
Tipo: Char. Nome do colaborador. É o campo de exibição básico e aparece em muitas vistas; serve como identificador principal do registo.
2. create_date
Tipo: Datetime. Data e hora de criação do registo. É preenchido automaticamente pelo Odoo e útil para auditoria e relatórios.
3. write_date
Tipo: Datetime. Data e hora da última alteração. Também gerido automaticamente e importante para rastrear atualizações.
4. active
Tipo: Boolean. Indicador de arquivamento. Quando False, o registo fica inativo e desaparece das vistas por omissão — ideal para marcar colaboradores que saíram sem os apagar.
5. company_id
Tipo: Many2one (res.company). Indica a empresa a que o colaborador pertence em ambientes multi‑empresa — é exigido em grande parte dos registos funcionais.
6. user_id
Tipo: Many2one (res.users). Associação a um utilizador do Odoo. Quando definido, permite acesso ao sistema, portal, e funcionalidades como aprovações e folhas de horas.
7. work_email
Tipo: Char. Email profissional. Usado para notificações internas e comunicações do sistema.
8. work_phone
Tipo: Char. Telefone de trabalho. Aparece nas fichas e fluxos de contacto.
9. mobile_phone
Tipo: Char. Telemóvel profissional. Frequentemente usado para alertas urgentes ou mensagens SMS.
10. department_id
Tipo: Many2one (hr.department). Departamento do colaborador. Serve para organogramas, relatórios e regras de aprovação.
11. job_id
Tipo: Many2one (hr.job). Posição na empresa. Ligação ao registo de cargos que define título e vagas.
12. job_title
Tipo: Char. Título livre do cargo. Útil quando não se usa um job_id ou para títulos personalizados.
13. parent_id
Tipo: Many2one (hr.employee). Gestor direto. Permite construir hierarquias para cadeias de aprovação e organogramas.
14. coach_id
Tipo: Many2one (hr.employee). Mentor ou coach do colaborador. Usado em processos de avaliação e desenvolvimento; não confere automaticamente privilégios.
15. resource_id
Tipo: Many2one (resource.resource). Ligação ao recurso do calendário. Essencial para planeamento, alocação e integração com agendas.
16. work_contact_id
Tipo: Many2one (res.partner). Contacto profissional associado. Utilizado em documentos e comunicações de trabalho.
17. address_id
Tipo: Many2one (res.partner). Morada de trabalho. Aponta para o partner correspondente ao local de trabalho.
18. address_home_id
Tipo: Many2one (res.partner). Morada pessoal. Utilizada para cálculos de vencimentos, contactos de emergência e comunicações privadas.
19. resource_calendar_id
Tipo: Many2one (resource.calendar). Horário de trabalho. Define dias e horas laborais e é usada em presenças, férias e planeamento.
20. employee_type
Tipo: Selection. Tipo de colaborador: Empregado, Freelancer ou Estagiário. Campo obrigatório que influencia o histórico contratual e certas regras de processamento.
21. barcode
Tipo: Char. Identificador de crachá. Utilizado em quiosques de presença e leituras por código de barras.
22. pin
Tipo: Char. PIN para check‑in/out no modo Quiosque do módulo de Presenças. Também usado para operações como trocar o operador no PDV.
23. birthday
Tipo: Date. Data de nascimento. Mantém registos pessoais e permite lembretes opcionais.
24. identification_id
Tipo: Char. Número de identificação nacional. Relevante para conformidade de RH e vencimentos.
25. passport_id
Tipo: Char. Número de passaporte. Útil para viagens e gestão de autorizações de trabalho.
26. bank_account_id
Tipo: Many2one (res.partner.bank). Conta bancária para pagamento de salários.
27. private_email
Tipo: Char. Email pessoal do colaborador. Usado quando não existe email de trabalho.
28. phone
Tipo: Char. Telefone pessoal. Distinto dos contactos profissionais.
29. contract_id
Tipo: Many2one (hr.contract). Contrato ativo. Referência ao contrato em vigor.
30. contract_ids
Tipo: One2many (hr.contract). Histórico de contratos associados ao colaborador.
31. image_1920
Tipo: Binary. Fotografia do colaborador. O Odoo guarda várias dimensões; usada em fichas, relatórios e diretórios.
32. related_partner_id
Tipo: Many2one (res.partner). Parceiro associado ao colaborador. Faz a ligação entre dados de RH e o modelo partner para CRM e outros módulos.
33. leave_manager_id
Tipo: Many2one (res.users). Utilizador responsável pela aprovação de faltas. Se não definido, a aprovação segue para um administrador ou aprovador configurado.
34. expense_manager_id
Tipo: Many2one (res.users). Utilizador encarregado de aprovar despesas. Se vazio, a aprovação fica sob responsabilidade do administrador ou aprovador padrão.
35. timesheet_manager_id
Tipo: Many2one (res.users). Utilizador que aprova folhas de horas. Sem definição, usa‑se o administrador ou o responsável por timesheets.
Como este modelo entra nos processos de negócio
1. Diretório de colaboradores e integração na admissão
Ao criar um novo colaborador, o RH preenche a ficha hr.employee com nome, departamento, cargo, gestor e contactos. O campo user_id é ligado quando a pessoa precisa de acesso ao Odoo.
2. Presenças e controlo de horários
As entradas e saídas registem‑se na aplicação de Presenças e ficam ligadas ao hr.employee via hr.attendance. Os campos barcode e pin permitem modos de quiosque e autenticação rápida.
3. Férias e pedidos de tempo livre
Os pedidos de ausência referenciam o colaborador; o leave_manager_id e o resource_calendar_id determinam quem aprova e como é calculado o tempo disponível.
4. Folha de vencimentos e contratos
A folha salarial usa dados do hr.employee para estrutura salarial, conta bancária e referências contratuais. O contract_id aponta para o contrato ativo e o contract_ids conserva o histórico.
5. Folhas de horas e alocação a projetos
As horas lançadas em projetos ligam‑se ao hr.employee. O timesheet_manager_id controla aprovações e o resource_id integra a capacidade e o planeamento.
Como os programadores estendem este modelo
Os programadores estendem o hr.employee através de padrões do Odoo — a herança de modelos é a forma mais usada.
Herança de modelos
Declare _inherit = 'hr.employee' no seu módulo para acrescentar campos, alterar métodos ou adicionar restrições. Assim mantém as alterações separadas do código core, facilitando atualizações.
Adicionar campos
No modelo herdado declare novos campos com o tipo adequado: Char, Many2one, Boolean, Integer, Text, Selection. Pense em campos dependentes de empresa quando trabalha em ambientes multi‑empresa.
Extensões em Python
Sobrescreva métodos como create, write ou unlink para incorporar lógica própria — mas chame sempre super() para preservar o comportamento original. Tenha atenção a campos computados e às suas dependências.
Odoo Studio
O Odoo Studio permite criar campos sem código e é útil para alterações rápidas. Para regras complexas ou implementações que exigem manutenção e upgrades, é preferível um módulo personalizado.
Boas práticas
- Atribua user_id apenas quando o colaborador necessitar de acesso ao sistema. Nem todos precisam de uma conta de utilizador.
- Construa a hierarquia de forma consistente usando parent_id — comece pelo topo da organização para evitar incoerências.
- Defina resource_calendar_id para garantir cálculos coerentes de horário, presenças e dias de férias.
- Nas integrações API, utilize os endpoints XML‑RPC ou JSON‑RPC. O hr.employee está exposto via API; faça correspondência cuidada dos IDs externos para evitar colisões.
- Para campos personalizados, prefira prefixos x_ ou um prefixo de módulo para minimizar conflitos com futuras versões do Odoo.
- Campos sensíveis devem ser limitados a utilizadores com o grupo hr.group_hr_user. Use a propriedade groups nos campos para controlar a visibilidade.
Erros comuns
- Criar registos duplicados em vez de procurar existentes é um erro frequente. Utilize work_email, identification_id ou regras de deduplicação para evitar duplicidade de colaboradores.
- Confundir user_id com related_partner_id é comum: user_id liga a uma conta que acede ao Odoo; related_partner_id aponta para um contacto (res.partner).
- Não esquecer de definir employee_type: é obrigatório e influencia como os contratos são tratados.
- Sobrescrever métodos essenciais sem chamar super() pode quebrar funcionalidades de outros módulos e dificultar upgrades.
- Adicionar campos obrigatórios sem valores por defeito causa erros de validação em registos antigos durante upgrades.
- Expor campos confidenciais a utilizadores sem privilégios de RH é um risco — restrinja a visibilidade por grupos.
Conclusão
O hr.employee é o núcleo do módulo de RH no Odoo: centraliza dados do colaborador e articula‑se com contratos, presenças e férias. Dominar este modelo facilita a configuração, personalização e integração do sistema.
Seja a sua função a de consultor funcional a mapear processos de RH ou de programador a desenvolver, compreender bem o hr.employee evita retrabalho e erros operacionais.
Precisa de ajuda com a sua implementação Odoo?
A Dasolo acompanha empresas na implementação, personalização e otimização do Odoo. Especializamo‑nos em integrações via API e desenvolvimento orientado à arquitetura de dados do Odoo, incluindo modelos como o hr.employee.
Se precisa de apoio na sua implementação Odoo, num módulo RH personalizado ou numa integração, podemos ajudar. Agende uma demonstração para discutir o seu projeto.