Innledning
I Odoo beskriver modeller hvordan informasjonen lagres i databasen. Alle forretningsobjekter — fra ordre og fakturaer til ansatte — organiseres gjennom modeller som bestemmer hvilke data som finnes og hvordan de henger sammen.
Kunnskap om Odoo-modeller er viktig både for utviklere og funksjonelle konsulenter. Modeller utgjør ryggraden i datamodellen: de definerer feltene, relasjonene mellom poster og den forretningslogikken som skal kjøres.
Denne gjennomgangen konsentrerer seg om en kjernekomponent i HR‑modulen: hr.employee. Enten du setter opp onboarding, lønnsintegrasjoner eller fraværshåndtering, kommer du ofte borti denne modellen.
Hva er hr.employee-modellen
hr.employee er Odoos sentrale representasjon av en ansatt. Her samles kontaktinfo, stilling, tilknytning til selskap og andre HR‑relaterte data på ett sted.
Modellen hører hjemme i HR‑appen og brukes av flere funksjoner: fravær, kontrakter, lønn, tidregistrering og bemanningsplanlegging trekker alle på data fra hr.employee.
Når Employees‑appen aktiveres, opprettes modellen. Andre moduler utvider den via arv slik at hvert tillegg legger på det det trenger — for eksempel legger hr_contract på kontraktfelt, hr_attendance på innsjekksdata og hr_leave på fraværslogikk — uten å duplisere grunnstrukturen.
Det finnes også en avgrenset variant, hr.employee.public, som gir et begrenset utsyn for brukere som kun trenger minimal informasjon. Dette er et eksempel på hvordan Odoo bruker arv og tilgangsmodellering for å kontrollere synlighet.
Viktige felt i modellen
Her følger en oversikt over de viktigste feltene i hr.employee. Kjennskap til disse gjør det enklere å jobbe med personalregistre og integrasjoner.
1. name
Type: Char. Navnet på den ansatte. Dette er ofte den synlige etiketten i lister og skjemaer og brukes som hovedidentifikator i brukergrensesnittet.
2. create_date
Type: Datetime. Tidspunkt for når posten ble opprettet. Administreres automatisk og er nyttig for sporbarhet og rapportering.
3. write_date
Type: Datetime. Tid for siste endring. Også automatisk, og viktig for å vite når data sist ble oppdatert.
4. active
Type: Boolean. Brukes som et arkiveringsflagg. Når False blir posten skjult i standardvisninger i stedet for å bli slettet fysisk.
5. company_id
Type: Many2one (res.company). Angir hvilket selskap i et multinasjonalt eller multienhetsoppsett ansatte hører til. Mange HR‑operasjoner krever at dette er satt.
6. user_id
Type: Many2one (res.users). Kobler den ansatte til en Odoo‑bruker. Dette gir innlogging, rettigheter og rett til portal/tidsskriving.
7. work_email
Type: Char. Arbeidsemail for intern kommunikasjon og varsler.
8. work_phone
Type: Char. Arbeidstelefon som vises i ansattkort og kontakter.
9. mobile_phone
Type: Char. Mobilnummer for raske varsler eller SMS.
10. department_id
Type: Many2one (hr.department). Avdelingstilhørighet brukt i organisasjonskart og godkjenningsregler.
11. job_id
Type: Many2one (hr.job). Referanse til stillingstype og annonse/posisjon i HR‑oppsettet.
12. job_title
Type: Char. Fri tekst for stillingstittel, nyttig når man ønsker en annen visning enn job_id gir.
13. parent_id
Type: Many2one (hr.employee). Leder/rapporteringslinje som bygger hierarkiet i organisasjonen.
14. coach_id
Type: Many2one (hr.employee). Funksjonelt kontaktpunkt for utvikling/mentoring uten å gi spesielle rettigheter.
15. resource_id
Type: Many2one (resource.resource). Kobling til ressursplanlegging for kapasitet og kalenderintegrasjon.
16. work_contact_id
Type: Many2one (res.partner). Kontaktpost brukt i arbeidssammenheng for dokumenter og kommunikasjon.
17. address_id
Type: Many2one (res.partner). Arbeidsadresse — ofte kontoradressen til en ansatt.
18. address_home_id
Type: Many2one (res.partner). Privat adresse for lønn, utsendelser eller beredskapsinformasjon.
19. resource_calendar_id
Type: Many2one (resource.calendar). Definerer arbeidstider og skift — grunnlaget for fraværsberegning og planlegging.
20. employee_type
Type: Selection. Angir om personen er ansatt, frilanser eller praktikant. Påvirker blant annet kontraktshåndtering.
21. barcode
Type: Char. ID‑kode for adgangskort eller strekkodeleser ved tidregistrering.
22. pin
Type: Char. PIN for kioskmode i tidregistrering eller for kassaskifte i POS.
23. birthday
Type: Date. Fødselsdato brukt i HR‑arkiv og eventuelle påminnelser.
24. identification_id
Type: Char. Personnummer eller nasjonalt ID‑nummer for lovpålagte krav og lønn.
25. passport_id
Type: Char. Passnummer for reise og arbeidstillatelser.
26. bank_account_id
Type: Many2one (res.partner.bank). Konto for lønnsutbetalinger.
27. private_email
Type: Char. Privat e‑postadresse dersom arbeidsemail ikke er tilgjengelig.
28. phone
Type: Char. Privat telefonnummer, skilte fra arbeidsnummer.
29. contract_id
Type: Many2one (hr.contract). Referanse til gjeldende arbeidskontrakt.
30. contract_ids
Type: One2many (hr.contract). Historikk over alle kontrakter knyttet til den ansatte.
31. image_1920
Type: Binary. Bilde/portrett brukt i kataloger, rapporter og profiler — Odoo lagrer flere størrelser.
32. related_partner_id
Type: Many2one (res.partner). Kobling mot partnerposter for CRM, fakturering og kontaktlogg.
33. leave_manager_id
Type: Many2one (res.users). Bruker som godkjenner permisjoner; hvis tom, går godkjenning til standardgodkjenneren.
34. expense_manager_id
Type: Many2one (res.users). Ansvarlig for godkjenning av utlegg.
35. timesheet_manager_id
Type: Many2one (res.users). Person som godkjenner timelister.
Hvordan modellen brukes i arbeidsflyter
1. Ansattregister og onboarding
Ved opprettelse av en ny ansatt fyller HR inn grunndata i hr.employee: navn, avdeling, stilling, leder og kontaktinfo. user_id settes først når den ansatte skal ha Odoo‑tilgang.
2. Oppmøte og tidsporing
Oppmøte registreres via Attendance‑appen og lagres i hr.attendance med kobling til hr.employee. Felt som barcode og pin muliggjør kioskmode for enkel innsjekk.
3. Fravær og permisjon
Sykefravær og ferie refererer til hr.employee. leave_manager_id avgjør hvem som behandler søknaden, og resource_calendar_id bestemmer hvor mange dager som regnes som arbeidsdager.
4. Lønn og kontrakter
Lønnsberegning henter bankkonto, struktur og kontraktsinformasjon fra hr.employee og tilknyttede kontraktposter. contract_id peker på aktiv kontrakt, mens contract_ids gir full historikk.
5. Timelister og ressursallokering
Når timeføring skjer mot prosjekter, kobles dette til hr.employee. timesheet_manager_id styrer godkjenning, og resource_id knyttes mot planleggingsverktøy.
Slik utvider utviklere modellen
Utviklere bygger videre på hr.employee ved hjelp av Odoos arv- og utvidelsesmønstre, som gir fleksibilitet uten å endre kjerne‑modulen direkte.
Modellarv
Bruk _inherit = 'hr.employee' for å legge til felter, endre metoder eller tilføre validering. Endringene pakkes i en egen modul slik at kjerneoppdateringer blir lettere å håndtere.
Legge til felt
Definer nye felt i arvet modellen med riktig datatype: Char, Many2one, Boolean, Integer, Text eller Selection. For multinasjonale oppsett vurder company‑dependent felter der det er relevant.
Python‑utvidelser
Overstyr create, write eller unlink for å implementere tilpasset logikk, og husk alltid å kalle super() der det trengs. Vær spesielt oppmerksom på avhengigheter for beregnede felt.
Odoo Studio
Odoo Studio gir et hurtigverktøy for å legge til felter og enkle skjemaendringer uten koding. For mer avansert funksjonalitet og vedlikehold er moduler i kode ofte best på sikt.
Anbefalte fremgangsmåter
- Sett user_id bare for de som faktisk trenger å logge inn i Odoo. Ikke alle ansatte trenger brukerkonto eller lisens.
- Bygg organisasjonsstrukturen riktig ved å sette parent_id konsekvent — start fra toppen og arbeid nedover i hierarkiet.
- Angi resource_calendar_id for ansatte slik at fraværsberegninger og arbeidstidsregler blir konsistente på tvers av systemet.
- Ved API‑integrasjoner bruk XML‑RPC eller JSON‑RPC. hr.employee er tilgjengelig via Odoos API — kartlegg eksterne IDer og felt nøye for å unngå duplikater.
- For egendefinerte felter bruk x_‑prefiks eller et modulspesifikt prefiks for å unngå navnekonflikter ved fremtidige Odoo‑oppdateringer.
- Felt som inneholder sensitive HR‑data bør begrenses til brukere med hr.group_hr_user. Bruk grupper på feltnivå for å forhindre uautorisert forhåndslasting av data.
Vanlige feil
- Dobbelregistrering skjer ofte når man ikke søker etter eksisterende poster. Bruk unike felt som work_email eller identification_id for å slå opp og unngå duplikater.
- Skill tydelig mellom user_id og related_partner_id: user_id gir innloggingsrettigheter, mens related_partner_id er kontaktposten for CRM/fakturering.
- Husk å angi employee_type ved opprettelse — feltet er ofte påkrevd og påvirker hvordan kontrakter håndteres.
- Når du overstyrer kjernemetoder, sørg for å kalle super(), ellers kan det bryte andre moduler eller skape problemer ved oppgradering.
- Unngå å gjøre nye felt obligatoriske uten å legge inn standardverdier; ellers vil eksisterende poster feile validering ved oppgradering.
- Ikke eksponer sensitive felter for brukere uten HR‑rettigheter. Sett riktige grupper og tilgangskontroller på de feltene som inneholder personopplysninger.
Oppsummering
hr.employee er et nav i Odoo‑økosystemet for HR: det lagrer personaldata og kobler til kontrakter, tid og fravær. Å forstå feltene og utvidelsesmulighetene gjør det enklere å konfigurere og integrere systemet riktig.
Enten du kartlegger HR‑prosesser eller utvikler tilpassede moduler, sparer god forståelse av hr.employee tid og forebygger feil i implementasjonen.
Trenger du hjelp med Odoo-implementasjonen din?
Dasolo bistår virksomheter med å implementere, tilpasse og optimalisere Odoo. Vi har erfaring med API‑integrasjoner, tilpasset utvikling og Odoos datamodell, inkludert hr.employee.
Trenger du støtte til Odoo‑implementasjon, skreddersydde HR‑moduler eller integrasjoner, ta gjerne kontakt — vi hjelper deg videre. Bestill en demo for å diskutere prosjektet ditt.