Introduktion
I Odoo beskriver modeller hur information organiseras och sparas i databasen. All affärsdata — från order och fakturor till anställningsuppgifter — lever i modeller som definierar strukturen och formatet för varje typ av post.
Att förstå modeller är grundläggande både för utvecklare och funktionella konsulter. Modellerna är själva stomme i Odoo:s datalager: fälten, relationerna och affärslogiken utgår från modellernas definitioner.
Den här texten koncentrerar sig på en central modell i HR‑modulen: hr.employee. Oavsett om du sätter upp onboarding, löneintegrationer eller närvarohantering kommer du ofta att möta den här modellen.
Vad är modellen hr.employee
Modellen hr.employee är Odoos representation av en medarbetare — samlingspunkten för personuppgifter, kontaktuppgifter och kopplingar till andra HR‑funktioner.
hr.employee ingår i HR‑appen och används av flera delar: närvaro, ledighet, anställningsavtal, lönehantering och tidrapportering.
Modulen Employees installeras för att aktivera modellen. Andra moduler bygger på samma kärnmodell via Odoos arvsmönster: hr_contract lägger till avtal, hr_attendance hanterar in‑ och utstämpling, hr_leave sköter ledighet. På så vis kompletteras kärnstrukturen utan att duplicera grunddata.
Odoo erbjuder även hr.employee.public — en avskalad vy med begränsad åtkomst för användare som bara behöver se vissa uppgifter. Det är ett exempel på hur modell‑arv och abstraktion används för att kontrollera synlighet.
Viktiga fält i modellen
Nedan följer de nyckelfält i hr.employee som du oftast kommer att arbeta med. Att känna till dem underlättar konfiguration, rapportering och integrationer.
1. name
Typ: Char. Medarbetarens namn. Visas i de flesta vyer och fungerar som huvudidentifierare för posten.
2. create_date
Typ: Datetime. Tidpunkt då posten skapades. Hanteras automatiskt och är viktigt för revision och historik.
3. write_date
Typ: Datetime. Tidpunkt för senaste ändring. Automatiskt uppdaterad; hjälper dig spåra när information senast uppdaterades.
4. active
Typ: Boolean. Mjuk arkivering av poster. När den är False döljs posten i standardvyer istället för att tas bort permanent — användbart vid uppsägningar.
5. company_id
Typ: Many2one (res.company). Anger vilken koncern/enhet medarbetaren tillhör i multi‑company‑miljöer. Krävs i de flesta fall för att undvika fel i transaktioner.
6. user_id
Typ: Many2one (res.users). Kopplar medarbetaren till en Odoo‑användare. Ger inloggning, åtkomst till portal/medarbetargränssnitt och används i godkännande‑flöden.
7. work_email
Typ: Char. Arbetsmejl för intern kommunikation och aviseringar.
8. work_phone
Typ: Char. Arbetsnummer som visas i personalformulär och kontaktlistor.
9. mobile_phone
Typ: Char. Mobilnummer för snabba meddelanden eller nödkontakter.
10. department_id
Typ: Many2one (hr.department). Avdelningen personen tillhör — viktigt för organisationskartor, rapporter och godkännandesteg.
11. job_id
Typ: Many2one (hr.job). Koppling till tjänstetyp eller befattning som definieras i hr.job.
12. job_title
Typ: Char. Friformulering av titel som kan användas vid behov istället för eller tillsammans med job_id.
13. parent_id
Typ: Many2one (hr.employee). Chef/lina‑relation som bygger upp hierarkin för godkännanden och organisationsvy.
14. coach_id
Typ: Many2one (hr.employee). Utvecklingscoach eller handledare — används i prestationshantering utan att ge särskilda rättigheter som standard.
15. resource_id
Typ: Many2one (resource.resource). Koppling till resursmodellen för planering, beläggningsstyrning och kalenderintegration.
16. work_contact_id
Typ: Many2one (res.partner). Kontaktpost för arbetsrelaterade dokument och kommunikation.
17. address_id
Typ: Many2one (res.partner). Registrerad arbetsadress kopplad till en partnerpost.
18. address_home_id
Typ: Many2one (res.partner). Privat adress — relevant för lönehantering och i nödfall.
19. resource_calendar_id
Typ: Many2one (resource.calendar). Medarbetarens arbetsschema — påverkar frånvaroberäkningar och närvarorapportering.
20. employee_type
Typ: Selection. Typ av medarbetare (t.ex. tillsvidare, konsult, praktikant). Påverkar hur avtal och historik hanteras.
21. barcode
Typ: Char. ID för badge eller skanning i närvarokiosk.
22. pin
Typ: Char. PIN‑kod som används i kioskläge för stämpling och i vissa POS‑scenarier.
23. birthday
Typ: Date. Födelsedatum för HR‑register och eventuella påminnelser.
24. identification_id
Typ: Char. Personnummer eller annan nationell identifierare för compliance och lönehantering.
25. passport_id
Typ: Char. Passnummer för resor och uppehålls/tillståndsärenden.
26. bank_account_id
Typ: Many2one (res.partner.bank). Konto för utbetalning av lön.
27. private_email
Typ: Char. Personlig e‑postadress om arbetsmejl saknas.
28. phone
Typ: Char. Privat telefonnummer, skilt från arbetskontaktuppgifter.
29. contract_id
Typ: Many2one (hr.contract). Pekar på det aktuella anställningsavtalet.
30. contract_ids
Typ: One2many (hr.contract). Hela avtalshistoriken kopplad till medarbetaren.
31. image_1920
Typ: Binary. Profilbild/avat ar i högupplöst format som visas i kataloger och rapporter.
32. related_partner_id
Typ: Many2one (res.partner). Partnerpost kopplad till medarbetaren för CRM och extern kommunikation.
33. leave_manager_id
Typ: Many2one (res.users). Användaren som godkänner ledighetsansökningar; om tomt faller godkännandet tillbaka till administratör eller definierad beslutsfattare.
34. expense_manager_id
Typ: Many2one (res.users). Ansvarig för utläggsgodkännande.
35. timesheet_manager_id
Typ: Many2one (res.users). Ansvarig för att godkänna tidrapporter.
Hur modellen används i affärsflöden
1. Personalregister och onboarding
När HR skapar en ny medarbetare registreras grunduppgifter i hr.employee: namn, avdelning, befattning, chef och kontaktuppgifter. Länken till user_id sätts först när personen behöver inloggning i Odoo.
2. Närvaro och tidrapportering
Närvaro registreras i Attendance‑appen och kopplas till hr.employee via hr.attendance. Fält som barcode och pin möjliggör kiosk‑stämpling för snabba in/ut‑skrivningar.
3. Ledighet och frånvaro
Ledighetsansökningar refererar till medarbetaren och styrs av fält som leave_manager_id och resurskalendern för att avgöra vem som godkänner och hur många dagar som påverkas.
4. Lönehantering och avtal
Lön och avtal använder hr.employee för att hämta lönestruktur, bankkonto och avtalskopplingar. contract_id pekar på det aktuella avtalet medan contract_ids bevarar historik.
5. Tidrapportering och projektallokering
När tid rapporteras mot projekt kopplas den till medarbetaren. timesheet_manager_id ansvarar för godkännande och resource_id kopplar ihop med planering och beläggningsverktyg.
Hur utvecklare bygger ut modellen
Utvecklare bygger ut hr.employee med flera mönster där Odoos arv är det vanligaste och mest robusta sättet att lägga till funktionalitet.
Modellarv
I din modul använder du _inherit = 'hr.employee' för att lägga till fält, överköra metoder eller sätta valideringar. Genom att hålla ändringar i separata moduler blir uppgraderingar och underhåll smidigare.
Lägga till fält
Definiera nya fält i din ärvda modell med lämplig typ: Char, Many2one, Boolean, Integer, Text, Selection med mera. Tänk på företagsspecifika fält i multi‑company‑installationer.
Python‑utökningar
Skriv om create, write eller unlink för att lägga in affärslogik, men anropa alltid super() där det behövs. Var extra försiktig med beräknade fält och deras beroenden så att uppdateringar sker korrekt.
Odoo Studio
Odoo Studio är snabbt för att lägga till fält utan kod — bra för prototyper. För komplex logik eller när du planerar uppgraderingar är en anpassad modul oftast mer hållbar.
Rekommenderade arbetssätt
- Skapa user_id endast för de som verkligen behöver inloggning. Var restriktiv — inte alla anställda behöver ett användarkonto.
- Använd parent_id korrekt för att bygga organisationsstrukturen uppifrån och ner — det underlättar godkännande‑flöden och rapporter.
- Sätt resource_calendar_id för att få konsekventa arbetstider och korrekta beräkningar av semester och frånvaro.
- Vid API‑integrationer använd XML‑RPC eller JSON‑RPC. hr.employee exponeras fullt i Odoo:s API, men mappa externa ID:n noggrant för att undvika dubletter.
- För egna fält rekommenderas x_‑prefix eller modulprefix på fältnamn för att undvika namnkonflikter vid framtida Odoo‑uppgraderingar.
- Fält som innehåller känslig HR‑data bör skyddas med grupper (t.ex. hr.group_hr_user) så att de inte förprefetchas eller syns för obehöriga användare.
Vanliga misstag
- Att skapa dubblettposter istället för att söka upp existerande är vanligt. Använd work_email, identification_id eller andra unika fält för deduplicering.
- Blanda inte ihop user_id och related_partner_id — den förstnämnda ger inloggning, den sistnämnda är kontaktposten för extern kommunikation.
- Glöm inte att ange employee_type — fältet är viktigt och påverkar hur avtal och historik hanteras.
- Att override:a kärnmetoder utan att kalla super() riskerar att störa andra moduler eller orsaka problem vid uppgraderingar.
- Att lägga till obligatoriska fält utan standardvärden kan göra att befintliga poster inte validerar vid uppgradering — ange lämpliga defaults.
- Exponera inte känsliga HR‑fält för användare utan hr.group_hr_user. Använd fält‑gruppering för att behålla sekretess.
Sammanfattning
hr.employee är navet i Odoos HR‑funktionalitet. Den lagrar medarbetarinfo och länkar ihop avtal, närvaro och ledighet. Att förstå dess fält och hur andra moduler bygger vidare på den gör det enklare att konfigurera, anpassa och integrera systemet.
Oavsett om du kartlägger HR‑processer som konsult eller utvecklar skräddarsydd funktionalitet sparar du tid och undviker fel om du har god koll på hr.employee.
Behöver du hjälp med din Odoo-implementation?
Dasolo hjälper företag att implementera, anpassa och optimera Odoo. Vi är specialiserade på API‑integrationer och utveckling med djup erfarenhet av Odoo‑datamodeller som hr.employee.
Behöver du stöd för Odoo‑implementation, anpassade HR‑moduler eller integrationer — hör av dig så hjälper vi till. Boka en demo för att diskutera ditt projekt.