Introductie
Tijdens Odoo-implementaties valt één idee steeds terug: modellen bouwen niet alles opnieuw uit, ze lenen en delen waar mogelijk. Die filosofie voorkomt duplicatie en maakt het platform beheersbaar wanneer je functionaliteit uitbreidt.
Geërfde velden zijn de praktische uitwerking van die filosofie. Ze laten een model velden gebruiken die fysiek ergens anders staan, zonder dat je die velden opnieuw moet aanmaken of data gaat kopiëren.
In deze handleiding zetten we helder uiteen wat geërfde velden zijn, welke soorten modelinherentie in Odoo bestaan, hoe de gegevens in de database terechtkomen en hoe je die technieken in echte projecten inzet.
Wat is een geërfd veld in Odoo?
In Odoo spreek je van een geërfd veld zodra een model toegang krijgt tot een veld dat oorspronkelijk op een ander model gedefinieerd is via een van de beschikbare ervingsmechanismen. In plaats van het veld te dupliceren hergebruikt het kindmodel het bestaande veld.
Dat maakt het datamodel overzichtelijk: hetzelfde name-veld voor een contact is overal gelijk — op offertes, klantenkaarten en facturen — omdat alle modellen naar dezelfde bron verwijzen.
De drie vormen van erving in Odoo
Odoo kent drie manieren om modellen te laten erven, en elk van die vormen behandelt velden op een eigen manier.
1. Klassieke erving
Bij klassieke erving gebruik je _inherit zonder een nieuw _name op te geven. Je breidt een bestaand model rechtstreeks uit: nieuwe velden en methodes worden aan datzelfde model toegevoegd en er komt geen extra tabel in de database.
Dit is de standaardmanier waarop modules extra velden toevoegen aan Odoo-modellen. Installeer je CRM, dan voegt die module extra velden toe aan res.partner en die worden bewaard in diezelfde partnertabel.
2. Prototype-erwing
Combineer je _inherit wél met een nieuw _name, dan kopieer je structurallementen van het oudermodel naar een nieuw model met een eigen tabel. De velden van het oudermodel worden zo gedupliceerd in de nieuwe tabel; wijzigen van het kind verandert het oudermodel niet.
Deze aanpak zie je minder vaak bij eenvoudige aanpassingen, maar is handig als je een nieuw model wil maken dat qua structuur sterk op een bestaand model lijkt.
3. Delegatie-erwing
De meest karakteristieke vorm is _inherits. Het kindmodel bevat een Many2one-veld naar het oudermodel en toont alle oudervelden alsof ze van het kind zijn. De data blijft fysiek in de tabel van het oudermodel staan.
In de strikte zin spreken ontwikkelaars vaak over geërfde velden bij delegatie: die velden worden niet gekopieerd, maar via de relatie opgevraagd wanneer je ze leest of schrijft.
Een bekend voorbeeld is de koppeling tussen res.users en res.partner: een gebruiker is ook altijd een partner. Naam, e-mail en telefoon worden op de partner opgeslagen en via delegatie beschikbaar voor de gebruiker.
Hoe het veld werkt
Delegatie-erwing: wat gebeurt er precies
Bij gebruik van _inherits bouwt Odoo een transparante verbinding tussen twee tabellen. Lees je een geërfd veld op een kindrecord, dan volgt Odoo automatisch de Many2one-link en haalt de waarde uit het ouderrecord.
Schrijf je naar datzelfde veld vanaf het kindmodel, dan schrijft Odoo naar het ouderrecord. Voor de ontwikkelaar voelt het veld 'native' aan, maar in de database leeft de waarde in de tabel van het oudermodel.
Het praktische voordeel is dat er geen dubbele data ontstaat: pas je bijvoorbeeld de naam van een partner aan, dan zie je die wijziging meteen overal terug waar die partner gekoppeld is.
Klassieke erving en de database
Bij klassieke erving worden toegevoegde velden in de bestaande tabel van het model bijgeschreven. Er komt geen extra tabel. Database-technisch zijn het originele en het uitgebreide model hetzelfde — daarom is dit de meest elegante en gebruikte methode voor uitbreidingen.
Related-velden: lichte vorm van erving
Een related-veld is in Odoo een berekend veld dat zijn waarde leest via een keten van relationele velden. Het is geen modelerving op zich, maar wordt vaak gebruikt om gegevens van een ander model zichtbaar te maken zonder de structuur van het huidige model te wijzigen.
Bijvoorbeeld: op een verkooporder kun je een partner_country_id aanmaken die leest van partner_id.country_id. Het voelt aan als een veld op de verkooporder, maar de waarde komt van de partner.
Je kunt related-velden opslaan met store=True om zoeken en filteren te versnellen, maar dat kost extra opslag en vergt recomputatie zodra de bron verandert.
Hoe velden tijdens runtime worden opgelost
Bij het laden van modeldefinities bouwt Odoo een volledig veldenschema, inclusief alle geërfde velden. Voor gebruik is al vastgelegd waar elk veld vandaan komt — eigen tabel, ouder via delegatie of via een related-pad. Die mapping wordt bij serverstart berekend en gecachet voor betere prestaties.
Zakelijke toepassingsgebieden
Geërfde velden zijn niet alleen theorie; ze lossen echte businessproblemen op door data consistent en niet-duplicerend beschikbaar te maken in verschillende modules.
1. CRM en Verkoop: contactgegevens
Wanneer een verkoper een lead aanmaakt, komen naam, telefoon en e-mail van de gekoppelde partner via een Many2one-relatie. Een wijziging aan het partnerrecord wordt meteen zichtbaar op alle gerelateerde leads, offertes en bestellingen.
Hier werken klassieke uitbreiding en related-velden samen: CRM voegt partnergerelateerde attributen toe aan res.partner, terwijl verkooprecords contactinfo tonen via gerelateerde velden.
2. Producten en varianten
Productvarianten in Odoo gebruiken delegatie: product.product linkt naar product.template via _inherits. Algemene eigenschappen (naam, categorie, verkoopprijs, omschrijving) staan op het template, variant-specifieke gegevens op het variantrecord zelf.
Zo kun je tientallen kleurvarianten van een T-shirt hebben zonder naam en omschrijving telkens opnieuw in de database te bewaren.
3. Gebruikers en contacten
Elke gebruiker is ook een contact. Door _inherits = {'res.partner': 'partner_id'} ervaart res.users alle velden van res.partner. Een aanpassing van iemands e-mailadres verandert dus in zowel het gebruikersprofiel als in de contactenlijst.
4. Magazijn: voorraadbewegingen en productinformatie
Magazijnregels tonen productbeschrijvingen die via gerelateerde paden van het producttemplate komen. Logistiek personeel ziet zo altijd correcte productinfo in picklists, zonder dat de voorraadmodule productgegevens dupliceert.
5. Boekhouding: factuurregels
Factuurregels verwijzen naar producten en partners: productnaam, rekeningschema's en belastingsinstellingen worden via relaties opgehaald. Accountants zien consistente waarden die overeenkomen met wat verkoopteams op het product hebben ingesteld.
Een geërfd veld maken of aanpassen
Werken met Odoo Studio
Odoo Studio is de no-code manier om modellen en views aan te passen. Als je daar velden toevoegt, doet Studio onderhuids wat klassieke erving doet: het voegt een veld toe aan de bestaande modeldefinitie.
Studio laat je ook related-velden aanmaken. Kies je "Related Field", dan kun je een pad aanwijzen naar elk veld dat bereikbaar is via relaties van het huidige model — bijvoorbeeld het land of btw-nummer van de klant op een verkooporder.
Voor functionele consultants en eindgebruikers is Studio doorgaans voldoende: het regelt veldnamen, database-migratie en plaatsing in views automatisch.
Technische aanpassingen met Python
Ontwikkelaars definiëren geërfde velden in Python met de models.Model-klasse van Odoo's ORM.
Voor klassieke uitbreiding voeg je eenvoudig een nieuw veld toe aan een bestaand model:
class CrmLead(models.Model):
_inherit = 'crm.lead'
x_contract_value = fields.Float(
string='Geschat contractwaarde'
)Voor delegatie-erwing creëer je een nieuw model dat velden van een bestaand model hergebruikt:
class EmployeeProfile(models.Model):
_name = 'hr.employee.profile'
_inherits = {'res.partner': 'partner_id'}
partner_id = fields.Many2one(
'res.partner',
required=True,
ondelete='cascade'
)
employee_id = fields.Many2one(
'hr.employee',
string='Werknemer'
)En zo maak je een related-veld om een waarde van een gelinkt record zichtbaar te maken:
class SaleOrder(models.Model):
_inherit = 'sale.order'
partner_country_id = fields.Many2one(
related='partner_id.country_id',
string='Klantland',
store=True
)Via de XML-RPC API (remote configuratie)
Je kunt velden ook programmatically toevoegen via de XML-RPC API op het model ir.model.fields. Dat is precies wat tools voor remote configuratie doen en komt neer op hetzelfde dat Studio doet, maar dan via scriptmatige deployment.
Een related-veld via de API maak je door een record in ir.model.fields aan te maken met het juiste ttype en het related-pad. Deze methode is handig voor geautomatiseerde setup of provisioning.
Best practices
Kies het juiste ervingstype
Gebruik klassieke erving wanneer je gewoon velden of methodes aan een bestaand model wil toevoegen — dat is de eenvoudigste en meest gebruikte route. Schakel over naar delegatie alleen als je twee aparte entiteiten wilt die logisch gekoppeld zijn, bijvoorbeeld wanneer een concept uitbreidt op een contact maar zelf geen contact is.
Geef de voorkeur aan related-velden voor leesdoeleinden
Als je enkel een waarde van een gelinkt record wil tonen in een view, is een related-veld meestal beter dan delegatie. Het introduceert geen extra structurele koppeling en blijft overzichtelijk en onderhoudbaar.
Wees terughoudend met store=True op related-velden
Opslaan van een related-veld versnelt zoeken en groeperen, maar maakt van de waarde een kopie. Dat vereist recomputatie bij bronwijzigingen en kan in randgevallen sync-problemen geven. Sla alleen op als je echt op die velden wilt filteren of groeperen op schaal.
Prefix altijd custom velden met x_
Voeg extra velden aan standaardmodellen altijd toe met een x_-prefix (of gebruik een module-namespace) om toekomstige botsingen met officiële Odoo-velden te vermijden.
Documenteer je ervingsketen
Bij complexe aanpassingen noteer kort waar een veld vandaan komt en waarom het bestaat. Een veld x_country_code op een verkooporder is niet meteen herkenbaar als partner_id.country_id.code zonder toelichting.
Zorg voor juiste cascade deletes
Bij delegatie wordt het ouderrecord vaak automatisch aangemaakt. Bij verwijdering wil je doorgaans dat het ouderrecord mee verdwijnt. Zet ondelete='cascade' op de Many2one in _inherits om verweesde records te vermijden.
Veelvoorkomende valkuilen
Verwarring tussen de drie ervingstypen
Een veelgemaakte fout is _inherit combineren met _name wanneer je eigenlijk klassiek wil uitbreiden. Dat creëert per ongeluk een nieuw model. Controleer je definitie: wil je geen nieuw model, laat _name dan weg.
Vergeten om het ouderrecord aan te maken bij _inherits
Bij delegatie zorgt Odoo doorgaans voor creatie van het ouderrecord, maar in scripts of via de API moet je soms zelf het ouderrecord aanmaken of ervoor zorgen dat de ORM het correct doet. Anders krijg je constraint-fouten.
Een veldtype proberen te wijzigen via erving
Je kunt het type van een bestaand veld niet overschrijven via erving. Labels of helptekst veranderen mag, maar een Char naar Integer omzetten niet — dat veroorzaakt installatiefouten.
Related-velden te veel opslaan
Het verleidelijk opslaan van alle related-velden voor betere performance vergroot de database en verhoogt onderhoud. Als bronvelden vaak veranderen leidt dat tot veel recomputaties. Doe dit selectief, alleen bij echte noodzaak.
Denken dat geërfde velden altijd onder kindmodelbeveiliging vallen
Bij delegatie staan de velden fysiek op het oudermodel. Toegangsregels van het kindmodel worden daar niet automatisch op afgedwongen. Als je toegang op het kind beperkt maar niet op het oudermodel, kunnen gebruikers de gegevens via het oudermodel nog zien. Controleer beveiligingsregels op beide modellen.
Slotwoord
Geërfde velden vormen geen randverschijnsel maar zitten in het hart van Odoo: gebruikers-partnerrelaties, product-variantarchitectuur en het tonen van klantinfo op orders — allemaal werken ze dankzij velderving om data consistent te houden.
Als je weet welk ervingstype wanneer past, wanneer een related-veld volstaat en wat de databasegevolgen zijn, werk je efficiënter met Odoo. Je maakt overzichtelijkere datamodellen, schrijft schonere code en bespaart tijd bij debugging.
Kort gezegd: Odoo is opgebouwd rond één bron van waarheid per gegeven. Geërfde velden zorgen ervoor dat die bron vanuit veel verschillende modellen bereikbaar blijft, en dat houdt het ecosysteem coherent naarmate je functionaliteit uitbreidt.
Hulp nodig bij je Odoo-implementatie?
Bij Dasolo begeleiden we bedrijven bij het implementeren, aanpassen en optimaliseren van Odoo. Of je nu een custom module bouwt, standaardmodellen uitbreidt of vastloopt op onduidelijke datagedragingen — wij hebben de praktijkervaring om gericht te helpen.
Heb je vragen over je Odoo-datamodel, strategie voor custom velden of technische implementatie? We bekijken graag je situatie en geven concrete adviezen. Neem contact met ons op en samen zoeken we de beste aanpak voor jouw project.