Einleitung
In Odoo legt jedes Modell fest, wie Informationen in der Datenbank abgelegt werden. Alle geschäftsrelevanten Daten — von Angeboten über Rechnungen bis zu Buchungszeilen — sind in Modellen organisiert und bestimmen, wie Sie später filtern, berichten und integrieren können.
Für Entwickler und Berater sind Modelle das Rückgrat der Odoo-Datenarchitektur. Sie legen Felder, Verknüpfungen und die Geschäftslogik fest: wer was sieht, wie Werte berechnet werden und welche Beziehungen bestehen.
Dieser Beitrag konzentriert sich auf eines der zentralen Modelle der Buchhaltung: account.move.line. Ob Sie Berichte bauen, Schnittstellen programmieren oder Ausgleichsprozesse einrichten — mit diesem Modell kommen Sie regelmäßig in Berührung.
Worum es beim Modell account.move.line geht
Das Modell account.move.line bildet einzelne Buchungszeilen ab. Jede Zeile ist entweder Soll oder Haben; zusammen müssen die Zeilen eines Buchungssatzes ausgeglichen sein, sodass Soll- und Haben-Summen übereinstimmen.
account.move.line steht im Kontext des Accounting-Moduls und ist ein Kind von account.move — dem Buchungskopf (z. B. Rechnung, Gutschrift, Bankauszug). Jeder Buchungssatz besteht aus einer oder mehreren dieser Zeilen.
Die Basisklasse ist im account-Modul definiert; andere Module erweitern sie über Odoo-Inheritance. So ergänzt Sale Rechnungsdetails, Purchase bringt Bestellinformationen, und Analytic fügt Kostenstellenverteilung hinzu — ohne die zentrale Struktur zu duplizieren.
Wichtige Felder im Modell
Im Folgenden die wichtigsten Felder von account.move.line. Wer diese Felder kennt, kann Buchungen gezielt auswerten, filtern und für Reconciliation oder Berichte nutzen.
name
Typ: Char. Kurzbeschreibung oder Bezeichnung der Zeile. In Journalansichten und Berichten sichtbar; bei Rechnungen oft Produktname oder ein freier Text, der den Buchungszweck erklärt.
move_id
Typ: Many2one (account.move). Verknüpft die Zeile mit dem übergeordneten Buchungssatz. Jede Zeile gehört genau zu einem move — die zentrale Beziehung, um Einträge zusammenzufassen.
account_id
Typ: Many2one (account.account). Das Sachkonto, auf das die Zeile gebucht wird. Pflichtfeld — kein Ansichts- oder gesperrtes Konto. Wichtig für Bilanz- und GuV-Auswertungen und Gruppierungen.
debit
Typ: Float. Betrag im Soll. Standard 0.0. Pro Zeile ist entweder Soll oder Haben gefüllt. Soll erhöht vor allem Aktiv- und Aufwandkonten.
credit
Typ: Float. Betrag im Haben. Standard 0.0. Haben erhöht Passiv-, Eigenkapital- und Ertragskonten. Die Summe aller Soll-Beträge muss der Summe aller Haben-Beträge im Buchungssatz entsprechen.
balance
Typ: Float. Berechnetes Feld: debit minus credit. Zeigt die Nettowirkung der Zeile an — positiv bei Soll, negativ bei Haben. Brauchbar in Auswertungen und bei der Abstimmung.
partner_id
Typ: Many2one (res.partner). Kunde, Lieferant oder sonstiger Geschäftspartner. Relevant für Forderungen/Verbindlichkeiten, Altersanalysen und Abstimmungen.
date
Typ: Date. Buchungs- bzw. Wirkungsdatum der Zeile. Meistens vom Parent move übernommen. Wichtig für Periodenschluss, Berichte und Aging-Analysen.
date_maturity
Typ: Date. Fälligkeitsdatum zur Zahlungsplanung. Relevant für Forderungs-/Verbindlichkeitsauswertungen und Mahnläufe.
currency_id
Typ: Many2one (res.currency). Währung der Zeile. Kann von der Firmenwährung abweichen, z. B. bei Fremdwährungsbuchungen.
amount_currency
Typ: Float. Betrag in der angegebenen Währung. Zusammen mit currency_id ermöglicht es die korrekte Darstellung und Berechnung bei Mehrwährungsbuchungen.
quantity
Typ: Float. Optionale Menge, relevant bei produktbezogenen Zeilen (Rechnungen, Gutschriften). Nützlich für mengenbasierte Auswertungen und Stückpreisberechnungen.
product_id
Typ: Many2one (product.product). Verknüpft das Produkt, wenn die Zeile aus Bestellung oder Rechnung stammt. Erleichtert Produktanalysen und Margenberichte.
product_uom_id
Typ: Many2one (uom.uom). Einheit der Menge. Wichtig für korrekte Anzeige und Umrechnung bei Mengenspalten.
price_unit
Typ: Float. Einzelpreis, verwendet zusammen mit Menge zur Berechnung von Rechnungsbeträgen.
tax_ids
Typ: Many2many (account.tax). Auf die Zeile angewendete Steuern. Beim Buchen werden oft zusätzliche Steuerzeilen erzeugt; relevant für Umsatzsteuer- und Abzugsberechnungen.
tax_line_id
Typ: Many2one (account.tax). Referenz für Steuerzeilen, die von einer Steuerregel erzeugt wurden — unterscheidet Steuerbuchungen von normalen Zeilen.
analytic_account_id
Typ: Many2one (account.analytic.account). Analytisches Konto für Kosten-/Erlösverfolgung. Wird genutzt, wenn Analytik aktiviert ist, z. B. für Projekte oder Abteilungen.
analytic_distribution
Typ: Json oder Text. Verteilung über mehrere analytische Konten. In neueren Odoo-Versionen ersetzt es teilweise das einzelne analytic_account_id bei komplexen Verteilungen.
ref
Typ: Char. Externe Referenz oder Kurzerklärung, oft vom Parent move vererbt. Nutzbar zur Zuordnung in Berichten und beim Abgleich von Belegen.
narration
Typ: Text. Interner Vermerk oder ausführliche Notiz, meist nicht auf Kundenbelegen gedruckt, aber für interne Prüfung und Kommentare verwendet.
journal_id
Typ: Many2one (account.journal). Journal des Parent move. Nützlich zum Filtern und für journal-spezifische Reports (z. B. Bank, Kasse, Verkauf).
company_id
Typ: Many2one (res.company). Zugehörige Firma. In Multi-Company-Setups bestimmt dies Sichtbarkeit, Rechte und Konsolidierungsverhalten.
reconciled
Typ: Boolean. Zeigt an, ob die Zeile vollständig abgestimmt wurde. Dient als Filterkriterium in Reconciliation-Ansichten.
full_reconcile_id
Typ: Many2one (account.full.reconcile). Verbindet alle zusammen abgestimmten Zeilen und erlaubt das Nachvollziehen von Abstimmungsgruppen.
payment_id
Typ: Many2one (account.payment). Bei Zahlungsbuchungen die Verlinkung zum Zahlungsbeleg — wichtig beim Abstimmen von Rechnungen mit Zahlungen.
statement_id
Typ: Many2one (account.bank.statement). Verknüpfung zu einem Bankauszug, relevant für Bankabstimmungen und Kassenbuchungen.
statement_line_id
Typ: Many2one (account.bank.statement.line). Referenz zu einer konkreten Bankauszugszeile, hilfreich beim Matching zwischen Buchung und Bankbewegung.
display_type
Typ: Selection. Sichtbare Typen wie 'line_section' oder 'line_note' für strukturelle Überschriften oder Hinweise in Buchungssätzen; diese Zeilen tragen keine Soll-/Haben-Beträge.
create_date
Typ: Datetime. Zeitpunkt der Erstellung. Wird automatisch gesetzt und ist nützlich für Audits und Nachvollziehbarkeit.
write_date
Typ: Datetime. Zeitpunkt der letzten Änderung. Automatisch verwaltet, hilft beim Nachvollziehen von Änderungen im Zeitverlauf.
Einsatz des Modells im täglichen Geschäft
Kundenrechnungen
Beim Bestätigen einer Kundenrechnung legt Odoo die notwendigen account.move.line-Zeilen an: Erlös auf Ertragskonten, Forderung auf das Debitorenkonto, dazu Steuerzeilen je Steuerregel. partner_id verbindet die Zeilen mit dem Kunden für Altersanalysen und Abstimmung.
Lieferantenrechnungen
Lieferantenrechnungen erzeugen Aufwandsposten, Vorsteuer und Verbindlichkeiten. Aufbau und Logik entsprechen den Kundenrechnungen, jedoch mit anderen Kontotypen und Buchungsrichtungen.
Bankabstimmung
Bankauszugszeilen werden über statement_line_id mit Buchungszeilen abgeglichen. Bei der Abstimmung verbindet Odoo die Zeilen per full_reconcile_id; danach wird das Feld reconciled auf True gesetzt.
Manuelle Buchungen
Bei manuellen Journalbuchungen legen Anwender mehrere Zeilen an — jeweils mit Konto, Soll/Haben und ggf. Partner. Vor dem Buchen prüft Odoo, dass Soll und Haben ausgeglichen sind.
Analytik und Kostenberichte
Mit aktivierter analytischer Buchführung enthalten Zeilen analytic_account_id oder eine Verteilungsangabe. Auswertungen gruppieren nach Analytik, um Kosten und Erlöse je Projekt, Bereich oder Kostenstelle sichtbar zu machen.
Wie Entwickler das Modell erweitern
Entwickler erweitern account.move.line mit verschiedenen Mustern. Modell-Vererbung ist dabei der zentrale Weg.
Modell-Vererbung
Setzen Sie _inherit = 'account.move.line', um das Modell zu erweitern. So fügen Sie Felder hinzu, überschreiben Methoden oder ergänzen Constraints. Änderungen bleiben im eigenen Modul und erleichtern spätere Upgrades.
Felder ergänzen
Neue Felder definieren Sie in Ihrem geerbten Modell — Char, Many2one, Boolean, Integer, Text, Selection etc. Denken Sie an unternehmensabhängige Felder in Multi-Company-Umgebungen und beachten Sie Abhängigkeiten bei berechneten Feldern.
Python-Erweiterungen
Überschreiben Sie create, write oder unlink, um Logik einzubauen — rufen Sie super() auf, damit der Standardprozess erhalten bleibt. Achten Sie darauf, die Summe von Soll und Haben nicht zu verletzen; diese Methoden sind die Integrationpunkte für externe Systeme.
Odoo Studio
Odoo Studio erlaubt schnelle Anpassungen ohne Code, zum Beispiel zusätzliche Beschriftungen oder Tags. Für komplexe Geschäftsregeln oder Abstimmungslogik sind jedoch modulare Erweiterungen nachhaltiger.
Praxisregeln und Empfehlungen
- Operative Regeln: Gehen Sie nie direkt auf move-line-Datensätze los — arbeiten Sie über den move. Benutzen Sie das line_ids-API des Buchungssatzes, damit Odoo Validierungen, Sequenzen und Konsistenzprüfungen ausführen kann.
- Beim Reporting: Filtern Sie auf move_id.state = 'posted', um nur gebuchte (nicht Entwurf oder stornierte) Buchungen zu berücksichtigen.
- Nutzen Sie account_id mit dem passenden Kontotyp (z. B. receivable, payable), damit Aging- und Abstimmungsprozesse korrekt funktionieren.
- Bei API-Integrationen: Legen Sie zuerst den move an, fügen Sie dann Zeilen hinzu und stellen Sie sicher, dass Soll und Haben vor dem Buchen ausgeglichen sind.
- Für eigene Felder: Verwenden Sie Namenspräfixe (x_ oder Modulpräfix), um Namenskonflikte mit künftigen Odoo-Versionen zu vermeiden.
Häufige Fehler und Fallen
- Soll und Haben gleichzeitig befüllen. Jede Zeile sollte nur Soll oder nur Haben enthalten, nicht beides — das führt zu Fehlern bei Validierungen.
- Unausgeglichene Buchungssätze anlegen. Odoo verlangt beim Buchen, dass Soll- und Haben-Summen übereinstimmen; unausgeglichene Moves werden abgelehnt.
- Gebuchte Zeilen direkt ändern. Stattdessen sollten Korrekturen über Stornierungen oder Gegenbuchungen erfolgen, um Historie und Audit-Trail zu erhalten.
- Partner bei Forderungen/Verbindlichkeiten weglassen. Fehlt partner_id, funktionieren Altersanalysen und Abstimmungen nicht richtig.
- Kernmethoden überschreiben ohne super(). Das kann Abstimmung, Sperren oder Integrationen zerstören — immer den Basisprozess respektieren.
Fazit
Das account.move.line-Modell ist das Herzstück der Odoo-Buchhaltung: Hier landen alle Soll- und Habenbuchungen aus Rechnungen, Belegen und Journalbuchungen. Ein klares Verständnis der Felder und Erweiterungspunkte hilft bei Konfiguration, Anpassung und Integration.
Ob Sie als Berater Buchungsprozesse abbilden oder als Entwickler Integrationen und Berichte bauen — fundiertes Wissen über account.move.line spart Zeit und vermeidet teure Fehler.
Brauchen Sie Unterstützung bei Ihrer Odoo-Einführung?
Dasolo unterstützt Unternehmen bei Einführung, Anpassung und Optimierung von Odoo. Unser Schwerpunkt liegt auf API-Integrationen und Entwicklungsprojekten; wir kennen die Odoo-Datenarchitektur und Modelle wie account.move.line sehr genau.
Benötigen Sie Hilfe bei der Odoo-Implementierung, beim Bau kundenspezifischer Module oder Integrationen? Wir begleiten Sie gern. Demo buchen um Ihr Projekt zu besprechen.