Fält Beroende Av Företag i Odoo — Så Fungerar Det och När Använda

Introduktion

En funktion som ofta förbises i Odoos datamodell är det företagsspecifika fältet. Det är en liten inställning som blir avgörande i miljöer där flera juridiska enheter delar samma databastabeller.

I standardfall lagrar ett fält ett enda värde per post som alla användare ser. Problemet uppstår när samma produkt ägs av flera bolag men varje bolag måste ha egna internkoder, konton eller standardinställningar — då räcker inte en enda global kolumn.

Det är precis här attributet company_dependent kommer in. Oavsett om du utvecklar egna moduler, gör anpassningar eller bara planerar struktur för en koncern, ger en förståelse för detta fälttyp dig bättre kontroll i multi‑company‑projekt.

Vad betyder ett företagsspecifikt fält i Odoo?

Ett företagsspecifikt fält innebär att samma databaspole kan innehålla olika värden beroende på vilken firma som läser posten. Användare i företag A ser sitt värde, medan användare i företag B ser ett annat — allt på samma post.

I gränssnittet beter sig fältet som vilket annat fält som helst. Skillnaden ligger i hur Odoos ORM hämtar och sparar värdena bakom kulisserna.

Hur det visas i gränssnittet

I Odoos UI syns ingen särskild markör som berättar att värdet är företagsspecifikt. Det är avsiktligt — användaren ska inte behöva tänka på lagringslogik, de ser bara sitt företags värde.

För utvecklare kan company_dependent användas på många fälttyper: Char, Boolean, Integer, Float, Many2one med flera. Det är flaggan company_dependent=True som aktiverar det särskilda beteendet i ORM:en.

I Odoo Studio dyker en del företagsspecifika fält upp på standardmodeller (till exempel produktfält för konton). Studio kan användas för enklare fall, men ibland saknas stöd för att slå på detta attribut i vissa Odoo‑versioner.

Hur fältet fungerar

Under ytan sparas och hämtas företagsspecifika värden annorlunda än vanliga kolumner. Att känna till mekaniken minskar risken för överraskningar vid utveckling och felsökning.

Lagring i ir.property

I Odoo 16 och tidigare sparas inte företagsspecifika värden i modellens egen tabell. Istället används systemtabellen ir.property för att hålla per‑företag‑värden.

Varje rad i ir.property länkar ihop:

• En specifik post (t.ex. produkt med id 42),
• Ett specifikt fältnamn (t.ex. property_account_income_id),
• En specifik firma,
• Och det faktiska värdet för den kombinationen.

Detta förklarar transparensen: ORM:en läser och skriver mot ir.property baserat på aktuell företagskontext utan att användaren ser extra fält i modellens tabell.

Förändringar i Odoo 17 och senare

Från och med Odoo 17 ändrades lagringsmodellen. Företagsspecifika fält sparas nu i modellens egen tabell i en jsonb‑kolumn, där varje företagsvärde ligger som en post i ett JSON‑objekt — vilket ger betydligt bättre prestanda och enklare frågor mot databasen.

Gränssnittet och API:erna för utvecklare ser i stort sett likadana ut, men sökningar och massoperationer blir snabbare i stora installationer.

Standardvärden

Företagsspecifika fält kan ha standards värden per företag. Om inget företagsspecifikt värde satts används fältets standardvärde. I Odoo 16 ställs detta ofta via ir.property, medan Odoo 17+ hanterar defaults mer direkt på modellen.

Interaktion med ORM:en

När du arbetar i Odoos ORM respekteras alltid den aktiva företagskontexten (self.env.company) för företagsspecifika fält. Det betyder att:

• Läsning returnerar värdet för det aktiva företaget,
• Skrivning uppdaterar endast värdet för det aktiva företaget,
• Och du kan växla kontext med record.with_company(company) för att läsa eller skriva för ett annat företag.

Affärsscenarier där det används

Detta är inte bara en teknisk finess; företagsspecifika fält löser konkreta problem i verksamheter med flera bolag. Nedan följer vanliga situationer där de gör verklig nytta.

1. Redovisning: separata intäkts- och kostnadskonton per företag

Ett klassiskt exempel är att produktens income/expense‑konton varierar mellan bolag — därför är dessa fält företagsspecifika i standard‑Odoo.

Praktiskt: två bolag säljer samma artikel men har olika kontoplaner. Istället för att duplicera produkten kan varje bolag ha sina egna konton kopplade till samma produktpost.

2. Försäljning och CRM: prislistor per bolag

I en koncern kan varje säljbolag ha sin prissättning. Genom att göra prislistan företagsspecifik kan en gemensam kundpost innehålla olika standardprislistor för varje bolag som handlägger affären.

Det håller CRM‑datan samlad samtidigt som varje bolag styr sin kommersiella logik.

3. Lager: värderingsmetod per bolag

När lager sprids över olika juridiska enheter kan krav skilja sig — en produkt kan värderas med FIFO i ett land och genomsnittlig kostnad i ett annat. Företagsspecifika inställningar för produkt eller kategori undviker behovet av separata kataloger.

4. Produktion: standardleverantör per bolag

Om samma artikel köps från olika leverantörer beroende på bolag kan ett företagsspecifikt many2one‑fält (mot res.partner) peka på rätt leverantör för varje enhet utan konflikt.

5. Anpassade fält för regelverk och efterlevnad

Koncerner som verkar i flera länder behöver ofta lagra landsspecifika referenser — till exempel olika HS‑koder eller skatteklassificeringar. Ett företagsspecifikt textfält är en lättviktslösning som undviker modellduplication.

Skapa eller anpassa fältet

Det finns två huvudsakliga sätt att skapa sådana fält: via Odoo Studio eller genom att deklarera dem i Python i en modul.

Skapa via Odoo Studio

Studio låter dig lägga till fält utan kod, men alla versioner exponerar inte alltid en tydlig inställning för company_dependent. I Odoo 16–17 kan alternativet finnas på vissa fälttyper, men stödet varierar mellan versionerna.

För komplexa anpassningar är teknisk utveckling ofta säkrare. Studio passar bra för snabba, enkla fält men når sina begränsningar i mer avancerade scenarier.

Teknisk metod: Python‑fält

I en egen modul är det enkelt att deklarera ett företagsspecifikt fält i modelldefinitionen — det är standardmönstret för utvecklare.

Exempel i kod (konceptuellt):
from odoo import fields, models

class ProductTemplate(models.Model):
    _inherit = 'product.template'

    x_internal_ref = fields.Char(
        string='Intern referens (per företag)',
        company_dependent=True,
    )

    x_preferred_carrier_id = fields.Many2one(
        comodel_name='res.partner',
        string='Föredragen transportör',
        company_dependent=True,
    )

Att lägga company_dependent=True i fältdeklarationen är ofta allt som krävs — ORM:en sköter den fortsatta hanteringen.

Sätta standardvärden per företag

I Odoo 16 och tidigare används ir.property för att sätta företagsvisa standardvärden utan att uppdatera varje enskild post. Det är praktiskt vid rollout eller migrering.

Exempel på hur man sätter default via ir.property (konceptuellt):
self.env['ir.property']._set_default(
    'x_internal_ref',
    'product.template',
    'DEFAULT-VALUE',
    company_id=self.env.company.id,
)

I Odoo 17+ lagras default oftare direkt på modellen, vilket förenklar hanteringen.

Begränsningar i Odoo Studio

När du skapar anpassade fält via Studio måste du använda x_‑prefixet. Företagsspecifikt beteende syns inte alltid i Studio‑gränssnittet, men kan konfigureras via tekniska inställningar i utvecklarläge när det behövs.

God praxis

Att arbeta med företagsspecifika fält blir smidigt när du följer några etablerade rutiner. Här är rekommendationer som minskar riskerna.

1. Använd bara när värden faktiskt varierar per företag

Ett företagsspecifikt fält ökar komplexiteten. Om värdet är samma i hela koncernen använd ett vanligt fält istället — company_dependent hör hemma där flera bolag verkligen behöver skilda värden.

2. Testa alltid i multi‑company‑miljö

Bygg och testa med minst två aktiva företag. Problem som inte syns i en single‑company‑dev kan dyka upp direkt i produktion om du missar kontexten.

3. Använd with_company() för operationer över företag

När du behöver läsa eller skriva för ett annat bolag, använd record.with_company(target_company) och undvik att manuellt byta miljökonteksten utan att återställa den.

4. Var försiktig vid export och import

Export visar värden för det företag som användaren är inloggad i. Om du importerar samma fil under ett annat företag kommer värdena sättas för det företaget — planera dataflöden och migrationer därefter.

5. Dokumentera vilka fält som är företagsspecifika

Slutanvändare vet sällan vilka fält som varierar per bolag. En kort anteckning i intern dokumentation eller onboarding minskar förvirring när värden skiljer sig åt vid bolagsbyte.

6. Föredra Many2one framför text för strukturerad data

Om värdet pekar på en annan post (konto, prislista, partner) är en företagsspecifik Many2one bättre än att lagra namn i textformat — det håller modellen ren och rapporteringen pålitlig.

Vanliga fallgropar

Trots erfarenhet stöter även rutinerade utvecklare på problem. Här är vanliga fallgropar att ha koll på.

Fallgrop 1: Glömma företagskontext i automatiska åtgärder

Schemalagda eller server‑actions körs ofta i en standard‑kontext (t.ex. första företaget i databasen). Kontrollera alltid företag innan du läser eller skriver företagsspecifika fält — använd with_company() för att vara tydlig.

Fallgrop 2: Förväxla med beräknade fält

Företagsspecifika fält är inte computed‑fält. Variation sker genom lagring, inte genom ett compute‑anrop. Kombinationer med compute= brukar ge oväntade fel och fungerar inte som man tror.

Fallgrop 3: Söka över bolagsgränser

Vanliga ORM‑sökningar returnerar bara resultat för aktuell firma. Om du behöver rapportera över alla bolag måste du antingen läsa ir.property direkt (Odoo 16 eller äldre) eller hantera jsonb‑kolumnen korrekt i Odoo 17+.

Fallgrop 4: Inte sätta default för alla bolag

När ett företagsspecifikt fält införs i ett live‑system kommer befintliga poster sakna värde för företag som inte explicit fått ett värde — vilket kan bli None/False. Sätt standardvärden per företag vid rollout via en migrationsscript om affärslogiken kräver det.

Fallgrop 5: Förväxla med behörigheter

Ett företagsspecifikt fält styr vilket värde som visas, inte vilka användare som kan se fältet. Om du vill dölja fält för vissa företag eller roller behövs record rules eller fältbehörigheter, inte company_dependent.

Sammanfattning

Ett företagsspecifikt fält är en diskret men kraftfull funktion i Odoo: osynlig tills den behövs, oumbärlig när samma post ska bära olika värden i olika juridiska enheter — allt från redovisning och prissättning till regulatoriska fält.

Att förstå lagringsmekanismen, versionsskillnaderna och de typiska fallgroparna sparar mycket tid i multi‑company‑projekt. Oavsett om du hittar detta i dokumentation eller när du felsöker en produktion, är kunskap om company_dependent ett tecken på kunnande inom Odoo.

Om du bygger på Odoo‑plattformen och behöver hantera per‑företagsdata på ett rent och skalbart sätt är company_dependent=True ofta rätt verktyg.

Behöver du hjälp med din Odoo‑implementation?

På Dasolo hjälper vi företag att implementera, anpassa och optimera Odoo för allt från enkla installationer till komplexa multi‑company‑landskap. Vi täcker datamodell, fältstrategi och hela rollout‑projektet med både teknisk och funktionell kompetens.

Har du frågor om företagsspecifika fält eller andra delar av din Odoo‑lösning, så berättar vi gärna hur vi kan hjälpa till. Kontakta oss så tar vi ett samtal om vad du vill bygga.