Inledning
I Odoo organiseras all affärsdata i modeller — de är mallarna som bestämmer hur information lagras i databasen. Kundregister, fakturor, offerter och kontakter är inte fristående filer utan poster i en modell, och modellen avgör både struktur och beteende.
Att förstå Odoo-modeller är lika viktigt för konsulter som för utvecklare. Modellerna ligger till grund för datamodellen: de beskriver fälten, relationerna mellan poster och den affärslogik som styr hur data valideras och processas.
Den här genomgången fokuserar på en av de mest centrala modellerna i Odoo: res.partner. Oavsett om du bygger anpassade moduler, kopplar externa system eller sätter upp arbetsflöden kommer du ofta att hamna hos denna modell.
Vad är modellen res.partner
Modellen res.partner är Odoos samlingsplats för alla slags kontakter — privatpersoner, kunder, leverantörer och juridiska enheter. Alla uppgifter om parter sparas här eller pekar tillbaka hit.
res.partner används i praktiskt taget alla kärnmoduler. Sälj, CRM, bokföring, inköp och e-handel refererar till partnerposter. När du skapar en kund, lead eller leverantör skapas eller länkas en res.partner-post.
Basdefinitionen ligger i base-modulen och fler moduler kompletterar den via arv. CRM adderar fält för leads, ekonomi lägger till betalningsvillkor och kreditinformation — varje modul bygger på kärnstrukturen utan att duplicera den.
Viktiga fält i modellen
Nedan listas de viktigaste fälten i res.partner. Kännedom om dem underlättar både konfiguration, utveckling och integrationer.
1. name
Typ: Char. Visningsnamn för posten — företagsnamn för en organisation eller fullständigt namn för en person. Används i listor, vyer och som huvudsaklig identifierare för partnern.
2. create_date
Typ: Datetime. Tidpunkt då posten skapades. Odoo sköter detta automatiskt och det är värdefullt för rapportering och spårbarhet.
3. write_date
Typ: Datetime. Tidpunkt för senaste uppdatering. Hjälper att avgöra när information senast ändrades och används i revisionssammanhang.
4. email
Typ: Char. Primär e‑postadress för kommunikation och portalåtkomst. Odoo försöker validera formatet för att minska felaktigheter.
5. phone
Typ: Char. Huvudnummer för företags- eller kontaktsamtal. Visas i kontaktkort och används i kommunikationsflöden.
6. mobile
Typ: Char. Mobilnummer för SMS‑aviseringar eller snabba kontakter när det skiljer sig från huvudnumret.
7. street
Typ: Char. Första raden i adressen — används i dokument, fraktsedlar och kundkort.
8. street2
Typ: Char. Andra adressraden för lägenhet, våningsplan eller ytterligare information.
9. city
Typ: Char. Stad eller ort. Formatet kan variera beroende på lokal praxis och land.
10. zip
Typ: Char. Postnummer som används vid validering, fraktberäkningar och adressering.
11. state_id
Typ: Many2one (res.country.state). Delstat eller region, normalt filtrerad efter land. Många länder använder inte detta fält.
12. country_id
Typ: Many2one (res.country). Land valt för adressformat, skattelagstiftning och lokalisering.
13. is_company
Typ: Boolean. Visar om posten är ett företag eller en privatperson. Företag kan ha underkontakter; personer kan kopplas till ett moderföretag via parent_id.
14. parent_id
Typ: Many2one (res.partner). Länkar en kontakt till dess företag. Möjliggör hierarki där kontakt är ett barn till en företags-post och många fält kan ärvas från föräldern.
15. child_ids
Typ: One2many (res.partner). Invers relationen till parent_id — listar alla kontakter associerade med ett företag och används för navigation mellan företag och dess kontakter.
16. company_id
Typ: Many2one (res.company). Vid multi‑company anger detta vilken juridisk enhet i Odoo posten tillhör och påverkar synlighet och åtkomstregler.
17. vat
Typ: Char. Momsregistreringsnummer eller skattenummer. Valideras efter landsformat och viktigt för fakturering och efterlevnad. En särskild notation kan användas för undantagna parter.
18. customer_rank
Typ: Integer. Anger om partnern har kundrelationer — Odoo ökar värdet när försäljning sker. Används för filtrering och prioritering i listor.
19. supplier_rank
Typ: Integer. Visar om partnern fungerar som leverantör — ökas vid inköp eller leverantörsfakturor. Underlättar identifiering av leverantörer.
20. user_id
Typ: Many2one (res.users). Ansvarig säljare eller kontaktperson. Viktigt för CRM‑hantering, uppdragsfördelning och rapporter.
21. type
Typ: Selection. Adresstyp för barnkontakter: Kontakt, Faktura, Leverans eller Övrigt. Bestämmer vilken adress som används i dokument och utskick.
22. ref
Typ: Char. Intern referenskod. Bra för kartläggning mot externa system och för egna nummerserier.
23. website
Typ: Char. Webbadress som visas i kontaktkort och e‑handelsflöden.
24. comment
Typ: Html. Interna anteckningar och kommentarer synliga för kollegor — användbart för säljanteckningar eller speciella instruktioner.
25. active
Typ: Boolean. Mjukarkiveringsflagga — sätts False för att gömma poster utan att ta bort dem fysiskt från databasen.
26. lang
Typ: Selection. Föredraget språk för kommunikation. Används för att skicka dokument eller e‑post på rätt språk, ofta ärvt från föräldraposten.
27. image_1920
Typ: Binary. Bild eller logotyp för partnern. Odoo genererar flera storlekar och bilden används i formulär, rapporter och på webbplatsen.
28. category_id
Typ: Many2many (res.partner.category). Taggar eller kundsegmentering — praktiskt för målgruppsinriktad marknadsföring och filtrering.
Användningsområden i företagsflöden
1. Sälj och CRM
När en säljare skapar en offert väljer hen kunden från res.partner — samma post följer genom säljprocessen från lead till order. customer_rank och user_id styr rapporter, uppföljning och ansvarsfördelning.
2. Fakturering
Fakturor refererar partnern för fakturaadress och momsuppgifter. VAT‑fältet påverkar skatteberäkningar och partnerns kreditgräns samt betalningsvillkor används vid bokföring.
3. Inköp och leverantörer
Inköpsorder och leverantörsfakturor pekar på res.partner. supplier_rank hjälper att identifiera aktiva leverantörer och fält som buyer_id kan ange ansvarig inköpare.
4. E‑handel och portal
Webbplatsbesökare som registrerar sig skapar partnerposter som används för beställningar, offersystem och portalåtkomst — alla kontakter och adresser hämtas från partnern.
5. Multi‑company och konsolidering
I multi‑company‑miljö kan samma juridiska kund representeras av olika partnerposter per företag. company_id och interna regler avgör vad som synkas och vilka poster som delas.
Hur utvecklare bygger på modellen
Utvecklare bygger ut res.partner med olika mönster där arv är det vanligaste verktyget.
Modellarv
Använd _inherit = 'res.partner' för att utöka modellen. Du kan lägga till fält, skriva om metoder eller lägga in valideringar — ändringarna hålls i separata moduler vilket underlättar uppgraderingar och underhåll.
Att lägga till fält
Definiera nya fält i din ärvda modell med rätt typ (Char, Many2one, Boolean, Integer, Text, Selection). Tänk på företagsberoende fält vid multi‑company för att undvika dubbletter och konflikter.
Python‑förlängningar
Skriv över create, write eller unlink för att införa affärslogik — använd super() för att behålla standardbeteendet. Var försiktig med beräknade fält och deras beroenden så du inte introducerar prestandaproblem.
Odoo Studio
Odoo Studio låter dig snabbt lägga till fält utan kod — utmärkt för snabba ändringar. För komplexa krav eller långsiktig portabilitet är kodbaserade moduler dock oftare att föredra.
God praxis
- Praktiska tips: skapa företaget först och lägg sedan till kontakter med parent_id för att etablera hierarkin korrekt.
- Sätt alltid country_id för att få rätt adressformat och skattelogik beroende på land.
- Använd commercial_partner_id när du behöver gruppera transaktioner eller kreditinformation på det översta juridiska nivån.
- Vid integrationer: använd XML‑RPC eller JSON‑RPC mot Odoo API. res.partner är fullständigt exponerad — matcha externa ID noggrant för att undvika dubbletter.
- Vid egna fält: använd x_‑prefix eller ett modulprefix för att minska risk för framtida krockar med kärnfunktionalitet.
Vanliga misstag
- Att skapa dubblettposter i stället för att söka upp existerande — använd email_normalized eller ref för att deduplicera innan du skapar nya poster.
- Att blanda ihop parent_id och company_id — parent_id binder kontakt till företag, medan company_id styr vilket Odoo‑bolag posten tillhör i multi‑company‑scenarion.
- Att glömma sätta type på underkontakter — fel typ gör att leverans‑ eller fakturaadresser inte plockas rätt i dokument.
- Att skriva över kärnmetoder utan att anropa super() — kan bryta kompatibilitet med andra moduler och framtida Odoo‑uppgraderingar.
- Att lägga till obligatoriska egna fält utan att ange standardvärden — det gör att befintliga poster kan misslyckas vid validering efter installation eller uppgradering.
Sammanfattning
res.partner är hjärtat i Odoos kontakt- och partshantering. En god förståelse för dess fält och hur andra moduler kompletterar modellen hjälper dig att konfigurera, utveckla och integrera systemet smidigare.
Oavsett om du kartlägger processer som konsult eller bygger funktionalitet som utvecklare — tid investerad i att bemästra res.partner ger färre fel och snabbare leveranser.
Behöver du hjälp med din Odoo‑implementering?
Dasolo hjälper företag att implementera, anpassa och optimera Odoo. Vi är specialiserade på API‑integrationer och skräddarsydd utveckling, med bred erfarenhet av Odoos datamodell och centrala modeller som res.partner.
Behöver du stöd med anpassade moduler, integrationer eller implementationen i stort — vi kan hjälpa till. Boka en demo för att diskutera ditt projekt.