Introductie
Als je ooit een formulier in Odoo hebt opgeslagen en één van de invoervelden zag oplichten in het rood, dan heb je de werking van een verplicht veld al ervaren. Het is een eenvoudige maar krachtige manier om te zorgen dat belangrijke informatie niet vergeten wordt tijdens dagelijkse processen.
Of je nu Odoo instelt voor een verkoopteam, een nieuw gegevensmodel maakt of aan een technische implementatie werkt: weten wat de required-eigenschap doet, voorkomt verrassingen en maakt je processen betrouwbaarder.
In deze gids leggen we stap voor stap uit hoe verplichte velden zich gedragen binnen Odoo, hoe je ze creëert met Studio of via Python/API, wanneer je ze best inzet en welke fouten je best vermijdt.
Wat betekent “verplicht veld” in Odoo?
In Odoo is het attribuut required een eigenschap op veldniveau die voorkomt dat een record wordt opgeslagen zolang dat veld leeg is. Het geldt voor vrijwel alle veldtypen: tekst, nummers, selecties, many2one-relaties, datums enzovoort.
Het behoort tot het kerngegevensmodel van Odoo en is een van de meest gebruikte parameters bij maatwerk. Een verplicht veld is vaak de eerste maatregel om onvolledige of inconsistente data tegen te houden.
Hoe het zichtbaar wordt voor gebruikers
In de gebruikersinterface vallen verplichte velden meteen op. Wanneer je een formulier bewerkt, toont Odoo vaak een visuele hint en als je probeert op te slaan zonder de waarde in te vullen, markeert het veld zich rood en verschijnt er een foutmelding.
Die directe feedback in de webinterface helpt gebruikers meteen corrigeren en vermindert het aantal onvolledige registraties.
Statisch versus dynamisch verplicht maken
Er zijn twee hoofdmethodes: een veld altijd verplicht maken (statisch) of het alleen verplicht maken onder specifieke voorwaarden (dynamisch), afhankelijk van andere veldwaarden op hetzelfde record.
Beide methodes zijn nuttig; welke je kiest hangt af van de logica van je proces.
Hoe het mechanisme precies werkt
Technische werking en waar je op moet letten
Handhaving op applicatieniveau
Een belangrijk punt dat voor velen onverwacht is: het required-attribuut wordt gecontroleerd door de Odoo applicatie (ORM), niet door de database zelf. De check gebeurt in Python vóórdat de data de database ingaat.
Standaard wordt er geen NOT NULL-constraint toegevoegd aan de PostgreSQL-kolom wanneer je required=True zet. De validatie gebeurt in de ORM-laag van Odoo zelf.
Dat betekent concreet: wie rechtstreeks in de database schrijft (buiten Odoo om) omzeilt deze controle. Werk daarom altijd via de ORM of de officiële API om te blijven rekenen op die bescherming.
Wat gebeurt er als de regel wordt overtreden?
Als een gebruiker een formulier probeert op te slaan terwijl een verplicht veld leeg is, gebeuren twee dingen:
- het veld krijgt in de interface een rode markering en er verschijnt een validatieboodschap
- de opslaan-actie wordt geblokkeerd totdat het veld ingevuld is
Als je de validatie programmeert (bijvoorbeeld via XML-RPC of serveracties), gooit Odoo een ValidationError met een foutmelding die aangeeft welk verplicht veld ontbreekt.
Dynamisch verplicht maken via voorwaarden
Binnen Odoo maak je een verplicht veld conditioneel met view-expressies. In oudere versies gebeurde dat met attrs in de view-XML,
bijvoorbeeld door een veld pas verplicht te maken als een ander veld een bepaalde waarde heeft.
In recentere Odoo-versies is de syntax eenvoudiger en kun je rechtstreeks een expressie op het veld zetten,
waardoor het verplichtheidscriterium leesbaarder en compacter in de view-definitie komt te staan.
Let op: zulke conditionele regels leven in de view-laag en niet in het model. Een model-level required=True is altijd bindend, view-level expressies gelden alleen binnen de specifieke interface waar ze staan.
Samenwerking met ORM en API
Wanneer je model.create() of model.write() aanroept, controleert de ORM vooraf alle velden met required=True. Als een verplicht veld ontbreekt of False is, komt er een ValidationError en wordt de bewerking afgebroken.
Dat geldt ook voor recordcreatie via de XML-RPC API: verplichte modelvelden moeten in de gevraagde data opgenomen zijn, anders faalt de call.
Wanneer bedrijven er baat bij hebben
Vijf praktische bedrijfsvoorbeelden
1) CRM: klantsegment verplicht maken op leads
Een salesorganisatie wil dat elke lead onmiddellijk een segment krijgt toegewezen, anders wordt later rapporteren per segment onbetrouwbaar omdat verkopers die stap soms overslaan.
Door een ‘Klantsegment’-veld verplicht te maken op het lead-formulier vang je dat probleem onmiddellijk af: geen segment = niet opslaan.
2) Verkoop: leveradres verplicht op verkooporders
Voor wie fysieke goederen verzendt is het leveradres cruciaal. Standaard is dat soms niet verplicht, waardoor orders bevestigd kunnen worden zonder adres.
Een verplicht leveradres op het verkooporder voorkomt dat een order wordt bevestigd zonder logistieke informatie, en vermindert fouten in de fulfilment.
3) Magazijn: lot- of serienummer verplicht bij ontvangst
In gereguleerde sectoren (voeding, farma, elektronica) is het bijhouden van lotnummers noodzakelijk. Odoo ondersteunt dit via producttracking, wat effectief vereist dat een lot/serie wordt opgegeven bij stockbewegingen.
Voor maatwerkvelden op ontvangstformulieren, zoals een kwaliteitsreferentie, zorgt een verplicht veld ervoor dat de warehousemedewerker de info nooit vergeet te registreren.
4) Boekhouding: kostplaats verplicht op leveranciersfacturen
Finance-teams hebben vaak elke kost naar een kostplaats moeten toewijzen. Zonder afdwinging blijven die velden soms leeg, wat budgetrapportage ondermijnt.
Een verplicht many2one-veld naar kostplaatsen op het leveranciersfactuurformulier zorgt dat geen factuur geboekt kan worden zonder die toewijzing — een eenvoudige wijziging met grote impact op datakwaliteit.
5) HR: contracttype verplicht vóór onboarden
HR wil vaak dat het contracttype vastligt voordat een personeelsrecord definitief wordt. Een verplicht veld op het personeelsformulier voorkomt dat onvolledige medewerkersrecords worden opgeslagen tijdens drukke onboardingprocessen.
Velden aanmaken of aanpassen: opties
Twee manieren om velden verplicht te maken
Gebruik van Odoo Studio (no-code)
Odoo Studio laat je zonder code veldeigenschappen aanpassen. Selecteer een veld en zet de ‘Verplicht’-schakelaar aan in het eigenschappenpaneel.
Dat schakelt in de meeste gevallen snel en eenvoudig het veld als verplicht in en is geschikt voor standaardvelden en custom velden die via Studio zijn toegevoegd.
Beperkingen: Studio zet doorgaans een statische verplichting. Voor conditionele verplichtingen op basis van andere velden moet je de view-XML aanpassen of de technische route kiezen.
Technische route: Python fields
In een custom module geef je een veld verplicht door required=True in de Python-definitie toe te voegen. Dit is de standaardaanpak bij ontwikkelaars,
en ziet er bijvoorbeeld uit als het definiëren van een Selection- of Many2one-veld met required=True zodat het altijd geldig is, ongeacht welke view wordt gebruikt.
Een model-level required is strikter: het geldt altijd, ongeacht welke interface of API gebruikt wordt om het record aan te maken.
Dynamisch verplicht maken in view-XML
Als je het verplicht maken slechts onder bepaalde voorwaarden wil toepassen, plaats je dat in de view-definitie in plaats van in het model.
In oudere Odoo-XML gebruikte je attrs om aan te geven wanneer een veld verplicht is,
terwijl
in nieuwere versies een meer leesbare expressie rechtstreeks op het veld mogelijk is.
Bedenk dat dit alleen geldt binnen de specifieke view waarin deze regel staat; het is geen universele modelconstraint.
Velden via de API aanmaken
Als je velden aanmaakt met de XML-RPC API op ir.model.fields, kun je meteen het required-attribuut meegeven. Dat is handig in geautomatiseerde deployments waar velden programmatisch worden aangemaakt.
Programmeervoorbeeld: bij het aanmaken van een veld geef je onder andere naam, type, label en required=True mee zodat de velddefinitie klaar is voor gebruik.
Op die manier creëer je het veld en de verplichting in één stap — handig voor geautomatiseerde installaties en migraties.
Aanbevolen werkwijzen
Gouden regels bij verplicht maken van velden
1) Maak alleen velden verplicht als het écht nodig is
Te veel verplichte velden is een veelvoorkomende fout. Als gebruikers geen correcte waarde hebben, vullen ze vaak tijdelijke of foutieve data in om verder te kunnen — wat je datakwaliteit schaadt.
Vraag jezelf af: is die info altijd beschikbaar bij het aanmaken? Als niet, overweeg om de verplichting pas later in het proces af te dwingen of maak het dynamisch verplicht.
2) Valideer per fase in plaats van vanaf het begin
Voor meervoudige workflows (bv. opportuniteiten of productieorders) is het vaak beter om verplichte checks te koppelen aan stadia. Gebruik Python-constraints of automatische acties die gecontroleerd worden bij stage-wijzigingen.
Dat is toegankelijker voor gebruikers dan alles direct verplicht te maken.
3) Gebruik standaardwaarden waar mogelijk
Als een verplicht veld in de meeste gevallen een voor de hand liggende waarde heeft, stel dan een default in. Dat verlaagt de frictie zonder de verplichting te ondermijnen.
4) Voor kritieke gegevens: geef model-level prioriteit
Voor echt cruciale gegevens (boekhoudidentificaties, wettelijke gegevens) zet de verplichting in het Python-model. View-only verplichtingen kunnen worden omzeild via API of alternatieve views.
5) Communiceer wijzigingen aan gebruikers
Als je nieuwe verplichte velden toevoegt op bestaande formulieren, informeer je gebruikers vooraf — vooral als bestaande records later foutmeldingen kunnen veroorzaken bij bewerking.
6) Test met lege en gedeeltelijke data
Test altijd je workflow met lege waarden en gedeeltelijke records, via web, API en eventuele integraties. Dat voorkomt verrassingen bij productie-uitrol.
Veelgemaakte fouten en valkuilen
Veelvoorkomende valkuilen en hoe ze te vermijden
Valstrik 1: verplicht maken op een model met al bestaande records
Als je required=True toevoegt op een model waarin duizenden records staan zonder die waarde, dan kunnen gebruikers bij de volgende bewerking niet meer opslaan. Migratie van bestaande data is dan noodzakelijk.
Controleer dus altijd eerst de bestaande data en vul waar nodig vooraf waarden in via een datamigratie.
Valstrik 2: view-level en model-level verwarren
Een verplicht veld in de view (Studio of XML) handhaaft niets buiten die view. API-aanroepen, imports of andere views omzeilen die regel. Heb je een harde vereiste nodig, zet required=True in de Python-definitie.
Dit misverstand veroorzaakt vaak datakwaliteitsproblemen in productie.
Valstrik 3: geautomatiseerde acties vergeten aan te passen
Automatiseringen die records aanmaken moeten alle verplichte velden meegeven. Als zo’n actie is geschreven voordat een veld verplicht werd, zal ze falen na de wijziging.
Controleer daarom alle schedulers, automatiseringen en serveracties na het invoeren van nieuwe verplichte velden.
Valstrik 4: importbestanden zonder verplichte velden
Bij CSV-imports of gebruik van het Odoo-importscherm zal het ontbreken van verplichte velden de import doen falen. Dat is correct, maar het verrast wie gewend is gedeeltelijke data te importeren.
Zorg dat je importtemplates altijd alle verplichte velden bevatten en documenteer wat vereist is in je importinstructies.
Valstrik 5: required gebruiken voor complexe validatie
required controleert alleen dat een veld niet leeg is; het valideert geen complexere regels of onderlinge consistentie. Voor dat soort businessregels gebruik je @api.constrains in Python.
Proberen alle logica in required te stoppen leidt tot starre configuraties die later moeilijk te onderhouden zijn.
Samenvatting
Verplichte velden blijven een van de eenvoudigste en tegelijk meest impactvolle tools in Odoo: goed gebruikt verbeteren ze datakwaliteit en procesbetrouwbaarheid; slecht gebruikt veroorzaken frustratie en rommelige data.
Belangrijk is het onderscheid tussen model- en view-level verplichtingen, zorgvuldigheid bij het kiezen welke velden echt verplicht moeten zijn en nadenken over effecten op API’s en automatiseringen.
Of je nu de developer-gids volgt, een maatwerkproject doet of wijzigingen doorvoert in Studio: inzicht in het required-mechanisme maakt het verschil tussen een robuuste Odoo-implementatie en een installatie die over maanden problemen oplevert.
Hulp nodig bij je Odoo-implementatie?
Bij Dasolo ondersteunen we bedrijven bij het implementeren, aanpassen en optimaliseren van Odoo — van simpele valideringen tot complexe datamodellen. We combineren functionele kennis met technische skills om duurzame oplossingen te bouwen.
Heb je vragen over verplichte velden of iets anders in je Odoo-omgeving? We denken graag met je mee. Neem contact met ons op en laten we samen bekijken wat je wil realiseren.