Introduktion
I Odoo definierar modeller hur data struktureras och lagras i databasen. Varje del av affärsdata du arbetar med, från försäljningsorder till fakturor till journalposter, finns i en modell.
Att förstå Odoo-modeller är avgörande för både utvecklare och funktionella konsulter. Modeller är grunden för Odoo:s dataarkitektur. De definierar Odoo-fält, relationer och affärslogik.
Denna artikel fokuserar på en av de viktigaste modellerna i Odoo Accounting: account.move. Oavsett om du bygger anpassade rapporter, integrerar externa system eller konfigurerar faktureringsarbetsflöden, kommer du att arbeta med denna modell.
Vad är account.move-modellen
Modellen account.move representerar journalposter i Odoo. I Odoo 13 och senare enades den om vad som tidigare var separata modeller: kundfakturor, leverantörsfakturor, kreditnotor och manuella journalposter. Idag lever de alla i account.move.
Denna modell i Odoo används av redovisningsmodulen. Den är förälder till account.move.line, som håller de individuella debet- och kreditlinjerna. Varje faktura, faktura eller journalpost är en account.move-post med en eller flera linjer.
Modellen definieras i redovisningsmodulen. Andra moduler utökar den genom Odoo-modellarv. Försäljning lägger till fakturaskapande från beställningar. Inköp lägger till fakturaskapande. Varje modul lägger till vad den behöver utan att duplicera den grundläggande strukturen.
Nyckelfält i modellen
Här är de viktigaste Odoo-fälten i modellen account.move. Att förstå dessa kommer att hjälpa dig att arbeta effektivt med fakturor, fakturor och journalposter.
1. namn
Typ: Char. Detta fält lagrar journalpostens nummer eller namn. Det genereras vanligtvis automatiskt från journalens sekvens. Visas i listvyer och på tryckta dokument.
2. move_type
Typ: Val. Bestämmer typen av rörelse: entry (manuell journalpost), out_invoice (kundfaktura), out_refund (kundkreditnota), in_invoice (leverantörsfaktura), in_refund (leverantörskreditnota). Detta fält styr vilka vyer och arbetsflöden som gäller.
3. state
Typ: Val. Arbetsflödesstatus: utkast, publicerad eller avbruten. Utkast kan redigeras. Publicerade rörelser är låsta och påverkar huvudboken. Avbryt återför effekten.
4. datum
Typ: Datum. Dokumentdatumet. Används för rapportering, åldersanalys och periodavslut. För fakturor är detta ofta fakturadatumet.
5. journal_id
Typ: Many2one (account.journal). Journalen som denna transaktion tillhör. Försäljnings-, inköps-, bank- och övriga journaler har var och en sin egen. Journalen bestämmer sekvensen och standardkontona.
6. company_id
Typ: Many2one (res.company). I flerbolagsinställningar anger detta vilken företag transaktionen tillhör. Påverkar synlighet och konsolidering av poster.
7. partner_id
Typ: Many2one (res.partner). Kunden eller leverantören. Krävs för fakturor och räkningar. Används för åldersrapporter, betalningsmatchning och dokumenthuvuden.
8. currency_id
Typ: Many2one (res.currency). Valutan för transaktionen. Beloppen lagras i denna valuta. Transaktioner med flera valutor använder företagsvalutan för rapportering.
9. amount_total
Typ: Monetär. Det totala beloppet för transaktionen. För fakturor är detta det belopp som ska betalas. Beräknas från raderna.
10. amount_residual
Typ: Monetär. Det obetalda beloppet. För betalda fakturor är detta noll. Används för ålders- och betalningsarbetsflöden.
11. payment_state
Typ: Val. Betalningsstatus: not_paid, in_payment, paid, partial, reversed, eller invoicing_legacy. Driver betalningspåminnelser och rapportering.
12. line_ids
Typ: One2many (account.move.line). Journalpostens rader. Varje rad har ett konto, debet och kredit. Summan av debet måste vara lika med summan av kredit.
13. invoice_line_ids
Typ: One2many (account.move.line). För fakturor och räkningar är detta produkt- eller tjänsterader. Varje rad genererar en eller flera journalpostrader när den bokförs.
14. invoice_date
Typ: Datum. Fakturadatumet. Används för fakturering och skatteperioder. Kan skilja sig från bokföringsdatumet i vissa konfigurationer.
15. invoice_date_due
Typ: Datum. Förfallodatum för betalning. Beräknas utifrån betalningsvillkor eller sätts manuellt. Används för åldersanalys och krav.
16. ref
Typ: Char. Extern referens eller leverantörsfakturanummer. Användbart för att matcha betalningar och avstämma med externa dokument.
17. invoice_origin
Typ: Char. Källdokumentet. För fakturor från försäljningsorder lagras SO-numret här. Möjliggör spårbarhet från order till faktura.
18. create_date
Typ: Datetime. Lagrar datum och tid när posten skapades. Hanteras automatiskt av Odoo.
19. write_date
Typ: Datetime. Lagrar datum och tid för den senaste ändringen. Också hanterad automatiskt.
20. narration
Typ: Text. Interna anteckningar eller memo. Visas på tryckta journalposter. Inte synliga för kunder på fakturor.
21. fiscal_position_id
Typ: Many2one (account.fiscal.position). Den skattemässiga positionen för skatteregler. Bestämmer vilka skatter som gäller baserat på partner och land.
22. invoice_payment_term_id
Typ: Many2one (account.payment.term). Betalningsvillkor (t.ex. Net 30). Används för att beräkna invoice_date_due och dela upp betalningar.
23. invoice_user_id
Typ: Many2one (res.users). Säljaren eller ansvarig användare för fakturan. Används för provision och rapportering.
24. reversed_entry_id
Typ: Many2one (account.move). För omvända poster, länkar detta till omvändningsposten. Möjliggör revisionsspår av korrigeringar.
25. to_check
Typ: Boolean. Flagga för poster som behöver granskning. Används i bankavstämning och undantagsarbetsflöden.
26. active
Typ: Boolean. Flagga för mjuk radering. När False, arkiveras posten. Avbrutna poster sätts vanligtvis till active=False.
27. sequence_number
Typ: Integer. Sekvensnumret från journalen. Används för ordning och visning. Hanteras av sekvensmixinen.
28. amount_untaxed
Typ: Monetär. Delbeloppet före skatt. För fakturor är detta summan av radbelopp före skatt.
29. amount_tax
Typ: Monetär. Det totala skattebeloppet. Beräknas från fakturalinjer och skattekonfiguration.
30. invoice_source_email
Typ: Char. För leverantörsfakturor som skapats från e-post, lagrar detta källans e-postadress. Används för automatiserad fakturainmatning.
Hur denna modell används i affärsarbetsflöden
1. Kundfakturering
När en försäljningsorder levereras skapar Odoo en account.move med move_type out_invoice. invoice_line_ids kommer från orderlinjerna. Bokföring av rörelsen skapar journalposterna och uppdaterar kundfordringar.
2. Leverantörsfakturor
Inköpsorder kan generera fakturor, eller så anges fakturor manuellt. Varje faktura är en account.move med move_type in_invoice. partner_id är leverantören. Bokföring uppdaterar leverantörsskulder.
3. Betalningsavstämning
Betalningar matchas mot fakturor med hjälp av fälten amount_residual och payment_state. Avstämningsprocessen kopplar betalningsrörelser till fakturarörelser och rensar det kvarstående beloppet.
4. Manuella journalposter
Revisorer skapar rörelser med move_type entry för justeringar, upplupna kostnader eller korrigeringar. De lägger manuellt till line_ids med konton, debiteringar och krediter. Rörelsen måste balansera innan den bokförs.
5. Kreditnotor och Återbetalningar
Kreditnotor är transaktioner med move_type out_refund eller in_refund. De återställer effekten av den ursprungliga fakturan eller räkningen. reversed_entry_id länkar tillbaka till den ursprungliga för revision.
Hur utvecklare utökar denna modell
Utvecklare utökar account.move med flera mönster. Odoo-modellarv är den huvudsakliga mekanismen.
Modellarv
Använd _inherit = 'account.move' för att utöka modellen. Lägg till nya Odoo-fält, åsidosätt metoder eller lägg till begränsningar. Den ärvda modellen i Odoo behåller dina ändringar i en separat modul för enkla uppgraderingar.
Lägga till Fält
Definiera nya Odoo-fält i din ärvda modell. Använd rätt fälttyp: Char, Many2one, Boolean, Integer, Text, Selection. Tänk på företagsberoende fält för flera företag. För fakturaspecifika fält, använd ett domän på move_type.
Python Utvidgningar
Åsidosätt create, write, _post eller button_draft för att lägga till logik. Använd super() för att anropa den ursprungliga. Var försiktig med beräknade fält och deras beroenden. API-modellen i Odoo-dekoratorer (@api.model, @api.depends) kontrollerar när metoder körs.
Odoo Studio
Odoo Studio låter dig lägga till fält utan kod. Bra för snabba anpassningar som extra referensfält. För komplex logik, validering eller automatiserade åtgärder är anpassade moduler mer underhållbara.
Obs: account.move är en vanlig modell, inte en Odoo-abstrakt modell eller Odoo tillfällig modell. Abstrakta modeller används som mallar och skapar inte databas-tabeller. Tillfälliga modeller är temporära och används för guider. account.move lagrar permanent bokföringsdata.
Bästa praxis
- Filtrera alltid efter move_type när du bygger rapporter eller integrationer. Olika typer har olika obligatoriska fält och beteenden.
- Använd rätt journal för varje move type. Att blanda journaler kan bryta sekvenser och rapportering.
- När du skapar moves via API, se till att line_ids balanserar (debiteringar = krediter) innan du postar. Obalanserade moves kommer att misslyckas med valideringen.
- För fakturaskapande från externa system, mappa dina dokumenttyper till move_type korrekt. out_invoice för försäljning, in_invoice för inköp.
- Använd
x_-prefixet för anpassade fält för att undvika konflikter med framtida Odoo-versioner.
Vanliga misstag
- Posta moves utan balanserade rader. Odoo kommer att avvisa posten. Verifiera alltid att debet- och kreditbelopp matchar.
- Att direkt modifiera postade moves. Postade moves är låsta. Använd en omvändning och skapa en ny move istället.
- Att glömma att ställa in partner_id på kund- eller leverantörsmoves. Många rapporter och arbetsflöden beror på det.
- Att använda fel move_type. En out_refund är inte samma sak som en negativ out_invoice. Använd rätt typ för återbetalningar och kreditnotor.
- Att åsidosätta kärnmetoder utan att kalla super(). Detta kan bryta andra moduler eller framtida uppgraderingar.
Slutsats
Modellen account.move är central för Odoo Accounting. Den representerar fakturor, räkningar och journalposter i en enhetlig struktur. Att förstå dess fält och hur moduler utökar den kommer att hjälpa dig att konfigurera, anpassa och integrera Odoo effektivt.
Oavsett om du är en funktionell konsult som kartlägger affärsprocesser eller en utvecklare som bygger anpassade moduler, kommer en solid förståelse av account.move att spara tid och förhindra fel.
Behöver du hjälp med din Odoo-implementering?
Dasolo hjälper företag att implementera, anpassa och optimera Odoo. Vi specialiserar oss på API-integrationer och Odoo-utveckling. Vårt team har djup erfarenhet av Odoo:s dataarkitektur och modeller som account.move.
Om du behöver hjälp med din Odoo-implementering, anpassade moduler eller integrationer, så finns vi här för att hjälpa till. Boka en demo för att diskutera ditt projekt.