Indledning
I Odoo organiseres al forretningsdata i modeller — de bestemmer, hvordan information gemmes, hvilke felter der findes, og hvordan poster hænger sammen. Hver kunde, leverandør, ordre eller kontakt bor i en model og er dermed let at genfinde og genbruge på tværs af systemet.
For både udviklere og konsulenter er forståelsen af Odoo-modeller afgørende. Modeller udgør fundamentet i datalaget: de fastlægger felter, relationer og den forretningslogik, der sikrer konsistens i hele løsningen.
Denne guide zoomer ind på en af de mest centrale modeller i Odoo: res.partner. Uanset om du opsætter workflows, bygger integrationer eller udvikler tilpasninger, vil du ofte møde og arbejde med denne model.
Hvad er res.partner-modellen
res.partner er Odoos samlede register for personer og virksomheder — kunder, leverandører og andre forretningspartnere. Her samles kontaktoplysninger, faktureringsdata og relationer, så alle moduler kan bruge de samme oplysninger.
Modellen bruges på tværs af næsten alle moduler: salg, CRM, økonomi, indkøb og webshoppe trækker alle på res.partner. Når du opretter en kunde, en leverandør eller en kontakt, oprettes eller linkes der til en res.partner-post.
Selve definitionen ligger i base-modulet, mens andre moduler tilføjer felter og regler via Odoos arve-mekanisme. CRM udvider eksempelvis med lead-felter, regnskab tilføjer kredit- og betalingsbetingelser — alt sammen uden at duplikere kerne-strukturen.
Vigtige felter i modellen
Nedenfor finder du de felter i res.partner, som oftest er relevante i praksis. Kendskab til disse gør det lettere at konfigurere formularer, integrationer og rapporter korrekt.
1. name
Type: Char. Partnerens visningsnavn — virksomhedens navn eller en persons fulde navn. Bruges som hovedidentifier i lister og formularer.
2. create_date
Type: Datetime. Tidspunkt for oprettelse. Odoo sætter dette automatisk og det er nyttigt til rapportering og revision.
3. write_date
Type: Datetime. Sidste ændringstidspunkt. Hjælper med at spore, hvornår data sidst blev opdateret.
4. email
Type: Char. Primær e-mailadresse til kommunikation, fakturering og portaladgang. Odoo forsøger at validere formatet.
5. phone
Type: Char. Hovedtelefonnummer, vist i kontaktkort og brugt i kommunikationsflows.
6. mobile
Type: Char. Mobilnummer, ofte brugt til SMS-notifikationer eller hurtig kontakt.
7. street
Type: Char. Første adressefelt — bruges på dokumenter og i adresseblokke.
8. street2
Type: Char. Andet adressefelt til lejlighedsnummer, etage eller supplerende information.
9. city
Type: Char. By eller lokalitet. Format og validering kan variere mellem lande.
10. zip
Type: Char. Postnummer, bruges til validering og til beregning af forsendelsespriser.
11. state_id
Type: Many2one (res.country.state). Region eller delstat. Udvalget filtreres efter land — ikke alle lande benytter dette felt.
12. country_id
Type: Many2one (res.country). Landet. Påvirker adresseformat, skatteregler og lokal tilpasning.
13. is_company
Type: Boolean. Angiver om posten er en virksomhed eller en privatperson. Virksomheder kan have underkontakter; personer kan peges mod en virksomhed via parent_id.
14. parent_id
Type: Many2one (res.partner). Peger en kontakt mod en overordnet virksomhed, så adresse og visse felter kan arves og hierarkier opbygges.
15. child_ids
Type: One2many (res.partner). Invers relationen til parent_id — viser alle kontakter under en virksomhed.
16. company_id
Type: Many2one (res.company). Angiver hvilken Odoo-virksomhed posten hører til i multi-company-miljøer. Påvirker synlighed og rettigheder.
17. vat
Type: Char. CVR/VAT-nummer. Valideres ofte efter landets format og er centralt for fakturering og compliance.
18. customer_rank
Type: Integer. Brugerresumé for kundeaktivitet — øges når der oprettes salg. Giver et hurtigt indblik i hvem der er aktive kunder.
19. supplier_rank
Type: Integer. Lignende for leverandører — øges ved indkøb eller leverandørfakturaer, og hjælper med at identificere leverandørrelationer.
20. user_id
Type: Many2one (res.users). Den ansvarlige sælger eller bruger — bruges i CRM, salgsteam og til opgavefordeling.
21. type
Type: Selection. Adresse-type på underkontakter: Kontakt, Faktura, Levering eller Andet. Bestemmer hvilken adresse der anvendes på dokumenter.
22. ref
Type: Char. Internt referencefelt eller ekstern kode — nyttigt ved integration og unik identifikation.
23. website
Type: Char. Webadresse, vist i kontaktkort og relevant for e-handel.
24. comment
Type: Html. Interne noter til brugere — salgskommentarer, instrukser eller historik.
25. active
Type: Boolean. Arkiveringsflag — sat til False skjuler posten fra standardvisninger uden at slette data.
26. lang
Type: Selection. Foretrukket sprog for kommunikation og dokumenter; kan arves fra overordnet enhed.
27. image_1920
Type: Binary. Billedfil eller logo for partneren — bruges i formularer, rapporter og på hjemmesider.
28. category_id
Type: Many2many (res.partner.category). Tags eller segmenter til filtrering og marketing, fleksibelt til klassifikation.
Hvordan modellen bruges i forretningsprocesser
1. Salg og CRM
Salgsteamet vælger kunder fra res.partner, og samme partner følger igennem fra lead over tilbud til ordre. Felter som customer_rank og user_id styrer rapportering og ansvarfordeling.
2. Fakturering
Fakturaer og leverandørfakturaer peger på partnerens faktureringsadresse. VAT-feltet bruges i skattemæssige beregninger, mens betalingsbetingelser og kreditgrænser ofte gemmes på partneren.
3. Indkøb og leverandører
Indkøbsordrer og leverandørfakturaer refererer til res.partner. Supplier_rank gør det nemt at finde aktive leverandører, og buyer_id tildeler ansvar for leverandørstyring.
4. E-handel og portal
Webshopbrugere oprettes typisk som partnere, så ordrer, tilbud og portaladgang binder sig til samme partnerpost. Adresse- og kontaktdata kommer direkte fra partneren.
5. Multi-company og konsolidering
I multi-company-miljøer kan samme juridiske enhed optræde som flere partnerposter på tværs af selskaber. company_id og inter-company-regler bestemmer, hvilke data der deles.
Hvordan udviklere udvider modellen
Udviklere udvider res.partner med flere metoder, men fællesnævneren er Odoos arve-mønster og velstrukturerede ændringer.
Modelarv
Ved at bruge _inherit = 'res.partner' kan du tilføje felter, ændre metoder og opstille constraints i en separat modulpakke — det gør ændringerne mere vedligeholdbare i takt med opgraderinger.
Tilføje felter
Definér nye felter i din arvemodel med korrekt datatype: Char, Many2one, Boolean, Integer, Text eller Selection. Overvej selskabsspecifikke felter i multi-company-scenarier.
Python-udvidelser
Override create, write eller unlink for at indsætte forretningslogik, men kald altid super() hvor nødvendigt. Vær opmærksom på afhængigheder i beregnede felter for at undgå inkonsistens.
Odoo Studio
Odoo Studio er praktisk til hurtige tilpasninger uden kode, men til komplekse workflows og langsigtede løsninger er et egentligt modul ofte mere robust og vedligeholdelsesvenligt.
Gode fremgangsmoldeller
- Praktisk tip: opret først virksomheden og tilknyt derefter kontakter via parent_id, så hierarkiet bliver korrekt.
- Sørg altid for at sætte country_id rigtigt — det påvirker adresseformat og skattemæssige regler.
- Brug commercial_partner_id når du skal arbejde med topniveau-enheden, fx ved kreditstyring eller koncernrapportering.
- Ved API-integrationer benyt XML-RPC eller JSON-RPC — res.partner er fuldt tilgængelig, men sørg for entydig mapping af eksterne id'er.
- Giv brugerdefinerede felter et x_ eller modulpræfiks for at undgå navnekonflikter ved fremtidige Odoo-opgraderinger.
Almindelige fejl
- At oprette dubletter i stedet for at søge eksisterende partnere. Benyt felter som email_normalized eller ref i dedupliceringslogik.
- At forveksle parent_id og company_id. parent_id knytter kontakt til virksomhed; company_id angiver i hvilken Odoo-virksomhed posten tilhører.
- At glemme at sætte type på underkontakter. Faktura- og leveringsadresser skal have korrekt type for at blive brugt på dokumenter.
- At overskrive kernemetoder uden at kalde super(). Det kan bryde funktionalitet i eksisterende eller fremtidige moduler.
- At tilføje påkrævede felter uden standardværdier. Eksisterende poster kan ellers fejle validering efter opgraderinger.
Afrunding
res.partner er kernen i Odoos kundeleverandør-økosystem. Når du forstår de vigtigste felter og hvordan moduler bygger videre på modellen, bliver det langt nemmere at sætte systemet op, skabe integrationer og undgå fejl.
Uanset om du kortlægger forretningsprocesser som konsulent eller udvikler funktionalitet, vil et solidt kendskab til res.partner spare tid og reducere risici i dine Odoo-implementeringer.
Brug for hjælp til din Odoo-implementering?
Dasolo hjælper virksomheder med at implementere, tilpasse og optimere Odoo. Vi specialiserer os i API-integrationer og skræddersyet udvikling og har indgående erfaring med Odoos datamodel og nøgler som res.partner.
Har du brug for støtte til implementering, udvikling af moduler eller integrationer, står vi klar til at hjælpe. Book en demo for at drøfte dit projekt.