Einführung
In Odoo bestimmen Modelle, wie Informationen gespeichert, verknüpft und abgefragt werden. Jedes Geschäftsobjekt — von Angeboten über Rechnungen bis hin zu Mitarbeiterdaten — lebt in einem Modell und definiert damit seine Datenstruktur.
Ein sicheres Verständnis der Odoo‑Modelle ist für Entwickler und Berater gleich wichtig. Modelle sind das Rückgrat der Datenarchitektur: Sie legen Felder, Beziehungen und die zugrundeliegende Logik fest.
Dieser Beitrag konzentriert sich auf ein zentrales Modell im Personalbereich: hr.employee. Ganz gleich, ob Sie Personalprozesse anpassen, die Lohnabrechnung integrieren oder Anwesenheit und Abwesenheit konfigurieren — mit diesem Modell arbeiten Sie jederzeit.
Was das hr.employee‑Modell ist
Das hr.employee‑Modell bildet die Mitarbeiterakte in Odoo ab. Hier werden alle relevanten personenbezogenen Informationen zusammengeführt — von Kontaktdaten bis zu organisatorischen Zuordnungen.
Das Modell gehört zur HR‑App und dient als Basis für Funktionen wie Anwesenheitserfassung, Abwesenheitsmanagement, Arbeitsverträge, Lohnabrechnung und Zeiterfassung.
Sobald die App "Mitarbeiter" aktiviert ist, wird hr.employee verfügbar. Weitere Module erweitern es über Odoo‑Vererbung: hr_contract ergänzt Vertragsfelder, hr_attendance bringt Check‑in/out‑Logik, hr_leave verwaltet Freistellungen. Die Erweiterungen fügen nur hinzu, was nötig ist, ohne die Grundstruktur zu duplizieren.
Für Fälle mit eingeschränkter Einsicht stellt Odoo hr.employee.public bereit — eine reduzierte Ansicht der Mitarbeiterdaten. So lässt sich über Modellmuster und Vererbung feingranularer Zugriff steuern.
Wichtige Felder im Modell
Nachfolgend die wichtigsten Felder, die Sie kennen sollten. Sie sind nützlich für Konfiguration, Reporting und Integrationen.
1. name
Typ: Char. Enthält den Namen des Mitarbeiters. In Listen und Formularen ist dieses Feld die primäre Beschriftung des Datensatzes.
2. create_date
Typ: Datetime. Zeitpunkt der Erstellung des Datensatzes. Odoo pflegt dieses Feld automatisch — sinnvoll für Audit‑Protokolle und Historien.
3. write_date
Typ: Datetime. Zeitstempel der letzten Änderung. Ebenfalls automatisch gepflegt, hilft beim Nachvollziehen von Updates.
4. active
Typ: Boolean. Flag für Archivierung. Bei False ist der Datensatz ausgeblendet, bleibt aber in der Datenbank erhalten — praktisch für ausschiedende Mitarbeitende.
5. company_id
Typ: Many2one (res.company). Gibt die Konzern‑/Firmeneinheit an, zu der der Mitarbeiter gehört — wichtig in Multi‑Company‑Setups.
6. user_id
Typ: Many2one (res.users). Verknüpft den Mitarbeiter mit einem Odoo‑Benutzerkonto. Erst damit sind Login, Portalzugang, Stundenzettel und Genehmigungen möglich.
7. work_email
Typ: Char. Dienstliche E‑Mailadresse für interne Benachrichtigungen und Workflows.
8. work_phone
Typ: Char. Dienstliche Telefonnummer, sichtbar in Formularen und Kontaktlisten.
9. mobile_phone
Typ: Char. Mobilnummer für SMS‑ oder Dringlichkeitsbenachrichtigungen.
10. department_id
Typ: Many2one (hr.department). Fachabteilung des Mitarbeiters — relevant für Organigramme, Reportings und Genehmigungswege.
11. job_id
Typ: Many2one (hr.job). Stellenbezeichnung als Verweis auf hr.job, dort sind Rollen und offene Positionen definiert.
12. job_title
Typ: Char. Freitext für individuelle Jobbezeichnungen, wenn kein job_id verwendet wird oder zusätzliche Infos nötig sind.
13. parent_id
Typ: Many2one (hr.employee). Vorgesetzter/Line Manager. Stellt Hierarchien her und treibt Genehmigungsprozesse an.
14. coach_id
Typ: Many2one (hr.employee). Mentoring/Coach‑Zuweisung für Entwicklungs‑ und Performance‑Prozesse. Keine weiteren Zugriffsrechte implizit.
15. resource_id
Typ: Many2one (resource.resource). Verknüpft mit den Planungsressourcen — wichtig für Einsatzplanung und Kalenderintegration.
16. work_contact_id
Typ: Many2one (res.partner). Geschäftlicher Kontaktdatensatz, nutzbar für Dokumente und geschäftliche Kommunikation.
17. address_id
Typ: Many2one (res.partner). Arbeitsstandort/Office‑Adresse als Partnerdatensatz.
18. address_home_id
Typ: Many2one (res.partner). Privatadresse des Mitarbeiters — relevant für Lohnabrechnung oder Notfälle.
19. resource_calendar_id
Typ: Many2one (resource.calendar). Arbeitszeitkalender: definiert Schichten, Wochenarbeitszeit und ist Grundlage für Anwesenheit und Urlaubsberechnung.
20. employee_type
Typ: Selection. Klassifizierung: Mitarbeiter, Freiberufler, Praktikant. Beeinflusst Vertragslogik und wie Verträge historisiert werden.
21. barcode
Typ: Char. Badge‑ID für Scannerlösungen wie das Anwesenheitskiosk.
22. pin
Typ: Char. PIN für Kiosk‑Anmeldung oder bestimmte POS‑Wechselvorgänge.
23. birthday
Typ: Date. Geburtsdatum — optional, aber nützlich für HR‑Reports oder Erinnerungen.
24. identification_id
Typ: Char. Staats‑/Personalausweisnummer für HR‑ und Payroll‑Vorgänge.
25. passport_id
Typ: Char. Reisepassnummer für Reisethemen oder Aufenthaltstitel.
26. bank_account_id
Typ: Many2one (res.partner.bank). Bankverbindung für Gehaltszahlungen.
27. private_email
Typ: Char. Private E‑Mailadresse, falls dienstliche Mail nicht vorhanden ist.
28. phone
Typ: Char. Private Telefonnummer, getrennt von dienstlichen Kontaktdaten.
29. contract_id
Typ: Many2one (hr.contract). Aktuell gültiger Vertrag — wichtig für Gehaltsstruktur und rechtliche Parameter.
30. contract_ids
Typ: One2many (hr.contract). Historie aller Verträge des Mitarbeiters.
31. image_1920
Typ: Binary. Mitarbeiterfoto/Avatar; Odoo verwaltet mehrere Größen für Listen, Formulare und Verzeichnisse.
32. related_partner_id
Typ: Many2one (res.partner). Der zugeordnete Partnerdatensatz, oft genutzt für CRM‑Beziehungen und externe Kommunikation.
33. leave_manager_id
Typ: Many2one (res.users). Benutzer, der Abwesenheiten genehmigt — ist dieses Feld leer, springt die Genehmigung an zentrale Rollen.
34. expense_manager_id
Typ: Many2one (res.users). Verantwortlicher für Spesenfreigaben.
35. timesheet_manager_id
Typ: Many2one (res.users). Zuständiger für die Freigabe von Stundenzetteln.
Wie das Modell in Geschäftsprozessen genutzt wird
1. Mitarbeiterverzeichnis und Onboarding
Beim Anlegen einer neuen Person pflegt HR die Stammdaten im hr.employee‑Datensatz: Name, Abteilung, Rolle, Vorgesetzte und Kontaktinfos. Erst mit gesetztem user_id‑Feld bekommt die Person ein Odoo‑Login.
2. Anwesenheit und Zeiterfassung
Check‑ins und Check‑outs werden über die Attendance‑App erfasst und in hr.attendance mit dem jeweiligen hr.employee‑Eintrag verknüpft. Barcode und PIN ermöglichen Kiosk‑Betrieb.
3. Abwesenheiten und Urlaub
Urlaubsanträge referenzieren den Mitarbeiter. leave_manager_id legt fest, wer genehmigt, resource_calendar_id bestimmt wie viele Arbeitstage angerechnet werden.
4. Lohnabrechnung und Arbeitsverträge
Für Payroll sind Bankverbindung, Gehaltsstruktur und Vertragsdaten im hr.employee relevant. contract_id verweist auf den aktiven Vertrag, contract_ids dokumentiert die Vertragsgeschichte.
5. Stundenerfassung und Einsatzplanung
Zeiterfassungen auf Projektebene werden mit dem hr.employee‑Datensatz verknüpft. timesheet_manager_id regelt Genehmigungen, resource_id verbindet zur Einsatzplanung.
Wie Entwickler das Modell erweitern
Entwickler erweitern hr.employee hauptsächlich über die Odoo‑Vererbung und einige bewährte Muster.
Modellerweiterung (Inheritance)
Verwenden Sie _inherit = 'hr.employee', um das Modell zu erweitern. So lassen sich Felder hinzufügen, Methoden anpassen oder Validierungen ergänzen, ohne den Core‑Code zu verändern — das vereinfacht Wartung und Updates.
Neue Felder anlegen
Ergänzen Sie Felder in Ihrem erweiterten Modell und wählen Sie passende Datentypen (Char, Many2one, Boolean, Integer, Text, Selection). In Multi‑Company‑Umgebungen denken Sie an unternehmensabhängige Felder.
Erweiterungen in Python
Überschreiben Sie Methoden wie create, write oder unlink, um Geschäftslogik einzufügen — rufen Sie dabei super() auf. Achten Sie besonders auf berechnete Felder und deren Abhängigkeiten.
Odoo Studio
Odoo Studio erlaubt schnelle Feld‑ und Layoutanpassungen ohne Code — praktisch für Prototypen. Für komplexe Logik oder produktive Lösungen sind maßgeschneiderte Module langfristig stabiler.
Empfohlene Vorgehensweisen
- Legen Sie user_id nur an, wenn ein echtes Odoo‑Login benötigt wird. Nicht jeder Mitarbeiter braucht ein Benutzerkonto.
- Nutzen Sie parent_id sinnvoll für die Aufbauorganisation — von oben nach unten strukturiert sich ein klares Genehmigungs‑ und Berichtssystem leichter.
- Pflegen Sie resource_calendar_id, damit Arbeitszeiten, Pausen und Urlaubsberechnung konsistent funktionieren.
- Für API‑Integration nutzen Sie XML‑RPC oder JSON‑RPC. hr.employee ist über die Odoo‑API verfügbar — stimmen Sie Fremd‑IDs und Mappings sauber ab.
- Bei benutzerdefinierten Feldern empfiehlt sich das Präfix x_ oder ein Modul‑Prefix, um Kollisionen mit späteren Odoo‑Versionen zu vermeiden.
- Felder mit sensiblen Informationen sollten nur für Benutzer mit hr.group_hr_user vorab geladen werden. Steuern Sie Sichtbarkeit über Gruppen in den Felddefinitionen.
Häufige Fehler
- Doppelte Mitarbeiterdatensätze entstehen häufig bei fehlerhafter Suche vor dem Anlegen. Nutzen Sie eindeutige Felder wie work_email oder identification_id zur Duplikaterkennung.
- user_id und related_partner_id nicht zu verwechseln: user_id ist das Odoo‑Login, related_partner_id der Kontakt/Partnerdatensatz für externe Kommunikation.
- employee_type nicht vergessen — dieses Pflichtfeld beeinflusst Vertragslogik und wurde aus gutem Grund eingeführt.
- Methoden zu überschreiben ohne super() aufzurufen kann andere Module stören oder Upgrades brechen. Immer erst die Basis‑Implementierung aufrufen.
- Achten Sie darauf, bei neuen Pflichtfeldern sinnvolle Default‑Werte zu setzen — sonst schlagen Migrationen und Upgrades für bestehende Datensätze fehl.
- Vermeiden Sie, vertrauliche HR‑Felder für alle Benutzer sichtbar zu machen. Setzen Sie Zugriffsgruppen, um personenbezogene Daten zu schützen.
Fazit
hr.employee ist das Herzstück der Odoo‑Personalverwaltung: Es speichert persönliche Daten, verknüpft Verträge, Anwesenheit und Abwesenheit und bildet damit die Grundlage für Konfiguration, Anpassung und Integration.
Ob Sie nun HR‑Prozesse abbilden oder Module entwickeln — eine fundierte Kenntnis von hr.employee spart Zeit, reduziert Fehler und erleichtert Erweiterungen.
Brauchen Sie Unterstützung bei Ihrer Odoo‑Einführung?
Dasolo unterstützt Unternehmen bei Einführung, Anpassung und Optimierung von Odoo. Spezialisiert sind wir auf API‑Integrationen und individuelle Odoo‑Entwicklung mit fundierter Erfahrung in der Odoo‑Datenarchitektur, inklusive hr.employee.
Wenn Sie Hilfe bei Implementierung, maßgeschneiderten HR‑Modulen oder Integrationen brauchen, sprechen Sie uns an. Vereinbaren Sie eine Demo und lassen Sie uns Ihr Projekt besprechen.