Introduktion
I Odoo beskriver modeller hur information lagras i databasen. Allt från order till fakturor och bokföringsposter representeras genom modeller — de bestämmer fälten, relationerna och var posterna sparas.
Att förstå modeller är viktigt både för utvecklare och funktionella konsulter. Modeller utgör ryggraden i Odoos datalager och styr vilka fält som finns, hur poster länkas och vilken affärslogik som körs.
Den här texten går igenom en av de centrala modellerna i Odoo Accounting: account.move. Oavsett om du tar fram rapporter, kopplar ihop system eller ställer in faktureringsflöden kommer du ofta att möta just den här modellen.
Vad är modellen account.move
Modellen account.move fångar själva bokföringsposter i systemet. Från Odoo 13 och framåt slogs tidigare separata modeller för kundfakturor, leverantörsfakturor, kreditfakturor och manuella verifikationer ihop — allt hanteras nu som olika typer inom account.move.
I grunden används modellen av redovisningsmodulen. Den är förälder till account.move.line som innehåller de enskilda debet- och kreditraderna. Varje faktura, räkning eller verifikation är en account.move med en eller flera rader.
Själva definitionen ligger i account-modulen, medan andra moduler bygger på den via arv. Försäljning lägger exempelvis till automatisk fakturaskapning från order, inköp lägger till leverantörsfakturor — utan att duplicera kärnstrukturen.
Viktiga fält i modellen
Nedan följer de fält som oftast är relevanta när du arbetar med fakturor, räkningar och verifikationer. Kännedom om dem förenklar både konfiguration och utveckling.
1. name
Typ: Char. Fältet används för verifikationsnumret eller namnet på dokumentet. Vanligtvis genereras det automatiskt från journalens sekvens och syns i listor och på utskrifter.
2. move_type
Typ: Selection. Bestämmer vilken typ av verifikation det är — t.ex. manuell verifikation, kundfaktura, kundkredit, leverantörsfaktura eller leverantörskredit. Fältet styr också vilka vyer och arbetsflöden som gäller.
3. state
Typ: Selection. Visar arbetsflödets status: draft, posted eller cancel. I utkast kan poster ändras, postade poster är låsta och påverkar huvudboken, cancel neutraliserar effekten.
4. date
Typ: Date. Dokumentets datum. Används i rapporter, vid åldring och periodstängning. För fakturor är detta ofta fakturadatum.
5. journal_id
Typ: Many2one (account.journal). Anger vilken journal verifikationen hör till — försäljning, inköp, bank eller diverse. Journalen bestämmer sekvens och förvalda konton.
6. company_id
Typ: Many2one (res.company). I koncerner med flera bolag anger detta vilken enhet verifikationen hör till — påverkar synlighet och koncernkonsolidering.
7. partner_id
Typ: Many2one (res.partner). Kund eller leverantör. Krävs för fakturor och räkningar och används i åldringsrapporter, betalningsmatchning och på dokumenthuvuden.
8. currency_id
Typ: Many2one (res.currency). Valutan för verifikationen. Beloppen lagras i denna valuta; multi-valutaaffärer redovisas i bolagets valuta för rapportering.
9. amount_total
Typ: Monetary. Totalbeloppet för verifikationen. För fakturor motsvarar det att betala beloppet och beräknas från raderna.
10. amount_residual
Typ: Monetary. Det kvarvarande obetalda beloppet. För betalda fakturor är det noll. Används i åldring och betalningsrutiner.
11. payment_state
Typ: Selection. Betalstatus: not_paid, in_payment, paid, partial, reversed eller invoicing_legacy. Påverkar påminnelser och rapportering.
12. line_ids
Typ: One2many (account.move.line). Verifikationens rader. Varje rad anger konto, debet och kredit — summan av debet måste motsvara summan av kredit.
13. invoice_line_ids
Typ: One2many (account.move.line). För fakturor och räkningar innehåller detta produkt- eller tjänsteraderna, som vid bokning genererar en eller flera verifikationsrader.
14. invoice_date
Typ: Date. Fakturadatum. Viktigt för momsperioder och fakturahantering; kan i vissa inställningar skilja sig från verifikationsdatumet.
15. invoice_date_due
Typ: Date. Betalningsdatum enligt villkor. Beräknas från betalningsvillkor eller sätts manuellt och används för påminnelser och åldringslistor.
16. ref
Typ: Char. Extern referens, exempelvis leverantörens fakturanummer. Bra vid matchning mot betalningar och externa dokument.
17. invoice_origin
Typ: Char. Ursprungligt dokument — t.ex. ordernummer för fakturor skapade ur en försäljningsorder. Ger spårbarhet mellan order och faktura.
18. create_date
Typ: Datetime. Tidpunkt då posten skapades. Hanteras automatiskt av Odoo.
19. write_date
Typ: Datetime. Tidpunkt för senaste ändring. Också automatiskt skött av systemet.
20. narration
Typ: Text. Interna anteckningar eller minnesanteckningar. Visas på bokföringsutskrifter men inte för kunden på fakturor.
21. fiscal_position_id
Typ: Many2one (account.fiscal.position). Anger skatteregler baserat på partner och land — påverkar vilka skatter som appliceras.
22. invoice_payment_term_id
Typ: Many2one (account.payment.term). Betalningsvillkor (t.ex. Netto 30). Används för att beräkna förfallodatum och dela upp betalningar.
23. invoice_user_id
Typ: Many2one (res.users). Ansvarig säljare eller användare för fakturan. Används i provisioner och rapporter.
24. reversed_entry_id
Typ: Many2one (account.move). Vid krediteringar länkar detta till den ursprungliga verifikationen och ger spårbarhet för korrigeringar.
25. to_check
Typ: Boolean. Markör för poster som kräver granskning. Vanlig i bankavstämning och undantagshantering.
26. active
Typ: Boolean. Mjuk radering/arkivering. När False är posten arkiverad — cancellerade verifikationer kan sättas som inaktiva.
27. sequence_number
Typ: Integer. Sekvensnummer från journalen. Används för sortering och presentation och hanteras av sekvensmixin.
28. amount_untaxed
Typ: Monetary. Belopp före skatt. För fakturor är detta summan av radernas belopp innan skatt.
29. amount_tax
Typ: Monetary. Totalt skattemässigt belopp. Beräknas från fakturarader och momskonfiguration.
30. invoice_source_email
Typ: Char. Vid leverantörsfakturor skapade från e-post sparas här källadressen. Underlättar automatiserad fakturahantering.
Hur modellen används i affärsflöden
1. Kundfakturering
När en försäljningsorder levereras skapas i Odoo en account.move med move_type out_invoice. Fakturaraderna kommer från ordern och när verifikationen bokas genereras rader som uppdaterar kundfordringarna.
2. Leverantörsfakturor
Inköpsorder kan generera leverantörsfakturor eller så läggs de in manuellt. Varje leverantörsfaktura är en account.move med move_type in_invoice och när den bokas uppdateras leverantörsskulderna.
3. Betalningsavstämning
Betalningar matchas mot fakturor med hjälp av amount_residual och payment_state. Avstämningsprocessen kopplar betalningsverifikationer till fakturaverifikationer och nollställer restbeloppet.
4. Manuella verifikationer
Redovisningsansvariga skapar verifikationer med move_type entry för justeringar, periodiseringar eller korrigeringar. De lägger själva in rader med konto, debet och kredit och verifikationen måste balansera för att kunna bokföras.
5. Kreditfakturor och återbetalningar
Kreditnotor använder move_type out_refund eller in_refund och vänder effekten av den ursprungliga fakturan. reversed_entry_id länkar tillbaka till originalet för revisionsspår.
Hur utvecklare bygger på modellen
Utvecklare bygger på account.move med olika mönster, där modellärv är det vanligaste sättet att lägga till funktionalitet.
Modellarv
Genom att sätta _inherit = 'account.move' kan du utöka modellen. Du lägger till fält, modifierar metoder eller lägger in begränsningar i din modul — på så vis hålls ändringarna separata och lättare att underhålla.
Lägga till fält
Definiera nya fält i den ärvda modellen med rätt fälttyp: Char, Many2one, Boolean, Integer, Text eller Selection. Tänk på företagsspecifika fält i multi-company-miljöer och använd domäner för att begränsa fält till fakturatyper vid behov.
Python-utökningar
Överskugga metoder som create, write, _post eller button_draft för att styra logik vid skapande, uppdatering och bokning. Anropa alltid super() där det behövs och var försiktig med beräknade fält och deras beroenden. Använd Odoos API-dekoratörer (@api.model, @api.depends) korrekt.
Odoo Studio
Odoo Studio är smidigt för snabba ändringar — till exempel extra referensfält utan kod. För mer avancerad validering, automatik eller komplexa processer är kodade moduler mer hållbara.
Observera att account.move är en vanlig (permanent) modell — inte ett abstrakt eller transient objekt. Abstrakta modeller skapar inga tabeller, transient-modeller används för wizards. account.move sparar bestående redovisningsdata.
Rekommenderade arbetssätt
- Filtrera alltid på move_type när du bygger rapporter eller integrationer — olika typer har skilda krav och beteenden.
- Använd rätt journal för varje typ av verifikation. Fel journal kan störa sekvenser och ge fel i rapporteringen.
- När du skapar verifikationer via API, säkerställ att line_ids balanserar (debet = kredit) innan bokning. Obalanserade poster kommer att misslyckas vid validering.
- Vid import från externa system: mappa dokumenttyper till rätt move_type — out_invoice för försäljning och in_invoice för inköp, för att undvika felaktiga flöden.
- Använd prefixet x_ för egna fält för att minska risk för kollisioner med framtida Odoo-versioner.
Vanliga misstag
- Att försöka bokföra obalanserade rader leder till att Odoo avvisar posten. Kontrollera alltid att debet och kredit stämmer.
- Att ändra postade verifikationer direkt är fel — postade poster är låsta. Gör en reversal och skapa en ny verifikation för korrigeringar.
- Att glömma partner_id på kund- eller leverantörsposter skapar problem — många rapporter och processer förutsätter att partner är satt.
- Att använda fel move_type är vanligt — en out_refund är inte samma sak som en negativ out_invoice. Använd rätt typ för kreditfakturor.
- Att override:a kärnmetoder utan att anropa super() kan skapa oförutsägbara fel och försvåra framtida uppgraderingar.
Sammanfattning
account.move är navet i Odoo Accounting — en samlad modell för fakturor, räkningar och verifikationer. Att förstå dess fält och hur andra moduler bygger på den gör det lättare att konfigurera, anpassa och integrera systemet.
Oavsett om du arbetar funktionellt med processkartläggning eller bygger egna moduler tekniskt, sparar kunskap om account.move tid och minskar risken för fel.
Behöver du hjälp med din Odoo-implementation?
Dasolo hjälper företag att implementera, anpassa och optimera Odoo. Vi specialiserar oss på API-integrationer och utveckling och har djup erfarenhet av Odoos datamodell, inklusive modeller som account.move.
Om du behöver stöd med implementation, skräddarsydda moduler eller systemintegrationer finns vi tillgängliga för konsultation. Boka en demo för att diskutera ditt projekt.