Overslaan naar inhoud

Custom Fields in Odoo: De Ultieme Gids voor Aanpasbare Velden

Ontdek hoe je elk Odoo-model verrijkt met maatwerkvelden — zowel snel via Odoo Studio als krachtig met Python — en waarom die extra gegevens cruciaal zijn voor efficiëntere bedrijfsvoering en betere beslissingen
6 maart 2026 in
Custom Fields in Odoo: De Ultieme Gids voor Aanpasbare Velden
Dasolo
| Nog geen reacties

Elke onderneming werkt net even anders. Je verzamelt gegevens die standaardsoftware vaak niet voorziet — precies daar komen aangepaste velden in Odoo van pas.


In plaats van je processen te laten buigen naar een vast datamodel, kun je in Odoo bijna elk record uitbreiden met extra velden: klantfiches, offerteorders, producten, facturen — jij bepaalt welke informatie belangrijk is en Odoo bewaart die naast de bestaande velden.


Dit artikel geeft je een compleet overzicht: wat aangepaste velden zijn, hoe ze technisch in elkaar steken, hoe je ze maakt (met of zonder code) en hoe je ze inzet zodat je Odoo-overzicht netjes en onderhoudbaar blijft.

Wat is een aangepaste veld in Odoo


Een aangepast veld is simpelweg een extra kolom die je toevoegt aan een bestaand Odoo-model. Het slaat één specifieke stukje informatie op dat gekoppeld is aan een record, precies zoals een ingebouwd veld dat doet.


In Odoo herken je aangepaste velden aan het voorvoegsel x_. Velden gemaakt met Odoo Studio krijgen bijvoorbeeld namen als x_studio_priority_level, terwijl technische implementaties vaak een bedrijfspecifieke prefix gebruiken, zoals x_acme_cost_center.


Voor eindgebruikers voelt een aangepast veld precies aan als een standaardveld: je kunt het in formulieren, lijstweergaven, filters, groeperingen en rapporten tonen. Wie geen inzicht heeft in de technische kant merkt geen verschil.


Beschikbare veldtypes

Odoo biedt een ruime keuze aan veldtypes voor aangepaste velden, afgestemd op bijna elke databehoefte:

  • Text (Char): korte tekst, bijvoorbeeld een referentie of code
  • Long Text: meerdere regels vrije tekst voor notities en omschrijvingen
  • Integer: gehele getallen, handig voor aantallen of scores
  • Decimal (Float): getallen met decimalen voor meetwaarden of tarieven
  • Monetary: een valutagebonden bedrag, gekoppeld aan een valuta-veld
  • Boolean: ja/nee checkbox
  • Date / Date & Time: kalenderdatum of tijdsstempel
  • Selection: vooraf gedefinieerde dropdownlijst
  • Many2one: link naar één record in een ander model
  • One2many: lijst van gerelateerde records uit een ander model
  • Many2many: meerdere gekoppelde records uit een ander model
  • Binary: bestand als bijlage
  • HTML: rijke tekstinhoud

Kies het juiste type vanaf het begin: is het keuzewaarden, gebruik dan een Selection in plaats van vrije tekst — dat voorkomt rommel in filters en rapporten.

Hoe het veld werkt


Odoo draait op een laag die we de Odoo ORM noemen (Object-Relational Mapping). Achter elk formulier en record staat een Python-model dat correspondeert met een PostgreSQL-tabel. Wanneer je een aangepast veld toevoegt, registreert Odoo dat veld in de ORM en maakt automatisch de corresponderende kolom in de database aan.


Die metadata-laag maakt het model flexibel: je past geen broncode aan, maar breidt het datamodel uit via een registratietabel (ir.model.fields). Odoo leest die metadata bij het opstarten en bouwt de velden dynamisch op.


Velden gedefinieerd in code versus velden in de database

Bij klassieke Odoo-ontwikkeling definieer je velden in Python-klassen met het Odoo-framework. Een eenvoudige velddefinitie wordt rechtstreeks in het model beschreven.


Een typisch voorbeeld in code zou een Python-definitie zijn die een nieuw Char-veld toevoegt aan een bestaand model, zodat het bij upgraden en versiebeheer aan de codebase gekoppeld blijft.

Velden die je via de interface of API creëert, worden als state = 'manual' in ir.model.fields opgeslagen en bij runtime geladen. Beide routes resulteren in een echte databasekolom en zien er voor de gebruiker hetzelfde uit.


Relationele velden en wederkerigheid

Bij het aanmaken van een Many2one naar een ander model verwacht Odoo doorgaans een bijbehorende One2many aan de andere kant. Dat is niet enkel stijl: het is hoe de ORM relaties navigeert tussen records.


Stel dat je op een offerte een x_project_id (Many2one naar project.project) toevoegt: idealiter maak je op het projectmodel ook x_sale_order_ids (One2many naar sale.order) zodat je vanuit het project terug kunt bladeren naar gekoppelde offertes.


Berekenbare (computed) aangepaste velden

Computed fields worden automatisch ingevuld op basis van andere waarden. Technisch schrijf je een Python-methode en koppel je die aan het veld via de compute-parameter. Dergelijke velden zijn meestal read-only en worden geüpdatet wanneer afhankelijkheden veranderen.


Computed velden zijn krachtig maar vereisen code; je kunt ze meestal niet rechtstreeks via Studio aanmaken zonder developer mode en Python-kennis.

Praktische bedrijfsvoorbeelden


Bij Dasolo komt bijna elk Odoo-project met aangepaste velden. Hieronder vijf herkenbare toepassingen uit de praktijk.

1. CRM: leads beter kwalificeren

Standaard-leads bevatten contactgegevens en pipelinestadia, maar verkoopteams willen vaak extra classificatie. Een Selection-veld voor 'sector' of een Many2one naar een intern 'marktsegment'-model helpt verkopers sneller te categoriseren en maakt gerichte pipeline-rapportage mogelijk.


2. Sales: interne projectcodes bij offertes

Wanneer je per project factureert, is het nuttig om een intern projectnummer of budgetreferentie aan offertes en orders te koppelen. Een eenvoudig Char-veld 'Projectcode' op sale.order maakt dat mogelijk zonder volle projectintegratie; het verschijnt ook op afdrukken en in rapportfilters.


3. Voorraad: producteigenschappen op maat

Naast standaard productvelden hebben sommige sectoren technische specificaties nodig: 'Garantieduur (maanden)' als Integer, 'Certificeringsnorm' als Selection of 'Land van herkomst' als Many2one naar res.country. Deze velden passen naadloos in het productformulier en verschijnen in voorraadrapporten.


4. Boekhouding: kostencentra en budgettoewijzing

Finance-teams willen facturen of journaalposten taggen met een kostencentrum of budgetlijn. Een Many2one op account.move naar een custom 'Cost Center'-model maakt gedetailleerde kostentoewijzing mogelijk en werkt meteen in filters, draaitabellen en exports.


5. HR: aanvullende onboardinggegevens

HR verzamelt vaak informatie tijdens onboarding die niet in standaard velden past: landgebonden contracttypes, interne vaardigheidscategorieën of wagenparkcode. Aangepaste velden op hr.employee houden die data centraal in Odoo in plaats van in losse spreadsheets.

Een veld aanmaken of aanpassen


Er zijn twee gangbare manieren om aangepaste velden aan te maken; welke je kiest hangt af van de technische capaciteit en de complexiteit van het veld.


Optie 1: Odoo Studio (zonder code)

Odoo Studio is de snelste route voor functionele gebruikers. Met Studio actief voeg je in enkele klikken een veld toe:

  1. Open de app en het recordtype (bv. offerteformulier) waar je het veld wilt tonen
  2. Activeer de Studio-bewerkmodus
  3. Sleep het gewenste veldtype uit het linkerpaneel naar het formulier
  4. Stel label, technische naam en eventuele eigenschappen in
  5. Bewaar en sluit Studio af

Studio maakt het veld in ir.model.fields aan met het x_studio_-voorvoegsel en voegt het direct aan de view toe. Geen deployment of serverrestart nodig — ideaal voor eenvoudige velden zonder extra logica.


Optie 2: Technische aanpassing via de API of modules

Voor ontwikkelteams is het aanmaken van velden via de XML-RPC API of in een Python-module de juiste keuze als je computed logic, complexe domeinen of versiebeheer nodig hebt.


Via de API kun je programatisch een selection-veld of ander veldtype aanmaken en configureren zonder de codebase direct te wijzigen.


Met API-aanroepen haal je eerst het model-id op en maak je vervolgens een record in ir.model.fields met de gewenste eigenschappen, zoals naam, beschrijving, ttype en selectie-opties.

Deze werkwijze past in een standaard ontwikkelworkflow voor Odoo en is handig voor geautomatiseerde configuraties en remote setups.


Voor grotere of blijvende aanpassingen verdient een Python-module de voorkeur: velden worden dan onderdeel van een module die je kunt upgraden, testen en beheren via versiecontrole.


Het veld zichtbaar maken in de view

Een veld bestaat in de database maar verschijnt niet automatisch in de interface. Met Studio voeg je het meteen toe aan de view; bij technische wijzigingen pas je de XML-view aan of maak je een overervende view die het veld inschakelt op de juiste plaats.


Aanbevelingen en goede gewoonten


Aangepaste velden zijn eenvoudig te maken, maar zonder structuur ontstaan op termijn onderhoudsproblemen. Volg deze praktijken om chaos te vermijden.


Gebruik keuzevelden in plaats van vrije tekst waar mogelijk

Als de waarden vooraf bekend zijn, kies dan een Selection-veld in plaats van Char. Vrije tekst leidt tot inconsistente invoer ('Klant', 'klant', 'KLANT') en maakt filters en rapporten onbetrouwbaar.


Geef velden duidelijke en consistente namen

De technische naam (x_project_type) moet de betekenis weerspiegelen. Namen als x_field_1 zijn onhoudbaar; werk met een consistente conventie en documenteer het doel van elk veld.


Extend native modellen niet ondoordacht

Als je veel velden op bijvoorbeeld sale.order zet, is dat vaak een signaal dat er een nieuw custom model moet komen. Groepen velden die samen een entiteit vormen (project, contract, certificaat) horen beter in een eigen model met een Many2one-koppeling.


Test altijd op een stagingomgeving

Voer veldtoevoegingen eerst uit op een kopie van de productieomgeving. Hoewel veldcreatie meestal veilig is, kan een verkeerde modelkeuze of type een handmatige herstelactie vereisen; staging vangt dat op.


Documenteer je aangepaste velden

Hou een register bij van elk custom veld: model, technische naam, doel en aanvrager. Zonder documentatie wordt het onmogelijk te bepalen welke velden nog in gebruik zijn en welke verwijderd kunnen worden.


Gebruik de juiste techniek voor berekeningslogica

Wanneer een waarde afhankelijk is van andere velden, kies dan voor een computed field in plaats van handmatige invoer. Dat voorkomt inconsistenties en fouten bij datainvoer; computed fields zijn standaard onderdeel van Odoo's Python-functionaliteit.

Veelvoorkomende valkuilen


Ook ervaren teams struikelen soms over dezelfde problemen met custom velden. De volgende issues komen het meest voor.


Vergeten de One2many aan te maken bij een Many2one

Deze fout zien we vaak: je maakt een Many2one naar model B maar vergeet de bijbehorende One2many op B. Daardoor kun je vanuit B niet terugkoppelen naar A en zijn gerelateerde records niet zichtbaar — maak beide kanten tegelijk aan.


Een veld verwijderen dat nog data bevat

Verwijderen betekent permanent: de databankkolom en alle inhoud zijn weg. Er is geen automatische undo. Als je de data misschien later nog nodig hebt, archiveer of verberg het veld in plaats van definitief te verwijderen.


Velden direct in productie aanmaken

Wijzigingen rechtstreeks op een live database doorvoeren zonder staging is riskant. Als een view foutief geraakt, krijgen gebruikers fouten te zien; daarom altijd eerst op een testomgeving valideren.


Naamconflicten met standaardvelden

Odoo blokkeert dubbele veldnamen, maar je kunt per ongeluk een naam kiezen die later bots met een module die je installeert. Gebruik een bedrijfsvoorvoegsel (bv. x_acme_) om dat risico te verkleinen.


Een veld aan de view toevoegen zonder UX te overwegen

Niet elk veld hoort standaard in het zicht. Overvolle formulieren vertragen gebruikers. Plaats zelden gebruikte velden in aparte tabbladen of maak ze conditioneel zichtbaar met domeinregels.


Studio- en technische velden mengelen zonder strategie

Een mix van Studio-aanpassingen en code kan leiden tot overlappingen of naamconflicten. Bepaal bij de start of Studio gebruikt wordt voor no-code wijzigingen en code voor complexere logica — of kies voor één aanpak om onderhoud te vereenvoudigen.

Samenvatting


Aangepaste velden zijn een van de meest effectieve manieren om Odoo aan je bedrijfsrealiteit aan te passen. Ze vereisen geen broncodewijziging, integreren met het platform en geven gebruikers precies de velden die ze nodig hebben zonder omwegen.

Belangrijk is: denk na vóór je bouwt. Kies het juiste veldtype, benoem velden eenduidig, respecteer relationele conventies en documenteer alles. Een doordacht veldmodel maakt je Odoo-omgeving eenvoudiger te onderhouden en schaalbaar naarmate je bedrijf groeit.


Of je nu snel velden toevoegt met Odoo Studio of Python-modules schrijft als onderdeel van een bredere aanpassing, de principes blijven hetzelfde: laat het veld overeenkomen met de data, houd het model overzichtelijk en test altijd voor productie.

Bij Dasolo begeleiden we bedrijven bij implementatie, aanpassing en optimalisatie van Odoo zodat het echt aansluit op hun workflow. Of je nu enkele velden nodig hebt of een volledige custom module wilt laten ontwikkelen, we helpen graag.

Neem contact op als je advies wilt over je Odoo-opstelling. We bekijken met plezier je huidige configuratie en adviseren de meest onderhoudsvriendelijke weg vooruit.

Custom Fields in Odoo: De Ultieme Gids voor Aanpasbare Velden
Dasolo 6 maart 2026
Deel deze post
Aanmelden om een reactie achter te laten