Hver bedrift er forskjellig. Teamet ditt sporer informasjon som ingen standardprogramvare forutser, og det er akkurat der tilpassede felt i Odoo kommer inn.
I stedet for å tvinge arbeidsflytene dine til å passe inn i en rigid datamodell, lar Odoo deg legge til nye felt til nesten hvilken som helst post, enten det er en kunde, en salgsordre, et produkt eller en faktura. Du bestemmer hva slags data som skal fanges, og Odoo lagrer det sammen med alt annet.
Denne guiden dekker alt du trenger å vite: hva tilpassede felt er, hvordan de fungerer under panseret, hvordan du oppretter dem med eller uten kode, og hvordan du bruker dem på en måte som holder Odoo-instansen din ren og vedlikeholdbar.
Hva er et tilpasset felt i Odoo
Et tilpasset felt er et databasefelt du legger til en eksisterende Odoo-modell, utover det som følger med standard. Det lagrer et spesifikt stykke informasjon knyttet til en post, akkurat som et innebygd felt ville gjort.
I Odoo identifiseres tilpassede felt med x_-prefikset. Felt opprettet gjennom Odoo Studio bruker navn som x_studio_priority_level, mens felt som legges til programmessig kan bruke et prefiks spesifikt for prosjektet ditt, som x_dasolo_cost_center.
Fra brukergrensesnittet ser et tilpasset felt ut og oppfører seg akkurat som et standardfelt. Det kan vises i skjemaer, listevisninger, filtre, gruppering-alternativer og rapporter. Brukere som ikke kjenner den tekniske siden vil aldri merke forskjellen.
Tilgjengelige felttyper
Odoo støtter et bredt spekter av felttyper for tilpassede felt, som dekker de fleste databehov:
- Tekst (Char): Kort tekst, som en referansekode eller en etikett
- Lang tekst: Flerlinjers fri tekst for notater eller beskrivelser
- Heltall: Hele tall, nyttige for tellinger eller poeng
- Desimal (Float): Tall med desimaler, for målinger eller satser
- Monetær: Valuta-bevisst beløp, knyttet til et valutafelt
- Boolean: En sann/usann avkrysningsboks
- Dato / Dato & Tid: Kalenderdato eller tidsstempel
- Valg: En fast nedtrekksliste med alternativer
- Mange-til-en: En lenke til en enkelt post i en annen modell
- One2many: En liste over relaterte poster fra en annen modell
- Many2many: Flere poster knyttet fra en annen modell
- Binary: Filvedlegg
- HTML: Rikt tekstinnhold
Å velge riktig felttype fra starten av sparer mye problemer senere. Et valgfelt er nesten alltid bedre enn et fritekstfelt når settet av mulige verdier er kjent på forhånd.
Hvordan feltet fungerer
Odoo er bygget på et rammeverk kalt Odoo ORM (Object-Relational Mapping). Hver form, listevisning og post du ser i grensesnittet er støttet av en Python-modell som kartlegger til en databasetabell. Når du legger til et tilpasset felt, registrerer Odoo det i ORM og oppretter den tilsvarende kolonnen i PostgreSQL automatisk.
Dette er hva som gjør Odoo datamodell fleksibel: du endrer ikke kildekoden. Du utvider modellen gjennom et metadata-lag lagret i ir.model.fields-tabellen. Odoo leser den tabellen ved oppstart og bygger feltene dynamisk.
Felter Definert i Kode vs. Felter Definert i Databasen
I standard Odoo utvikling defineres felter direkte i Python-modellklasser ved hjelp av Odoo rammeverket. En typisk feltdedefinisjon ser slik ut ut:
from odoo import models, fields
class SaleOrder(models.Model):
_inherit = 'sale.order'
cost_center = fields.Char(string='Kostnadssenter')Tilpassede felter opprettet via UI eller API følger en annen vei: de lagres med state = 'manual' i ir.model.fields og lastes inn ved kjøring. Begge tilnærmingene produserer en ekte databasokolonne og oppfører seg identisk fra brukerens perspektiv.
Relasjonelle Felter og Gjensidighet
Når du oppretter et Many2one tilpasset felt som peker til en annen modell, forventer Odoo et matchende One2many felt på den andre siden. Dette er ikke bare en konvensjon: det er hvordan Odoo ORM navigerer i relasjoner mellom poster.
For eksempel, hvis du legger til et x_project_id (Many2one til project.project) på en salgsordre, bør du også legge til x_sale_order_ids (One2many tilbake til sale.order) på prosjektmodellen. Uten dette er navigering fra prosjektet til dets tilknyttede ordrer ikke mulig gjennom standardgrensesnittet.
Beregnet Tilpassede Felt
Odoo beregnede felt er felt hvis verdi beregnes automatisk basert på andre felt, i stedet for å bli skrevet inn av brukeren. I tekniske tilpasninger definerer du en Python-metode og kobler den til feltet ved hjelp av compute-parameteren. Disse feltene er skrivebeskyttede og oppdateres når avhengighetene deres endres.
Beregnete felt er kraftige, men krever kode. De kan for øyeblikket ikke opprettes gjennom Odoo Studio uten utviklermodus og noe Python-kunnskap.
Forretningsbrukstilfeller
Tilpassede felt vises i nesten hvert Odoo-prosjekt vi jobber med hos Dasolo. Her er fem vanlige scenarier fra virkelige forretningsarbeidsflyter.
1. CRM: Kvalifisere Leads Mer Presist
Standard Odoo leads fanger kontaktinformasjon og pipeline-stadium, men mange salgsteam trenger mer. Et Utvalg felt for "Kundeindustri" eller en Many2one som lenker til en intern "Markedssegment"-modell lar salgsrepresentanter kvalifisere leads raskere og gjør det mulig for ledelsen å rapportere om pipeline etter segment.
2. Salg: Spore Interne Prosjektkoder
Selskaper som fakturerer kunder per prosjekt trenger ofte å knytte en intern prosjektkode eller budsjettreferanse til hvert tilbud eller salgsordre. Et enkelt Char felt kalt "Prosjektkode" på sale.order gjør dette mulig uten en full prosjektledelsesintegrasjon. Feltet vises på trykte dokumenter og kan brukes til å filtrere og gruppere ordrer i rapporter.
3. Lager: Produktspecifikke Attributter
Utover Odoos standard produktattributter, trenger bedrifter noen ganger å spore tekniske spesifikasjoner unike for deres bransje. En produsent kan legge til felt for "Garanti Periode (måneder)" (Heltall), "Sertifiseringsstandard" (Utvalg), eller "Opprinnelsesland" (Many2one til res.country). Disse feltene integreres naturlig med produktformen og er tilgjengelige i lager rapporter.
4. Regnskap: Budsjett og Kostnadssenterallokering
Finansavdelinger må ofte merke fakturaer eller journaloppføringer med et kostnadssenter eller budsjettlinje. Et Many2one-felt på account.move som peker til en tilpasset "Kostnadssenter"-modell tillater detaljert kostnadsallokering uten å endre Odoos analytiske regnskapsoppsett. Filtre, pivot-tabeller og eksporteringer respekterer alle feltet umiddelbart etter opprettelse.
5. HR: Tilpassede Onboarding-data
HR-avdelinger samler ofte data under onboarding som ikke passer inn i standard ansattfelt: kontrakttyper spesifikke for et land, interne ferdighetskategorier eller referanser til flåtetildelinger. Tilpassede felt på hr.employee holder denne informasjonen inne i Odoo i stedet for i et separat regneark, noe som gjør den søkbar og rapporterbar.
Opprette eller tilpasse feltet
Det er to hovedmåter å opprette tilpassede felt i Odoo. Det riktige valget avhenger av dine tekniske ressurser og hvor komplekst feltet må være.
Alternativ 1: Odoo Studio (Ingen kode)
Odoo Studio-felt er den raskeste veien for forretningsbrukere. Med Studio aktivert kan du legge til et nytt felt i hvilken som helst visning med noen få klikk:
- Åpne appen og registrer typen der du vil ha feltet (for eksempel et salgsordre-skjema)
- Klikk på blyantikonet for å gå inn i Studio redigeringsmodus
- Dra en felt-type fra venstre panel til skjemaet
- Sett feltetikett, teknisk navn og eventuelle tilleggsegenskaper
- Lagre og avslutt Studio
Studio oppretter feltet i ir.model.fields med x_studio_-prefikset og legger det direkte til visningen. Ingen distribusjon eller serveromstart er nødvendig. Dette er den anbefalte tilnærmingen for enkle felt som ikke krever tilpasset logikk.
Alternativ 2: Teknisk tilpasning via API
For team som jobber med Odoo-tilpasning prosjekter, kan felt opprettes programmatisk ved hjelp av XML-RPC API eller ved å skrive en Python-modul. Dette er den rette veien når du trenger beregnede felt, komplekse domene-filtre, eller felt som bør være en del av en versjonskontrollert kodebase.
Ved å bruke API-en, ser opprettelsen av et tilpasset valgfelt på en salgsordre slik ut:
# Finn modell-ID for sale.order
model = models.execute_kw(
db, uid, api_key,
'ir.model', 'search_read',
[['model', '=', 'sale.order']],
{'fields': ['id', 'name']}
)[0]
# Opprett det tilpassede feltet
field_id = models.execute_kw(
db, uid, api_key,
'ir.model.fields', 'create',
[{
'name': 'x_project_type',
'field_description': 'Prosjekttype',
'model_id': model['id'],
'ttype': 'selection',
'selection': [('internal', 'Intern'), ('client', 'Kunde'), ('rd', 'FoU')],
'state': 'manual',
}]
)Dette er en del av den standard Odoo utviklerguiden arbeidsflyten for å legge til felt uten å endre kildefiler. Det er spesielt nyttig for eksterne konfigurasjoner og automatiserte distribusjonsskript.
For en full Python-modultilnærming, defineres felt i en modellklasse og lastes inn via den standard Odoo-modulmekanismen. Dette er det mest vedlikeholdbare alternativet for felt som vil bestå gjennom oppgraderinger og må spores i versjonskontroll.
Legge til feltet i en visning
Å opprette et felt gjør det ikke automatisk synlig i grensesnittet. Du må også legge det til i den relevante skjema- eller listevisningen. Med Studio gjøres dette samtidig som feltopprettelsen. Med teknisk tilpasning må du enten endre visnings-XML direkte eller opprette en arvet visning som injiserer feltet på riktig plass.
Beste praksis
Tilpassede felt er enkle å opprette, men en dårlig planlagt feltarkitektur skaper problemer som er vanskelige å fikse senere. Dette er praksisene som holder ting ryddige.
Bruk valgfelt fremfor fritekst når det er mulig
Hvis settet med mulige verdier er kjent på forhånd, bruk alltid et valgfelt i stedet for et Char-felt. Fritekst fører til inkonsekvente oppføringer ("Kunde", "kunde", "KUNDE", "K.") som bryter filtre og rapporter. En nedtrekksmeny håndhever konsistens uten ekstra kostnad.
Navn Felt Klart og Konsistent
Det tekniske navnet (x_project_type) bør gjenspeile innholdet, ikke posisjonen på skjemaet. Et felt kalt x_field_1 er umulig å vedlikeholde seks måneder senere. Bruk en konsekvent navngivningskonvensjon og dokumenter hva hvert felt er for.
Ikke Overforlenge Native Modeller
Å legge til ti tilpassede felt til sale.order er vanligvis et tegn på at en tilpasset modell ville vært bedre. Hvis en gruppe felt hører sammen og representerer en ny enhet i virksomheten din (et prosjekt, en kontrakt, en sertifisering), vurder å opprette en tilpasset modell og koble den med et Many2one-felt i stedet.
Test Alltid på en Staging Database
Før du legger til felt i en produksjonsinstans, test på en kopi av databasen. Opprettelse av felt er stort sett trygt, men å legge til et felt til feil modell, eller med feil type, kan kreve manuell opprydding. Et staging-miljø fanger opp disse problemene tidlig.
Dokumenter Dine Tilpassede Felt
Hold en oversikt over hvert tilpasset felt du legger til: modellen, det tekniske navnet, formålet, og hvem som ba om det. Odoo-implementeringer akkumulerer felt over tid, og uten dokumentasjon blir det umulig å vite hvilke som fortsatt er i bruk og hvilke som kan fjernes.
Bruk Riktig Verktøy for Beregnet Logikk
Hvis verdien av et felt avhenger av andre felt, bruk et beregnet felt i stedet for å be brukerne fylle det ut manuelt. Dette unngår inkonsekvenser og reduserer feil ved datainntasting. Beregnede felt er en del av kjerne Odoo Python-felt funksjonalitet og er godt dokumentert i den offisielle Odoo tekniske veiledningen.
Vanlige fallgruver
Selv erfarne team støter på de samme problemene med tilpassede felt. Her er de som dukker opp oftest.
Glemmer One2many Når Man Oppretter en Many2one
Dette er den vanligste tekniske feilen. Hvis du legger til et Many2one-felt på modell A som peker til modell B, og du ikke oppretter det tilsvarende One2many-feltet på modell B, er navigasjonen fra B til A ødelagt. Brukere kan ikke se relaterte poster fra den andre siden av forholdet. Opprett alltid begge feltene sammen.
Slette et felt som inneholder data
Å slette et tilpasset felt fjerner permanent databasens kolonne og all data den inneholder. Det finnes ingen angre-funksjon. Hvis det er noen sjanse for at feltet eller dataene vil være nødvendige i fremtiden, arkiver eller skjul feltet i stedet for å slette det.
Opprette felt direkte i produksjon
Å gjøre endringer direkte på en live produksjonsdatabase, uten å teste på staging først, er en risiko selv for enkle felt tillegg. Hvis noe går galt med visningskonfigurasjonen, får brukerne feil. Valider alltid i et testmiljø først.
Navnekonflikter med standardfelt
Odoo vil avvise et feltnavn som allerede eksisterer på modellen, men det er lett å ved et uhell opprette et felt som skygger for et felt fra et modul du installerer senere. Å bruke et selskaps-spesifikt prefiks (som x_acme_) for dine tilpassede felt reduserer denne risikoen betydelig.
Legge til et felt i visningen uten å tenke på UX
Bare fordi et felt kan legges til i et skjema, betyr det ikke at det skal være synlig som standard. Rotete skjemaer senker brukernes hastighet. Hvis et felt kun er relevant i spesifikke kontekster, plasser det i en egen fane eller gjør det betinget synlig ved hjelp av domene-baserte usynlighetsregler.
Blande Studio-felt og tekniske felt inkonsekvent
Når et prosjekt kombinerer Studio-tilpasning og kodebasert tilpasning, kan du ende opp med felt som har overlappende formål eller konfliktende navn. Bli enige om en strategi i starten av prosjektet: enten bruk Studio for alle uten kode-felt og kode for kompleks logikk, eller bruk kode for alt. Å blande begge uten en klar plan skaper vedlikeholdsproblemer.
Konklusjon
Tilpassede felt er en av de enkleste og mest innflytelsesrike måtene å tilpasse Odoo til din virksomhet. De krever ingen kildekode-modifikasjoner, integreres naturlig med resten av plattformen, og gir brukerne den nøyaktige datainnsamlingen de trenger uten omveier.
Nøkkelen er å planlegge før du bygger. Velg riktig felttype, navngi ting klart, respekter relasjonsfeltkonvensjoner, og dokumenter hva du lager. En godt utformet feltarkitektur gjør Odoo-instansen din enklere å vedlikeholde og lettere å utvikle etter hvert som virksomheten din vokser.
Enten du bruker Odoo Studio for raske no-code-felt eller skriver Python-moduler som en del av et bredere Odoo tilpasnings prosjekt, er de underliggende prinsippene de samme: match feltet med dataene, hold modellen ren, og test alltid før du distribuerer til produksjon.
Hos Dasolo hjelper vi selskaper med å implementere, tilpasse og optimalisere Odoo for å passe deres virkelige arbeidsflyter. Enten du trenger noen tilpassede felt lagt til din eksisterende oppsett eller en full tilpasset modul bygget fra bunnen av, er vårt team her for å hjelpe.
Ta kontakt med oss hvis du trenger veiledning om din Odoo-implementering. Vi er glade for å gjennomgå ditt nåværende oppsett og foreslå den reneste veien videre.