Wprowadzenie
W Odoo modele określają strukturę danych i sposób ich zapisu w bazie. Każdy element firmowych informacji — od zamówień sprzedaży, przez faktury, po dane pracowników — jest przechowywany właśnie w modelu.
Znajomość modeli Odoo jest niezbędna zarówno dla deweloperów, jak i konsultantów funkcjonalnych. Modele stanowią trzon architektury danych, definiując pola, powiązania i logikę biznesową.
Ten materiał skupia się na kluczowym modelu modułu HR: hr.employee. Jeśli tworzysz procesy kadrowe, integrujesz płace lub konfigurujesz obecności i urlopy, prędzej czy później trafisz na ten model.
Czym jest model hr.employee
Model hr.employee odpowiada za zapis informacji o pracownikach w Odoo. To centralne miejsce, w którym zbierane są dane personalne i służbowe.
Model ten należy do aplikacji HR i jest wykorzystywany w modułach związanych z obecnością, urlopami, umowami, płacami oraz ewidencją czasu pracy.
Po instalacji aplikacji Pracownicy model hr.employee staje się dostępny, a inne moduły rozszerzają go przez dziedziczenie modelu. hr_contract dodaje pola związane z umowami, hr_attendance — rejestry wejść/wyjść, a hr_leave — mechanizmy urlopowe. Dzięki temu każdy moduł dopina własne dane bez duplikowania rdzenia.
Odoo udostępnia też hr.employee.public — uproszczony widok danych pracowniczych dla użytkowników z ograniczonym dostępem. To przykład, jak przy użyciu abstrakcji i dziedziczenia steruje się widocznością informacji.
Najważniejsze pola w modelu
Poniżej wymieniono kluczowe pola modelu hr.employee. Rozumienie ich roli ułatwi pracę z kartotekami pracowników.
1. name
Typ: Pole tekstowe (Char). Przechowuje imię i nazwisko pracownika lub jego wyświetlaną nazwę. To podstawowy identyfikator wykorzystywany w widokach i listach.
2. create_date
Typ: Datetime. Rejestruje czas utworzenia rekordu. Odoo zarządza tym automatycznie — przydatne w raportowaniu i audytach.
3. write_date
Typ: Datetime. Zawiera datę ostatniej modyfikacji rekordu. Również zarządzane automatycznie — pomaga śledzić aktualizacje.
4. active
Typ: Boolean. Flaga archiwizacji. Gdy False, rekord jest ukrywany w standardowych widokach — używane przy odejściu pracownika bez fizycznego usuwania danych.
5. company_id
Typ: Many2one (res.company). W środowisku wielofirmowym określa, do której spółki należy pracownik. Pole wymagane w większości kartotek.
6. user_id
Typ: Many2one (res.users). Łączy pracownika z kontem użytkownika Odoo. Gdy ustawione, pracownik może się logować — ma to znaczenie dla dostępu do portalu, ewidencji czasu i zatwierdzeń.
7. work_email
Typ: Char. Służbowy adres e‑mail, wykorzystywany do wewnętrznych powiadomień i komunikacji.
8. work_phone
Typ: Char. Numer telefonu służbowego, widoczny w formularzach i stosowany w procesach kontaktowych.
9. mobile_phone
Typ: Char. Numer komórkowy służbowy — przydatny przy powiadomieniach pilnych lub SMS.
10. department_id
Typ: Many2one (hr.department). Działa przypisania do departamentu — używane w strukturze organizacyjnej, raportach i przepływach zatwierdzeń.
11. job_id
Typ: Many2one (hr.job). Odniesienie do stanowiska — łączy z modelem hr.job, który opisuje tytuły i otwarte rekrutacje.
12. job_title
Typ: Char. Swobodne pole na nazwę stanowiska — przydatne, gdy nie korzystasz z powiązanego job_id.
13. parent_id
Typ: Many2one (hr.employee). Przełożony — pozwala budować hierarchię pracowników dla łańcuchów zatwierdzeń i wykresów organizacyjnych.
14. coach_id
Typ: Many2one (hr.employee). Opiekun rozwoju pracownika — stosowany w ocenach i planach rozwojowych; nie nadaje automatycznych uprawnień.
15. resource_id
Typ: Many2one (resource.resource). Powiązanie z zasobem systemowym — przydatne do planowania, grafiku i integracji kalendarza.
16. work_contact_id
Typ: Many2one (res.partner). Kontakt służbowy — partner wykorzystywany w dokumentach i komunikacji firmowej.
17. address_id
Typ: Many2one (res.partner). Adres służbowy — powiązanie z rekordem partnera opisującym biuro lub lokalizację pracy.
18. address_home_id
Typ: Many2one (res.partner). Adres prywatny — domowy kontakt potrzebny np. do rozliczeń czy sytuacji awaryjnych.
19. resource_calendar_id
Typ: Many2one (resource.calendar). Kalendarz pracy — definiuje godziny i dni pracy, co ma wpływ na obecności i naliczanie urlopów.
20. employee_type
Typ: Selection. Typ pracownika: Pracownik etatowy, Freelancer lub Stażysta. Pole wymagane; wpływa na zasady umów i ich historię.
21. barcode
Typ: Char. Identyfikator z karty/rachunku — stosowany w kioskach rejestracji czasu i przy skanowaniu.
22. pin
Typ: Char. PIN do logowania w trybie kiosku obecności. Może też służyć przy zmianie kasjera w POS.
23. birthday
Typ: Date. Data urodzenia — używana w dokumentacji kadrowej i opcjonalnych przypomnieniach.
24. identification_id
Typ: Char. Numer identyfikacyjny (PESEL/NRID) — ważne dla wymogów kadrowo‑płacowych.
25. passport_id
Typ: Char. Numer paszportu — przydatny do obsługi podróży służbowych lub zezwoleń na pracę.
26. bank_account_id
Typ: Many2one (res.partner.bank). Rachunek bankowy pracownika do wypłat wynagrodzeń.
27. private_email
Typ: Char. Prywatny e‑mail — używany, gdy służbowy nie jest dostępny.
28. phone
Typ: Char. Prywatny numer telefonu, oddzielony od danych służbowych.
29. contract_id
Typ: Many2one (hr.contract). Bieżąca umowa — odniesienie do aktywnego dokumentu umownego.
30. contract_ids
Typ: One2many (hr.contract). Historia umów powiązanych z pracownikiem.
31. image_1920
Typ: Binary. Zdjęcie pracownika — Odoo przechowuje obrazy w kilku rozmiarach, wykorzystywane w katalogach i raportach.
32. related_partner_id
Typ: Many2one (res.partner). Powiązany kontakt — łącze z partnerem używanym także w CRM i innych modułach.
33. leave_manager_id
Typ: Many2one (res.users). Użytkownik odpowiedzialny za zatwierdzanie urlopów — jeśli puste, proces kierowany jest do administratora lub osoby upoważnionej.
34. expense_manager_id
Typ: Many2one (res.users). Osoba zatwierdzająca wydatki pracownicze — domyślnie przechodzi do administratora, gdy brak ustawienia.
35. timesheet_manager_id
Typ: Many2one (res.users). Osoba zatwierdzająca timesheety — ważne przy ewidencji czasu pracy i rozliczeniach projektowych.
Zastosowania modelu w procesach biznesowych
1. Katalog pracowników i proces onboardingu
Przy tworzeniu karty pracownika HR wprowadza podstawowe dane: imię i nazwisko, dział, stanowisko, przełożonego i dane kontaktowe. Link do user_id ustawiamy jedynie wtedy, gdy pracownik ma mieć dostęp do systemu.
2. Obecności i rejestracja czasu
Rejestracje wejść/wyjść zapisuje moduł Obecności w hr.attendance i powiązane są z rekordem hr.employee. Pola barcode i pin umożliwiają pracę w trybie kiosku.
3. Urlopy i nieobecności
Wnioski urlopowe odnoszą się do rekordu pracownika — to leave_manager_id i resource_calendar_id decydują, kto zatwierdza i jak naliczane są dni wolne.
4. Płace i umowy
Płace korzystają z danych hr.employee przy określaniu struktury wynagrodzeń, konta bankowego i powiązanej umowy. contract_id wskazuje aktywną umowę, a contract_ids przechowuje historię.
5. Timesheety i przypisanie do projektów
Gdy pracownik rejestruje czas na projekt, timesheet odnosi się do hr.employee. Osoba zatwierdzająca określona jest przez timesheet_manager_id, a resource_id pozwala planować zasoby.
Jak programiści rozszerzają ten model
Programiści rozszerzają model hr.employee korzystając z kilku podejść, z których podstawowym jest dziedziczenie modelu Odoo.
Dziedziczenie modelu
W module rozszerzającym ustaw _inherit = 'hr.employee', aby dodać nowe pola, nadpisać metody lub wprowadzić ograniczenia. Dzięki temu modyfikacje pozostają w osobnym module, ułatwiając przyszłe aktualizacje.
Dodawanie pól
W klasie dziedziczącej deklarujesz nowe pola — wybieraj odpowiedni typ: Char, Many2one, Boolean, Integer, Text, Selection. W środowiskach wielofirmowych warto rozważyć pola zależne od company_id.
Rozszerzenia w Pythonie
Nadpisuj metody create, write czy unlink, aby dodać logikę biznesową, zawsze wywołując super(). Zwróć uwagę na pola obliczane i ich zależności, by unikać problemów z cache i wydajnością.
Odoo Studio
Odoo Studio pozwala dodawać pola bez programowania — szybkie rozwiązanie dla prostych zmian. Dla złożonych scenariuszy i potrzeby długoterminowych aktualizacji lepsze będą moduły napisane ręcznie.
Dobre praktyki
- Ustawiaj user_id tylko wtedy, gdy pracownik rzeczywiście potrzebuje konta w Odoo — nie każdy rekord pracownika wymaga logowania.
- Buduj strukturę organizacyjną poprawnie, wykorzystując parent_id jako relację przełożony–podwładny, zaczynając od najwyższych szczebli.
- Zadbaj o resource_calendar_id, aby obliczenia czasu pracy i urlopów były spójne w całym systemie.
- Przy integracjach API korzystaj z XML-RPC lub JSON-RPC — model hr.employee jest w pełni udostępniony przez API. Dokładnie mapuj identyfikatory zewnętrzne, aby uniknąć duplikatów.
- Dla pól własnych stosuj prefiks modułu (np. x_nazwa_modulu_), żeby ograniczyć ryzyko konfliktów z przyszłymi wersjami Odoo.
- Pola zawierające wrażliwe dane ograniczaj do grupy hr.group_hr_user — nie prefetchuj takich pól dla użytkowników bez dostępu HR.
Najczęściej popełniane błędy
- Tworzenie zduplikowanych kart pracowniczych zamiast wyszukiwania istniejących rekordów. Używaj work_email lub identification_id do deduplikacji.
- Mylące użycie user_id i related_partner_id. user_id służy do logowania do Odoo, related_partner_id to rekord kontaktu/partnera.
- Zapominanie o ustawieniu employee_type. Pole jest wymagane i wpływa na zachowanie związane z umowami.
- Nadpisywanie metod rdzenia bez wywołania super(). Taka praktyka może łamać działanie innych modułów lub komplikować przyszłe aktualizacje.
- Dodawanie wymaganych pól custom bez wartości domyślnych. Istniejące rekordy mogą wtedy nie przejść walidacji po aktualizacji.
- Udostępnianie wrażliwych danych HR użytkownikom bez odpowiednich uprawnień. Zabezpieczaj pola przez grupy dostępu.
Podsumowanie
Model hr.employee jest kluczowym elementem modułu HR w Odoo. Zawiera dane pracowników i łączy je z umowami, ewidencją obecności oraz urlopami. Znajomość jego pól i mechanizmów rozszerzania ułatwia konfigurację, rozwój i integracje.
Zarówno konsultanci mapujący procesy HR, jak i deweloperzy tworzący rozszerzenia, zyskają na czasie i zmniejszą liczbę błędów, gdy dobrze zrozumieją model hr.employee.
Potrzebujesz pomocy przy wdrożeniu Odoo?
Dasolo wspiera firmy we wdrożeniach, dostosowaniach i optymalizacji Odoo. Specjalizujemy się w integracjach API oraz rozwoju modułów — mamy szerokie doświadczenie w architekturze danych Odoo i pracy z modelami takimi jak hr.employee.
Jeśli potrzebujesz wsparcia przy wdrożeniu Odoo, tworzeniu modułów HR lub integracjach, chętnie pomożemy. Umów demonstrację i porozmawiajmy o Twoim projekcie.