Johdanto
Yksi Odoon tietomallin vähemmän esitellyistä, mutta käytännössä hyödyllisistä ominaisuuksista on yhtiökohtainen kenttä. Pieneen määritteeseen piilee suuri vaikutus, kun järjestelmässä ajetaan usean yhtiön toimintaa samaan aikaan.
Useimmiten tietueen kenttä kantaa yhtä arvoa, jonka kaikki järjestelmän käyttäjät näkevät. Moniyhtiöympäristössä kuitenkin sama tuotekortti voi palvella eri laskentakäytäntöjä tai sisäisiä tunnisteita: miten siis ylläpidetään yhtä tuotetta, mutta eri yhtiöillä omat tilikoodit tai oletusasetukset?
Tähän tarpeeseen vastaa company_dependent‑attribuutti. Kun työskentelet Odoo‑kehityksen, muokkauksen tai arkkitehtuurin parissa, tämän kenttätyypin ymmärtäminen helpottaa merkittävästi moniyhtiöisten ratkaisujen suunnittelua.
Mikä on yhtiökohtainen kenttä Odoossa
Yhtiökohtainen kenttä tarkoittaa sitä, että samaan tietueeseen tallennetaan eri yhtiöille omat arvonsa. Käyttäjä, joka työskentelee yhtiö A:n kontekstissa, näkee oman arvonsa; käyttäjä yhtiö B:stä näkee toisen arvon — kaikki samalla tietueella.
Käyttäjälle kenttä näyttää ja käyttäytyy tavalliselta kentältä. Ero löytyy tietokannan ja Odoon ORM‑tason käsittelystä: taustalla tapahtuu arvojen valinta yhtiökontekstin perusteella.
Kuinka se näkyy käyttöliittymässä
Käyttöliittymässä yhtiökohtainen kenttä ei eroa muista kentistä — ei mitään näkyvää tunnistetta kerroksena yhtiökohtaisuudesta. Tämä on suunniteltua: loppukäyttäjä ei tarvitse erityistä tietoa kentän taustalla toimivasta logiikasta.
Kehittäjän näkökulmasta company_dependent‑ominaisuus voidaan liittää monen tyyppisiin kenttiin: Char, Boolean, Integer, Float, Many2one ja muihin. Kun kenttään lisätään company_dependent=True, ORM alkaa käsitellä arvoa yhtiökohtaisesti.
Odoo Studiossa joissakin vakiomalleissa on valmiiksi yhtiökohtaisia kenttiä, erityisesti tuotteisiin liittyvissä tilikentissä. Studio mahdollistaa myös omien kenttien luomisen, mutta kaikkien Odoo‑versioiden Studio‑käyttöliittymä ei aina näytä tätä attribuuttia selkeästi.
Miten kenttä toimii
Taustalla toimiva mekanismi poikkeaa huomattavasti peruskenttien tallennustavasta. Jos tiedät, miten arvot varastoidaan ja haetaan, vältät yllätyksiä muokkauksissa ja vikojen etsinnässä.
Tallennus ir.property‑tauluun
Odoo 16:ssa ja sitä vanhemmissa versioissa yhtiökohtaiset arvot eivät sijaitse alkuperäisen mallin taulussa. Ne tallennetaan järjestelmätauluun ir.property, joka linkittää kentän, tietueen ja yhtiön arvoon.
Jokainen ir.property‑merkintä yhdistää seuraavat tiedot:
- Tietyn tietueen (esim. tuote, ID 42)
- Tietyn kentän (esim. property_account_income_id)
- Tietyn yhtiön
- Ja kyseiselle yhdistelmälle kuuluva arvon
Tästä syystä käyttäjäkokemus on saumaton: ORM huolehtii ir.property‑taulun hakemisesta ja päivityksestä automaattisesti kulloisenkin yhtiökontekstin perusteella.
Muutokset Odoo 17+:ssa
Odoo 17:stä lähtien tallennusmalli uudistettiin. Yhtiökohtaiset kentät voidaan tallentaa suoraan mallin tauluun jsonb‑sarakkeeseen, jossa jokaisen yhtiön arvot säilytetään JSON‑sanakirjana. Tämä parantaa suorituskykyä ja tekee kyselyistä yksinkertaisempia suuressa mittakaavassa.
Käyttäjärajapinta ja kehittäjän API säilyvät samankaltaisina, mutta suorituskyky ja skaalautuvuus paranevat merkittävästi uusilla tallennusmenetelmillä.
Oletusarvot
Yhtiökohtaiset kentät tukevat yhtiökohtaisia oletusarvoja. Jos kyseiselle yhtiölle ei ole asetettu arvoa, kenttä voi pudota kenttätason tai ir.property:n määrittelemään oletukseen (Odoo 16 ja aiemmat) tai mallin kenttämäärittelyssä olevaan oletukseen (Odoo 17+).
Vuorovaikutus ORM:n kanssa
ORM‑kontekstissa yhtiökohtaisen kentän käsittely kunnioittaa aina nykyistä yhtiötä (self.env.company). Tämä tuottaa selkeän käyttäytymismallin:
- Kentän lukeminen palauttaa aktiivisen yhtiön arvon
- Kirjoitusmuutokset koskevat vain aktiivisen yhtiön arvoa
- Kontekstin vaihtaminen record.with_company(company) avulla mahdollistaa lukemisen tai kirjoittamisen tietylle yhtiölle
Liiketoimintatapaukset
Yhtiökohtainen kenttä ei ole pelkkä tekninen kuriositeetti — se ratkaisee käytännön ongelmia moniyhtiöasennuksissa. Seuraavassa viisi tavallista käyttötapausta, joissa se on hyvin hyödyllinen.
1. Kirjanpito: yhtiökohtaiset tulos‑ ja kulutilit
Tämä on kentän yleisin käyttötapa Odoossa. Esimerkiksi product.template‑mallin property_account_income_id ja property_account_expense_id ovat yhtiökohtaisia.
Käytännössä sama tuote voi myydä eri yhtiöissä, joilla on omat tilikartat. Kun tuote on yhteinen, tilikoodit voidaan määrittää yhtiökohtaisesti ilman tuotteen duplikaattien luomista.
2. Myynti ja CRM: yhtiökohtaiset hinnastot
Moniyhtiöisessä konsernissa eri myyntiyksiköillä voi olla omat hinnastopolitiikkansa. Hinnasto kenttänä per yritys mahdollistaa, että yhteinen asiakaskortti kantaa eri oletushinnastot riippuen siitä, mikä yhtiö myyntiä käsittelee.
Tällä tavoin CRM‑tiedot pysyvät keskitettyinä, mutta kaupalliset säännöt voivat poiketa yhtiöittäin.
3. Varasto: yhtiökohtainen varaston arvostusmenetelmä
Erilaiset säädökset ja käytännöt voivat edellyttää, että sama tuote arvostetaan eri yhtiöissä eri menetelmillä (esim. FIFO vs. keskihinta). Yhtiökohtaiset kentät tuotteella tai kategoriassa estävät koko tuoteluettelon monistamisen.
4. Valmistus: yhtiökohtainen oletus toimittaja
Jos eri yhtiöt ostavat saman tuotteen eri toimittajilta, yhtiökohtainen Many2one‑kenttä (res.partner) voi pitää jokaisen yhtiön suosikkitoimittajan erikseen. Näin kukin yhtiö näkee oman toimittajansa ilman ristiriitoja.
5. Sääntelyyn liittyvät mukautetut kentät
Kansainvälisissä toimijoissa samoihin tietoihin täytyy usein kiinnittää maan/yrityksen mukaisia sääntelytietoja, kuten eri HS‑koodit tai veroasetukset. Yhtiökohtainen Char‑kenttä on kevyt ja siisti tapa ylläpitää näitä arvoja ilman mallien monistamista.
Kentän luominen tai muokkaaminen
Yhtiökohtaisen kentän voi lisätä kahdella päämenetelmällä: Odoo Studiolla tai teknisesti Python‑koodilla moduulissa.
Odoo Studion käyttö
Studio mahdollistaa kenttien luomisen ilman koodia, mutta kaikkia versioita ja kenttätyyppejä ei välttämättä paljasteta Studio‑UI:ssä company_dependent‑kytkimenä. Odoo 16 ja 17 tarjoavat tätä vaihtoehtoa joissakin tilanteissa, mutta ei aina täyden hallinnan tasolla.
Jos tarvitset varmaa ja kontrolloitua ratkaisua, koodipohjainen kehitys on luotettavampi. Studio soveltuu hyviksi prototyyppaukseen ja yksinkertaisiin tapauksiin, mutta monimutkaisemmat vaatimukset vaativat teknistä muokkausta.
Tekninen tapa: Python‑kentät
Oma moduuli tarjoaa suoran tavan määritellä kenttä company_dependent‑attribuutilla. Tämä on tavallinen käytäntö Odoo‑kehityksessä.
Esimerkki Python‑määrittelystä voi näyttää tältä:
Lisäämällä company_dependent=True kenttädefinitioon ORM hoitaa yhtiökohtaisen käsittelyn automaattisesti.
Oletusarvojen asettaminen yhtiöittäin
Odoo 16:ssa ja aiemmissa oletusarvoja yhtiötasolle voi asettaa ir.propertyn kautta. Tämä on kätevää, kun haluat, että tietylle yhtiölle asetetaan järkevä yleisarvo ilman, että kävisit läpi kaikkia tietueita.
Esimerkkinä ir.property‑oletuksen asettaminen voidaan tehdä ohjelmallisesti, jolloin uusi yhtiö saa halutun oletusarvon helposti.
Odoo 17+:ssa oletusarvot tallennetaan suoremmin malliin ja ovat osa kenttädefinitiota, mikä yksinkertaistaa hallintaa.
Studio‑kentät ja niiden rajoitukset
Studiossa mukautettavat kentät vaativat x_‑etuliitteen. Yhtiökohtaisen käyttäytymisen näkyvyys Studio‑UI:ssä voi olla rajallinen, mutta kehittäjänäkymä (kehittäjätila) antaa pääsyn tekniseen konfiguraatioon asetusten kautta.
Hyvät käytännöt
Kun työskentelet yhtiökohtaisten kenttien kanssa, muutama toimintatapa säästää aikaa ja estää virheitä.
1. Käytä sitä vain kun arvot eroavat yhtiöittäin
Yhtiökohtainen kenttä lisää rakennetta ja hallinnollista taakkaa. Jos arvo on sama kaikille yhtiöille, riittää tavallinen kenttä. Käytä company_dependent=True vain silloin, kun arvo aidosti vaihtelee yhtiöittäin.
2. Testaa aina moniyhtiötilanteessa
Kehityksessä ja testauksessa käytä vähintään kahta yhtiötä. Moni bugi jää huomaamatta yksiyhtiöisessä ympäristössä, mutta ilmenee heti tuotannossa moniyhtiöasetuksessa.
3. Käytä with_company() ristiinyhtiötoiminnoissa
Kun koodisi lukee tai kirjoittaa toisen yhtiön arvoja, record.with_company(target_company) on turvallinen tapa. Älä vaihda ympäristön yhtiötä manuaalisesti ilman, että palautat sen ennalleen.
4. Huomioi viennit ja tuonnit
Kun viet dataa, yhtiökohtaiset kentät heijastavat vientihetken yhtiö kontekstia. Tuotaessa sama tiedosto eri yhtiössä, import asettaa arvot tuontiyhtiölle — tämä voi olla tahdottua, mutta kannattaa määritellä selkeästi siirrossa ja migraatiossa.
5. Dokumentoi, mitkä kentät ovat yhtiökohtaisia
Loppukäyttäjät harvoin tietävät, mitkä kentät muuttuvat yhtiön vaihtuessa. Lyhyt merkintä käyttöohjeissa tai onboarding‑materiaalissa välttää sekaannusta, kun samaan tietueeseen liittyvät arvot vaihtuvat yhtiön vaihtuessa.
6. Käytä Many2one‑suhdetta tekstin sijaan rakenteelliseen tietoon
Jos arvo viittaa toiseen tietueeseen (esim. tiliin, hinnastoon, toimittajaan), käytä Many2one‑kenttää yrityskohtaisena sen sijaan, että tallentaisit nimen tekstinä. Se pitää tietomallin eheänä ja raportoinnin luotettavana.
Yleiset sudenkuopat
Jopa kokeneet kehittäjät kompastuvat yhtiökohtaisten kenttien sudenkuoppiin. Tässä muutama yleinen virhelähde, joita kannattaa varoa.
Sudenkuoppa 1: unohtuu huomioida yhtiökonteksti automatisoiduissa toiminnoissa
Ajastetut toiminnot ja server actionit voivat ajaa kontekstissa, jossa aktiivinen yhtiö ei ole se, mitä odotat. Varmista aina, että automatisoidut skriptit käyttävät oikeaa yhtiökontekstia, ja käytä tarvittaessa with_company():a.
Sudenkuoppa 2: kenttää ei pidä käsitellä kuin laskettua kenttää
Yhtiökohtaiset kentät eivät ole compute‑kenttiä — niiden perusero on tallennuksessa, ei laskennassa. Yrityksen arvojen tuottaminen compute‑parametrilla ei korvaa company_dependent‑ominaisuutta ja voi aiheuttaa virheitä.
Sudenkuoppa 3: haku eri yhtiöiden yli
ORM‑haut palauttavat oletuksena vain aktiivisen yhtiön mukaiset rivit. Jos sinun pitää hakea kaikkien yhtiöiden arvot, sinun täytyy joko kysyä ir.property‑taulua (Odoo 16 ja aiemmat) tai käsitellä jsonb‑saraketta oikein (Odoo 17+). Tämä on yleinen yllätyksen aihe raportoinnissa.
Sudenkuoppa 4: oletusarvojen puuttuminen uusille yhtiöille
Kun lisäät yhtiökohtaisen kentän jo toimivaan järjestelmään, olemassa oleville riveille ei välttämättä ole arvoa uusille yhtiöille. Ne palauttavat False/None, ellei oletuksia ole asetettu. Migraatio‑skripti kaikkien yhtiöiden oletusarvojen asettamiseksi on usein tarpeen.
Sudenkuoppa 5: sekoittaminen käyttöoikeuksiin
Yhtiökohtaiset kentät määrittävät, mikä arvo näkyy, eivätkä ne estä kentän näkymistä kokonaan. Jos kenttä pitää piilottaa tietylle yhtiölle tai käyttäjäryhmälle, käytä record ruleja tai kenttäkohtaisia käyttöoikeuksia — ei company_dependent‑asetusta.
Yhteenveto
Yhtiökohtainen kenttä on usein näkymätön—kunnes tarvitset sitä. Silloin se on korvaamaton työkalu tilanteissa, joissa sama tietue tarvitsee kulloinkin yhtiökohtaisen arvon: kirjanpito, hinnastot, sääntelytiedot tai yhtiökohtaiset liiketoimintatiedot.
Kun tunnet tallennusmallin erot eri Odoo‑versioissa ja osaat välttää tyypilliset virheet, säästyt useilta tunteilta ja koodipulmilta moniyhtiöprojekteissa. Sekä devausvaiheessa että tuotantovirheitä selvittäessä tämä osaaminen näkyy heti.
Jos haluat hallita yhtiökohtaisia arvoja siististi Odoossa, company_dependent=True on oikea ratkaisu useimpiin tilanteisiin.
Tarvitsetko apua Odoo‑implementaatiossasi?
Me Dasololla autamme yrityksiä ottamaan Odoon käyttöön, muokkaamaan sitä ja optimoimaan monimutkaiset moniyhtiöasetukset. Tarjoamme sekä teknistä että toiminnallista osaamista, olipa kyse kenttästrategiasta, tietomallin suunnittelusta tai koko käyttöönotosta.
Jos kysymyksiä heräsi yhtiökohtaisten kenttien tai muun Odoo‑implementaation suhteen, autamme mielellämme. Ota meihin yhteyttä Keskustellaan projektistasi ja katsotaan, miten voimme auttaa.