Introductie
In Odoo bepaalt een model de manier waarop bedrijfsdata gestructureerd en opgeslagen wordt. Alles wat je in je organisatie bijhoudt — klanten, leveranciers, offertes, facturen — staat in een model als res.partner.
Kennis van Odoo-modellen is cruciaal voor zowel consultants als ontwikkelaars. Modellen vormen de ruggengraat van Odoo: ze definiëren velden, relaties en de logica die data valideert en manipuleert.
Dit artikel zoomt in op een van de pijlers van Odoo: het res.partner-model. Of je nu maatwerk modules bouwt, koppelt met externe systemen of workflows inricht, je komt dit model voortdurend tegen.
Wat is het res.partner-model
res.partner is het centrale object voor contacten: klanten, leveranciers, prospecten en bedrijfsentiteiten. Alle partijgegevens — adressen, communicatiegegevens en identificatie — worden hier bijeengehouden.
Je vindt res.partner terug in vrijwel alle kernmodules. Verkoop, CRM, boekhouding, aankoop en webshops gebruiken dezelfde partnerrecords — een klant in Verkoop is hetzelfde entiteit als een klant in CRM of een leverancier in Inkoop.
Het basismodel staat in de base-module; andere modules breiden het uit via Odoo-inheritance. Zo voegt CRM velden voor leads toe en boekhouding velden voor betalingstermijnen — zonder het onderliggende model te dupliceren.
Belangrijke velden in het model
Onderstaand overzicht behandelt de kerneigenschappen van res.partner. Als je deze velden begrijpt, werk je veel efficiënter met contacten en partners in Odoo.
1. name
Type: Char. De weergavenaam van de partner; bij bedrijven de bedrijfsnaam, bij natuurlijke personen de volledige naam. Dit is het belangrijkste identificatieveld dat in lijsten en formulieren getoond wordt.
2. create_date
Type: Datetime. Tijdstip van aanmaak van het record. Odoo vult dit automatisch in en het is handig voor rapportage en audits.
3. write_date
Type: Datetime. Tijdstip van de laatste wijziging. Ook automatisch bijgehouden; nuttig om te zien wanneer informatie voor het laatst bijgewerkt werd.
4. email
Type: Char. Primaire e-mailcontact. Wordt gebruikt voor communicatie, portaltoegang en facturatie. Odoo probeert het formaat te valideren.
5. phone
Type: Char. Vast telefoonnummer of algemeen contactnummer. Vervult een zichtbare plaats in het contactformulier en workflowmeldingen.
6. mobile
Type: Char. Mobiel nummer, vaak gebruikt voor sms-berichten of dringende meldingen die afwijken van het hoofdnummer.
7. street
Type: Char. Eerste regel van het adres; onderdeel van het standaard adresblok dat op documenten verschijnt.
8. street2
Type: Char. Tweede adresregel voor verdieping, gebouwnaam of extra aanwijzingen.
9. city
Type: Char. Plaats of gemeente. Het adresformaat kan per land verschillen.
10. zip
Type: Char. Postcode. Belangrijk voor adresvalidatie en verzendkostencalculaties.
11. state_id
Type: Many2one (res.country.state). Provincie of staat; de selectie wordt gefilterd op basis van het gekozen land. Niet elk land gebruikt dit veld.
12. country_id
Type: Many2one (res.country). Landkeuze beïnvloedt adresformaten, btw-regels en lokale instellingen.
13. is_company
Type: Boolean. Geeft aan of het record een bedrijf of een persoon betreft. Bedrijven kunnen subcontacten hebben; personen kunnen een parent_id hebben naar hun werkgever.
14. parent_id
Type: Many2one (res.partner). Verwijzing naar het hoofdbedrijf voor contactrecords. Gebruikt om hiërarchieën te bouwen en om velden van de parent te erven.
15. child_ids
Type: One2many (res.partner). Omgekeerde relatie van parent_id: toont de contacten die aan een bedrijf gelinkt zijn.
16. company_id
Type: Many2one (res.company). In multi-company omgevingen bepaalt dit tot welke juridische of operationele company het partnerrecord behoort en wie het mag zien.
17. vat
Type: Char. BTW-nummer of fiscaal identificatienummer. Vaak gevalideerd volgens landformaat; cruciaal voor facturatie en compliance.
18. customer_rank
Type: Integer. Geeft aan of en hoe actief de partner als klant is — Odoo verhoogt deze waarde bij verkoopactiviteiten.
19. supplier_rank
Type: Integer. Zelfde idee als customer_rank maar dan voor leveranciers; toont actieve leveranciersrelaties.
20. user_id
Type: Many2one (res.users). Verantwoordelijke gebruiker of accountmanager; gebruikt in rapportering, teamtoewijzingen en activiteiten.
21. type
Type: Selection. Adrestype voor subcontacten: Contact, Invoice, Delivery of Other. Bepaalt welk adres op documenten wordt gebruikt.
22. ref
Type: Char. Interne referentie of code voor mapping met externe systemen of eigen nummering.
23. website
Type: Char. Website-URL; zichtbaar in het contactformulier en e-commercecontexten.
24. comment
Type: Html. Interne aantekeningen en commerciële opmerkingen. Alleen zichtbaar voor interne gebruikers.
25. active
Type: Boolean. Soft-delete vlag: uitgeschakelde partners worden gearchiveerd en komen niet in standaardlijsten voor.
26. lang
Type: Selection. Voorkeurstaal van de partner; documenten en mails kunnen automatisch in die taal worden verstuurd.
27. image_1920
Type: Binary. Logo of foto van de partner; Odoo bewaart verschillende resoluties voor gebruik in formulieren en op de website.
28. category_id
Type: Many2many (res.partner.category). Labels of segmenten voor marketing en filtering; flexibel in te zetten voor doelgroepindeling.
Hoe dit model in bedrijfsprocessen wordt gebruikt
1. Verkoop en CRM
Bij het aanmaken van een offerte of opportunity kiest de verkoper een partner uit res.partner. Datzelfde record volgt de lead doorheen het verkoopproces; customer_rank en user_id ondersteunen segmentatie en opvolging.
2. Facturatie
Facturen en leveranciersfacturen refereren aan een partner voor het factuuradres; vat speelt een rol bij belastingberekeningen en betaalvoorwaarden/limieten zitten vaak op het partnerrecord.
3. Aankoop en leveranciers
Inkooporders en leveranciersfacturen linken naar res.partner. Supplier_rank maakt actieve leveranciers zichtbaar en koperverantwoordelijken worden toegewezen via velden zoals buyer_id.
4. E‑commerce en portal
Websitegebruikers maken bij registratie vaak partnerrecords aan. Die data wordt gebruikt voor bestellingen, offertes en portaltoegang; adressen en contactgegevens komen rechtstreeks uit res.partner.
5. Multi-company en consolidatie
In multi-company omgevingen kan eenzelfde juridische entiteit als aparte partnerrecords per company bestaan. company_id en inter-company regels bepalen wat gedeeld wordt.
Hoe ontwikkelaars dit model uitbreiden
Ontwikkelaars breiden res.partner uit met verschillende technieken, waarbij Odoo’s model-inheritance centraal staat.
Model-inheritance
Zet _inherit = 'res.partner' om het bestaande model uit te breiden: voeg velden toe, override methodes, of definieer constraints. Zo blijven wijzigingen netjes in een apart modulepakket en zijn upgrades eenvoudiger.
Velden toevoegen
Voeg nieuwe Odoo-velden toe in je inherited model en kies het juiste type: Char, Many2one, Boolean, Integer, Text of Selection. Denk aan company-dependent velden in multi-company opzetten.
Python-extensies
Override methodes zoals create, write of unlink om bedrijfslogica toe te voegen. Roep altijd super() aan en let op computed fields en hun dependencies.
Odoo Studio
Odoo Studio biedt een codearme manier om velden en views toe te voegen — handig voor snelle aanpassingen. Voor complexere of onderhoudsgevoelige logica blijft een custom-module aan te raden.
Aanbevolen werkwijzen
- Maak de bedrijf–contact-hiërarchie correct aan: creëer eerst de hoofdorganisatie en link daarna de contactpersonen via parent_id.
- Stel country_id in voor correcte adresformaten en juiste belastinginstellingen.
- Gebruik commercial_partner_id wanneer je met groepsniveaus werkt (bv. voor kredietlimieten of consolidatierapporten).
- Voor API‑koppelingen gebruik je XML‑RPC of JSON‑RPC: res.partner is volledig beschikbaar via de API, maar map externe identifiers zorgvuldig.
- Voor custom velden gebruik je het
x_-prefix of een moduleprefix om botsingen met toekomstige Odoo-versies te vermijden.
Veelgemaakte fouten
- Partners dubbel aanmaken in plaats van te zoeken naar bestaande records. Gebruik velden zoals
email_normalizedofrefom te dedupliceren. - Verwarring tussen parent_id en company_id: parent_id koppelt contacten aan een bedrijf; company_id regelt multi-company toewijzing binnen Odoo.
- Vergeten het type in te stellen op subcontacten: factuur‑ of leveringsadressen moeten het juiste type hebben om op documenten te verschijnen.
- Core-methodes overschrijven zonder
super()aan te roepen — dat kan incompatibiliteiten met andere modules of upgrades veroorzaken. - Verplichte custom velden toevoegen zonder defaultwaarden: bestaande records kunnen dan falen bij validatie of upgrades.
Samenvatting
res.partner is een hoeksteen van Odoo: het beheert contacten, klanten en leveranciers. Begrijpen welke velden bestaan en hoe modules daarop uitbreiden, maakt configuratie, maatwerk en integratie een stuk vlotter.
Of je nu processen ontwerpt als consultant of modules bouwt als ontwikkelaar: een goede kennis van res.partner voorkomt fouten en bespaart implementatietijd.
Hulp nodig bij jouw Odoo‑implementatie?
Dasolo ondersteunt bedrijven bij implementatie, maatwerk en optimalisatie van Odoo. We specialiseren ons in API‑koppelingen en development en hebben diepe ervaring met de Odoo-datalaag en modellen zoals res.partner.
Heb je hulp nodig met implementatie, maatwerk of koppelingen? We helpen je graag. Plan een demo om je project te bespreken.