Inleiding
Een vaak over het hoofd gezien, maar krachtig onderdeel van het Odoo-datamodel is het zogenaamde company dependent-veld. Het lijkt klein in syntaxis, maar levert grote voordelen zodra je met meerdere vennootschappen binnen één database werkt.
Normaal gesproken bevat elk veld op een record één waarde die door iedereen wordt gezien. Maar in een situatie waarbij twee juridische entiteiten hetzelfde product gebruiken, kan elke entiteit andere interne referenties, rekeningen of standaardinstellingen nodig hebben. Dan voldoet één universele waarde niet meer.
Dat is precies waar de attribute company_dependent voor ontworpen is. Of je nu ontwikkelt, aanpast of simpelweg met Odoo experimenteert: wie multi-company oplossingen bouwt, plukt veel sneller resultaat met dit veldtype.
Wat is een company dependent-veld in Odoo?
Een company dependent-veld slaat voor hetzelfde record verschillende waarden op, één per bedrijfseenheid. Een gebruiker die aangemeld is bij Vennootschap A ziet de waarde van A; een gebruiker bij Vennootschap B ziet de waarde van B.
Voor de eindgebruiker gedraagt het veld zich als elk ander veld in de interface. De bijzondere logica speelt zich af in de onderliggende ORM-laag, onzichtbaar maar bepalend voor het resultaat.
Weergave in de interface
In de Odoo-interface lijkt een company dependent-veld identiek aan een regulier veld. Er staat geen visuele markering bij om aan te geven dat de getoonde waarde companiespecifiek is — dat is bewust zo, om de gebruikservaring eenvoudig te houden.
Voor ontwikkelaars is belangrijk te weten dat dit veldtype kan worden toegepast op veel standaardveldtypes: Char, Boolean, Integer, Float, Many2one, enzovoort. De toevoeging company_dependent=True in de velddefinitie activeert deze behaviour in de ORM.
Sommige standaardvelden met companiespecifieke waarde zijn al zichtbaar in Odoo Studio (bijvoorbeeld productvelden voor boekhoudrekeningen). Het aanmaken van custom company dependent-velden via Studio is mogelijk, maar in bepaalde Odoo-versies is de ondersteuning beperkt.
Hoe het veld werkt
Technisch gezien werkt het heel anders dan een gewoon veld. Wie begrijpt hoe de opslag en opvraging gebeuren, voorkomt verrassingen bij ontwikkeling en debugging.
Opslagmechanisme en ir.property
In Odoo 16 en eerdere versies worden waarden van company dependent-velden niet in de tabel van het model zelf bewaard, maar in een aparte systeemtabel: ir.property.
Elke rij in ir.property koppelt namelijk:
- Een specifiek record (bijvoorbeeld product met id 42),
- Een specifiek veld (zoals property_account_income_id),
- Een specifieke vennootschap,
- En de waarde die bij die combinatie hoort.
Daarom lijkt de waarde transparant voor gebruikers: de ORM leest en schrijft automatisch in ir.property, afhankelijk van welke company in de context actief is.
Wat er veranderde in Odoo 17 en later
Vanaf Odoo 17 werd dit ontwerp aangepast. Company dependent-waarden worden nu rechtstreeks in de modeltabel bewaard via een jsonb-kolom, waarin per-company waarden als een JSON-object worden opgeslagen. Dat versnelt queries en vereenvoudigt opslag.
De gebruikersinterface en het ontwikkelaars-API bleven grotendeels hetzelfde, maar performance en schaalbaarheid werden duidelijk verbeterd.
Standaardwaarden
Company dependent-velden ondersteunen companiespecifieke standaardwaarden. Als voor een bedrijf nog geen expliciete waarde bestaat, valt het veld terug op de default die op het veld zelf gedefinieerd is. In oudere versies gebeurt dat via ir.property; vanaf Odoo 17 gebeurt dat meer rechtstreeks op het model.
Interactie met de ORM
Binnen de Odoo-ORM respecteert het uitlezen en wegschrijven van zo'n veld altijd de actieve company in de omgeving (self.env.company). Dat betekent onder meer:
- Lezen levert de waarde voor de actieve vennootschap op;
- Schrijven verandert alleen de waarde voor die actieve vennootschap;
- Met record.with_company(company) kun je specifiek lezen of schrijven voor een andere vennootschap.
Praktische bedrijfsgevallen
Company dependent-velden zijn geen academische curiositeit: ze lossen concrete problemen op in multi-company omgevingen. Hieronder vind je veelvoorkomende scenario's waarin ze van pas komen.
1. Boekhouding: aparte inkomsten- en kostrekeningen per vennootschap
Een klassiek voorbeeld: productvelden zoals property_account_income_id en property_account_expense_id zijn companiespecifiek.
Concreet: twee bedrijven verkopen hetzelfde artikel, maar werken met verschillende rekeningschema's. In plaats van het product te dupliceren, configureert elk bedrijf zijn eigen boekhoudregel. Het product blijft gedeeld, de boekhouding niet.
2. Sales & CRM: per-company prijslijsten
Binnen een groep kunnen verkoopstrategieën per entiteit verschillen. Een gedeelde klant kan daardoor voor bedrijf A een andere standaardprijslijst tonen dan voor bedrijf B.
Dat houdt klantdata gecentraliseerd terwijl elke entiteit toch haar eigen commerciële regels hanteert.
3. Voorraad: per-company waarderingsmethode
Logistiek over meerdere juridische entiteiten kan vereisen dat eenzelfde product in het ene land FIFO gebruikt en in een ander land gemiddelde kostprijs. Companiespecifieke velden op product of categorie vermijden duplicatie van het hele assortiment.
4. Productie: per-company voorkeurssupplier
Als elk bedrijf binnen de groep producten bij andere leveranciers bestelt, kan een Many2one company dependent-veld naar res.partner de preferente leverancier per entiteit bewaren. Iedereen ziet zijn eigen voorkeur zonder conflictsituaties.
5. Regelgeving: per-company compliancegegevens
Internationaal opererende groepen hebben vaak jurisdictiespecifieke referenties nodig (bv. HS-codes, lokale belastingclassificaties). Een companiespecifiek Char-veld is een compacte manier om zulke data te beheren zonder aparte modellen te maken.
Een dergelijk veld aanmaken of aanpassen
Er zijn twee gebruikelijke methodes om dergelijke velden toe te voegen: via Odoo Studio of rechtstreeks via Python in een module.
Velden maken met Odoo Studio
Studio maakt het mogelijk velden toe te voegen zonder code. Let wel: niet alle Studio-versies tonen expliciet een switch voor company_dependent. In Odoo 16 en 17 vind je de optie soms bij het aanmaken van velden op standaardmodellen.
Voor volledige controle en voorspelbare resultaten is technische ontwikkeling vaak betrouwbaarder. Studio werkt prima voor eenvoudige gevallen, maar loopt tegen limieten aan in complexe aanpassingen.
Technische aanpak: Python-velden
In een custom module is het toevoegen van een company dependent-veld een eenvoudige wijziging in de velddefinitie. Dit is de gangbare aanpak bij ontwikkeling met Odoo Python-velden:
Je voegt in je modeldeklaratie een veld toe en zet company_dependent=True zodat de ORM het juiste opslag- en leesgedrag toepast (bijv. een Char- of Many2one-veld met companiespecifieke waarde).
Het enige dat je hoeft toe te voegen is company_dependent=True; de ORM regelt opslag en terughalen voor je.
Standaardwaarden instellen per vennootschap
In Odoo 16 en eerder zet je companiespecifieke defaults via ir.property. Dat is handig als je voor alle records binnen een vennootschap een startwaarde wilt instellen zonder elk record afzonderlijk te updaten.
Met ir.property kun je programmatisch een default instellen voor een veld en een specifiek model, gekoppeld aan een company_id.
Vanaf Odoo 17 worden defaults ook meer direct op het model en veldniveau opgeslagen, wat beheer eenvoudiger maakt.
Beperkingen van Odoo Studio-velden
Onthoud dat custom velden in Studio het x_-voorvoegsel moeten hebben. Het companiespecifieke gedrag verschijnt niet altijd in de Studio-UI, maar is vaak wel bereikbaar via het technische menu wanneer ontwikkelaarsmodus actief is.
Aanbevolen werkwijzen
Praktische aanbevelingen
1. Gebruik het alleen als waarden echt per vennootschap verschillen
Company dependent-velden brengen extra complexiteit met zich mee. Als de waarde identiek is voor alle bedrijven, houd het dan bij een gewoon veld. Zet company_dependent alleen waar meerdere waarden per record echt nodig zijn.
2. Test altijd in een multi-company scenario
Bouw en test met minstens twee actieve bedrijven. Problemen die in een single-company omgeving onzichtbaar blijven, duiken vaak direct op zodra je meerdere bedrijven activeert.
3. Gebruik with_company() voor acties over bedrijven heen
Als je vanuit code waarden voor een andere vennootschap moet lezen of schrijven, werk dan met record.with_company(target_company). Vermijd het handmatig wisselen van self.env.company zonder correcte herstelstap.
4. Let op bij import en export
Exportbestanden bevatten de waarden van de company van de exporterende gebruiker. Importeren onder een andere company-context schrijft die waarden naar die company. Maak duidelijke afspraken bij migraties en data-imports.
5. Documenteer welke velden companiespecifiek zijn
Gebruikers weten zelden welke velden per company verschillen. Een kort stukje in je interne handleiding of onboarding voorkomt verwarring wanneer gebruikers van company wisselen en andere waarden zien.
6. Gebruik Many2one voor verwijzingen in plaats van losse tekst
Als de per-company waarde naar een ander record verwijst (rekening, prijslijst, partner), kies dan voor een Many2one company dependent-veld. Dat houdt je datamodel strak en verbetert rapportage.
Veelvoorkomende valkuilen
Veelvoorkomende problemen en hoe ze te vermijden
Valkuil 1: de company-context vergeten in geautomatiseerde acties
Scheduled en server actions draaien soms in de context van de eerste company in de database. Controleer expliciet welke company actief is als je company dependent-velden leest of schrijft en gebruik with_company() waar nodig.
Valkuil 2: het veld verwarren met een berekend veld
Company dependent-velden zijn geen compute-velden. Het verschil per company komt door opslag, niet door een compute-functie. Proberen compute= te combineren met company_dependent kan foutmeldingen of onvoorspelbaar gedrag veroorzaken.
Valkuil 3: zoeken over bedrijven heen
Standaard ORM-searches houden rekening met de actieve company. Als je over alle vennootschappen wilt zoeken, moet je ir.property direct bevragen (Odoo 16-) of de jsonb-structuur zorgvuldig benaderen (Odoo 17+). Dit is een veelvoorkomende bron van verwarring bij rapportages.
Valkuil 4: geen defaults voor alle companies instellen
Wanneer je een company dependent-veld toevoegt in een live omgeving, retourneren bestaande records False/None voor bedrijven zonder waarde. Als je logica een default verwacht, zet die defaults vooraf via een data-migratiescript.
Valkuil 5: verwarring met toegangsrechten
Company dependent-velden bepalen welke waarde wordt getoond, niet wie het veld mag zien. Als je een veld volledig wilt verbergen voor bepaalde bedrijven of gebruikers, regel dat met record rules of rechten op veldniveau, niet met company_dependent.
Slotwoord
Samengevat: het company dependent-veld is onopvallend totdat je het nodig hebt — daarna blijkt het vaak onmisbaar. Het is de juiste keuze wanneer hetzelfde record voor verschillende vennootschappen andere instellingen of referenties moet dragen, bijvoorbeeld in boekhouding, prijsbeleid, compliance of leveranciersinformatie.
Wie begrijpt hoe de opslag werkt, welke versie van Odoo welk opslagmodel gebruikt en welke valkuilen te vermijden, bespaart veel tijd bij multi-company projecten. Kennis van dit veldtype is een praktisch pluspunt voor elke Odoo-specialist.
Als je op het Odoo-platform werkt en per-company data netjes wilt beheren, is company_dependent=True precies het gereedschap dat je zoekt.
Hulp nodig bij je Odoo-implementatie?
Bij Dasolo ondersteunen we organisaties bij het inrichten, aanpassen en optimaliseren van Odoo, ook voor complexe multi-company landschappen. Of je nu een aangepast datamodel, een veldstrategie of een volledige uitrol nodig hebt: ons team combineert functionele en technische ervaring om het goed aan te pakken.
Heb je vragen over company dependent-velden of andere onderdelen van je Odoo-implementatie? We denken graag met je mee. Contacteer ons en laten we bespreken wat jij wil opbouwen.