Introduksjon
I Odoo beskriver modeller hvordan forretningsopplysninger organiseres og lagres i databasen. Alt fra salg og innkjøp til fakturaer og hovedboksposteringer finnes i ulike modeller – de er skjemaet som holder systemet sammen.
Å forstå Odoo‑modeller er viktig både for utviklere og funksjonelle konsulenter. Modellene danner grunnmuren i datamodellen: felttyper, relasjoner og forretningslogikk defineres her, og fra dette bygger man prosesser, rapporter og integrasjoner.
Denne artikkelen tar for seg en av de mest sentrale modellene i regnskapsdelen: account.move. Enten du lager skreddersydde rapporter, bygger integrasjoner mot eksterne systemer eller setter opp fakturaflyt, kommer du til å møte denne modellen.
Hva er account.move‑modellen
account.move er Odoos representasjon av journalposter. Fra og med Odoo 13 ble kunde- og leverandørfakturaer, kreditnotaer og manuelle journalposter samlet i én modell, slik at alle posteringer håndteres konsistent i account.move.
Modellen brukes av regnskapsmodulen og er «forelderen» til account.move.line, som inneholder de enkelte debet- og kredittrader. En faktura, en leverandørregning eller en manuell justering er én account.move med én eller flere linjer.
Selve definisjonen ligger i account‑modulen, men andre moduler bygger videre på den via arv. Salg legger til automatiske fakturagenereringer, innkjøp legger til leverandørregninger – hver modul tilfører funksjonalitet uten å gjenta kjerneoppsettet.
Viktige felt i modellen
Nedenfor finner du de viktigste feltene i account.move som det er nyttig å kjenne til. Gode kunnskaper om disse gjør det enklere å jobbe med fakturering, betaling og bokføring i Odoo.
1. name
Type: Char. Feltet holder navn eller nummer på dokumentet, som oftest generert fra journalens sekvens. Vises i lister og på utskrifter for å identifisere posten.
2. move_type
Type: Selection. Angir hvilken type post det er: manuell journalpost, kundefaktura, leverandørfaktura eller kreditnota. Feltet styrer hvilke skjermbilder og arbeidsflyter som gjelder.
3. state
Type: Selection. Angir arbeidsflyt‑tilstand: utkast, bokført eller kansellert. Utkast kan endres, bokførte poster er låst og påvirker hovedboken, kansellerte reverserer effekten.
4. date
Type: Date. Dokumentdatoen. Brukes i rapportering, aldringsberegning og periodeavslutning. For fakturaer er dette gjerne fakturadatoen.
5. journal_id
Type: Many2one (account.journal). Hvilken journal posten tilhører. Salg, innkjøp, bank og diverse har egne journaler som bestemmer sekvens og standardkontoer.
6. company_id
Type: Many2one (res.company). Firmaets identifikator i multi‑selskapsscenarier. Påvirker synlighet, valutahåndtering og konsolidering.
7. partner_id
Type: Many2one (res.partner). Kunde eller leverandør. Viktig for fakturaer og regninger, brukt ved avstemming, aldring og i dokumentoverskrifter.
8. currency_id
Type: Many2one (res.currency). Valutaen for posten. Beløp lagres i denne valutaen; ved flervaluta rapporteres det også i selskapsvaluta.
9. amount_total
Type: Monetary. Totalbeløpet på posten. For fakturaer tilsvarer dette summen som skal betales, beregnet fra linjene.
10. amount_residual
Type: Monetary. Det utestående beløpet. For betalte fakturaer er dette null, og feltet brukes i aldring og betalingsflyt.
11. payment_state
Type: Selection. Betalingsstatus: ikke betalt, under betaling, betalt, delvis, reversert eller eldre varians. Påvirker purringer og rapporter.
12. line_ids
Type: One2many (account.move.line). Journalradene for posten. Hver rad har konto, debet og kredit; summen av debet må balansere med kreditt.
13. invoice_line_ids
Type: One2many (account.move.line). For fakturaer og regninger inneholder dette produkt‑ eller tjenestelinjene. Ved bokføring genereres en eller flere regnskapslinjer fra hver av disse.
14. invoice_date
Type: Date. Fakturadato brukt i avgiftsperioder og rapportering. I enkelte konfigurasjoner kan denne avvike fra postdatoen.
15. invoice_date_due
Type: Date. Forfallsdato. Beregnes fra betalingsbetingelser eller settes manuelt, og benyttes i aldring og purring.
16. ref
Type: Char. Ekstern referanse, for eksempel leverandørens fakturanummer. Nyttig ved avstemming og verifisering mot eksterne dokumenter.
17. invoice_origin
Type: Char. Kildedokumentet, for eksempel ordrenummer ved faktura fra salg. Gir sporbarhet fra ordre til faktura.
18. create_date
Type: Datetime. Tidspunkt for når posten ble opprettet. Håndteres automatisk av systemet.
19. write_date
Type: Datetime. Tidspunkt for siste endring. Også automatisk oppdatert for revisjonsspor.
20. narration
Type: Text. Intern merknad eller memo som kan vises på bokførte dokumenter, men normalt ikke på kunde‑fakturaer.
21. fiscal_position_id
Type: Many2one (account.fiscal.position). Brukes for skatteregler og avgiftsplassering basert på partner og land.
22. invoice_payment_term_id
Type: Many2one (account.payment.term). Betalingsbetingelser (f.eks. Netto 30) som bestemmer forfallsdato og eventuell delbetaling.
23. invoice_user_id
Type: Many2one (res.users). Kontoansvarlig eller selger knyttet til fakturaen, nyttig ved provisjon og rapportering.
24. reversed_entry_id
Type: Many2one (account.move). Lenke til reversert post ved kreditnotaer eller korreksjoner, for å bevare revisjonsspor.
25. to_check
Type: Boolean. Flagg for poster som trenger gransking eller manuell avstemming, ofte brukt i bankavstemming.
26. active
Type: Boolean. Soft‑delete‑flagg. Inaktive poster er arkiverte og vises ikke i standardlister.
27. sequence_number
Type: Integer. Sekvensnummer fra journalen brukt for sortering og visning, håndteres av sekvens‑miksin.
28. amount_untaxed
Type: Monetary. Beløp før skatt, altså subtotalen på fakturaen før avgifter beregnes.
29. amount_tax
Type: Monetary. Totalt skattebeløp, beregnet fra fakturalinjene og skattereglene.
30. invoice_source_email
Type: Char. Ved automatisk innlesing av leverandørfakturaer fra e‑post lagres avsenderadressen her for sporbarhet.
Slik brukes modellen i forretningsprosesser
1. Kundefakturering
Når en salgsordre leveres, kan Odoo opprette en account.move med move_type out_invoice. Fakturalinjene kommer fra ordren; når posten bokføres opprettes de underliggende regnskapslinjene og kundefordringene oppdateres.
2. Leverandørfakturaer
Innkjøpsordrer kan generere regninger, eller regninger legges inn manuelt. Disse lagres som account.move med move_type in_invoice, med leverandøren i partner_id. Bokføring oppdaterer leverandørgjeld.
3. Betalingsavstemming
Betalinger matches mot fakturaer ved hjelp av amount_residual og payment_state. Avstemmingsprosessen kobler betalingsposter til fakturaposter og nuller ut utestående beløp.
4. Manuelle journalposteringer
Regnskapsførere kan opprette move_type entry for justeringer, periodiseringer eller korreksjoner. De legger til line_ids med konto, debet og kredit, og postingen må balansere før den bokføres.
5. Kreditnotaer og refusjoner
Kreditnotaer representeres som out_refund eller in_refund og reverserer effekten av en original faktura eller regning. reversed_entry_id peker tilbake til opprinnelig post for revisjon.
Slik utvider utviklere modellen
Utviklere bygger videre på account.move med flere teknikker; modell‑arv er det mest brukte mønsteret.
Modellarv
Bruk _inherit = 'account.move' for å utvide modellen. Du kan legge til felt, overstyre metoder og legge inn begrensninger. Å holde endringene i egne moduler gjør det enklere å oppgradere systemet senere.
Legge til felt
Definer nye felter i den arvede modellen med riktig type: Char, Many2one, Boolean, Integer, Text eller Selection. Tenk gjennom selskapsspesifikke felt i multi‑selskap og bruk domener på move_type når felt kun skal gjelde for fakturaer.
Python‑utvidelser
Overstyr metoder som create, write, _post eller button_draft for å legge til logikk. Alltid kall super() der det trengs, og vær nøye med avhengigheter for beregnede felt ved hjelp av dekoratører som @api.depends og @api.model.
Odoo Studio
Odoo Studio gjør det mulig å legge til felt uten kode og er fint for raske tilpasninger. For avansert validering, automatisering eller vedlikeholdbar logikk er egne moduler og kode ofte bedre på sikt.
Merk: account.move er en ordinær database‑modell, ikke en abstrakt eller transient modell. Abstrakte modeller lager ingen tabeller, og transient‑modeller er midlertidige for wizards — account.move lagrer permanente regnskapsdata.
Beste praksis
- Filtrer alltid på move_type i rapporter og integrasjoner. Ulike typer har ulike feltkrav og oppførsel.
- Bruk riktig journal for hver type post. Feil journal kan ødelegge sekvenser og gi feil i rapporteringen.
- Når du oppretter poster via API, sørg for at line_ids balanserer (debet = kredit) før bokføring. Ubalanserte poster blir avvist.
- Ved import fra eksterne systemer, kartlegg dokumenttypene til riktig move_type: out_invoice for salg og in_invoice for kjøp.
- Bruk prefikset x_ for egendefinerte felt for å unngå kollisjoner med fremtidige Odoo‑felt.
Vanlige feil
- Å forsøke å bokføre ubalanserte linjer. Odoo vil avvise postingen — kontroller at debet og kredit stemmer.
- Å endre bokførte poster direkte. Bokførte poster er låst; bruk reversering og opprett en ny post for korrigeringer.
- Å glemme å sette partner_id på kunde‑ eller leverandørposter. Mange rapporter og arbeidsflyter forutsetter at partner er satt.
- Å bruke feil move_type. En out_refund er ikke det samme som en negativ out_invoice — bruk riktig type for kreditnotaer.
- Å overstyre kjernemetoder uten å kalle super(). Det kan ødelegge annen funksjonalitet og gjøre framtidige oppgraderinger vanskelige.
Oppsummering
account.move er kjernen i Odoo‑regnskapet og samler fakturaer, regninger og journalposter i én konsistent modell. Kjennskap til felt og utvidelsesmuligheter gjør det enklere å konfigurere, tilpasse og integrere Odoo på riktig måte.
Enten du kartlegger forretningsprosesser eller bygger moduler, vil grundig forståelse av account.move spare tid og redusere risiko for feil.
Trenger du hjelp med Odoo?
Dasolo hjelper bedrifter med implementasjon, tilpasning og optimalisering av Odoo. Vi er spesialister på API‑integrasjoner og utvikling, og har solid erfaring med Odoos dataarkitektur og sentrale modeller som account.move.
Hvis du trenger bistand med implementasjon, skreddersydde moduler eller integrasjoner, står vi klare til å hjelpe. Book en demo for å snakke om prosjektet ditt.