Hver virksomhet har sine egne data og behov som standardprogramvare sjelden dekker. Det er her egendefinerte felt i Odoo kommer inn — små tillegg som fanger akkurat de opplysningene teamet ditt trenger uten å tvinge dere inn i en mal som ikke passer.
I stedet for å omorganisere arbeidsprosessene for å passe et forhåndsdefinert skjema, lar Odoo deg legge til nye felt på nesten alle poster: kunder, tilbud, produkter eller fakturaer. Du bestemmer hva som skal registreres, og Odoo lagrer det sammen med resten av dataene i systemet.
Denne artikkelen gir deg det viktigste: hva egendefinerte felt er, hvordan de lagres, hvordan du oppretter dem uten eller med kode, og hvilke fremgangsmåter som gjør at systemet forblir ryddig og vedlikeholdbart.
Hva er en egendefinert felt i Odoo
Et egendefinert felt er enkelt sagt en ekstra databasekolonne som du legger til en eksisterende modell i Odoo for å holde en bestemt bit informasjon som hører til en post — akkurat som de innebygde feltene gjør.
I Odoo får slike felt tekniske navn som begynner med x_. Felt laget i Odoo Studio får typisk navn som x_studio_..., mens programmerte felt ofte bruker et prosjektspesifikt prefiks, for eksempel x_dittfirma_koststed.
For sluttbrukeren oppfører et egendefinert felt seg helt som et vanlig felt: det kan vises i skjemaer, lister, filtre, grupperinger og rapporter. De fleste brukere vil ikke kunne se at feltet er lagt til i etterkant.
Tilgjengelige felttyper
Odoo tilbyr mange ulike felttyper som dekker de fleste behov for tilleggsinformasjon:
- Kort tekst (Char): korte strenger som referansekoder eller etiketter
- Lang tekst: flerspaltet notat eller beskrivelse
- Heltall (Integer): tellinger eller poengsummer
- Desimaltall (Float): mål eller rater med desimaler
- Beløp (Monetary): valuta-beløp koblet til en valutaoppføring
- Boolean: av/ på -sjekkboks
- Dato / Dato & tid: kalenderdato eller tidsstempel
- Valg (Selection): forhåndsdefinert liste med alternativer
- Many2one: lenke til én post i en annen modell
- One2many: liste med relaterte poster fra en annen modell
- Many2many: flere lenkede poster fra en annen modell
- Binær (Binary): filvedlegg
- HTML: rik tekstinnhold
Velg riktig felttype fra starten — det sparer mye arbeid senere. Når verdiene er begrenset og kjente på forhånd, er en Selection nesten alltid å foretrekke fremfor fri tekst for å sikre konsistens.
Slik fungerer feltet
Under panseret ligger Odoo på en ORM (Object-Relational Mapping). Hvert skjema og hver oversikt i brukergrensesnittet er knyttet til en Python-modell som samsvarer med tabeller i PostgreSQL. Når du legger til et egendefinert felt, registreres det i ORM-en og får sin egen kolonne i databasen automatisk.
Dette gjør Odoo-modellen fleksibel: du endrer ikke kjørbar kildekode, men utvider modellen via metadata som lagres i ir.model.fields. Ved oppstart leser Odoo disse metadataene og bygger feltene dynamisk i minnet.
Felter definert i kode kontra felt definert i databasen
I tradisjonell Odoo-utvikling erklæres felter i Python-klasser ved hjelp av Odoo-rammeverket. Slik ser en typisk feltdefinisjon ut i kode:
Eksempel på enkel feltdefinisjon i Python: fra odoo import models, fields; klassen arver modellen og definerer felttypen (for eksempel fields.Char) for å gi modellen et nytt felt.
Felt opprettet via grensesnittet eller API-et blir lagret i ir.model.fields med state = 'manual' og lastes ved kjøring. Uansett om feltet er laget i UI eller i kode, får du en ekte databaskolonne og lik oppførsel for brukeren.
Relasjonelle felt og gjensidighet
Når du legger til et Many2one-felt som peker på en annen modell, forventer Odoo ofte en tilsvarende One2many på den andre siden. Dette er hvordan ORM-en håndterer og navigerer relasjoner mellom poster.
Hvis du for eksempel legger til x_project_id (Many2one til prosjektet) på en salgsordre, bør prosjektmodellen ha x_sale_order_ids (One2many tilbake til salgsordre) for å kunne vise relaterte ordrer fra prosjektsiden i grensesnittet.
Beregnete egendefinerte felt
Beregnete felter i Odoo gir verdier automatisk basert på andre felt. For å lage slike felt skriver du en Python-metode og peker feltet til den med compute-parameteren. Disse feltene er ofte skrivebeskyttet og oppdateres når avhengighetene endres.
Slike beregnede felt krever kode og kan ikke opprettes fullt ut via Studio uten utviklermodus og programmeringskunnskap.
Forretningsscenarier
Egendefinerte felt går igjen i nesten alle Odoo-prosjekter vi jobber med. Her er fem praktiske eksempler fra virkelige arbeidsflyter.
1. CRM: Bedre kvalifisering av leads
Standard lead-oppsett fanger grunnleggende kontaktinfo, men mange salgsteam trenger mer presisjon. Et Selection-felt for «Bransje» eller en Many2one til en intern «Markedssegment»-modell gjør det raskere å klassifisere leads og gir bedre styringsdata for pipeline-rapportering.
2. Salg: Interne prosjektkoder
Virksomheter som fakturerer per prosjekt trenger ofte et felt for intern prosjektkode på tilbud og ordre. Et enkelt Char-felt «Prosjektkode» på sale.order gjør det lett å vise koden på dokumenter og filtrere ordre i rapporter uten å implementere full prosjektstyring.
3. Lager: Produktskjemaer med bransjespesifikke attributter
Utover Odoos standardproduktfelter trenger produsenter ofte tekniske spesifikasjoner. Eksempler kan være «Garanti (måneder)» (Integer), «Sertifiseringsstandard» (Selection) eller «Produksjonsland» (Many2one til res.country). Slike felt integreres på produktskjemaet og blir tilgjengelige i lager- og rapportoversikter.
4. Regnskap: Koststed og budsjettmerking
Økonomi trenger ofte å merke fakturaer eller posteringer med koststed eller budsjettlinje. Et Many2one-felt på account.move som peker til en egen Koststed-modell gjør det mulig å fordele kostnader detaljert uten å endre den eksisterende analytiske strukturen.
5. HR: Tilpasset onboarding-informasjon
HR samler ofte spesifikk informasjon ved ansettelse som ikke finnes i standard felter — kontraktkategorier, interne kompetanseetiketter eller firmabilreferanser. Egendefinerte felt på hr.employee holder disse dataene i Odoo, gjør dem søkbare og enklere å ta med i rapporter enn å ha dem i regneark.
Opprette eller tilpasse feltet
Det finnes to hovedmåter å opprette egendefinerte felt på i Odoo. Valget bør baseres på teknisk kompetanse og hvor avansert feltet skal være.
Alternativ 1: Odoo Studio (uten kode)
Odoo Studio er raskt og brukervennlig for forretningsbrukere. Med Studio aktivert kan du legge til felt i et par klikk:
- Åpne riktig app og posttype (for eksempel salgsordre)
- Klikk penn-ikonet for å gå inn i Studio-redigering
- Dra ønsket felttype fra venstre panel og plasser det i skjemaet
- Sett etikett, teknisk navn og eventuelle egenskaper
- Lagre og avslutt Studio
Studio oppretter feltet i ir.model.fields med x_studio_-prefiks og legger det rett inn i visningen — ingen serverrestart eller deploy nødvendig. Dette er best for enkle felt uten komplisert logikk.
Alternativ 2: Teknisk tilpasning via API eller modul
For prosjekter med mer avanserte krav oppretter man felt programmatisk via XML-RPC/API eller ved å skrive en Python-modul. Dette er riktig når du trenger beregnede felt, avanserte domener eller full versjonskontroll i kodebasen.
Ved bruk av API kan du for eksempel opprette et Selection-felt på sale.order ved å kalle ir.model.fields.create og angi felttype og valg.
Med API/skript oppretter du først modellen (eller finner modell-id), og så oppretter du feltet med navn, beskrivelse, ttype = 'selection' og en liste over alternativer, og setter state til 'manual' for at systemet skal laste feltet dynamisk.
Denne fremgangsmåten er nyttig for automatiserte konfigurasjoner og når du vil legge til felt uten å endre kildekoden direkte — en vanlig del av Odoo-utviklerens verktøykasse.
For større og vedvarende endringer er det beste å definere feltene i en egen Python-modul som installeres som et vanlig Odoo-modul. Det gir versjonskontroll, enklere migrasjoner og bedre sporbarhet ved oppgraderinger.
Legge feltet til i visningen
Å opprette selve feltet gjør det ikke automatisk synlig i skjemaet. Du må legge det inn i riktig form- eller listevisning. Med Studio gjøres dette samtidig; ved kodearbeid redigerer du XML-visningen eller oppretter en arvet visning som setter feltet på riktig plass.
Gode praksiser
Egendefinerte felt er enkle å lage, men dårlig struktur kan skape problemer senere. Her er praksiser som sørger for orden.
Bruk Selection fremfor fri tekst når det er mulig
Når mulige verdier er begrensede, bruk Selection. Fritekst fører til ujevn inntasting («Kunde», «kunde», «Kunde.») som ødelegger søk og rapporter. En nedtrekksliste sikrer konsistente data.
Gi feltene klare og konsistente navn
Det tekniske navnet bør beskrive hva feltet inneholder, ikke hvor det står. Navn som x_field_1 blir umulige å vedlikeholde etter noen måneder. Innfør en navnekonvensjon og dokumenter formålet med hvert felt.
Unngå å overfylle native-modeller
Å legge ti felt på sale.order er ofte et tegn på at dere trenger en egen modell. Hvis en gruppe felt representerer en egen forretningsentitet (prosjekt, kontrakt, sertifikat), lag en modell og koble den med en Many2one i stedet for å presse alt inn i ett skjema.
Test alltid på en staging-database først
Før du endrer produksjon, prøv feltopprettelsen på en kopi av databasen. Selv om feltoppretting som regel er trygg, kan feil modellvalg eller typebytte kreve manuelt arbeid å rydde opp i. En staging-oppstilling fanger slike feil tidlig.
Dokumenter alle egendefinerte felt
Før logg over hvert felt: modell, teknisk navn, formål og hvem som ba om det. Uten dokumentasjon blir løsningen uoversiktlig ettersom felt hoper seg opp over tid.
Velg riktig verktøy for beregningslogikk
Når feltverdi avhenger av andre felter, bruk beregnede felt i stedet for å kreve manuell inntasting. Det reduserer feil og sikrer konsistens — denne funksjonaliteten ligger i Odoos Python-felt og er godt beskrevet i teknisk dokumentasjon.
Vanlige fallgruver
Selv erfarne team snubler i de samme problemene med egendefinerte felt. Her er de vanligste feilene.
Glemme One2many når du lager Many2one
Den vanligste tekniske feilen er å opprette en Many2one uten motsvarende One2many. Resultatet blir at brukere ikke kan navigere fra den relaterte modellen tilbake til postene. Lag alltid begge i sammenheng ved relasjoner.
Slette et felt som inneholder data
Å slette et egendefinert felt fjerner kolonnen og alle dataene for godt — det finnes ikke angreknapp. Hvis det er en mulighet for gjenbruk, skjul eller arkiver feltet i stedet for å slette det helt.
Opprette felt direkte i produksjon
Å gjøre endringer direkte i live-systemet uten testing er risikabelt. En feil i visningskonfigurasjonen kan gi brukerne feilmeldinger. Valider alltid endringer i et testmiljø først.
Navnekonflikter med standardfelt
Odoo blokkerer felt med identiske navn, men det er lett å lage et felt som kolliderer med et felt fra et modul dere installerer senere. Bruk et virksomhetsspesifikt prefiks (for eksempel x_dinfirma_) for å redusere denne risikoen.
Legge til felt i visningen uten å vurdere brukeropplevelse
Bare fordi et felt kan settes inn i et skjema betyr det ikke at det bør være synlig hele tiden. Rotete skjemaer senker produktiviteten. Plasser felt i fliker eller bruk betinget synlighet hvis de bare er relevante i enkelte sammenhenger.
Blande Studio-felt og tekniske felt uten plan
Når et prosjekt blander Studio og kode, kan man få overlappende eller konfliktende felt. Avtal en strategi på forhånd: enten bruk Studio til enklere tilpasninger og kode til alt som krever logikk, eller definer klare regler for når hver metode brukes.
Oppsummering
Egendefinerte felt er en av de enkleste og mest virkningsfulle måtene å tilpasse Odoo på. De krever ingen kjerneendringer, smelter inn i systemet og lar brukerne fange presist de dataene de trenger uten omveier.
Nøkkelen er å tenke før du bygger: velg riktig type, gi tydelige navn, følg relasjonskonvensjoner og dokumenter arbeidet. En gjennomtenkt feltarkitektur gjør Odoo enklere å vedlikeholde og klar for vekst.
Uansett om dere bruker Odoo Studio for raske, kodefrie felt eller utvikler Python-moduler i et større tilpasningsprosjekt, gjelder de samme prinsippene: la feltet matche dataene, hold modellen ryddig og test før du setter endringer i produksjon.
Hos Dasolo hjelper vi bedrifter med å implementere, tilpasse og optimalisere Odoo slik at systemet faktisk støtter måten de jobber på. Enten dere trenger noen få felt lagt til eller en komplett modul fra bunnen av, kan vårt team bidra.
Ta gjerne kontakt hvis dere trenger råd om Odoo-oppsettet. Vi kan gjennomgå løsningen deres og foreslå den mest oversiktlige og fremtidssikre veien videre.