Inleiding
Als u ooit een formulier in Odoo heeft opgeslagen en een veld rood heeft zien worden, bent u al in contact gekomen met het vereiste veld mechanisme. Het is een van de meest fundamentele functies in het Odoo datamodel en een van de eenvoudigste manieren om de datakwaliteit in uw bedrijfsworkflows te waarborgen.
Of u nu Odoo configureert voor een verkoopteam, een aangepast model instelt of werkt aan een technisch Odoo-ontwikkelingsproject, het begrijpen van hoe de vereiste eigenschap werkt, zal u helpen om betrouwbaardere processen te bouwen.
Deze gids behandelt alles: hoe het veld zich gedraagt in het Odoo-framework, hoe het te configureren met Odoo Studio of Python-code, wanneer het te gebruiken, en welke fouten u moet vermijden.
Wat is het Vereiste Veld in Odoo
In Odoo is de required attribuut een veldniveau beperking die voorkomt dat een record wordt opgeslagen tenzij het veld een waarde bevat. Het is van toepassing op vrijwel alle Odoo-veldtypen: tekstvelden, numerieke velden, selectievakken, many2one-velden, datums en meer.
Het maakt deel uit van het kern Odoo-gegevensmodel en is een van de meest gebruikte attributen bij het aanpassen van Odoo. Een veld als verplicht instellen is de eerste verdedigingslinie tegen onvolledige of inconsistente gegevens in uw database.
Hoe het verschijnt in de interface
In de Odoo UI worden verplichte velden visueel onderscheiden van optionele. Wanneer een formulier in de bewerkingsmodus staat, tonen verplichte velden doorgaans een subtiele visuele indicator. Wanneer een gebruiker probeert het record op te slaan zonder een verplicht veld in te vullen, markeert Odoo het veld in het rood en toont een waarschuwingsbericht.
Dit gedrag is consistent in de webinterface. Gebruikers zien onmiddellijke, duidelijke feedback, wat de kans op het indienen van onvolledige records vermindert.
Statisch vs. Dynamisch Verplicht
Er zijn twee manieren om een veld verplicht te maken in Odoo. De eerste is een statisch verplicht: het veld is altijd verplicht, ongeacht wat. De tweede is een dynamisch verplicht: het veld wordt alleen verplicht wanneer aan bepaalde voorwaarden is voldaan, op basis van de waarden van andere velden op hetzelfde record.
Beide benaderingen worden regelmatig gebruikt in Odoo-ontwikkeling. De keuze hangt af van uw bedrijfslogica.
Hoe het Veld Werkt
Begrijpen hoe het required attribuut op technisch niveau werkt, helpt u het correct toe te passen en problemen op te lossen wanneer ze zich voordoen.
Toepassingsniveau Handhaving
Een belangrijk detail dat veel Odoo-gebruikers verrast: het required attribuut wordt gehandhaafd op het toepassingsniveau, niet op het databasenniveau. Dit betekent dat de beperking wordt gecontroleerd door de Odoo ORM wanneer een record wordt aangemaakt of geschreven, voordat de gegevens de database bereiken.
Er is geen NOT NULL beperking toegevoegd aan de onderliggende PostgreSQL-kolom standaard wanneer u required=True op een veld instelt. De validatie gebeurt in Python, binnen de Odoo ORM-laag.
In de praktijk betekent dit dat gegevens die rechtstreeks in de database worden ingevoerd (bypassing Odoo) niet door de vereiste beperking zullen worden opgevangen. Interageer altijd met uw Odoo-databasevelden via de ORM of de API om van deze bescherming te profiteren.
Wat Gebeurt Er Wanneer de Beperking Wordt Overtreden
Wanneer een gebruiker probeert een formulier op te slaan met een verplicht veld dat leeg is gelaten, gebeuren er twee dingen:
- Het veld wordt rood in de interface, en Odoo toont een validatiemelding
- De opslaanbewerking wordt geblokkeerd totdat het veld is ingevuld
Als u de validatie programmatisch activeert (bijvoorbeeld via de XML-RPC API of een serveractie), genereert Odoo een ValidationError met een bericht dat aangeeft welk verplicht veld ontbreekt.
Dynamisch Vereist Met Gebruik van Domeinen
In het Odoo-framework kan de required eigenschap voorwaardelijk worden gemaakt met behulp van expressies op het niveau van de weergave. In Odoo 16 en eerder gebeurt dit met de attrs eigenschap in de weergave-XML:
<field name="x_delivery_date" attrs="{'required': [('order_type', '=', 'delivery')]}" />In Odoo 17 en later is de syntaxis vereenvoudigd met een directe required expressie op de veldtag in de weergave:
<field name="x_delivery_date" required="order_type == 'delivery'" />Deze voorwaardelijke regels bevinden zich in de weergave-laag, niet in de model-laag. Dit is een belangrijk onderscheid: de model-niveau required=True handhaaft altijd de beperking, terwijl expressies op weergave-niveau alleen van toepassing zijn in specifieke interface-contexten.
Interactie met de ORM en API
In de Odoo ORM, wanneer je create() of write() aanroept op een model, controleert de ORM alle velden met required=True voordat de databasebewerking wordt uitgevoerd. Als een verplicht veld ontbreekt of is ingesteld op False, genereert Odoo een ValidationError.
Dit geldt ook wanneer records worden aangemaakt via de XML-RPC API. Elk veld dat als verplicht is gemarkeerd in de modeldefinitie moet worden verstrekt in de gegevensdictionary die aan de create methode wordt doorgegeven, anders zal de oproep mislukken met een foutmelding.
Zakelijke Gebruikscases
Verplichte velden komen overal in standaard Odoo voor en zijn even nuttig in aangepaste configuraties. Hier zijn vijf concrete voorbeelden uit echte bedrijfsworkflows waar het verplicht maken van een veld een wezenlijk verschil maakt.
1. CRM: Klantsegment Vereist op Leads
Een verkoopteam wil ervoor zorgen dat elke lead aan een klantsegment is toegewezen voordat deze naar de pijplijn wordt verplaatst. Zonder een verplicht veld slaan verkoopmedewerkers deze stap vaak over, waardoor het onmogelijk is om later rapportages over leadbronnen per segment te maken.
Door een aangepast "Klantsegment" selectievak als verplicht te markeren op het CRM leadformulier, zorgt het team ervoor dat de gegevens altijd op het moment van invoer worden vastgelegd. Geen segment, geen opslaan.
2. Verkoop: Leveringsadres Vereist op Bestellingen
Voor bedrijven die fysieke goederen verzenden, is het leveringsadres cruciaal. In sommige Odoo-configuraties is het leveringsadresveld standaard niet verplicht, wat betekent dat bestellingen kunnen worden bevestigd zonder een adres.
Het verplicht maken van het leveringsadresveld op het verkooporderformulier voorkomt dat de bestelling wordt bevestigd voordat het logistieke team de informatie heeft die ze nodig hebben. Dit elimineert een veelvoorkomende bron van fouten in het fulfilmentproces.
3. Voorraad: Lot- of Serienummer Vereist bij Ontvangst
Voor bedrijven die actief zijn in gereguleerde sectoren (voedsel, farmaceutica, elektronica) is het volgen van lotnummers op ontvangen goederen niet optioneel. Odoo ondersteunt dit van nature via de trackinginstelling op producten, wat effectief een verplicht lot- of serienummer afdwingt tijdens voorraadbewegingen.
Voor aangepaste velden op ontvangstformulieren, zoals een kwaliteitscontrole referentie, zorgt het verplicht stellen van het veld ervoor dat het magazijnteam nooit vergeet de informatie vast te leggen tijdens het ontvangstproces.
4. Boekhouding: Kostenplaats Vereist op Leveranciersfacturen
Financiële teams moeten vaak elke uitgave toewijzen aan een kostenplaats voor budgetbewaking. Zonder handhaving kunnen accountants of inkoopmanagers het veld leeg laten, wat leidt tot hiaten in de financiële rapportage.
Een verplicht many2one veld dat naar het kostenplaatsmodel verwijst, toegevoegd aan het leveranciersfactuurformulier, zorgt ervoor dat er geen factuur kan worden geboekt zonder deze toewijzing. Dit soort Odoo-aanpassing is snel te implementeren en heeft een directe impact op de volledigheid van gegevens.
5. HR: Contracttype Vereist Voor Onboarding
HR-teams die het onboardingproces van werknemers in Odoo beheren, willen vaak ervoor zorgen dat het contracttype wordt vastgelegd voordat het werknemersrecord wordt afgerond. Een verplicht veld op het werknemersformulier voorkomt dat het HR-team per ongeluk een incompleet werknemersrecord opslaat tijdens een drukke onboardingperiode.
Een Veld Maken of Aanpassen
Er zijn twee hoofdmanieren om een veld als verplicht te markeren in Odoo: gebruik maken van Odoo Studio voor een no-code benadering, of Python-code schrijven voor volledige controle. Beide zijn geldig, afhankelijk van uw context.
Gebruik Odoo Studio
Odoo Studio is de ingebouwde no-code tool waarmee je velden kunt configureren zonder enige ontwikkeling. Wanneer je Studio opent en een veld op een formulier selecteert, zie je een "Verplicht" schakelaartje in het eigenschappenpaneel van het veld aan de rechterkant.
Het inschakelen van deze schakelaar markeert het veld als verplicht in de weergave en slaat de beperking op modelniveau op. Dit is de snelste benadering voor eenvoudige gevallen en vereist geen technische kennis. Het werkt goed voor zowel standaard Odoo-velden als aangepaste velden die zijn toegevoegd via Odoo Studio-velden.
De beperking van Studio is dat het alleen een statische verplichte beperking configureert. Voor dynamisch verplichte gedragingen op basis van andere veldwaarden, moet je de weergave-XML rechtstreeks bewerken of de technische benadering gebruiken.
Technische Benadering: Python Velden
In een aangepaste Odoo-module is het declareren van een verplicht veld zo eenvoudig als het toevoegen van required=True aan de velddefinitie. Dit is het standaardpatroon in de ontwikkeling van Odoo Python-velden:
from odoo import fields, models
class SaleOrder(models.Model):
_inherit = 'sale.order'
x_customer_segment = fields.Selection(
selection=[
('smb', 'SMB'),
('enterprise', 'Enterprise'),
('public', 'Publieke Sector'),
],
string='Klantsegment',
required=True,
)
x_cost_center_id = fields.Many2one(
comodel_name='account.analytic.account',
string='Kostenplaats',
required=True,
)Met deze aanpak wordt de beperking afgedwongen op modelniveau, wat betekent dat deze van toepassing is ongeacht welke weergave of interface wordt gebruikt om het record aan te maken. Het kan niet worden omzeild door toegang te krijgen tot het record via een andere weergave.
Dynamisch Vereist in Weergave XML
Wanneer de vereiste beperking alleen onder bepaalde voorwaarden moet gelden, voeg deze dan toe op weergaveniveau in plaats van op modelniveau. In Odoo 16:
<field name="x_cost_center_id"
attrs="{'required': [('order_type', '=', 'invoiced')]}" />In Odoo 17:
<field name="x_cost_center_id"
required="order_type == 'invoiced'" />Dit is een beperking die alleen op weergaveniveau geldt. Het is minder strikt dan een verplichting op modelniveau, aangezien het alleen van toepassing is wanneer het record wordt bewerkt via de specifieke weergave die deze definitie bevat.
Vereiste Velden Aanmaken via de API
Als je de XML-RPC API gebruikt om velden aan te maken (zoals behandeld in andere artikelen in de Odoo Data & API-collectie), kun je required instellen bij het aanroepen van create op ir.model.fields. Dit maakt deel uit van de standaard Odoo-ontwikkelaarsgids voor programmatic customization:
models.execute_kw(ODOO_DB, uid, ODOO_API_KEY,
'ir.model.fields', 'create',
[{
'name': 'x_customer_segment',
'field_description': 'Klantsegment',
'model_id': model_id,
'ttype': 'selection',
'selection': "[('smb', 'SMB'), ('enterprise', 'Enterprise')]",
'required': True,
'state': 'manual',
}]
)Dit creëert het veld en handhaaft de vereiste beperking in één stap, wat nuttig is in geautomatiseerde implementatieworkflows voor het creëren van velden in Odoo-scenario's.
Beste Praktijken
Een veld als verplicht markeren lijkt eenvoudig, maar het goed gebruiken vergt enige nadenkwerk. Hier zijn de praktijken die je tijd zullen besparen en frustratie voor je gebruikers zullen voorkomen.
1. Maak Velden Alleen Verplicht Wanneer Ze Echte Verplichtingen Zijn
Te veel velden verplicht maken is een van de meest voorkomende configuratiefouten in Odoo. Als een gebruiker een formulier niet kan invullen omdat een veld verplicht is maar de informatie nog niet beschikbaar is, zullen ze alternatieven vinden (zoals het invoeren van tijdelijke waarden) die je gegevens kunnen corrumperen.
Voordat je een veld als verplicht markeert, vraag je af: is deze informatie altijd beschikbaar op het moment van invoer? Als het antwoord geen duidelijk ja is, overweeg dan om het verplicht te maken op een later moment (bijvoorbeeld bij bevestiging in plaats van bij creatie) of gebruik een dynamische verplichting in plaats daarvan.
2. Gebruik Fasegebaseerde Validatie In Plaats Van Altijd Verplicht
Voor workflows met meerdere stappen, zoals een CRM-kans of een productieorder, is het vaak beter om vereiste velden op specifieke momenten af te dwingen in plaats van vanaf het begin. Dit gebeurt meestal via Python-beperkingen of geautomatiseerde acties die veldwaarden controleren wanneer het record naar een bepaalde fase gaat.
Dit patroon is flexibeler en gebruiksvriendelijker dan elk veld vanaf dag één verplicht te maken.
3. Koppel Verplichte Velden Aan Standaardwaarden Waar Sensibel
Als een veld verplicht is en een redelijke standaardwaarde heeft voor de meeste gevallen, stel dan een default in op de velddefinitie. Dit vermindert wrijving voor gebruikers die de standaard niet hoeven te wijzigen, terwijl het nog steeds garandeert dat het veld nooit leeg is.
4. Geef Voorkeur Aan Modelniveau Verplicht Voor Kritieke Gegevens
Voor gegevens die echt kritisch zijn (zoals boekhoudinformatie, regelgevende identificatoren of verplichte identificatoren), handhaaf de beperking op modelniveau in Python in plaats van alleen op weergaveniveau. Beperkingen op weergaveniveau kunnen worden omzeild als een record wordt aangemaakt via de API of een andere weergave die de beperking niet bevat.
5. Communiceer Vereiste Velden aan Eindgebruikers
Wanneer je nieuwe vereiste velden toevoegt aan bestaande formulieren, kunnen gebruikers die halverwege een workflow zijn verrast zijn. Communiceer wijzigingen naar je team voordat je deze uitrolt, vooral als bestaande records mogelijk niet voldoen aan de validatie bij de volgende bewerking.
6. Test met Lege en Gedeeltelijke Gegevens
Voordat je een configuratie met nieuwe vereiste velden uitrolt, test altijd de volledige workflow met lege waarden en gedeeltelijke gegevens. Dit omvat testen via de webinterface, via de API, en via eventuele geautomatiseerde acties of integraties die records in Odoo aanmaken. Dit is een basisstap in elke verantwoordelijke Odoo technische tutorial.
Veelvoorkomende Valkuilen
Zelfs ervaren Odoo-implementators lopen tegen problemen aan met vereiste velden. Weten waar je op moet letten, bespaart debugtijd en voorkomt pijnlijke terugdraaien.
Valstrik 1: Een Veld Vereist Maken op een Model Dat Al Records Heeft
Als je required=True toevoegt aan een veld op een model dat al duizenden records bevat, en die records hebben geen waarde voor dat veld, kun je problemen tegenkomen wanneer die records de volgende keer worden bewerkt. Gebruikers kunnen geen wijzigingen opslaan totdat ze het nieuw vereiste veld invullen.
Controleer altijd of bestaande records al waarden hebben voordat je een vereiste beperking op een bestaand veld uitrolt. Als dat niet het geval is, voer dan eerst een gegevensmigratie uit om het veld te vullen.
Valstrik 2: Verwarrende Vereisten op Weergave- en Modelniveau
Een veld als vereist instellen in een weergave (of het nu via Studio of weergave-XML is) handhaaft de beperking niet op modelniveau. Een record dat via de API, een andere weergave of een import is aangemaakt, omzeilt volledig de vereiste beperkingen op weergaveniveau.
Als je een harde beperking nodig hebt, stel dan required=True in de Python-velddefinitie in. Dit is een vaak verkeerd begrepen punt in de Odoo-veld tutorialgemeenschap, en het veroorzaakt echte problemen met de gegevenskwaliteit in productie.
Valstrik 3: Vereiste Velden in Geautomatiseerde of Geplande Acties
Wanneer een geautomatiseerde actie of geplande actie records programmatisch aanmaakt, moet deze waarden voor alle vereiste velden opgeven. Als de actie is geschreven voordat een vereiste veld werd toegevoegd, zal deze stilletjes of met een cryptische fout beginnen te falen nadat de vereiste beperking is geïmplementeerd.
Controleer altijd alle geautomatiseerde recordcreatiecode na het toevoegen van een vereiste veld aan een bestaand model.
Valstrik 4: Gegevens importeren die vereiste velden missen
Bij het importeren van records via CSV of de Odoo-importtool zullen ontbrekende vereiste velden in het importbestand ervoor zorgen dat de import mislukt. Dit is eigenlijk het juiste gedrag, maar het verrast gebruikers die gewend zijn om gedeeltelijke gegevens te importeren.
Zorg ervoor dat alle vereiste velden in uw importtemplates zijn opgenomen. Het is een goede praktijk om te documenteren welke velden vereist zijn in uw richtlijnen voor gegevensimport.
Valstrik 5: Vereist gebruiken in plaats van een Python-beperking voor complexe validatie
De required eigenschap controleert alleen of een veld niet leeg is. Het valideert de inhoud of de relatie tussen velden niet. Voor meer complexe validatie (bijvoorbeeld ervoor zorgen dat een datum in de toekomst ligt, of dat twee velden consistent zijn), gebruik in plaats daarvan een @api.constrains decorator in Python.
Proberen om bedrijfslogica alleen in vereiste velden te coderen leidt tot inflexibele configuraties die moeilijk te onderhouden zijn.
Conclusie
De vereiste veld eigenschap is een van de eenvoudigste tools in Odoo, maar heeft een echte impact op de kwaliteit van uw gegevens. Goed gebruikt, zorgt het ervoor dat kritieke informatie altijd op het juiste moment in uw bedrijfsprocessen wordt vastgelegd. Slecht gebruikt, frustreert het gebruikers en creëert het oplossingen die uw gegevens minder betrouwbaar maken, niet meer.
De sleutel is om het verschil te begrijpen tussen vereiste beperkingen op modelniveau en op weergaveniveau, om bewust te zijn van welke velden echt handhaving nodig hebben, en om vooruit te denken over hoe de beperking zich zal gedragen in geautomatiseerde workflows en API-integraties.
Of u nu een Odoo-ontwikkelaarsgids volgt, een volledige Odoo-aanpassingsproject doet, of gewoon een formulier in Odoo Studio aanpast, het is de moeite waard om de vereiste eigenschap diepgaand te begrijpen. Het is een van die details die een schone Odoo-implementatie scheidt van een implementatie die zes maanden na de livegang hoofdpijn veroorzaakt.
Hulp Nodig bij Uw Odoo Implementatie?
Bij Dasolo helpen we bedrijven bij het implementeren, aanpassen en optimaliseren van Odoo in alle bedrijfsfuncties en niveaus van complexiteit. Of u nu hulp nodig heeft bij het ontwerpen van een solide datamodel, het configureren van validatieregels of het bouwen van aangepaste modules, ons team brengt zowel technische als functionele expertise naar elk project.
Als je vragen hebt over vereiste velden of een ander aspect van je Odoo-configuratie, helpen we je graag. Neem contact met ons op en laten we praten over wat je aan het bouwen bent.