Einleitung
In Odoo legt ein Modell die Struktur und Speicherung von Geschäftsdatensätzen in der Datenbank fest. Jede Information — von Angeboten über Rechnungen bis zu Buchungssätzen — wird als Datensatz in einem passenden Modell abgelegt.
Ein solides Verständnis der Odoo‑Modelle ist für Entwickler und funktionale Berater gleichermaßen wichtig. Modelle bilden das Rückgrat der Datenarchitektur, definieren Felder, Beziehungen und die zugrundeliegende Geschäftslogik.
Dieser Beitrag behandelt eines der zentralen Modelle in Odoo Accounting: account.move. Egal ob Sie Berichte bauen, Fremdsysteme anbinden oder Rechnungsabläufe konfigurieren — Sie werden mit diesem Modell arbeiten.
Was ist das account.move‑Modell?
Das account.move‑Modell bildet Buchungsbelege ab. Seit Odoo 13 fasst es sämtliche Belegarten zusammen, die früher in getrennten Modellen lagen: Kundenrechnungen, Lieferantenrechnungen, Gutschriften und manuelle Buchungen sind nun allesamt account.move‑Datensätze.
account.move gehört zum Accounting‑Modul und ist die übergeordnete Entität zu account.move.line, das die einzelnen Soll‑ und Haben‑Zeilen hält. Jede Rechnung, jede Rechnung des Lieferanten oder jeder Buchungssatz ist ein account.move‑Datensatz mit einer oder mehreren Zeilen.
Die Definition des Modells liegt im account‑Modul; andere Module erweitern es über Odoo‑Vererbung. So fügt Sale die Erzeugung von Rechnungen aus Aufträgen hinzu, Purchase das Erstellen von Lieferantenrechnungen — ohne die Kernstruktur zu duplizieren.
Wichtige Felder im Modell
Im Folgenden finden Sie die wichtigsten Felder des account.move‑Modells. Wer diese Felder kennt, kann effizienter mit Rechnungen, Lieferantenbelegen und Buchungssätzen arbeiten.
1. name
Typ: Char. Enthält die Belegnummer oder -bezeichnung, meist automatisch aus der Journalsequenz erzeugt. Sichtbar in Listenansichten und auf Ausdrucken.
2. move_type
Typ: Selection. Legt die Belegart fest: entry (manueller Buchungssatz), out_invoice (Kundenrechnung), out_refund (Kundengutschrift), in_invoice (Lieferantenrechnung), in_refund (Lieferantengutschrift). Dieses Feld steuert Ansichten und Workflow‑Logik.
3. state
Typ: Selection. Workflow‑Status: draft, posted oder cancel. Draft‑Belege sind änderbar, posted‑Belege sind gesperrt und wirken in der Hauptbuchhaltung; cancel hebt die Wirkung auf.
4. date
Typ: Date. Das Belegdatum. Wichtig für Reporting, Altersanalysen und Periodenabschluss. Bei Rechnungen entspricht es in der Regel dem Rechnungsdatum.
5. journal_id
Typ: Many2one (account.journal). Das zugehörige Journal (Verkauf, Einkauf, Bank, Sonstiges). Das Journal bestimmt Sequenz und Standardkonten.
6. company_id
Typ: Many2one (res.company). Bei Multi‑Company‑Setups gibt dieses Feld an, zu welcher Firma der Beleg gehört — relevant für Sichtbarkeit und Konsolidierung.
7. partner_id
Typ: Many2one (res.partner). Kunde oder Lieferant. Für Rechnungen und Lieferscheine Pflichtfeld; relevant für Mahnwesen, Zahlungserfassung und Dokumentenkopf.
8. currency_id
Typ: Many2one (res.currency). Die Währung des Belegs. Beträge werden in dieser Währung gespeichert; für Berichtswesen werden ggf. Umrechnungen in die Firmenwährung vorgenommen.
9. amount_total
Typ: Monetary. Der Gesamtbetrag des Belegs. Bei Rechnungen entspricht das dem fälligen Gesamtbetrag — berechnet aus den einzelnen Zeilen.
10. amount_residual
Typ: Monetary. Offener Restbetrag. Bei komplett bezahlten Rechnungen ist dieser Wert null; wichtig für Altersanalysen und Zahlungsabstimmung.
11. payment_state
Typ: Selection. Zahlungsstatus: not_paid, in_payment, paid, partial, reversed oder invoicing_legacy. Dieser Wert steuert Zahlungserinnerungen und Auswertungen.
12. line_ids
Typ: One2many (account.move.line). Die Buchungszeilen: Konto, Soll und Haben. Summe Soll = Summe Haben muss erfüllt sein.
13. invoice_line_ids
Typ: One2many (account.move.line). Bei Rechnungen/Lieferscheinen die Positionen für Produkte oder Dienstleistungen; beim Buchen erzeugt jede Position die entsprechenden Buchungszeilen.
14. invoice_date
Typ: Date. Rechnungsdatum — relevant für Besteuerungsperioden. In manchen Setups kann es vom Belegdatum abweichen.
15. invoice_date_due
Typ: Date. Fälligkeitsdatum, berechnet aus Zahlungsbedingungen oder manuell gesetzt; wichtig für Mahnläufe.
16. ref
Typ: Char. Externe Referenz oder Lieferantenrechnungsnummer. Nützlich für Abgleich mit Eingangsrechnungen und Zahlungsabstimmung.
17. invoice_origin
Typ: Char. Quellbeleg, z. B. die Nummer des Verkaufsauftrags. Hilft bei der Rückverfolgbarkeit vom Auftrag bis zur Rechnung.
18. create_date
Typ: Datetime. Zeitpunkt der Erstellung des Datensatzes — automatisch von Odoo gepflegt.
19. write_date
Typ: Datetime. Zeitpunkt der letzten Änderung — ebenfalls automatisch gepflegt.
20. narration
Typ: Text. Interne Notizen oder Vermerk; erscheint auf Buchungsbelegen, aber nicht zwingend auf Kunden‑Rechnungen.
21. fiscal_position_id
Typ: Many2one (account.fiscal.position). Fiskalposition für Steuerregeln; bestimmt Steuerumsetzungen basierend auf Partner und Land.
22. invoice_payment_term_id
Typ: Many2one (account.payment.term). Zahlungsbedingungen (z. B. 30 Tage netto). Bestimmt Fälligkeit und eventuelle Ratenaufteilung.
23. invoice_user_id
Typ: Many2one (res.users). Verantwortlicher Benutzer oder Vertriebsmitarbeiter — wichtig für Reporting und Provisionsberechnung.
24. reversed_entry_id
Typ: Many2one (account.move). Verweis auf den rückbuchenden Beleg bei Stornierungen — wichtig für die Prüfbarkeit von Korrekturen.
25. to_check
Typ: Boolean. Kennzeichnung für Belege, die geprüft werden müssen — nützlich bei Bankabstimmung oder Ausnahmen.
26. active
Typ: Boolean. Soft‑Delete‑Flag. Bei False ist der Datensatz archiviert; stornierte Belege werden häufig auf inaktiv gesetzt.
27. sequence_number
Typ: Integer. Sequenznummer aus dem Journal für Sortierung und Anzeige; verwaltet über das Sequence‑Mixin.
28. amount_untaxed
Typ: Monetary. Zwischensumme vor Steuern — bei Rechnungen die Summe der Positionen ohne Steuer.
29. amount_tax
Typ: Monetary. Gesamte Steuerbeträge — aus Positionen und Steuerkonfiguration berechnet.
30. invoice_source_email
Typ: Char. Bei per E‑Mail erstellten Lieferantenrechnungen die Quell‑E‑Mail-Adresse; relevant für automatisches Einlesen von Rechnungen.
Wie dieses Modell in Geschäftsabläufen eingesetzt wird
1. Kundenrechnungen
Wenn ein Verkaufsauftrag geliefert wird, legt Odoo eine account.move mit move_type out_invoice an. Die invoice_line_ids kommen aus den Auftragspositionen; beim Buchen entstehen die Buchungszeilen und die Forderung wird gebucht.
2. Lieferantenrechnungen
Bestellungen können Rechnungen erzeugen oder Belege werden manuell erfasst. Jede Lieferantenrechnung ist ein account.move mit move_type in_invoice; beim Buchen werden Verbindlichkeiten aktualisiert.
3. Zahlungsabstimmung
Zahlungen werden anhand von amount_residual und payment_state mit Rechnungen abgeglichen. Der Abstimmungsprozess verbindet Zahlungsbewegungen mit Rechnungen und reduziert den offenen Betrag.
4. Manuelle Buchungen
Buchhalter legen move_type entry‑Belege für Anpassungen, Abgrenzungen oder Korrekturen an. Sie erfassen die line_ids manuell mit Konten, Soll und Haben; der Beleg muss vor dem Buchen ausgeglichen sein.
5. Gutschriften und Rückerstattungen
Gutschriften sind out_refund oder in_refund‑Belege und kehren die Wirkung eines ursprünglichen Belegs um. Das Feld reversed_entry_id verknüpft die Stornierung mit dem Original für die Nachvollziehbarkeit.
Wie Entwickler das Modell erweitern
Entwickler erweitern account.move mit verschiedenen Mustern, wobei die Odoo‑Modellvererbung das zentrale Mittel ist.
Modellvererbung
Mit _inherit = 'account.move' bauen Sie auf dem bestehenden Modell auf. Sie können Felder hinzufügen, Methoden überschreiben oder Validierungen ergänzen. Änderungen bleiben in Ihrem Modul und erleichtern spätere Upgrades.
Felder hinzufügen
Ergänzen Sie in Ihrem geerbten Modell neue Felder mit dem passenden Field‑Typ: Char, Many2one, Boolean, Integer, Text oder Selection. Denken Sie an firmenabhängige Felder für Multi‑Companys und nutzen Sie Domain‑Einschränkungen bei reinen Rechnungsfeldern.
Erweiterung in Python
Überschreiben Sie create, write, _post oder button_draft, um zusätzliche Logik einzubringen — rufen Sie dabei immer super() auf. Achten Sie auf berechnete Felder und ihre Dependencies sowie auf die richtigen Odoo‑Decoratoren (@api.model, @api.depends).
Odoo Studio
Odoo Studio eignet sich für schnelle Anpassungen ohne Code, etwa zusätzliche Referenzfelder. Für komplexe Validierungen oder automatisierte Prozesse sind aber Custom‑Module langfristig robuster.
Wichtig: account.move ist ein normales persistentes Modell, kein abstraktes Template‑Modell oder ein transienter Wizard. Abstract‑Modelle erzeugen keine Tabellen, transient‑Modelle sind temporär; account.move enthält dauerhafte Buchungsdaten.
Best Practices
- Filtern Sie bei Reporting und Integrationen stets nach move_type — jede Belegart hat eigene Pflichtfelder und Verhaltensweisen.
- Nutzen Sie für jede Belegart das passende Journal. Falsche Journalzuweisungen können Sequenzen und Berichte ungültig machen.
- Beim Anlegen von Belegen über die API müssen die line_ids ausgeglichen sein (Summe Soll = Summe Haben), bevor Sie posten. Unausgeglichene Belege werden validiert abgelehnt.
- Beim Import von Rechnungen aus Fremdsystemen mappen Sie Dokumenttypen korrekt auf move_type: out_invoice für Verkäufe, in_invoice für Einkäufe.
- Verwenden Sie das x_‑Präfix für eigene Felder, um Konflikte mit künftigen Odoo‑Versionen zu vermeiden.
Häufige Fehler
- Belege ohne ausgeglichene Zeilen posten zu wollen: Odoo blockiert das Posten. Prüfen Sie immer, dass Soll‑ und Haben‑Summen übereinstimmen.
- Direktes Ändern gebuchter Belege: gebuchte Belege sind gesperrt. Korrigieren Sie über Storno und legen Sie einen neuen Beleg an.
- Partner_id bei Kunden‑ oder Lieferantenbelegen nicht setzen: Viele Auswertungen und Workflows hängen davon ab.
- Falsche Wahl des move_type: Eine out_refund ist nicht einfach eine negative out_invoice. Verwenden Sie die korrekte Belegart für Rückerstattungen.
- Kernmethoden zu überschreiben, ohne super() aufzurufen: Das kann andere Module und künftige Updates beschädigen.
Fazit
Das account.move‑Modell ist das Herzstück der Odoo‑Buchhaltung: Es vereinheitlicht Rechnungen, Lieferantenbelege und Buchungssätze. Wer Felder, Erweiterungsmöglichkeiten und Zusammenhänge kennt, kann Odoo sicher konfigurieren, anpassen und integrieren.
Ob Sie als Berater Prozesse abbilden oder als Entwickler Module erstellen — ein fundiertes Verständnis von account.move spart Zeit und verhindert Fehler.
Brauchen Sie Unterstützung bei Ihrer Odoo‑Einführung?
Dasolo begleitet Unternehmen bei Einführung, Anpassung und Optimierung von Odoo. Unser Schwerpunkt liegt auf API‑Integrationen und Entwicklung — wir kennen die Odoo‑Datenarchitektur und Modelle wie account.move sehr genau.
Wenn Sie Hilfe bei Implementierung, Custom Modules oder Integrationen brauchen, sprechen Sie uns an. Demo buchen um Ihr Projekt zu besprechen.