Introduksjon
I Odoo definerer modeller hvordan data er strukturert og lagret i databasen. Hver bit av forretningsdata du jobber med, fra salgsordrer til fakturaer til journaloppføringer, lever i en modell.
Å forstå Odoo-modeller er avgjørende for både utviklere og funksjonelle konsulenter. Modeller er grunnlaget for Odoo-datastrukturen. De definerer Odoo-felt, relasjoner og forretningslogikk.
Denne artikkelen fokuserer på en av de viktigste modellene i Odoo Regnskap: account.move. Enten du bygger tilpassede rapporter, integrerer eksterne systemer eller konfigurerer faktureringsarbeidsflyter, vil du jobbe med denne modellen.
Hva er account.move-modellen
Modellen account.move representerer journaloppføringer i Odoo. I Odoo 13 og senere, ble det samlet det som tidligere var separate modeller: kundefakturaer, leverandørfakturaer, kreditnotaer og manuelle journaloppføringer. I dag lever de alle i account.move.
Denne modellen i Odoo brukes av regnskapsmodulen. Den er forelderen til account.move.line, som inneholder de individuelle debet- og kreditlinjene. Hver faktura, regning eller journaloppføring er én account.move-post med en eller flere linjer.
Modellen er definert i regnskapsmodulen. Andre moduler utvider den gjennom Odoo-modellarv. Salg legger til fakturering fra bestillinger. Innkjøp legger til oppretting av regninger. Hver modul legger til det den trenger uten å duplisere den grunnleggende strukturen.
Nøkkelfelt i modellen
Her er de viktigste Odoo-feltene i account.move-modellen. Å forstå disse vil hjelpe deg med å jobbe effektivt med fakturaer, regninger og journaloppføringer.
1. navn
Type: Char. Dette feltet lagrer journaloppføringsnummeret eller navnet. Det genereres vanligvis automatisk fra journalsekvensen. Vist i listevisninger og på trykte dokumenter.
2. move_type
Type: Valg. Bestemmer typen oppføring: entry (manuell journaloppføring), out_invoice (kundefaktura), out_refund (kundekreditnota), in_invoice (leverandørfaktura), in_refund (leverandørkreditnota). Dette feltet bestemmer hvilke visninger og arbeidsflyter som gjelder.
3. state
Type: Valg. Arbeidsflytstatus: utkast, postet eller kansellert. Utkast kan redigeres. Posterte oppføringer er låst og påvirker hovedboken. Kansellert reverserer effekten.
4. date
Type: Dato. Dokumentdatoen. Brukes til rapportering, aldring og periodeavslutning. For fakturaer er dette ofte fakturadatoen.
5. journal_id
Type: Many2one (account.journal). Journalet som denne bevegelsen tilhører. Salg, innkjøp, bank og diverse journaler har hver sine. Journalen bestemmer sekvensen og standardkontoene.
6. company_id
Type: Many2one (res.company). I multi-selskapsoppsett indikerer dette hvilket selskap bevegelsen tilhører. Påvirker synlighet av poster og konsolidering.
7. partner_id
Type: Many2one (res.partner). Kunden eller leverandøren. Påkrevd for fakturaer og regninger. Brukes for aldringsrapporter, betalingsmatching og dokumentoverskrifter.
8. currency_id
Type: Many2one (res.currency). Valutaen for bevegelsen. Beløp lagres i denne valutaen. Multi-valuta bevegelser bruker selskapsvalutaen for rapportering.
9. amount_total
Type: Monetary. Det totale beløpet for bevegelsen. For fakturaer er dette beløpet forfalt. Beregnes fra linjene.
10. amount_residual
Type: Monetary. Det ubetalte beløpet. For betalte fakturaer er dette null. Brukes for aldrings- og betalingsarbeidsflyter.
11. betalingsstatus
Type: Valg. Betalingsstatus: ikke_betalt, under_betaling, betalt, delvis, reversert, eller fakturering_legacy. Driver betalingspåminnelser og rapportering.
12. linje_ids
Type: One2many (account.move.line). Journalpostlinjene. Hver linje har en konto, debet og kredit. Summen av debet må være lik summen av kredit.
13. fakturalinje_ids
Type: One2many (account.move.line). For fakturaer og regninger, er disse produkt- eller tjenestelinjene. Hver linje genererer en eller flere journalpostlinjer når den postes.
14. fakturadato
Type: Dato. Fakturadatoen. Brukes for fakturering og skatteperioder. Kan avvike fra bevegelsesdatoen i noen konfigurasjoner.
15. forfallsdato
Type: Dato. Forfallsdato for betaling. Beregnes fra betalingsbetingelser eller settes manuelt. Brukes for aldring og inndrivelse.
16. ref
Type: Char. Ekstern referanse eller leverandørfakturanummer. Nyttig for å matche betalinger og avstemme med eksterne dokumenter.
17. invoice_origin
Type: Char. Kildedokumentet. For fakturaer fra salgsordrer lagres SO-nummeret her. Muliggjør sporbarhet fra ordre til faktura.
18. create_date
Type: Datetime. Lagrer dato og klokkeslett når posten ble opprettet. Administreres automatisk av Odoo.
19. write_date
Type: Datetime. Lagrer dato og klokkeslett for den siste modifikasjonen. Også administrert automatisk.
20. narration
Type: Text. Interne notater eller memo. Vist på trykte journaloppføringer. Ikke vist til kunder på fakturaer.
21. fiscal_position_id
Type: Many2one (account.fiscal.position). Den skattemessige posisjonen for skatteregler. Bestemmer hvilke skatter som gjelder basert på partner og land.
22. invoice_payment_term_id
Type: Many2one (account.payment.term). Betalingsbetingelser (f.eks. Net 30). Brukes til å beregne invoice_date_due og dele opp betalinger.
23. invoice_user_id
Type: Many2one (res.users). Salgspersonen eller ansvarlig bruker for fakturaen. Brukes for provisjon og rapportering.
24. reversed_entry_id
Type: Many2one (account.move). For reverserte poster, dette kobles til reverseringsbevegelsen. Muliggjør revisjonsspor av korrigeringer.
25. to_check
Type: Boolean. Flag for bevegelser som trenger gjennomgang. Brukes i bankavstemming og unntaksarbeidsflyter.
26. active
Type: Boolean. Myk slettingsflag. Når False, blir posten arkivert. Avbestilte bevegelser settes vanligvis til active=False.
27. sequence_number
Type: Integer. Sekvensnummeret fra journalen. Brukes for sortering og visning. Håndteres av sekvensmixin.
28. amount_untaxed
Type: Monetary. Delsummen før skatt. For fakturaer er dette summen av linje beløp før skatt.
29. amount_tax
Type: Monetær. Det totale skattebeløpet. Beregnet fra fakturalinjer og skattekonfigurasjon.
30. invoice_source_email
Type: Char. For leverandørfakturaer opprettet fra e-post, lagrer dette kilde-e-postadressen. Brukes for automatisert fakturainntak.
Hvordan denne modellen brukes i forretningsarbeidsflyter
1. Kunde Fakturering
Når en salgsordre blir levert, oppretter Odoo en account.move med move_type out_invoice. invoice_line_ids kommer fra ordrelinjene. Posting av bevegelsen oppretter journaloppføringer og oppdaterer fordringer.
2. Leverandørfakturaer
Innkjøpsordrer kan generere fakturaer, eller fakturaer blir registrert manuelt. Hver faktura er en account.move med move_type in_invoice. partner_id er leverandøren. Posting oppdaterer gjeld.
3. Betalingsavstemming
Betalinger matches med fakturaer ved hjelp av feltene amount_residual og payment_state. Avstemmingsprosessen kobler betalingsbevegelser til fakturabevegelser og fjerner restbeløpet.
4. Manuelle journaloppføringer
Revisorer oppretter bevegelser med move_type entry for justeringer, avsetninger eller korrigeringer. De legger manuelt til line_ids med kontoer, debiteringer og krediteringer. Bevegelsen må balansere før posting.
5. Kreditnotater og refusjoner
Kreditnotater er bevegelser med move_type out_refund eller in_refund. De reverserer effekten av den opprinnelige fakturaen eller regningen. reversed_entry_id lenker tilbake til den opprinnelige for revisjon.
Hvordan utviklere utvider denne modellen
Utviklere utvider account.move ved å bruke flere mønstre. Odoo-modellarv er hovedmekanismen.
Modellarv
Bruk _inherit = 'account.move' for å utvide modellen. Legg til nye Odoo-felt, overstyr metoder, eller legg til begrensninger. Den arvede modellen i Odoo holder endringene dine i en egen modul for enkle oppgraderinger.
Legge til felt
Definer nye Odoo-felt i din arvede modell. Bruk riktig felttype: Char, Many2one, Boolean, Integer, Text, Selection. Vurder selskapsavhengige felt for flere selskaper. For faktura-spesifikke felt, bruk et domene på move_type.
Python-utvidelser
Overstyr create, write, _post, eller button_draft for å legge til logikk. Bruk super() for å kalle den opprinnelige. Vær forsiktig med beregnede felt og deres avhengigheter. API-modellen i Odoo-dekoratører (@api.model, @api.depends) kontrollerer når metoder kjøres.
Odoo Studio
Odoo Studio lar deg legge til felt uten kode. Bra for raske tilpasninger som ekstra referansefelt. For kompleks logikk, validering eller automatiserte handlinger, er tilpassede moduler mer vedlikeholdbare.
Merk: account.move er en vanlig modell, ikke en Odoo abstrakt modell eller Odoo transient modell. Abstrakte modeller brukes som maler og oppretter ikke databaser. Transiente modeller er midlertidige og brukes for veivisere. account.move lagrer permanent regnskapsdata.
Beste praksis
- Filtrer alltid etter move_type når du bygger rapporter eller integrasjoner. Ulike typer har forskjellige nødvendige felt og atferd.
- Bruk riktig journal for hver move type. Å blande journaler kan bryte sekvenser og rapportering.
- Når du oppretter bevegelser via API, sørg for at line_ids balanserer (debiteringer = krediteringer) før du poster. Ubalanserte bevegelser vil mislykkes i validering.
- For fakturering fra eksterne systemer, kartlegg dokumenttypene dine til move_type korrekt. out_invoice for salg, in_invoice for kjøp.
- Bruk
x_-prefikset for tilpassede felt for å unngå konflikter med fremtidige Odoo-versjoner.
Vanlige feil
- Poste bevegelser uten balanserte linjer. Odoo vil avvise posten. Verifiser alltid at debet- og kreditbeløpene stemmer.
- Modifisere posterte bevegelser direkte. Posterte bevegelser er låst. Bruk en reversering og opprett en ny bevegelse i stedet.
- Glemme å sette partner_id på kunde- eller leverandørbevegelser. Mange rapporter og arbeidsflyter er avhengige av det.
- Bruke feil move_type. En out_refund er ikke det samme som en negativ out_invoice. Bruk riktig type for refusjoner og kreditnotaer.
- Overstyre kjerne metoder uten å kalle super(). Dette kan bryte andre moduler eller fremtidige oppgraderinger.
Konklusjon
account.move-modellen er sentral i Odoo Regnskap. Den representerer fakturaer, regninger og journaloppføringer i en enhetlig struktur. Å forstå feltene dens og hvordan moduler utvider den vil hjelpe deg med å konfigurere, tilpasse og integrere Odoo effektivt.
Enten du er en funksjonell konsulent som kartlegger forretningsprosesser eller en utvikler som bygger tilpassede moduler, vil en solid forståelse av account.move spare tid og forhindre feil.
Trenger du hjelp med Odoo-implementeringen din?
Dasolo hjelper selskaper med å implementere, tilpasse og optimalisere Odoo. Vi spesialiserer oss på API-integrasjoner og Odoo-utvikling. Vårt team har dyp erfaring med Odoo-databasearkitekturen og modeller som account.move.
Hvis du trenger hjelp med Odoo-implementeringen din, tilpassede moduler eller integrasjoner, er vi her for å hjelpe. Bestill en demo for å diskutere prosjektet ditt.