Innledning
Et lite, ofte oversett element i Odoo er attributtet som gjør et felt «selskapsspesifikt». Det er en teknisk detalj som for mange virksomheter endrer hvordan data deles når flere juridiske enheter jobber mot samme database.
I en standard Odoo-installasjon har hvert felt én verdi per post som gjelder for alle brukere. Problemet oppstår når samme produkt eller kunde skal brukes av flere selskaper, men hver enhet trenger egne innstillinger — for eksempel unike interne referanser eller regnskapskontoer.
Det er her company_dependent-ideen kommer inn: den lar samme databasepost inneholde ulike verdier avhengig av hvilken selskapssammenheng brukeren arbeider i. Enten du utvikler moduler, tilpasser standardoppsett eller kartlegger datastruktur, er forståelsen av dette nødvendig i multiselskapsscenarier.
Hva er et selskapsspesifikt felt i Odoo
Et selskapsspesifikt felt betyr enkelt sagt at feltverdien kan variere per firma på samme post. Når en bruker i Selskap A ser posten, får de A sin verdi. Bruker i Selskap B ser en helt annen verdi, selv om posten fysisk er den samme i databasen.
For sluttbrukeren føles dette som et vanlig felt — samme brukergrensesnitt og samme interaksjon. Forskjellen ligger i hvordan Odoo lagrer og henter verdier bak kulissene via ORMen.
Hvordan det ser ut i grensesnittet
I brukergrensesnittet er det ingen visuell markør som sier «dette er selskapsspesifikt». Det er bevisst: løsningen skal være sømløs for de som jobber daglig i systemet, og adskillelsen skjer automatisk ut fra aktivt selskap i miljøet.
Fra utviklersiden kan dette anvendes på flere felttyper: tekstfelt, boolske, heltall, flyttall, Many2one-relasjoner med mer. Det som slår på funksjonaliteten er å deklarere feltet som company_dependent i feltdefinisjonen — så tar ORMen seg av resten.
I Odoo Studio finnes enkelte standardfelter med denne oppførselen, for eksempel produktfelt relatert til regnskap. Muligheten for å lage egendefinerte selskapsspesifikke felter via Studio varierer mellom versjoner, så for avanserte tilpasninger er kodedrevet utvikling ofte mer stabilt.
Hvordan feltet fungerer
Under panseret er lagringslogikken helt annerledes enn vanlige felt, og det er nyttig å kjenne mekanismene for å unngå overraskelser ved utvikling eller feilretting.
Lagring i ir.property (eldre versjoner)
I Odoo 16 og tidligere blir selskapsspesifikke verdier ofte ikke lagret i modellens egen tabell, men i en separat systemtabell kalt ir.property. Dette gir en slags «metadataboks» som holder verdier per felt og selskap.
Hver post i ir.property knytter sammen følgende elementer:
- En bestemt databasepost (for eksempel produkt med id 42)
- Et bestemt felt (for eksempel property_account_income_id)
- En gitt bedrift eller selskap
- Og selve verdien for den kombinasjonen
ORM-en sørger for å lese og skrive til ir.property basert på aktivt selskap, noe som gjør at sluttbrukeren opplever det som en vanlig feltverdi.
Endringer fra Odoo 17 og senere
Fra og med Odoo 17 ble lagringsstrategien endret: selskapsspesifikke verdier kan nå ligge direkte i modelltabellen i en jsonb-kolonne, hvor hver nøkkel representerer en selskapsspesifikk verdi. Dette gir raskere søk og enklere indeksering ved store datamengder.
API-et og hvordan du bruker feltet forblir likt for utviklere, men ytelsen på spørringer mot slike felter forbedres betydelig i nyere versjoner.
Standardverdier per selskap
Feltet kan ha ulike standardverdier per selskap. Hvis ingen verdi er satt for et selskap, faller feltet tilbake til et definert default. I eldre versjoner administreres dette ofte via ir.property; i nyere versjoner kan defaults være lagret mer direkte på modellen eller som del av feltdefinisjonen.
Interaksjon med ORMen
Alle lese- og skriveoperasjoner mot et selskapsspesifikt felt respekterer selskapssammenhengen i miljøet (self.env.company). Dette betyr blant annet:
- Lesing gir verdien for aktivt selskap
- Skriving oppdaterer kun aktivt selskaps verdi
- Hvis du trenger å manipulere en annens selskaps verdi, bruk record.with_company(target_company) for å gjøre det eksplisitt
Forretningsscenarier
Dette er ikke bare en teknisk kuriositet — feltet løser konkrete behov i selskaper som deler data, og bidrar til enklere modellering uten duplisering. Her er typiske bruksområder hvor det er særlig nyttig.
1) Regnskap: egne kontoer per selskap
Et klassisk eksempel er produktkontoene: income- og expense-kontoer på produkt kan være ulike per juridisk enhet, men du ønsker ett felles produktregister.
I praksis deler forretningsenhetene produktet, men hver har egne regnskapslinjer. Dermed slipper du å opprette separate produktposter for hvert selskap.
2) Salg og CRM: prisstrategier per selskap
En konserngroup kan ha ulike prisstrategier for samme kunde eller produkt. Et selskapsspesifikt prisfelt lar samme kundepost inneholde ulike standardprislister, avhengig av hvilken enhet som håndterer salget.
Dette holder CRM-data sentralt samtidig som hver enhet får sine kommersielle regler intakte.
3) Lager: verdsettelsesmetode per selskap
Ved drift i flere land kan varebeholdning kreve ulik kostnadsmetode (for eksempel FIFO vs. snitt). Å styre dette per selskap på produkt- eller kategorinivå unngår å måtte duplisere produktkatalogen.
4) Produksjon: foretrukket leverandør per enhet
Hvis samme vare kjøpes fra forskjellige leverandører avhengig av hvilket selskap som bestiller, kan et selskapsspesifikt Many2one-felt peke til riktig res.partner per selskap — uten konflikt i delt data.
5) Juridiske og regulatoriske felt
Internasjonale grupper trenger ofte land- eller selskapsspesifikke referanser på produkter, som HS-koder eller skattekategorier. Å bruke et selskapsspesifikt tekstfelt gir en enkel og lite ressurskrevende løsning på dette.
Opprette eller tilpasse feltet
To hovedveier til å opprette slike felt finnes: via Odoo Studio eller gjennom tradisjonell Python-utvikling i en modul.
Bruke Odoo Studio
Studio gir en enkel måte å legge til felter uten koding, men synligheten for selskapsspesifikk funksjonalitet varierer mellom versjoner. Noen felttyper eksponeres med denne muligheten i Studio i nyere versjoner, men ikke alle miljøer får det fullt ut.
For avanserte krav eller når du trenger presis kontroll over metadata, er teknisk utvikling ofte å foretrekke. Studio er fint for raske tilfeller, men har begrensninger ved mer komplekse tilpasninger.
Teknisk tilnærming: Python-felt
I en egendefinert modul deklarerer du feltet i modellen på vanlig måte, men legger til company_dependent=True på feltdefinisjonen. Mønsteret er enkelt og standard i Odoo-utvikling.
Et typisk eksempel i en modul vil være å utvide en eksisterende modell og legge til tekst- eller Many2one-felt med company_dependent-flagget slik at hver juridisk enhet får sin egen verdi per post.
Det eneste du trenger er å sette company_dependent=True i feltdeklarasjonen; ORMen tar seg av lagring og oppslag automatisk.
Sette standardverdier per selskap
I eldre Odoo-versjoner håndteres selskapsvise defaults via ir.property, og du kan sette disse programmatisk for å sikre fornuftige verdier uten å oppdatere hvert enkelt objekt manuelt.
Et eksempel på å sette en default via ir.property viser hvordan du kan sørge for at nye og eksisterende poster får forventet startverdi per selskap uten manuelle inngrep.
I Odoo 17+ skjer mye av denne logikken mer direkte i modellens struktur, noe som forenkler hvordan defaults administreres teknisk.
Studio-felter og begrensninger
Husk at egendefinerte felt i Studio må bruke x_-prefikset, og at selskapsspesifikk oppførsel noen ganger kun er synlig via teknisk meny med utviklermodus skrudd på. Dette er viktig å kommunisere til administratorer som jobber i Studio.
Gode fremgangsmåter
Arbeidsmåter som sparer tid
Bruk feltet bare når det faktisk trengs — unngå unødvendig kompleksitet ved å flagge felt som selskapsspesifikke hvis verdien er lik for alle enheter.
Hvis en verdi er felles for hele konsernet, hold den som et vanlig felt. company_dependent bør reserveres for tilfeller med reelle forskjeller mellom selskaper.
Test alltid i multiselskapsscenarioer
Utvikling og testing må skje mot minst to aktive selskaper. Feil og antakelser som ikke vises i et enkelt-selskap testmiljø dukker ofte opp når flere selskaper er i bruk i produksjon.
Bruk with_company() ved kryss-selskapsoperasjoner
Når koden skal lese eller skrive på vegne av et annet selskap, benytt record.with_company(target_company) for å være eksplisitt og unngå å slå over miljøets company uten å sette det tilbake.
Vær forsiktig ved eksport og import
Eksport av selskapsspesifikke felter gir verdier sett fra brukerens selskap. Import under et annet selskap vil tolkes som verdier for det selskapet. Dette er ofte ønsket oppførsel, men krever bevissthet i migrasjoner og masseimporter.
Dokumenter hvilke felt som er selskapsspesifikke
Sluttbrukere vet sjelden hvilke felter som endres når de bytter selskap. En enkel oversikt i intern dokumentasjon eller opplæringsmateriell sparer mye forvirring og supporthenvendelser.
Foretrekk Many2one for strukturerte referanser
Når verdien peker på en annen post (som konto, prisliste eller leverandør), er det bedre å bruke et Many2one-felt med company_dependent enn å lagre navnet som tekst. Det gir renere datamodell og mer pålitelig rapportering.
Vanlige fallgruver
Typiske fallgruver utviklere møter
1) Glemt selskapskontekst i automatiske jobber
Planlagte jobber og server actions kan kjøre i et annet selskapskontekst enn forventet, ofte første selskap i databasen. Derfor må slike skript eksplisitt ivareta with_company hvis de manipulerer selskapsspesifikke felt.
2) Feil antakelse om at feltet er beregnet
Selskapsspesifikke felt er ikke computed-felt. Forsøk på å kombinere compute= med company_dependent=True skaper ofte problemer fordi variasjonen ligger i lagringen, ikke i en beregningsmetode.
3) Søk på tvers av selskaper er ikke standard
Vanlige ORM-søk vil bare gi resultater for aktivt selskap. Hvis du trenger tverrselskaps-søk må du enten spørre ir.property direkte i eldre versjoner eller håndtere jsonb-strukturen i nyere versjoner — dette er en vanlig kilde til forvirring i rapporter.
4) Manglende defaults for nye selskaper
Når et selskapsspesifikt felt introduseres i et levende system, vil selskaper uten eksplisitt verdi få None eller False. Hvis forretningslogikk forventer en verdi, sett defaults for alle relevante selskaper gjennom migrasjonsskript.
5) Forveksle verdi-variasjon med tilgangskontroll
company_dependent styrer hvilken verdi som vises, ikke hvem som kan se feltet. Hvis du skal skjule et felt for enkelte brukere eller selskaper, bruk tilgangsregler eller feltbasert sikkerhet i stedet.
Oppsummering
Kort sagt er selskapsspesifikke felt en funksjon som først virker usynlig, men som blir uunnværlig i riktig kontekst. De gjør det mulig å dele masterdata uten å miste fleksibiliteten hver juridisk enhet trenger.
Kjennskap til hvordan ORMen håndterer disse feltene, hvilken Odoo-versjon som bruker hvilken lagringsmekanikk, og hvilke fallgruver som finnes, vil spare tid og redusere risiko i multiselskapprosjekter. Å mestre denne biten er et klart profesjonelt fortrinn ved implementasjoner og drift.
Når du trenger å håndtere per-selskap data på en ryddig måte i Odoo, er company_dependent=True ofte den riktige løsningen.
Trenger du hjelp med Odoo-implementasjonen din?
Hos Dasolo bistår vi med implementasjon, tilpasning og optimalisering av Odoo for selskaper i alle størrelser, inkludert komplekse multiselskap-oppsett. Vi hjelper med datamodell, feltstrategi og komplette utrullinger for å sikre riktig arkitektur og drift.
Har du spørsmål om selskapsspesifikke felt eller andre deler av Odoo-implementasjonen din, så hjelper vi gjerne. Ta kontakt med oss så tar vi en prat om hva dere ønsker å bygge.