Skip to Content

Forstå hr.employee-modellen: Odoo's medarbejderarkitektur forklaret

Den fulde guide til Odoos medarbejdermodel — for HR, udviklere og funktionelle konsulenter
11. marts 2026 af
Forstå hr.employee-modellen: Odoo's medarbejderarkitektur forklaret
Dasolo
| Ingen kommentarer endnu

Introduktion


I Odoo definerer modeller, hvordan forretningsdata organiseres og gemmes i databasen. Alt fra ordrer over fakturaer til medarbejderkort er repræsenteret som modeller — det er skabelonerne for de poster, du arbejder med i dagligdagen.


At forstå Odoo-modeller er vigtigt både for udviklere og konsulenter. Modeller udstikker felter, relationer og forretningslogik og udgør derfor fundamentet i Odoos datadesign.


Denne artikel tager udgangspunkt i en central HR-model: hr.employee. Har du behov for at bygge HR-workflows, koble lønsystemer på eller sætte fravær- og tidstyring op, så ligger meget funktionalitet og integration her.

Hvad er hr.employee-modellen


Modellen hr.employee er Odoos repræsentation af en medarbejder — det sted, hvor personaleoplysninger samles og vedligeholdes.


hr.employee er en del af HR-appen og bruges af funktioner som fravær, løn, kontrakter, tilstedeværelse og timesedler — kort sagt alt, der vedrører medarbejdernes arbejdsforhold.


Modellen aktiveres, når Employees-appen tændes, og de øvrige HR-moduler udvider den via Odoos arvehierarki. fx tilføjer hr_contract kontraktfelter, hr_attendance håndterer check-in/out, og hr_leave knytter tid_off til medarbejderen — hver udvidelse bygger ovenpå kernen uden at gentage strukturen.


Odoo tilbyder også en begrænset visning som hr.employee.public, beregnet til brugere med begrænset indsigt i medarbejderdata. Det er et eksempel på, hvordan modelarv og abstraherede visninger bruges til at styre adgang og dataseparation.

Væsentlige felter i modellen


Her er de vigtigste felter i hr.employee, som du bør kende. At have styr på dem gør det langt nemmere at arbejde med medarbejderposter i konfiguration, integration og rapportering.


1. name

Type: Char. Feltet holder medarbejderens navn og er ofte den synlige identifikation i lister og formularer — det er det primære label for posten.


2. create_date

Type: Datetime. Automatisk sat ved oprettelse. Bruges til revisionsspor, rapporter og til at se, hvornår posten blev oprettet.


3. write_date

Type: Datetime. Tidsstempel for seneste opdatering. Hjælper med at spore, hvornår data sidst blev ændret.


4. active

Type: Boolean. Blødt arkiv-flag. Sæt til False for at skjule en medarbejder i standardvisninger i stedet for at slette personen permanent.


5. company_id

Type: Many2one (res.company). Angiver hvilken virksomhed i et multi-company setup medarbejderen hører til — nødvendig i flerselskabsmiljøer.


6. user_id

Type: Many2one (res.users). Knytter medarbejderen til en Odoo-login. Hvis denne er sat, kan personen logge ind og få rettigheder til f.eks. tidsregistrering og godkendelser.


7. work_email

Type: Char. Arbejdsmailen bruges til interne notifikationer og kommunikation fra systemet.


8. work_phone

Type: Char. Arbejdstelefonnummer, synligt i medarbejderkort og kontaktflows.


9. mobile_phone

Type: Char. Mobilnummer til arbejdsrelaterede SMS'er eller hurtige beskeder.


10. department_id

Type: Many2one (hr.department). Hvilket afdelingskort medarbejderen tilhører — vigtigt for organisationsdiagrammer, rapporter og godkendelsesrules.


11. job_id

Type: Many2one (hr.job). Reference til stillingen, som peger på hr.job-objektet med stillingsoplysninger og åbne poster.


12. job_title

Type: Char. Fritekstsfelt til jobtitel, nyttigt når man vil vise en tilpasset titel i stedet for eller i tillæg til job_id.


13. parent_id

Type: Many2one (hr.employee). Direktør/leder-relationen. Bruges til opbygning af ledelseshierarki og til godkendelsesstrømme.


14. coach_id

Type: Many2one (hr.employee). Mentor eller coach for medarbejderen — bruges i udviklings- og performancemoduler uden specielle adgange.


15. resource_id

Type: Many2one (resource.resource). Forbindelse til resource-modellen til planlægning og kapacitetsstyring.


16. work_contact_id

Type: Many2one (res.partner). Den arbejdskontakt, som bruges til dokumenter og kommunikation rettet mod medarbejderens arbejdsrolle.


17. address_id

Type: Many2one (res.partner). Arbejdsadresse — oftest kontorets adresse gemt som partner-post.


18. address_home_id

Type: Many2one (res.partner). Privat adresse til fx løn- og nødkontakter.


19. resource_calendar_id

Type: Many2one (resource.calendar). Arbejdstidsplanen der definerer vagter, arbejdstimer og bruges i ferie- og tilstedeholdelsesberegninger.


20. employee_type

Type: Selection. Typen af medarbejder: fastansat, freelancer eller praktikant. Feltet styrer bl.a. kontraktlogik og hvordan historik håndteres.


21. barcode

Type: Char. Badge-ID til brug i adgangs- og tilstedeværelseskiosker med stregkodelæsere.


22. pin

Type: Char. PIN til kiosk-til- og -afcheckning; også brugt ved skift af kasse i POS.


23. birthday

Type: Date. Fødselsdato — relevant for personaleadministration og eventuelle reminders.


24. identification_id

Type: Char. Nationalt ID-nummer til compliance i HR og løn.


25. passport_id

Type: Char. Pasnummer til rejse- og arbejdstilladelsestjek.


26. bank_account_id

Type: Many2one (res.partner.bank). Konto til lønudbetalinger.


27. private_email

Type: Char. Privat e-mail — anvendes når arbejdsmail ikke er tilgængelig.


28. phone

Type: Char. Privat telefonnummer, adskilt fra arbejdskontakten.


29. contract_id

Type: Many2one (hr.contract). Henvisning til aktuel ansættelseskontrakt.


30. contract_ids

Type: One2many (hr.contract). Alle kontrakter tilknyttet medarbejderen — historik over tidligere aftaler.


31. image_1920

Type: Binary. Foto eller avatar i høj opløsning, brugt i medarbejderoversigter, rapporter og kort.


32. related_partner_id

Type: Many2one (res.partner). Kontaktposten der er koblet til medarbejderen, nyttig når HR-data skal bruges af CRM eller fakturering.


33. leave_manager_id

Type: Many2one (res.users). Den bruger som godkender fravær — ellers falder godkendelsen tilbage til en administrator eller udpeget approver.


34. expense_manager_id

Type: Many2one (res.users). Den som godkender udlæg og rejseudgifter.


35. timesheet_manager_id

Type: Many2one (res.users). Den ansvarlige for godkendelse af timesedler.

Hvordan modellen bruges i forretningsprocesser


1. Medarbejderkartotek og onboarding

Når HR opretter en ny medarbejder, udfyldes hr.employee-posten med navn, afdeling, stilling, leder og kontaktoplysninger. user_id sættes kun, når personen skal have adgang til Odoo, så man undgår unødige brugerkonti.


2. Tilstedeværelse og tidsregistrering

Tjek-in og tjek-ud registreres gennem Attendance-appen og gemmes i hr.attendance med reference til hr.employee. Felterne barcode og pin muliggør kioskmode og hurtig registrering ved indgange.


3. Fravær og ferie

Ferieanmodninger peger på medarbejderen; leave_manager_id og resource_calendar_id bestemmer, hvem der godkender, og hvordan fraværsdage beregnes.


4. Løn og kontrakter

Lønkørsler trækker oplysninger om bankkonto, lønstruktur og aktiv kontrakt fra hr.employee. contract_id viser aktuel aftale, mens contract_ids bevarer kontrakthistorikken.


5. Timesedler og projektallokering

Når medarbejdere bogfører tid på projekter, forbindes timesedlen til hr.employee. timesheet_manager_id styrer godkendelse, og resource_id bruges til planlægning i ressourceværktøjerne.

Hvordan udviklere udvider modellen


Udviklere bygger ovenpå hr.employee med Odoos arve- og udvidelsesmønstre for at tilføje funktionalitet uden at ændre kernen direkte.


Modelarv

I kode bruger du _inherit = 'hr.employee' for at udvide modellen: tilføje felter, overskrive metoder eller indføre constraints. Den metode holder ændringer i separate moduler og gør opgraderinger nemmere.


Tilføjelse af felter

Tilføj nye felter i dit arvede modul med passende typer: Char, Many2one, Boolean, Integer, Text eller Selection. Overvej company-dependent felter i flerselskabsscenarier.


Python-udvidelser

Overskriv create, write eller unlink for at indføre forretningslogik — kald super() hvor nødvendigt, og vær opmærksom på computed-felters afhængigheder for at undgå uventede beregningsfejl.


Odoo Studio

Odoo Studio gør det let at sætte felter op uden kode — hurtig og brugervenlig til mindre tilpasninger. Ved komplekse workflows eller vedligeholdelseskrav er rene moduler dog mere holdbare.

Bedste fremgangsmåder


  • Tildel user_id kun til de medarbejdere, som faktisk skal bruge Odoo. Unødvendige brugerkonti øger administrationsbyrden og sikkerhedsrisiko.
  • Byg organisationsstrukturen korrekt med parent_id, startende fra topniveau og ned, så godkendelseskæder og rapporter bliver konsistente.
  • Sæt resource_calendar_id konsekvent for at sikre korrekte arbejdstidsberegninger og ferieallokeringer på tværs af systemet.
  • Ved API-integrationer brug XML-RPC eller JSON-RPC. hr.employee er tilgængelig via Odoos API — pas på mapping af eksterne ID'er for at undgå duplikater.
  • Brug x_-prefix eller dit modulnavn som præfiks på tilpassede felter for at undgå navnekonflikter ved fremtidige Odoo-opgraderinger.
  • Feltadgang bør begrænses med grupper (fx hr.group_hr_user). Følsomme HR-felter må ikke blive præsenteret eller prefetched til brugere uden de rette rettigheder.

Almindelige fejl


  • Opret ikke dubletter: tjek eksisterende poster før oprettelse. Brug felter som work_email eller identification_id til match og deduplikering.
  • Forstå forskellen på user_id og related_partner_id: user_id er til login/brugerkonto; related_partner_id er kontaktposten i res.partner til eksternt brug.
  • Glem ikke at sætte employee_type — det er et obligatorisk valg og påvirker hvordan kontrakter og historik håndteres.
  • Husk altid at kalde super() når du overskriver kernemetoder; undladelse kan bryde andre moduler eller gøre fremtidige opgraderinger problematiske.
  • Undgå at tilføje krævede custom-felter uden at give standardværdier — ellers fejler eksisterende poster ved opdatering.
  • Eksponer aldrig følsomme HR-felter til alle brugere. Brug adgangsgrupper til at beskytte persondata og overholde GDPR-praksis.

Afslutning


hr.employee er kernen i Odoos HR-funktionalitet: den centraliserer medarbejderdata og knytter dem sammen med kontrakter, tilstedeværelse og fravær. Kendskab til felterne og hvordan moduler bygger videre på modellen gør konfiguration og integration langt lettere.


Uanset om du kortlægger HR-processer som konsulent eller udvikler tilpasninger, sparer et solidt kendskab til hr.employee tid og forhindrer fejl i implementeringen.

Brug for hjælp til din Odoo-implementering?


Dasolo hjælper virksomheder med implementering, tilpasning og optimering af Odoo. Vi har særlig ekspertise i API-integrationer og udvikling omkring Odoos datamodel og HR-moduler som hr.employee.


Har du behov for hjælp til Odoo-implementering, skræddersyede HR-moduler eller integrationer, tilbyder vi support og projektrådgivning. Book en demo for at tale om dit projekt.

Forstå hr.employee-modellen: Odoo's medarbejderarkitektur forklaret
Dasolo 11. marts 2026
Del dette indlæg
Log ind for at skrive en kommentar