Skip to Content

Stored Computed Fields i Odoo: Den Ultimative Guide

Få styr på, hvad gemte beregnede felter i Odoo egentlig er, hvornår de giver mening at bruge, og hvordan du opretter dem både ved hjælp af Python-kode og via Odoo Studio.
6. marts 2026 af
Stored Computed Fields i Odoo: Den Ultimative Guide
Dasolo
| Ingen kommentarer endnu

Introduktion


Hvis du har arbejdet med Odoo, har du sikkert mødt felter, der selv udfylder værdier. Et lagret beregnet felt går et skridt videre: systemet udregner værdien og gemmer resultatet direkte i databasen, så værdien er persistent og kan bruges som en almindelig kolonne.


Den forskel er vigtig. Et felt, der kun regnes ved visning, kan ikke effektivt søges, filtreres eller grupperes i databasen. Et lagret beregnet felt kan — det fungerer som en normal databasekolonne, men styres af den logik, du definerer i koden.


Denne guide forklarer alt, du behøver at vide om lagrede beregnede felter i Odoo: hvordan de passer ind i datamodellen, hvordan du opretter dem via Studio eller Python, konkrete forretningsanvendelser og de typiske faldgruber, du bør undgå.

Hvad er et lagret beregnet felt i Odoo


I Odoos ORM repræsenterer hvert felt en dataværdi på en model. De fleste felter gemmer det, brugeren indtaster manuelt. Et beregnet felt adskiller sig ved, at værdien frembringes af en Python-funktion i stedet for direkte brugerinput.


Et lagret beregnet felt er i praksis blot et beregnet felt med store=True. Når et afhængighedsfelt ændrer sig, kører compute-funktionen, og resultatet bliver skrevet til databasen — det bliver dermed tilgængeligt som alle andre felter.


I praksis i Python følger mønstret typisk denne struktur:

(Eksempel på feltdefinition og compute-metode, hvor totalbeløbet udregnes ud fra antal og enhedspris.)

Parameteren store=True er det, der skaber forskellen. Uden den genberegnes feltet hver gang det læses, men værdien gemmes ikke permanent i databasen.


I brugerfladen fremstår et lagret beregnet felt som et almindeligt felt — det vises på formularer, lister og rapporter, og brugere kan filtrere, gruppere og eksportere på det. Der er ingen særlig visuel markør, der afslører at feltet er beregnet.


Lagret vs. Ikke-lagret beregnede felter

At kende forskellen er afgørende ved Odoo-udvikling:

  • Ikke-lagret beregnet felt: beregnes ad hoc ved læsning. Kan ikke indgå i søgninger, filtre eller grupperinger. Bruger mindre diskplads, men er ikke tilgængelig for databaseforespørgsler.
  • Lagret beregnet felt: beregnes ved ændring af afhængigheder og gemmes i databasen. Søgbar, filtrerbar og kan eksporteres. Optager plads ligesom et almindeligt felt.

Valget mellem dem handler ikke om generel ‘bedst’, men om behov. Hvis feltet kun vises i en enkelt formular, er ikke-lagret ofte tilstrækkeligt. Skal du sortere, filtrere eller aggregere på feltet, vælg lagret.

Hvordan feltet fungerer


Når du definerer et lagret beregnet felt, opretter Odoo ORM automatisk triggere for genberegning baseret på de felter, du angiver i @api.depends()-dekorationen.


Hver gang en af de afhængige felter ændrer sig, markerer Odoo posten til genberegning, kører compute-metoden og skriver resultatet tilbage i den tilsvarende databasekolonne.


Livscyklus for genberegning

Procestrin i praksis:

  1. En bruger eller en automatisering ændrer et felt, som er angivet i @api.depends().
  2. Odoo opdager ændringen og identificerer de berørte poster.
  3. Compute-metoden køres for disse poster.
  4. Det beregnede resultat skrives til databasen.
  5. Feltet er nu opdateret og kan bruges i søgninger, filtre og eksport.

Normalt sker genberegningen straks i samme transaktion. Ved store batch-operationer kan Odoo udsætte eller behandle nogle genberegninger i baggrunden for at undgå store blokeringer.


Afhængigheder på tværs af relaterede modeller

@api.depends() understøtter stiveje (dotted paths) for felter på relaterede modeller, for eksempel partner_id.country_id.name.


(Eksempel der viser afhængighed fra partnerens landnavn og udregner et felt ud fra det.)

Når du bruger stiveje, sporer Odoo ændringer på tværs af relationer. Hvis landets navn ændres på partneren, genberegnes alle relaterede poster automatisk — en kraftfuld funktion i Odoo-rammeværket.


Indvirkning på databasen

Fordelen ved at gemme feltet er, at Odoo opretter en rigtig kolonne i PostgreSQL-tabellen. Feltet indgår direkte i SQL-forespørgsler, så søgninger og filtre er hurtige og effektive, som ved almindelige felter.

Forretningsscenarier


Her er fem konkrete eksempler fra praksis, hvor lagrede beregnede felter gør en forskel.


1. Salg: Bruttomargin pr. ordrebeklædning

Sælgerne vil hurtigt se marginen på hver salgsordrelinje. Et lagret felt beregner marginen ud fra salgspris og indkøbspris og gemmer resultatet på linjen, så ledere kan filtrere og gruppere ordrer efter margin og hurtigt finde ulønnsomme linjer.


2. CRM: Dage uden aktivitet på et lead

Et lagret felt på lead-modellen kan tælle dage siden sidste aktivitet. Kombineret med en planlagt handling, der genberegner hver morgen, kan salgsafdelingen filtrere leads efter inaktivitet uden manuel opfølgning.


3. Lager: Netto tilgængelig mængde

For komplekse lagersituationer kan et lagret felt indeholde forudberegnet tilgængelig mængde (på lager minus reserveret). Det gør, at produktansvarlige kan sortere og filtrere produktlisten uden at Odoo må beregne komplekse lagerregler live for hver række.


4. Regnskab: Antal forfaldne fakturaer pr. kunde

På kundeniveau kan et lagret felt tælle forfaldne fakturaer. Regnskabsteamet kan hurtigt sortere kontakter efter antal forfaldne poster, fordi tællingen ligger i databasen og ikke skal beregnes for hver række ved visning.


5. Produktion: Samlet estimeret arbejdstid

I en stykliste kan et lagret felt summere estimatet for alle operationer. Planlæggere kan så filtrere og sortere styklister efter samlet arbejdstid, hvilket hjælper ved kapacitetsplanlægning. Felter opdateres automatisk, når operationer ændres.

Oprette eller tilpasse feltet


Der er grundlæggende to veje til at oprette lagrede beregnede felter: hurtige felter i Odoo Studio eller fuld kontrol via Python i et custom modul.


Brug af Odoo Studio

Studio lader dig tilføje beregnede felter uden kode. Ved oprettelse af et numerisk felt kan du aktivere en formelfunktion, hvor du indtaster et Python-lignende udtryk. Studio tager sig af afhængighedssporingen bag scenen.


Studio er velegnet til simple regnearkslignende udtryk mellem felter på samme post. Det er hurtigt og kræver ikke udviklingsmiljø, men når logikken involverer relationer, konditioner eller aggregation over underposter, bliver Studio utilstrækkeligt — så må du bruge et modul.


Det er et vigtigt planlægningspunkt i din Odoo-tilpasning: Studio er effektivt til enkle behov, men Python giver friheden, når logikken vokser i kompleksitet.


Brug af et custom Python-modul

Når beregningen bliver mere avanceret, definerer du feltet i Python i et custom modul. Et typisk eksempel er at tilføje et marginprocent-felt til salgsordrelinjer.


(Eksempelkode, hvor x_margin_pct defineres med compute, store=True og @api.depends på price_unit og purchase_price.)

Når modulet installeres, opretter Odoo x_margin_pct-kolonnen i databasen, kører compute-metoden for eksisterende poster og begynder at spore ændringer i de afhængige felter fremover.


Praksis er at bruge x_-præfikset for brugerdefinerede felter for at undgå navnekonflikter med standardfelter — det er en almindelig konvention i Odoo-udvikling.


Gøre et lagret beregnet felt redigerbart

Som standard er beregnede felter skrivebeskyttede. Hvis du vil tillade manuel overskrivning, kan du definere en inverse-metode, der opdaterer de underliggende source-felter, når brugeren skriver direkte i det beregnede felt. Det er handy, når beregningen skal være et godt udgangspunkt, men lejlighedsvis manuelt justeres.


Odoo Studio-felter og XML-RPC API

Hvis du administrerer model-felter via XML-RPC, kan du oprette standardfelter gennem ir.model.fields. Men beregningslogikken for et lagret felt må leve i serverkode — compute-metoden skal være i et installeret modul. API-en er nyttig til provisionering af simple felter, men ikke til at implementere kompleks compute-logik uden et modul på serveren.

Bedste fremgangsmåder


Her er de anbefalinger, erfarne Odoo-konsulenter følger ved arbejde med lagrede beregnede felter.


Angiv alle afhængigheder præcist

@api.depends() skal liste hvert felt, compute-metoden læser. Glemmer du et felt, opdateres feltet ikke ved ændring af den afhængighed. Gennemgå compute-koden linje for linje og sørg for at hvert felt adgang er nævnt i dekoratoren.


Hold compute-metoder hurtige

Compute-metoden kører for alle berørte poster — i en travl installation kan det være tusinder af rækker. Undgå ekstra databaseforespørgsler inden i compute-metoder, brug allerede indlæste relationer frem for at lave nye søgninger, når det er muligt.


Brug kun store=True når nødvendigt

Lagrede felter kræver plads og skriver til databasen ved hver genberegning. Hvis feltet kun skal vises og aldrig bruges i søgning eller gruppering, er ikke-lagret lettere. Beslut dette bevidst, frem for at gøre alle beregnede felter lagrede som standard.


Håndter kanttilfælde i compute-metoden

Regn altid med tomme eller manglende værdier i din compute-metode. Division med nul, manglende relationer og null-værdier er almindelige årsager til fejl. Tilføj eksplicitte checks og sikre standardværdier, når beregningen ikke kan gennemføres.


Planlæg initial genberegning på store tabeller

Ved installation af et modul med et nyt lagret felt genberegner Odoo feltet for alle eksisterende poster. På tabeller med hundredtusinder af rækker kan det tage lang tid — test migrationen i en staging-opsætning og planlæg evt. vedligeholdsvindue eller baggrundsbehandling til produktion.


Undgå cirkulære afhængigheder

Hvis felt A afhænger af B og B afhænger af A, vil Odoo kaste fejl ved indlæsning. Design afhængigheder så de flyder i én retning for at undgå cyklusser.

Almindelige fejltrin


At glemme store=True

Det mest almindelige fejltrin er at glemme at sætte store=True. Feltet ser fint ud i formularen under test, men virker ikke i filtre eller rapporter. Beslut tidligt om feltet skal kunne søges — har du brug for det, tilføj store=True fra starten.


Manglende afhængighed i @api.depends

Hvis compute-metoden læser partner_id.country_id men dekoratoren kun nævner partner_id, vil feltet ikke opdatere ved ændringer i land på partneren. Spor hele adgangsstien og list hvert trin i dekoratoren.


Stille fejl i compute-metoden

Hvis compute-metoden rejser en undtagelse for en post, springer Odoo genberegningen over for den post og bibeholder den tidligere værdi. Fejlen kan dukke i serverlogs uden brugeradvarsel, hvilket kan give svære at opdage forældede værdier. Test compute-metoder med data, der kan være ufuldstændige eller atypiske.


Performance-problemer på store datasæt

En compute-metode, som fungerer i udvikling, kan blive en flaskehals i produktion, når tabellen vokser. Vær opmærksom på antal DB-forespørgsler per post — en ekstra forespørgsel per post gange ti tusind poster er titusind forespørgsler ved en enkelt gemning.


Brug af sudo() i compute-metoder

At kalde sudo() i en compute-metode for at kringgå adgangsrettigheder er en sikkerhedsrisiko. Returnerer compute-metoden data, som den aktuelle bruger ikke burde se, underminerer det Odoos rettighedsmodel. Brug sudo() kun hvis du nøje har vurderet sikkerhedskonsekvenserne.


Forventninger om øjeblikkelig genberegning i alle sammenhænge

I interaktive operationer er genberegning ofte synkron, men ved batch-importer, baggrundsjobs eller visse ORM-operationer kan Odoo udsætte genberegningen. Byg ikke forretningslogik der antager at værdien altid er opdateret umiddelbart efter skrivning — test i de kontekster dit felt vil blive brugt.

Konklusion


Lagrede beregnede felter er et af de mest praktiske værktøjer i Odoo: de automatiserer beregninger, sikrer konsistens og gør værdier søgbare og eksporterbare uden manuelt arbejde fra brugerne.


Hovedpunkterne at tage med videre:

  • Brug store=True når feltet skal kunne søges, filtreres eller eksporteres.
  • Angiv altid alle afhængigheder i @api.depends(), også stiveje på tværs af modeller.
  • Hold compute-metoder hurtige og håndter kanttilfælde eksplicit.
  • Til simple formler er Odoo Studio hurtigt; til kompleks logik skriv Python i et modul.
  • Planlæg initial genberegning når du deployer til produktion på store tabeller.

Uanset om du bygger et nyt modul, udvider en eksisterende model eller blot undersøger Odoo-felttyper, er forståelsen af lagrede beregnede felter værd at investere tid i. De står midt imellem ORM, databasen og din forretningslogik.


Brug for hjælp til din Odoo-implementering?

Dasolo hjælper virksomheder med at implementere, tilpasse og optimere Odoo til forskellige forretningsbehov. Om du vil tilføje beregnede felter, bygge rapporter baseret på udregnede værdier eller løfte din Odoo-udvikling, har vores team erfaringen til at hjælpe.


Kontakt os, hvis du har brug for support til dit Odoo-projekt. Vi tager gerne en samtale om dit behov og foreslår den rette fremgangsmåde for din virksomhed.

Stored Computed Fields i Odoo: Den Ultimative Guide
Dasolo 6. marts 2026
Del dette indlæg
Log ind for at skrive en kommentar