Introduktion
En af de mindre synlige, men kraftfulde funktioner i Odoos datamodel er det virksomhedsafhængige felt. Det er et lille flag i feltdefinitionen, men i multiselskabsopsætninger kan det spare dig for duplikater, lange arbejdsprocesser og masser af fejlretning.
I standardopsætninger gemmer et felt ét enkelt svar for alle brugere. Problemet opstår, når flere juridiske enheder deler fx samme produkt, men hver enhed skal bruge egne referencenumre, kontoplanposter eller prislogikker — samme rekord, forskellige værdier. Her er almindelige felter utilstrækkelige.
Det virksomhedsafhængige felt løser præcis dét: det lader det samme felt holde forskellige værdier pr. selskab. Uanset om du laver udvikling, tilpasninger eller blot planlægger en multiselskabs-arkitektur i Odoo, er det afgørende at forstå denne egenskab.
Hvad er et virksomhedsafhængigt felt i Odoo
Kort sagt: et virksomhedsafhængigt felt gemmer en separat værdi for hver virksomhed, selvom der kun er én databasepost. En bruger i Firma A får Firma A’s værdi, mens en bruger i Firma B ser Firma B’s værdi — alt sammen på samme record.
For slutbrugeren føles det som et helt almindeligt felt i Odoo. Synligt sker intet specielt i brugerfladen; forskellen ligger i, hvordan Odoo gemmer og henter værdi afhængigt af virksomheds-konteksten.
Hvordan det ser ud i brugerfladen
I brugergrænsefladen adskiller et virksomhedsafhængigt felt sig ikke fra et normalt felt — der er ingen markør, der siger ’dette felt varierer per selskab’. Den gennemsigtighed er designet, så slutbrugeren ikke skal tænke over teknikken.
For udviklere kan company_dependent anvendes sammen med mange felt-typer: Char, Boolean, Integer, Float, Many2one osv. Det er tilføjelsen company_dependent=True i feltdeklarationen, der aktiverer adfærden i ORM’en.
I Odoo Studio findes nogle virksomhedsspecifikke felter allerede på standardmodeller (fx produktfelter til konti). Studio kan bruges til simple tilpasninger, men understøttelsen af netop denne attribut varierer mellem Odoo-versioner og har tekniske begrænsninger.
Hvordan feltet fungerer
Bag scenen opfører virksomhedsafhængige felter sig ikke som almindelige kolonner. Kendskab til, hvordan værdier lagres og hentes, hjælper med at undgå overraskelser, især ved fejlretning og datamigrering.
Lagring i ir.property
I Odoo 16 og tidligere bliver værdier for virksomhedsafhængige felter ikke lagret i modeltabellen, men i en separat systemtabel kaldet ir.property.
Hver post i ir.property knytter sammen:
- En konkret record (fx et produkt med id 42),
- Et konkret felt (fx property_account_income_id),
- En bestemt virksomhed,
- Og den faktiske værdi for den kombination.
Derfor er adfærden transparent: ORM’en sørger automatisk for at slå op i ir.property ud fra den aktive virksomheds-kontekst, når feltet læses eller skrives.
Ændringer i Odoo 17+
Fra Odoo 17 blev lagringen omlagt: virksomhedsspecifikke værdier gemmes nu direkte i modeltabellen i en jsonb-kolonne, hvor hver virksomheds værdi ligger som en nøgle i et JSON-objekt. Det gør opslag og rapporter meget hurtigere og enklere at arbejde med i stor skala.
Brugerfladen og det API, udviklere arbejder med, er uændret — forskellen er primært intern og forbedrer performance ved store datamængder.
Standardværdier
Virksomhedsafhængige felter understøtter også standardsætninger per virksomhed. Hvis en virksomhed ikke har en eksplicit værdi, falder feltet tilbage til feltets default. På Odoo 16 og tidligere håndteres sådanne defaults via ir.property; i Odoo 17+ kan standarden ligge direkte i modelens struktur.
Samspil med ORM’en
Når du arbejder i Odoos ORM, respekterer feltet altid den aktive virksomhed i miljøet (self.env.company). Det betyder konkret, at:
- Læsning returnerer værdien for den aktive virksomhed,
- Skrivning opdaterer kun værdien for den aktive virksomhed,
- Og du kan eksplicit læse eller skrive for en anden virksomhed via record.with_company(company).
Forretningsscenarier
Virksomhedsafhængige felter er ikke blot en nørdet detalje — de løser reelle problemer i multiselskabsopsætninger. Nedenfor er fem konkrete eksempler, hvor de er særligt nyttige.
1. Regnskab: Separate indtægts- og omkostningskonti pr. selskab
Et klassisk eksempel: produktfelterne property_account_income_id og property_account_expense_id er virksomhedsafhængige.
Praktisk betyder det, at to selskaber kan sælge samme produkt, men poste salget på hver deres kontoplan uden at duplikere produktet — produktposten er delt, regnskabsopsætningen er forskellig.
2. Salg og CRM: Forskellige prisstrategier pr. selskab
I en koncern med flere salgsenheder vil hver juridisk enhed ofte have sin egen prissætning. Et virksomhedsafhængigt prisfelt giver mulighed for, at en delt kunde kan have forskellige standardprislister afhængigt af, hvem der laver handlen.
Resultatet er centraliseret CRM-data med decentral kommerciel logik.
3. Lager: Forskellige værdiansættelsesmetoder pr. selskab
Når et lager drives i flere lande med forskellige regler, kan samme vare kræve FIFO i ét selskab og gennemsnitspris i et andet. Feltet gør det muligt at holde en enkelt produktkatalog samtidig med forskellige værdiansættelser.
4. Produktion: Forskellige leverandørforvalg pr. selskab
Hvis samme vare købes fra forskellige leverandører afhængig af hvilket juridisk selskab der køber, kan et virksomhedsafhængigt Many2one-felt pege på den foretrukne leverandør per enhed — uden konflikt i delt data.
5. Egne felter til regulatoriske krav
Koncerner på tværs af lande skal ofte opbevare landespecifikke referencer på samme post—fx forskellige HS-koder eller skattekategorier. Et virksomhedsafhængigt Char-felt er en enkel løsning uden at skulle oprette adskilte modeller.
Oprettelse og tilpasning
Der er to overordnede metoder til at oprette sådanne felter: via Odoo Studio eller ved at kode dem i Python som en del af et modul.
Brug af Odoo Studio
Studio gør det let at oprette felter uden kode, men ikke alle versioner giver et klart valg for company_dependent i UI. I Odoo 16 og 17 findes muligheden på nogle felttyper, men understøttelsen er ikke konsekvent.
Hvis du har behov for fuld kontrol (fx migrationsscripts, defaults per selskab eller komplekse relationer), er teknisk udvikling i et modul ofte mere robust end udelukkende Studio-tilpasninger.
Teknisk tilgang: Python-felter
I et tilpasset modul deklareres feltet som normalt i modellen — det er en lille ændring i feltdefinitionen, men ORM’en tager sig af resten.
Eksempelmønster i et modul:
Det eneste, der kræves, er at tilføje company_dependent=True i feltdeklarationen; Odoo håndterer lagring og opslag automatisk.
Sætte standardværdier per virksomhed
På Odoo 16 og tidligere kan du bruge ir.property til at sætte per-virksomhed defaults programmatisk — praktisk ved udrulning, så du undgår tomme værdier efter lancering.
Et typisk script kan sætte en default via ir.property._set_default(...) med virksomhedens id, så alle eksisterende records får en fornuftig standard for hver enhed.
I Odoo 17+ håndteres defaults mere direkte i modellen, hvilket forenkler både opsætning og fremtidige forespørgsler.
Studio-felter og begrænsninger
Husk at brugerdefinerede felter i Studio skal starte med x_-prefixet. Hvis company_dependent ikke vises i Studio, kan du stadig aktivere og administrere det fra de tekniske indstillinger, når udviklertilstand er slået til.
Gode fremgangsmåder
Arbejdet med virksomhedsafhængige felter bliver flydende, når du følger enkle retningslinjer. Her er anbefalinger, som sparer tid og fejl.
1. Brug det kun når værdien virkelig varierer pr. selskab
Introducer ikke virksomhedsspecifik kompleksitet unødigt. Hvis alle selskaber deler samme værdi, er et almindeligt felt klart bedre. company_dependent hører til, hvor variation er reel og nødvendig.
2. Test altid i et multi-company miljø
Udvikling og test skal foregå med mindst to aktive selskaber. Mange fejl viser sig først, når flere virksomheder benytter systemet samtidigt — test derfor i en realistisk kontekst.
3. Brug with_company() ved tvær-selskabelige operationer
Når din kode skal læse eller skrive for en anden virksomhed, brug record.with_company(target_company). Undgå at skifte miljøets company manuelt uden at gendanne det bagefter.
4. Vær forsigtig ved eksport og import
Eksport af virksomhedsafhængige felter afhænger af den bruger og det selskab, der foretager eksporten. Import under en anden virksomheds-kontekst skriver værdier for den virksomhed — planlæg derfor migrations- og importflow eksplicit.
5. Dokumentér hvilke felter der er virksomhedsafhængige
Slutbrugere kender sjældent til denne adfærd. En kort intern note i jeres Odoo-dokumentation eller onboarding forhindrer forvirring, når brugere skifter selskab og ser andre værdier.
6. Brug Many2one fremfor Char når data er struktureret
Hvis den per-virksomhedsværdi peger på en anden post (fx konto, prisliste, partner), så brug Many2one. Det bevarer dataintegriteten og gør rapportering langt nemmere.
Almindelige faldgruber
Selv erfarne udviklere møder ofte problemer med virksomhedsafhængige felter. Kend disse typiske fejl, så du slipper for spildt arbejde.
Fælde 1: Glemmer virksomheds-konteksten i automatiske handlinger
Schedulerede scripts og server actions kan køre under en uventet company-kontekst (ofte første company i DB). Hvis disse handlinger læser eller skriver virksomhedsafhængige felter, sæt konteksten eksplicit via with_company().
Fælde 2: Forveksler feltet med et beregnet felt
Virksomhedsafhængige felter er ikke computed fields — variationen kommer fra lagringen, ikke en compute-funktion. Forsøg på at kombinere compute= med company_dependent=True giver typisk uventet adfærd eller fejl.
Fælde 3: Søger på tværs af virksomheder uden at håndtere lagringen
Standard ORM-søgninger respekterer den aktuelle virksomhed og vil derfor ikke finde poster med værdier i andre selskaber. For tværgående søgninger kræves direkte arbejde mod ir.property (Odoo 16-) eller korrekt håndtering af jsonb-kolonnen (Odoo 17+).
Fælde 4: Ikke at sætte defaults for eksisterende selskaber
Når du tilføjer et virksomhedsafhængigt felt i et live-system, vil eksisterende poster være tomme for selskaber uden eksplicit værdi. Hvis din forretningslogik forventer en default, skræddersy en migrationsscript, så alle selskaber får en passende startværdi.
Fælde 5: Forveksling med adgangskontrol
Virksomhedsafhængige felter bestemmer hvilken værdi en bruger ser — ikke om brugeren overhovedet kan se feltet. Skal et felt skjules for bestemte selskaber eller roller, brug record rules eller feltbaserede adgangsrettigheder.
Konklusion
Det virksomhedsafhængige felt er en af de diskrete funktioner i Odoo, der virker usynlig indtil behovet opstår — og så bliver den uvurderlig. Når samme record skal bære forskellige værdier pr. juridisk enhed — konti, priser, regulatoriske koder eller andre virksomhedsspecifikke attributter — er det det rigtige værktøj.
At forstå lagringsmodellen, versionsforskellene og faldgruberne sparer rigtig meget tid i multiselskabsprojekter. Uanset om du møder det i en udviklermanual eller i en produktionstjek, er kendskabet til disse felter et tegn på solid Odoo-kompetence.
Hvis du bygger videre på Odoo og har brug for en ryddelig, vedligeholdelsesvenlig måde at håndtere per-virksomhedsdata på, så er company_dependent=True ofte den løsning, du mangler.
Brug for hjælp til jeres Odoo-implementering?
Hos Dasolo hjælper vi virksomheder med at implementere, tilpasse og optimere Odoo — også i komplekse multiselskabsscenarier. Vi kan hjælpe med datamodellering, feltstrategi, migrationer og fulde udrulninger, så I får en robust og effektiv løsning.
Har du spørgsmål om virksomhedsafhængige felter eller andre aspekter af jeres Odoo-setup, står vi klar til at rådgive. Kontakt os og lad os tage en snak om, hvad I er i gang med at bygge.