Elke onderneming is anders. Jouw team volgt informatie die geen enkele standaardsoftware voorziet, en dat is precies waar aangepaste velden in Odoo van pas komen.
In plaats van je workflows te dwingen zich aan een rigide datamodel aan te passen, laat Odoo je nieuwe velden toevoegen aan bijna elk record, of dat nu een klant, een verkooporder, een product of een factuur is. Jij beslist welke gegevens je wilt vastleggen, en Odoo slaat deze op naast alles wat er al is.
Deze gids behandelt alles wat je moet weten: wat aangepaste velden zijn, hoe ze onder de motorkap werken, hoe je ze kunt maken met of zonder code, en hoe je ze kunt gebruiken op een manier die je Odoo-instantie schoon en onderhoudbaar houdt.
Wat is een aangepast veld in Odoo
Een aangepast veld is een databaseveld dat je toevoegt aan een bestaand Odoo-model, bovenop wat standaard wordt geleverd. Het slaat een specifiek stuk informatie op dat aan een record is gekoppeld, precies zoals een native veld dat zou doen.
In Odoo worden aangepaste velden geïdentificeerd door het x_ voorvoegsel. Velden die zijn gemaakt via Odoo Studio gebruiken namen zoals x_studio_priority_level, terwijl velden die programmatisch zijn toegevoegd mogelijk een voorvoegsel gebruiken dat specifiek is voor jouw project, zoals x_dasolo_cost_center.
Vanuit de gebruikersinterface ziet een aangepast veld eruit en gedraagt het zich precies zoals elk standaardveld. Het kan verschijnen in formulieren, lijstweergaven, filters, groepeeropties en rapporten. Gebruikers die de technische kant niet kennen, zullen nooit het verschil opmerken.
Beschikbare Veldtypes
Odoo ondersteunt een breed scala aan veldtypes voor aangepaste velden, die de meeste gegevensbehoeften dekken:
- Tekst (Char): Korte tekst, zoals een referentiecode of een label
- Lange Tekst: Meerdere regels vrije tekst voor notities of beschrijvingen
- Geheel Getal: Gehele getallen, nuttig voor tellingen of scores
- Decimaal (Float): Getallen met decimalen, voor metingen of tarieven
- Monetair: Valuta-bewust bedrag, gekoppeld aan een valutaveld
- Boolean: Een waar/onwaar checkbox
- Datum / Datum & Tijd: Kalenderdatum of tijdstempel
- Selectie: Een vaste dropdownlijst met opties
- Many2one: Een koppeling naar een enkel record in een ander model
- One2many: Een lijst van gerelateerde records uit een ander model
- Many2many: Meerdere records gekoppeld vanuit een ander model
- Binary: Bestandsbijlage
- HTML: Rijke tekstinhoud
Het kiezen van het juiste veldtype vanaf het begin bespaart veel problemen later. Een selectievak is bijna altijd beter dan een vrij tekstveld wanneer de set mogelijke waarden van tevoren bekend is.
Hoe het veld werkt
Odoo is gebouwd op een framework genaamd de Odoo ORM (Object-Relational Mapping). Elke formulier, lijstweergave en record die je in de interface ziet, wordt ondersteund door een Python-model dat overeenkomt met een database-tabel. Wanneer je een aangepast veld toevoegt, registreert Odoo het in de ORM en creëert automatisch de bijbehorende kolom in PostgreSQL.
Dit is wat het Odoo-datamodel flexibel maakt: je patcht de broncode niet. Je breidt het model uit via een metadata-laag die is opgeslagen in de ir.model.fields tabel. Odoo leest die tabel bij het opstarten en bouwt de velden dynamisch.
Velden Gedefinieerd in Code vs. Velden Gedefinieerd in de Database
In standaard Odoo-ontwikkeling worden velden rechtstreeks gedefinieerd in Python-modelklassen met behulp van het Odoo-framework. Een typische velddefinitie ziet er als volgt uit:
from odoo import models, fields
class SaleOrder(models.Model):
_inherit = 'sale.order'
cost_center = fields.Char(string='Kostenplaats')Aangepaste velden die via de UI of API zijn gemaakt, volgen een ander pad: ze worden opgeslagen met state = 'manual' in ir.model.fields en worden tijdens runtime geladen. Beide benaderingen produceren een echte databasekolom en gedragen zich identiek vanuit het perspectief van de gebruiker.
Relationele Velden en Wederkerigheid
Wanneer je een Many2one aangepast veld maakt dat naar een ander model wijst, verwacht Odoo een bijpassend One2many veld aan de andere kant. Dit is niet alleen een conventie: het is hoe de Odoo ORM relaties tussen records navigeert.
Bijvoorbeeld, als je een x_project_id (Many2one naar project.project) toevoegt aan een verkooporder, moet je ook x_sale_order_ids (One2many terug naar sale.order) op het projectmodel toevoegen. Zonder dit is navigatie van het project naar zijn gekoppelde orders niet mogelijk via de standaardinterface.
Berekenende Aangepaste Velden
Odoo berekende velden zijn velden waarvan de waarde automatisch wordt berekend op basis van andere velden, in plaats van door de gebruiker ingevoerd. Bij technische aanpassingen definieer je een Python-methode en koppel je deze aan het veld met behulp van de compute parameter. Deze velden zijn alleen-lezen en worden bijgewerkt telkens wanneer hun afhankelijkheden veranderen.
Berekende velden zijn krachtig, maar vereisen code. Ze kunnen momenteel niet worden gemaakt via Odoo Studio zonder ontwikkelaarsmodus en enige kennis van Python.
Zakelijke gebruikscases
Aangepaste velden komen in bijna elk Odoo-project voor waar we bij Dasolo aan werken. Hier zijn vijf veelvoorkomende scenario's uit echte bedrijfsworkflows.
1. CRM: Leads Nauwkeuriger Kwalificeren
Standaard Odoo leads leggen contactgegevens en pipelinefase vast, maar veel verkoopteams hebben meer nodig. Een Selectieveld voor "Klantindustrie" of een Many2one die naar een intern "Marktsegment" model verwijst, stelt verkoopmedewerkers in staat om leads sneller te kwalificeren en stelt het management in staat om over de pipeline per segment te rapporteren.
2. Verkoop: Interne Projectcodes Volgen
Bedrijven die klanten per project factureren, moeten vaak een interne projectcode of budgetreferentie aan elke offerte of verkooporder koppelen. Een eenvoudig Char-veld genaamd "Projectcode" op sale.order maakt dit mogelijk zonder een volledige projectmanagementintegratie. Het veld verschijnt op afgedrukte documenten en kan worden gebruikt om orders in rapporten te filteren en te groeperen.
3. Voorraad: Product-Specifieke Attributen
Naast de standaard productattributen van Odoo, moeten bedrijven soms technische specificaties bijhouden die uniek zijn voor hun sector. Een fabrikant kan velden toevoegen voor "Garantieperiode (maanden)" (Integer), "Certificeringsnorm" (Selectie), of "Land van herkomst" (Many2one naar res.country). Deze velden integreren natuurlijk met het productformulier en zijn beschikbaar in voorraadrapporten.
4. Boekhouding: Budget en Kostenplaats Toewijzing
Financiële teams moeten vaak facturen of journaalposten taggen met een kostenplaats of budgetlijn. Een Many2one-veld op account.move dat verwijst naar een aangepast "Kostenplaats"-model maakt gedetailleerde kostenallocatie mogelijk zonder de analytische boekhoudopzet van Odoo te wijzigen. Filters, draaitabellen en exports respecteren het veld onmiddellijk na creatie.
5. HR: Aangepaste Onboarding Gegevens
HR-afdelingen verzamelen vaak gegevens tijdens de onboarding die niet passen in de standaard werknemersvelden: contracttypes specifiek voor een land, interne vaardigheidscategorieën of referenties voor vloottoewijzing. Aangepaste velden op hr.employee houden deze informatie binnen Odoo in plaats van in een aparte spreadsheet, waardoor het doorzoekbaar en rapporteerbaar is.
Een veld maken of aanpassen
Er zijn twee hoofdmanieren om aangepaste velden in Odoo te creëren. De juiste keuze hangt af van uw technische middelen en hoe complex het veld moet zijn.
Optie 1: Odoo Studio (Geen Code)
Odoo Studio-velden zijn de snelste weg voor zakelijke gebruikers. Met Studio ingeschakeld, kunt u in een paar klikken een nieuw veld aan elke weergave toevoegen:
- Open de app en het recordtype waar u het veld wilt (bijvoorbeeld een verkooporderformulier)
- Klik op het potloodpictogram om de Studio-bewerkmodus in te voeren
- Sleep een veldtype vanuit het linkerpaneel naar het formulier
- Stel het veldlabel, technische naam en eventuele aanvullende eigenschappen in
- Sla op en verlaat Studio
Studio creëert het veld in ir.model.fields met het x_studio_ voorvoegsel en voegt het direct toe aan de weergave. Geen implementatie of serverherstart is nodig. Dit is de aanbevolen aanpak voor eenvoudige velden die geen aangepaste logica vereisen.
Optie 2: Technische Aanpassing via de API
Voor teams die werken aan Odoo-aanpassingsprojecten, kunnen velden programmatisch worden aangemaakt met behulp van de XML-RPC API of door een Python-module te schrijven. Dit is het juiste pad wanneer je berekende velden, complexe domeinfilters of velden nodig hebt die deel moeten uitmaken van een versiebeheerde codebase.
Met de API ziet het creëren van een aangepast selectievak op een verkooporder er als volgt uit:
# Zoek het model-ID voor sale.order
model = models.execute_kw(
db, uid, api_key,
'ir.model', 'search_read',
[['model', '=', 'sale.order']],
{'fields': ['id', 'name']}
)[0]
# Maak het aangepaste veld
field_id = models.execute_kw(
db, uid, api_key,
'ir.model.fields', 'create',
[{
'name': 'x_project_type',
'field_description': 'Projecttype',
'model_id': model['id'],
'ttype': 'selection',
'selection': [('internal', 'Intern'), ('client', 'Klant'), ('rd', 'R&D')],
'state': 'manual',
}]
)Dit maakt deel uit van de standaard Odoo ontwikkelaarsgids workflow voor het toevoegen van velden zonder de bronbestanden te wijzigen. Het is vooral nuttig voor externe configuraties en geautomatiseerde implementatiescripts.
Voor een volledige Python-modulebenadering worden velden gedefinieerd in een modelklasse en geladen via de standaard Odoo-modulemechanisme. Dit is de meest onderhoudbare optie voor velden die zullen blijven bestaan na upgrades en die moeten worden bijgehouden in versiebeheer.
Het Veld Toevoegen aan een Weergave
Een veld creëren maakt het niet automatisch zichtbaar in de interface. Je moet het ook toevoegen aan de relevante formulier- of lijstweergave. Met Studio gebeurt dit tegelijkertijd met het creëren van het veld. Bij technische aanpassing wijzig je ofwel de weergave-XML direct of maak je een geërfde weergave die het veld op de juiste positie injecteert.
Beste praktijken
Aangepaste velden zijn gemakkelijk te creëren, maar een slecht geplande veldarchitectuur creëert problemen die later moeilijk op te lossen zijn. Dit zijn de praktijken die dingen schoon houden.
Gebruik Selectievelden in plaats van Vrije Tekst Waar Mogelijk
Als de set mogelijke waarden van tevoren bekend is, gebruik dan altijd een Selectieveld in plaats van een Char-veld. Vrije tekst leidt tot inconsistente invoer ("Klant", "klant", "KLANT", "Kl.") die filters en rapporten verstoren. Een dropdown handhaaft consistentie zonder extra kosten.
Naamvelden Duidelijk en Consistent
De technische naam (x_project_type) moet de inhoud weerspiegelen, niet de positie op het formulier. Een veld genaamd x_field_1 is onmogelijk te onderhouden zes maanden later. Gebruik een consistente naamgevingsconventie en documenteer waar elk veld voor dient.
Verleng Native Modellen Niet Te Veel
Het toevoegen van tien aangepaste velden aan sale.order is meestal een teken dat een aangepast model beter zou dienen. Als een groep velden bij elkaar hoort en een nieuwe entiteit in uw bedrijf vertegenwoordigt (een project, een contract, een certificering), overweeg dan om een aangepast model te creëren en dit te koppelen met een Many2one-veld.
Test Altijd op een Staging Database
Voordat u velden toevoegt aan een productie-instantie, test op een kopie van de database. Het aanmaken van velden is meestal veilig, maar het toevoegen van een veld aan het verkeerde model, of met het verkeerde type, kan handmatige opruiming vereisen. Een staging-omgeving vangt deze problemen vroegtijdig op.
Documenteer Uw Aangepaste Velden
Houd een record bij van elk aangepast veld dat u toevoegt: het model, de technische naam, het doel en wie het heeft aangevraagd. Odoo-implementaties accumuleren in de loop van de tijd velden, en zonder documentatie wordt het onmogelijk om te weten welke nog in gebruik zijn en welke kunnen worden verwijderd.
Gebruik de Juiste Tool voor Gecomputeerde Logica
Als de waarde van een veld afhankelijk is van andere velden, gebruik dan een gecomputeerd veld in plaats van gebruikers te vragen het handmatig in te vullen. Dit voorkomt inconsistenties en vermindert invoerfouten. Gecomputeerde velden maken deel uit van de kernfunctionaliteit van Odoo Python-velden en zijn goed gedocumenteerd in de officiële technische tutorial van Odoo.
Veelvoorkomende valkuilen
Zelfs ervaren teams lopen tegen dezelfde problemen aan met aangepaste velden. Hier zijn de meest voorkomende.
Vergeten de One2many te Maken bij het Creëren van een Many2one
Dit is de meest voorkomende technische fout. Als je een Many2one-veld toevoegt aan model A dat naar model B wijst, en je creëert het bijbehorende One2many-veld op model B niet, dan is de navigatie van B naar A verbroken. Gebruikers kunnen geen gerelateerde records van de andere kant van de relatie zien. Maak altijd beide velden samen aan.
Een Veld Verwijderen Dat Gegevens Bevat
Het verwijderen van een aangepast veld verwijdert permanent de databasekolom en alle gegevens die het bevat. Er is geen ongedaan maken. Als er enige kans is dat het veld of de gegevens in de toekomst nodig zijn, archiveer of verberg het veld in plaats van het te verwijderen.
Velden Direct in Productie Aanmaken
Wijzigingen direct op een live productiedatabase aanbrengen, zonder eerst op staging te testen, is een risico, zelfs voor eenvoudige veldtoevoegingen. Als er iets misgaat met de weergaveconfiguratie, krijgen gebruikers fouten. Valideer altijd eerst in een testomgeving.
Naamconflicten met Standaard Velden
Odoo zal een veldnaam afwijzen die al bestaat op het model, maar het is gemakkelijk om per ongeluk een veld te creëren dat een veld uit een later geïnstalleerde module overschaduwt. Het gebruik van een bedrijfsspecifiek voorvoegsel (zoals x_acme_) voor je aangepaste velden vermindert dit risico aanzienlijk.
Een Veld Aan de Weergave Toevoegen Zonder na te Denken Over UX
Simpelweg omdat een veld aan een formulier kan worden toegevoegd, betekent niet dat het standaard zichtbaar moet zijn. Overvolle formulieren vertragen gebruikers. Als een veld alleen relevant is in specifieke contexten, plaats het dan in een apart tabblad of maak het conditioneel zichtbaar met behulp van op domeinen gebaseerde onzichtbaarheidsregels.
Inconsistent Mengsel van Studio Velden en Technische Velden
Wanneer een project Studio-aanpassingen en code-gebaseerde aanpassingen combineert, kun je eindigen met velden die overlappende doeleinden of conflicterende namen hebben. Stem aan het begin van het project een strategie af: gebruik ofwel Studio voor alle no-code velden en code voor complexe logica, of gebruik code voor alles. Het mengen van beide zonder een duidelijk plan creëert onderhoudsproblemen.
Conclusie
Aangepaste velden zijn een van de eenvoudigste en meest impactvolle manieren om Odoo aan te passen aan jouw bedrijf. Ze vereisen geen wijzigingen in de broncode, integreren natuurlijk met de rest van het platform en geven gebruikers de exacte gegevensverzameling die ze nodig hebben zonder omwegen.
De sleutel is om te plannen voordat je bouwt. Kies het juiste veldtype, noem dingen duidelijk, respecteer de conventies voor relationele velden en documenteer wat je creëert. Een goed ontworpen veldarchitectuur maakt je Odoo-instantie gemakkelijker te onderhouden en gemakkelijker te laten evolueren naarmate je bedrijf groeit.
Of je nu Odoo Studio gebruikt voor snelle no-code velden of Python-modules schrijft als onderdeel van een breder Odoo-aanpassingsproject, de onderliggende principes zijn hetzelfde: stem het veld af op de gegevens, houd het model schoon en test altijd voordat je naar productie gaat.
Bij Dasolo helpen we bedrijven met het implementeren, aanpassen en optimaliseren van Odoo om aan hun werkelijke workflows te voldoen. Of je nu een paar aangepaste velden aan je bestaande setup wilt toevoegen of een volledige aangepaste module vanaf nul wilt laten bouwen, ons team staat klaar om te helpen.
Neem contact met ons op als je begeleiding nodig hebt bij je Odoo-implementatie. We bekijken graag je huidige setup en stellen de schoonste weg vooruit voor.