Hver virksomhed fungerer forskelligt. Dit team registrerer oplysninger, som standardsoftware ikke tager højde for — og det er præcis dér, brugerdefinerede felter i Odoo bliver relevante.
I stedet for at presse jeres arbejdsgange ind i en fastlåst datamodel, giver Odoo mulighed for at tilføje ekstra felter til næsten enhver post — kunde, ordre, produkt eller faktura. I bestemmer, hvilke oplysninger der skal gemmes, og Odoo opbevarer dem sammen med resten af dataene.
Denne guide forklarer det vigtigste: hvad et brugerdefineret felt er, hvordan det rent teknisk integreres i systemet, hvordan du opretter det med eller uden kode, og hvordan du bruger felterne, så din Odoo-installation forbliver overskuelig og vedligeholdelsesvenlig.
Hvad er et brugerdefineret felt i Odoo
Et brugerdefineret felt er simpelthen en ekstra databasekolonne, du tilføjer til en eksisterende Odoo-model ud over de standardfelter, der følger med. Det holder et konkret datastykke knyttet til en post, på samme måde som et indbygget felt ville gøre.
I Odoo får brugerdefinerede felter typisk navne med x_-præfikset. Felter oprettet via Odoo Studio hedder ofte noget i stil med x_studio_priority_level, mens programmatiske felter kan bruge et projekt- eller virksomheds-specifikt præfiks som fx x_dasolo_cost_center.
Set fra brugerfladen opfører et brugerdefineret felt sig som ethvert andet felt: det kan vises i formularer, lister, filtre, gruppéringsmuligheder og rapporter. Ikke-tekniske brugere vil som regel ikke kunne se forskel.
Tilgængelige felttyper
Odoo understøtter mange forskellige felttyper til brugerdefinerede felter, så de dækker de fleste databehov:
- Tekst (Char): Kort tekst, fx en referencekode eller et kort label
- Længere tekst: Flere linjer til noter eller beskrivelser
- Integer: Heltal til optælling eller scoringer
- Decimal (Float): Tal med decimaler, til målinger eller satser
- Monetært: Beløb med valutahåndtering, knyttet til et valuta-felt
- Boolean: En ja/nej-afkrydsning
- Dato / Dato & Tid: Kalenderdato eller tidsstempel
- Selection: En fast dropdown med foruddefinerede muligheder
- Many2one: Et link til en enkelt post i en anden model
- One2many: En liste af relaterede poster fra en anden model
- Many2many: Flere poster linket fra en anden model
- Binary: Filvedhæftning
- HTML: Rich text-indhold
Vælg korrekt felttype fra starten — det sparer tid og fejl senere. Når mulige værdier er kendte, er en Selection oftest bedre end fri tekst for at sikre konsistens.
Hvordan feltet fungerer
Odoo er bygget på et ORM-lag (Object-Relational Mapping). Hver formular, liste og post i brugerfladen svarer til en Python-model, som kortlægger til en database-tabel. Når du opretter et brugerdefineret felt, registrerer Odoo det i ORM’en og opretter kolonnen i PostgreSQL automatisk.
Det er denne metadata-baserede tilgang, der gør Odoo-datamodellen fleksibel: du ændrer ikke kildekoden, men udvider modellen via metadata gemt i ir.model.fields. Ved opstart læser Odoo den tabel og opbygger felterne dynamisk.
Feltdefektion i kode vs. i databasen
I traditionel Odoo-udvikling defineres felter i Python-klasser med Odoo-rammeværktøjet. En simpel feltdefinition i kode ser typisk sådan ud:
from odoo import models, fields
class SaleOrder(models.Model):
_inherit = 'sale.order'
cost_center = fields.Char(string='Cost Center')Brugerdefinerede felter oprettet via UI eller API følger en anden vej: de gemmes med state = 'manual' i ir.model.fields og indlæses ved runtime. Begge metoder skaber en reel databasekolonne og opfører sig ens i brugerfladen.
Relationelle felter og gensidighed
Når du laver et Many2one-felt, der peger på en anden model, forventer Odoo normalt et matchende One2many-felt på den modsatte side. Det er ikke bare skik og brug — det er, hvordan ORM’en navigerer relationerne mellem poster.
Eksempelvis: hvis du tilføjer x_project_id (Many2one til project.project) på en salgordre, bør projektmodellen have x_sale_order_ids (One2many tilbage til sale.order). Uden denne spejling kan du ikke nemt navigere fra projektet til dets ordrer i standardinterfacet.
Beregnete brugerdefinerede felter
Et beregnet felt (computed field) udfyldes automatisk ud fra andre felter i stedet for at blive tastet af brugeren. Tekniske tilpasninger definerer en Python-metode og binder den med compute-parameteren; disse felter er typisk skrivebeskyttede og opdateres, når afhængighederne ændrer sig.
Computed fields er kraftfulde, men kræver kode. De kan ikke oprettes direkte i Odoo Studio uden udviklertilstand og Python-viden.
Forretningsscenarier
Brugerdefinerede felter dukker op i næsten alle Odoo-projekter, vi arbejder med hos Dasolo. Her er fem reelle eksempler på, hvordan virksomheder bruger dem.
1. CRM: Skærp kvalificering af leads
Standardleads indeholder kontaktinfo og pipeline-stage, men salgsafdelinger har ofte brug for mere. Et Selection-felt til "Branche" eller et Many2one til en intern "Markedssegment"-model hjælper salgsfolk med hurtigere kvalificering og gør det muligt at lave meningsfulde rapporter på tværs af segmenter.
2. Salg: Interne projektkoder på tilbud
Virksomheder, der fakturerer pr. projekt, har ofte behov for at knytte et internt projektnummer eller budgetreference til et tilbud eller en salgsordre. Et enkelt Char-felt kaldet "Projektkode" på sale.order løser det uden fuld projektintegration — synligt på print og brugbart i filtre og rapportgrupperinger.
3. Lager: Produkt-specifikke attributter
Udover standard produktfelter kan producenter eller specialiserede leverandører have behov for tekniske specifikationer. Eksempler er "Garanti (måneder)" (Integer), "Certificeringsstandard" (Selection) eller "Oprindelsesland" (Many2one til res.country). De integreres direkte i produktformularen og medtages i lager- og rapportudtræk.
4. Regnskab: Budget- og omkostningsfordeling
Økonomiteams ønsker ofte at mærke fakturaer eller posteringer med et omkostningscenter eller en budgetlinje. Et Many2one-felt på account.move til en brugerdefineret "Omkostningscenter"-model muliggør detaljeret fordeling uden at ændre i Odoos analytiske regnskabsløsning. Feltet virker straks i filtre, pivottabeller og eksporter.
5. HR: Tilpasset onboarding-data
HR samler ofte oplysninger ved onboarding, som ikke passer ind i standard felter: lokale kontrakttyper, interne kompetencekategorier eller firmabilreferencer. Brugerdefinerede felter på hr.employee holder denne viden i Odoo i stedet for i regneark, hvilket gør data søgbare og anvendelige i rapporter.
Oprette eller tilpasse feltet
Der er to hovedmåder at oprette brugerdefinerede felter i Odoo. Valget afhænger af jeres tekniske ressourcer og kompleksiteten af feltet.
Mulighed 1: Odoo Studio (ingen kode)
Odoo Studio er den hurtigste vej for ikke-tekniske brugere. Med Studio aktiveret kan du tilføje et felt til en visning på få klik:
- Åbn den app og den posttype, hvor du vil tilføje feltet (fx salgordreformularen)
- Klik på blyant-ikonet for at gå i Studio-redigering
- Træk en felttype fra panelet til formularen
- Angiv feltets label, tekniske navn og evt. egenskaber
- Gem og forlad Studio
Studio opretter feltet i ir.model.fields med x_studio_-præfikset og indsætter det i visningen — ingen deployment eller server-genstart nødvendig. Det er den anbefalede metode til simple felter uden særlig logik.
Mulighed 2: Teknisk tilpasning via API
For teams i et større Odoo-tilpasningsprojekt kan felter oprettes programmatisk via XML-RPC API eller ved at skrive et Python-modul. Denne metode er bedst, når du har brug for beregnede felter, komplekse domains eller versionkontrollerede ændringer.
Via API’en kan man fx oprette et custom selection-felt på sale.order — processen er scriptbar og egner sig til automatiserede deployments.
# Find model-ID for sale.order
model = models.execute_kw(
db, uid, api_key,
'ir.model', 'search_read',
[['model', '=', 'sale.order']],
{'fields': ['id', 'name']}
)[0]
# Opret det brugerdefinerede felt
field_id = models.execute_kw(
db, uid, api_key,
'ir.model.fields', 'create',
[{
'name': 'x_project_type',
'field_description': 'Project Type',
'model_id': model['id'],
'ttype': 'selection',
'selection': [('internal', 'Internal'), ('client', 'Client'), ('rd', 'R&D')],
'state': 'manual',
}]
)Det er en almindelig del af Odoo-udviklerflowet for at tilføje felter uden at pille i kildefiler. Særligt velegnet til fjernkonfigurationer og automatiserede deployment-scripts.
Hvis du vælger fuld Python-modul-tilgang, defineres felterne i modelklasser og pakkes som et Odoo-modul — den mest holdbare løsning til felter, der skal versionsstyres og holdes igennem opgraderinger.
Tilføje feltet til en visning
Opdatering af databasen skaber ikke automatisk synlighed i UI — du skal selv tilføje feltet i den relevante formular- eller listevisning. Med Studio sker dette samtidigt; ved teknisk tilpasning ændrer du visnings-XML eller laver en arvet visning, der indsætter feltet på den rigtige plads.
Gode fremgangsmåder
Brugerdefinerede felter er nemme at lave, men uden planlægning kan de skabe rod, der er besværligt at rette op på senere. Følgende fremgangsmåder hjælper med at holde strukturen ren.
Brug Selection i stedet for fri tekst hvor muligt
Kendte værdier bør være dropdowns — fri tekst fører til inkonsistens ("Client", "client", "CLIENT", "Cl."), som knækker filtre og rapporter. En selection sikrer standardisering uden ekstra arbejde.
Giv felterne klare og konsistente navne
Det tekniske navn (x_project_type) bør beskrive indholdet, ikke hvor det står i skærmbilledet. Et navn som x_field_1 er umuligt at håndtere senere. Etabler en navngivningskonvention og dokumentér formålet med hvert felt.
Overbelast ikke native modeller
Hvis du har mange felter på fx sale.order, kan det være tegn på, at en ny model er bedre. Når flere felter hører sammen og repræsenterer en egen forretningsenhed (projekt, kontrakt, certifikat), så lav en separat model og link via Many2one i stedet for at fylde native modellen.
Test altid på en staging-database først
Opret felter på en kopi af produktionen før du ændrer live. Feltoprettelse er generelt sikker, men forkert modelvalg eller type kan kræve manuelt oprydningsarbejde — staging fanger disse fejl tidligt.
Dokumentér dine brugerdefinerede felter
Før log over hvert felt: model, teknisk navn, formål og hvem der bad om det. Odoo-implementeringer akkumulerer ofte felter, og uden dokumentation bliver det umuligt at vurdere, hvad der stadig bruges.
Brug det rigtige værktøj til beregningslogik
Er feltets værdi afhængig af andre felter, så brug et beregnet felt i stedet for manuel indtastning. Det mindsker fejl og sikrer konsistens. Computed fields er en velunderbygget del af Odoos Python-funktionalitet.
Almindelige faldgruber
Selv rutinerede teams rammer ofte de samme vanskeligheder med brugerdefinerede felter. Her er de hyppigste faldgruber.
Glemme One2many når du laver Many2one
Det hyppigste tekniske fejltrin: hvis du opretter Many2one fra model A til model B uden at lave det matchernde One2many tilbage, bryder du navigationen. Brugere kan ikke se relaterede poster fra den anden side. Skab altid begge sider samtidig.
Slette et felt der indeholder data
Sletning fjerner permanent kolonnen og alt indhold — der er ingen fortryd. Hvis data kan blive relevante igen, så skjul eller arkivér feltet i stedet for at slette det.
Oprette felter direkte i produktion
Ændringer direkte på live-databasen uden forudgående tests er risikabelt. Selv små fejl i visningskonfigurationen kan give brugerne fejlmeddelelser. Validér først i et testmiljø.
Navnekonflikter med standardfelter
Odoo afviser navne, der allerede findes, men du kan utilsigtet lave et felt, som fremtidige moduler vil overskrive. Brug et firma- eller projektpræfiks (fx x_acme_) for at mindske risikoen.
Tilføje et felt til visningen uden at tænke UX
Bare fordi et felt kan vises, betyder det ikke, at det skal være synligt som standard. Overfyldte formularer bremser brugere. Placer feltet i en separat fane eller gør det konditionelt synligt, hvis det kun er relevant i visse situationer.
Blande Studio-felter og tekniske felter uden strategi
Kombination af Studio- og kodebaserede tilpasninger kan føre til overlappende felter eller navnekonflikter. Aftal en strategi tidligt: brug enten Studio til no-code-ændringer og kode til kompleks logik — eller administrer alt gennem kode. Uden plan bliver vedligeholdelsen tung.
Konklusion
Brugerdefinerede felter er en af de enkleste og mest effektive måder at få Odoo til at passe til din forretning. De kræver ingen ændringer i kildekoden, passer naturligt ind i platformen og lader brugerne indsamle præcis de data, de har brug for.
Nøglen er at planlægge før du bygger: vælg korrekt felttype, navngiv entydigt, følg relationelle konventioner og dokumentér alt. En gennemtænkt feltarkitektur gør din Odoo-installation nemmere at vedligeholde og lettere at udvikle, når virksomheden vokser.
Uanset om I bruger Odoo Studio til hurtige no-code-felter eller skriver Python-moduler som led i en større Odoo-tilpasning, er principperne de samme: match felt til data, hold modellen ryddelig, og test før produktionssætning.
Hos Dasolo hjælper vi virksomheder med at implementere, tilpasse og optimere Odoo, så systemet passer til deres konkrete arbejdsgange. Har I brug for et par ekstra felter eller et komplet skræddersyet modul, står vores team klar til at hjælpe.
Kontakt os, hvis du ønsker rådgivning om din Odoo-opsætning. Vi gennemgår gerne jeres nuværende løsning og foreslår den mest robuste og plejbare vej frem.