Introduktion
I Odoo beskriver modeller, hvordan forretningsdata organiseres og gemmes i databasen. Alt fra salgsordrer til fakturaer og bogføringslinjer har en tilknyttet model, der bestemmer felter, relationer og opbevaring.
At forstå Odoo-modeller er afgørende både for udviklere og konsulenter. Modeller er fundamentet i Odoo’s datalandskab: de definerer felttyper, relationer mellem objekter og hvor forretningslogikken skal ligge.
Denne guide fokuserer på en af de mest centrale modeller i Odoo Regnskab: account.move. Uanset om du skal lave rapporter, koble eksterne systemer på eller sætte faktureringsflow op, kommer du til at arbejde med denne model.
Hvad er account.move-modellen
account.move repræsenterer bogførte posteringer i Odoo. Fra version 13 blev flere tidligere separate poster — kundefakturaer, leverandørfakturaer, kreditnotaer og manuelle bogføringer — samlet i denne ene model, så alle regnskabsposter håndteres ensartet.
Modellen anvendes primært i Regnskabsmodulet og er forælder til account.move.line, som indeholder de konkrete kredit- og debetlinjer. En faktura, en leverandørpostering eller en manuel justering er altid en account.move med én eller flere tilhørende lines.
Selve modellen ligger i account-modulet, men andre moduler udvider den via Odoos arvemekanisme. Salgsmodulet tilføjer fx logik for at oprette fakturaer fra ordrer, indkøbsmodulet for leverandørfakturaer — uden at kopiere kernearkitekturen.
Vigtige felter i modellen
Nedenfor er de mest centrale felter i account.move, som du bør kende for at kunne håndtere fakturering, leverandørbetalinger og bogføring korrekt.
1. name
Type: Char. Feltet indeholder journalens nummer eller betegnelse, typisk genereret fra journalens sekvens. Det vises i lister og på udskrifter som dokumentets identifikator.
2. move_type
Type: Selection. Angiver posteringens type: entry (manuel bogføring), out_invoice (kunde-faktura), out_refund (kunde-kreditnota), in_invoice (leverandørfaktura), in_refund (leverandør-kreditnota). Denne værdi styrer visninger og workflows.
3. state
Type: Selection. Arbejdsgangens tilstand: draft, posted eller cancel. Draft kan redigeres, posted er låst og påvirker hovedbogen, cancel annullerer effekten.
4. date
Type: Date. Dokumentdatoen, som bruges i rapportering, forfaldsberegninger og periodeafslutninger. For fakturaer svarer det ofte til fakturadatoen.
5. journal_id
Type: Many2one (account.journal). Den journal posten hører til — salg, indkøb, bank eller diverse. Journalen fastsætter sekvens og standardkonti.
6. company_id
Type: Many2one (res.company). Ved multi-selskaber angiver dette, hvilket selskab posten tilhører — vigtigt for synlighed, konsolidering og rapportering.
7. partner_id
Type: Many2one (res.partner). Kunden eller leverandøren. Påkrævet for fakturaer og regninger, og bruges til forfalds- og betalingsafstemning samt overskrifter på dokumenter.
8. currency_id
Type: Many2one (res.currency). Valutaen for posten; beløb gemmes i denne valuta, mens konvertering til selskabsvaluta sker ved rapportering.
9. amount_total
Type: Monetary. Postens samlede beløb — for fakturaer det der skal betales. Feltet er beregnet ud fra de tilknyttede linjer.
10. amount_residual
Type: Monetary. Det udestående beløb. Når en faktura er betalt, bliver værdien 0. Vigtigt for aging og betalingshåndtering.
11. payment_state
Type: Selection. Betalingsstatus: not_paid, in_payment, paid, partial, reversed eller invoicing_legacy. Bruges til rykkere, rapporter og dashboards.
12. line_ids
Type: One2many (account.move.line). Posteringens bogføringslinjer — hver med konto, debet og kredit. Summen af debet skal matche summen af kredit.
13. invoice_line_ids
Type: One2many (account.move.line). På fakturaer og regninger indeholder dette produkt- eller ydelseslinjerne, som ved bogføring bliver til de underliggende journal lines.
14. invoice_date
Type: Date. Fakturadatoen, relevant for momsperioder og faktureringslogik. Kan i visse opsætninger være forskellig fra postens dato.
15. invoice_date_due
Type: Date. Betalingsforfaldsdatoen, beregnet ud fra betalingsbetingelser eller sat manuelt. Anvendes i forfalds- og inkassoprocesser.
16. ref
Type: Char. Ekstern reference eller leverandørens fakturanummer. Hjælper ved betalinger og afstemning mod eksterne dokumenter.
17. invoice_origin
Type: Char. Kildeordrenummeret — fx salgsordre — der skabte fakturaen. Bruges til sporbarhed fra ordre til faktura.
18. create_date
Type: Datetime. Tidspunktet for, hvornår posten blev oprettet. Administreres automatisk af systemet.
19. write_date
Type: Datetime. Sidste ændringsdato og -tidspunkt for posten. Også automatisk håndteret.
20. narration
Type: Text. Interne noter eller bilagstekst. Vises på bogførte udskrifter, men er normalt ikke synlig for kunder på fakturaudskrifter.
21. fiscal_position_id
Type: Many2one (account.fiscal.position). Bestemmer skatteregler baseret på partner og land, og vælger hvilke skattekonti der skal bruges.
22. invoice_payment_term_id
Type: Many2one (account.payment.term). Betalingsbetingelser (fx 30 dage). Brugt til at udregne invoice_date_due og opdele betalinger.
23. invoice_user_id
Type: Many2one (res.users). Den ansvarlige bruger eller sælger på fakturaen — relevant for rapportering og provision.
24. reversed_entry_id
Type: Many2one (account.move). Ved omvendte posteringer linker dette felt til den oprindelige post og bevarer revisionsstien.
25. to_check
Type: Boolean. Markør for poster, der kræver manuel gennemgang — fx ved bankafstemning eller undtagelseshåndtering.
26. active
Type: Boolean. Blød sletning: når False arkiveres posten. Ofte sættes annullerede poster til active=False.
27. sequence_number
Type: Integer. Sekvensnummer fra journalen til sortering og visning. Håndteres af sequences-mixen.
28. amount_untaxed
Type: Monetary. Subtotal før skat — summen af linjebeløb uden moms på fakturaen.
29. amount_tax
Type: Monetary. Det samlede skattebeløb, beregnet fra linjer og skatteopsætning.
30. invoice_source_email
Type: Char. Ved leverandørfakturaer importeret fra e-mail gemmes afsenderens adresse her til sporbarhed og automatisering.
Hvordan modellen bruges i forretningsprocesser
1. Kundefakturering
Når en salgsordre leveres, opretter Odoo typisk en account.move med move_type out_invoice. Fakturalinjerne kommer fra ordren, og når posten bogføres, genereres de bagvedliggende kredit- og debetlinjer samt tilgodehavenderne.
2. Leverandørregninger
Indkøbsordrer kan skabe leverandørfakturaer, eller de indtastes manuelt. Hver leverandørfaktura er en account.move med move_type in_invoice, hvor partner_id peger på leverandøren, og bogføring opdaterer leverandørgælden.
3. Betalingsafstemning
Betalinger matches med fakturaer ud fra amount_residual og payment_state. Afstemningen linker betalingsposterne med fakturaerne og nulstiller residualet, når betaling er gennemført.
4. Manuelle bogføringer
Regnskabsmedarbejdere opretter poster med move_type entry til justeringer, periodiseringer eller korrektioner. De tilføjer selv line_ids med konti, debet og kredit — posten skal balancere før bogføring.
5. Kreditnotaer og refunderinger
Kreditnotaer bruger move_type out_refund eller in_refund og ophæver effekten af en oprindelig faktura eller regning. reversed_entry_id knytter tilbage til originalen for revisionsspor.
Hvordan udviklere udvider modellen
Udviklere kan udvide account.move med flere strategier, hvor Odoo’s arv og modulstruktur er de vigtigste værktøjer.
Modelarv
Sæt _inherit = 'account.move' i din modulmodel for at udvide funktionaliteten. Så kan du tilføje felter, overskrive metoder eller lægge restriktioner i et separat modul, hvilket gør opgraderinger lettere.
Tilføjelse af felter
Definér nye felttyper i din arvede model — Char, Many2one, Boolean, Integer, Text, Selection osv. Overvej selskabsafhængige felter i multi-company opsætninger, og sæt domæner på move_type for felter, der kun gælder for fakturaer.
Udvidelser i Python
Overskriv create, write, _post eller button_draft for at indsprøjte logik, men kald altid super() for at bevare eksisterende flow. Vær særlig opmærksom på beregnede felter og deres afhængigheder, samt brug Odoo-dekoratorer (@api.model, @api.depends) korrekt.
Odoo Studio
Odoo Studio gør det muligt at tilføje felter uden at kode — nyttigt til hurtige, mindre ændringer. Til kompleks validering, automatiserede handlinger eller dybere tilpasninger er et egentligt modul dog mere holdbart.
Vigtigt: account.move er en almindelig vedvarende model — ikke en abstrakt template eller transient model. Det betyder, at posterne gemmes permanent i databasen og ikke er midlertidige som wizards.
Anbefalet fremgangsmåde
- Når du bygger rapporter eller integrationer, filtrér altid på move_type, fordi de forskellige typer har forskellig obligatorisk data og adfærd.
- Brug altid den korrekte journal for hver posttype. Forkerte journals kan ødelægge sekvenser og give urigtige rapporter.
- Ved oprettelse af poster via API skal du sikre, at line_ids balancerer (debet = kredit) før bogføring — ubalancerede posteringer afvises.
- Ved import fra eksterne systemer, match dine dokumenttyper til move_type korrekt: out_invoice til salg, in_invoice til køb osv.
- Brug x_-præfikset til dine egne felter for at undgå navnekonflikter med fremtidige Odoo-udgivelser.
Almindelige fejltagelser
- At poste ubalancerede linjer. Odoo afviser bogføringen — tjek altid at debet og kredit stemmer overens.
- At ændre posteringer efter de er bogført. Posted poster er låst; lav i stedet en reversal og opret en ny korrekt postering.
- At glemme partner_id på kunde- eller leverandørposter. Mange rapporter og arbejdsgange forudsætter partneren.
- At bruge forkert move_type. En out_refund opfører sig ikke som en negativ out_invoice — brug den korrekte type for kreditnotaer.
- At overskrive kernemetoder uden at kalde super(). Det kan bryde andre modulers funktionalitet eller gøre opgraderinger sværere.
Konklusion
account.move er kernen i Odoo Regnskab — en samlet struktur til fakturaer, regninger og bogføringer. Kendskab til modelens felter og udvidelsesmuligheder gør det langt nemmere at konfigurere, tilpasse og integrere Odoo i virksomheden.
Uanset om du kortlægger forretningsprocesser som konsulent eller udvikler skræddersyede moduler, sparer et solidt kendskab til account.move tid og mindsker risikoen for fejl.
Har du brug for hjælp til Odoo?
Dasolo hjælper virksomheder med implementering, tilpasning og optimering af Odoo. Vi er specialister i API-integrationer og udvikling med dyb indsigt i Odoos datamodel og modeller som account.move.
Hvis du har brug for hjælp til implementering, udvikling af moduler eller integrationer i Odoo, står vi klar til at hjælpe. Book en demo for at tale om dit projekt.