Einführung
In Odoo definieren Modelle, wie Daten strukturiert und in der Datenbank gespeichert werden. Jedes Stück Geschäftsdaten, mit dem Sie arbeiten, von Verkaufsaufträgen über Rechnungen bis hin zu Buchungseinträgen, lebt in einem Modell.
Das Verständnis von Odoo-Modellen ist sowohl für Entwickler als auch für funktionale Berater unerlässlich. Modelle sind die Grundlage der Odoo-Datenarchitektur. Sie definieren Odoo-Felder, Beziehungen und Geschäftslogik.
Dieser Artikel konzentriert sich auf eines der wichtigsten Modelle in Odoo Accounting: account.move. Egal, ob Sie benutzerdefinierte Berichte erstellen, externe Systeme integrieren oder Rechnungsworkflows konfigurieren, Sie werden mit diesem Modell arbeiten.
Was ist das Modell account.move
Das Modell account.move repräsentiert Buchungseinträge in Odoo. In Odoo 13 und später wurde es vereinheitlicht, was früher separate Modelle waren: Kundenrechnungen, Lieferantenrechnungen, Gutschriften und manuelle Buchungseinträge. Heute leben sie alle in account.move.
Dieses Modell in Odoo wird vom Buchhaltungsmodul verwendet. Es ist der Elternteil von account.move.line, das die einzelnen Soll- und Habenbuchungen enthält. Jede Rechnung, Rechnung oder Buchungseintrag ist ein account.move-Datensatz mit einer oder mehreren Zeilen.
Das Modell ist im Buchhaltungsmodul definiert. Andere Module erweitern es durch die Odoo-Modellvererbung. Der Verkauf fügt die Erstellung von Rechnungen aus Bestellungen hinzu. Der Einkauf fügt die Erstellung von Rechnungen hinzu. Jedes Modul fügt hinzu, was es benötigt, ohne die Kernstruktur zu duplizieren.
Schlüsselfelder im Modell
Hier sind die wichtigsten Odoo-Felder im Modell account.move. Das Verständnis dieser wird Ihnen helfen, effektiv mit Rechnungen, Rechnungen und Buchungseinträgen zu arbeiten.
1. name
Typ: Char. Dieses Feld speichert die Buchungseintragsnummer oder den Namen. Es wird typischerweise automatisch aus der Buchungssequenz generiert. Wird in Listenansichten und auf gedruckten Dokumenten angezeigt.
2. move_type
Typ: Auswahl. Bestimmt die Art des Buchungseintrags: entry (manueller Buchungseintrag), out_invoice (Kundenrechnung), out_refund (Kundengutschrift), in_invoice (Lieferantenrechnung), in_refund (Lieferantengutschrift). Dieses Feld steuert, welche Ansichten und Workflows gelten.
3. state
Typ: Auswahl. Der Workflow-Zustand: Entwurf, gebucht oder storniert. Entwurfsbuchungen können bearbeitet werden. Gebuchte Buchungen sind gesperrt und wirken sich auf das Hauptbuch aus. Stornieren kehrt die Wirkung um.
4. date
Typ: Datum. Das Dokumentdatum. Wird für Berichterstattung, Alterung und Periodenabschluss verwendet. Bei Rechnungen ist dies oft das Rechnungsdatum.
5. journal_id
Typ: Many2one (account.journal). Das Journal, zu dem dieser Buchungsvorgang gehört. Verkaufs-, Einkaufs-, Bank- und Sonstiges-Journale haben jeweils ihre eigenen. Das Journal bestimmt die Reihenfolge und die Standardkonten.
6. company_id
Typ: Many2one (res.company). In Multi-Company-Setups zeigt dies an, zu welchem Unternehmen der Buchungsvorgang gehört. Beeinflusst die Sichtbarkeit der Aufzeichnungen und die Konsolidierung.
7. partner_id
Typ: Many2one (res.partner). Der Kunde oder Lieferant. Erforderlich für Rechnungen und Rechnungsstellungen. Wird für Altersberichte, Zahlungsabgleich und Dokumentenköpfe verwendet.
8. currency_id
Typ: Many2one (res.currency). Die Währung des Buchungsvorgangs. Beträge werden in dieser Währung gespeichert. Bei Mehrwährungsbuchungen wird die Unternehmenswährung für Berichterstattung verwendet.
9. amount_total
Typ: Monetär. Der Gesamtbetrag des Buchungsvorgangs. Bei Rechnungen ist dies der fällige Betrag. Wird aus den Zeilen berechnet.
10. amount_residual
Typ: Monetär. Der unbezahlte Betrag. Bei bezahlten Rechnungen beträgt dieser null. Wird für Alters- und Zahlungsworkflows verwendet.
11. payment_state
Typ: Auswahl. Zahlungsstatus: nicht_bezahlt, in_zahlung, bezahlt, teilweise, rückgängig gemacht oder rechnung_legacy. Treibt Zahlungserinnerungen und Berichterstattung voran.
12. line_ids
Typ: One2many (account.move.line). Die Buchungssatzzeilen. Jede Zeile hat ein Konto, Soll und Haben. Die Summe der Sollbeträge muss der Summe der Habenbeträge entsprechen.
13. invoice_line_ids
Typ: One2many (account.move.line). Für Rechnungen und Rechnungen sind dies die Produkt- oder Dienstleistungszeilen. Jede Zeile generiert eine oder mehrere Buchungssatzzeilen, wenn sie gebucht wird.
14. invoice_date
Typ: Datum. Das Rechnungsdatum. Wird für Rechnungs- und Steuerzeiträume verwendet. Kann in einigen Konfigurationen vom Buchungsdatum abweichen.
15. invoice_date_due
Typ: Datum. Das Fälligkeitsdatum der Zahlung. Wird aus den Zahlungsbedingungen berechnet oder manuell festgelegt. Wird für Alterung und Mahnwesen verwendet.
16. ref
Typ: Char. Externe Referenz oder Rechnungsnummer des Anbieters. Nützlich zum Abgleichen von Zahlungen und zur Abstimmung mit externen Dokumenten.
17. invoice_origin
Typ: Char. Das Quelldokument. Bei Rechnungen aus Verkaufsaufträgen wird hier die SO-Nummer gespeichert. Ermöglicht die Rückverfolgbarkeit vom Auftrag zur Rechnung.
18. create_date
Typ: Datetime. Speichert das Datum und die Uhrzeit, wann der Datensatz erstellt wurde. Wird automatisch von Odoo verwaltet.
19. write_date
Typ: Datetime. Speichert das Datum und die Uhrzeit der letzten Änderung. Ebenfalls automatisch verwaltet.
20. narration
Typ: Text. Interne Notizen oder Memo. Wird auf gedruckten Journalbuchungen angezeigt. Nicht auf Rechnungen für Kunden sichtbar.
21. fiscal_position_id
Typ: Many2one (account.fiscal.position). Die steuerliche Position für Steuerregeln. Bestimmt, welche Steuern basierend auf Partner und Land gelten.
22. invoice_payment_term_id
Typ: Many2one (account.payment.term). Zahlungsbedingungen (z. B. Net 30). Wird verwendet, um invoice_date_due zu berechnen und Zahlungen aufzuteilen.
23. invoice_user_id
Typ: Many2one (res.users). Der Verkäufer oder verantwortliche Benutzer für die Rechnung. Wird für Provisionen und Berichterstattung verwendet.
24. reversed_entry_id
Typ: Many2one (account.move). Für umgekehrte Buchungen verlinkt dies auf die Rückbuchung. Ermöglicht eine Prüfspur von Korrekturen.
25. to_check
Typ: Boolean. Flag für Buchungen, die überprüft werden müssen. Wird in der Bankabstimmung und in Ausnahme-Workflows verwendet.
26. active
Typ: Boolean. Soft-Delete-Flag. Wenn False, wird der Datensatz archiviert. Stornierte Buchungen werden typischerweise auf active=False gesetzt.
27. sequence_number
Typ: Integer. Die Sequenznummer aus dem Journal. Wird für die Reihenfolge und Anzeige verwendet. Wird durch das Sequenz-Mixin verwaltet.
28. amount_untaxed
Typ: Monetary. Der Zwischensumme vor Steuern. Für Rechnungen ist dies die Summe der Zeilenbeträge vor Steuern.
29. amount_tax
Typ: Monetär. Der gesamte Steuerbetrag. Berechnet aus den Rechnungszeilen und der Steuerkonfiguration.
30. invoice_source_email
Typ: Char. Für Lieferantenrechnungen, die aus E-Mails erstellt wurden, wird hier die Quell-E-Mail-Adresse gespeichert. Wird für die automatisierte Rechnungserfassung verwendet.
Wie dieses Modell in Geschäftsabläufen verwendet wird
1. Kundenabrechnung
Wenn ein Verkaufsauftrag geliefert wird, erstellt Odoo ein account.move mit move_type out_invoice. Die invoice_line_ids stammen aus den Bestellzeilen. Das Buchen des Moves erstellt die Buchungssätze und aktualisiert die Forderungen.
2. Lieferantenrechnungen
Bestellungen können Rechnungen generieren, oder Rechnungen werden manuell eingegeben. Jede Rechnung ist ein account.move mit move_type in_invoice. Der partner_id ist der Lieferant. Das Buchen aktualisiert die Verbindlichkeiten.
3. Zahlungsabgleich
Zahlungen werden anhand der Felder amount_residual und payment_state den Rechnungen zugeordnet. Der Abgleichsprozess verknüpft Zahlungsbewegungen mit Rechnungsbewegungen und tilgt den Restbetrag.
4. Manuelle Buchungssätze
Buchhalter erstellen Bewegungen mit move_type entry für Anpassungen, Rückstellungen oder Korrekturen. Sie fügen manuell line_ids mit Konten, Soll- und Habenbeträgen hinzu. Die Bewegung muss vor dem Buchen ausgeglichen sein.
5. Gutschriften und Rückerstattungen
Gutschriften sind Bewegungen mit dem move_type out_refund oder in_refund. Sie heben die Wirkung der ursprünglichen Rechnung oder des ursprünglichen Belegs auf. Die reversed_entry_id verweist auf die ursprüngliche für Prüfungszwecke.
Wie Entwickler dieses Modell erweitern
Entwickler erweitern account.move mit verschiedenen Mustern. Die Vererbung von Odoo-Modellen ist der Hauptmechanismus.
Modellvererbung
Verwenden Sie _inherit = 'account.move', um das Modell zu erweitern. Fügen Sie neue Odoo-Felder hinzu, überschreiben Sie Methoden oder fügen Sie Einschränkungen hinzu. Das vererbte Modell in Odoo hält Ihre Änderungen in einem separaten Modul für einfache Upgrades.
Felder hinzufügen
Definieren Sie neue Odoo-Felder in Ihrem vererbten Modell. Verwenden Sie den richtigen Feldtyp: Char, Many2one, Boolean, Integer, Text, Auswahl. Berücksichtigen Sie unternehmensabhängige Felder für mehrere Unternehmen. Für rechnungsspezifische Felder verwenden Sie eine Domain auf move_type.
Python-Erweiterungen
Überschreiben Sie create, write, _post oder button_draft, um Logik hinzuzufügen. Verwenden Sie super(), um das Original aufzurufen. Seien Sie vorsichtig mit berechneten Feldern und deren Abhängigkeiten. Die API-Modell-Dekoratoren in Odoo (@api.model, @api.depends) steuern, wann Methoden ausgeführt werden.
Odoo Studio
Odoo Studio ermöglicht es Ihnen, Felder ohne Code hinzuzufügen. Gut für schnelle Anpassungen wie zusätzliche Referenzfelder. Für komplexe Logik, Validierung oder automatisierte Aktionen sind benutzerdefinierte Module wartungsfreundlicher.
Hinweis: account.move ist ein reguläres Modell, kein Odoo-Abstract-Modell oder Odoo-transientes Modell. Abstract-Modelle werden als Vorlagen verwendet und erstellen keine Datenbanktabellen. Transiente Modelle sind temporär und werden für Assistenten verwendet. account.move speichert permanente Buchhaltungsdaten.
Best Practices
- Filtern Sie immer nach move_type, wenn Sie Berichte oder Integrationen erstellen. Verschiedene Typen haben unterschiedliche erforderliche Felder und Verhaltensweisen.
- Verwenden Sie das richtige Journal für jeden move type. Das Mischen von Journalen kann Sequenzen und Berichterstattung stören.
- Stellen Sie beim Erstellen von Bewegungen über die API sicher, dass die line_ids ausgeglichen sind (Soll = Haben), bevor Sie sie buchen. Unausgeglichene Bewegungen werden die Validierung nicht bestehen.
- Für die Erstellung von Rechnungen aus externen Systemen, ordnen Sie Ihre Dokumenttypen korrekt dem move_type zu. out_invoice für Verkäufe, in_invoice für Einkäufe.
- Verwenden Sie das
x_-Präfix für benutzerdefinierte Felder, um Konflikte mit zukünftigen Odoo-Versionen zu vermeiden.
Häufige Fehler
- Bewegungen ohne ausgeglichene Zeilen buchen. Odoo wird die Buchung ablehnen. Überprüfen Sie immer, ob die Soll- und Habenbeträge übereinstimmen.
- Direktes Ändern von gebuchten Bewegungen. Gebuchte Bewegungen sind gesperrt. Verwenden Sie stattdessen eine Rückbuchung und erstellen Sie eine neue Bewegung.
- Vergessen, partner_id bei Kunden- oder Lieferantenbewegungen festzulegen. Viele Berichte und Arbeitsabläufe hängen davon ab.
- Verwendung des falschen move_type. Ein out_refund ist nicht dasselbe wie eine negative out_invoice. Verwenden Sie den richtigen Typ für Rückerstattungen und Gutschriften.
- Kernmethoden überschreiben, ohne super() aufzurufen. Dies kann andere Module oder zukünftige Updates stören.
Fazit
Das Modell account.move ist zentral für die Odoo Buchhaltung. Es repräsentiert Rechnungen, Rechnungen und Buchungseinträge in einer einheitlichen Struktur. Das Verständnis seiner Felder und wie Module es erweitern, wird Ihnen helfen, Odoo effektiv zu konfigurieren, anzupassen und zu integrieren.
Egal, ob Sie ein funktionaler Berater sind, der Geschäftsprozesse abbildet, oder ein Entwickler, der benutzerdefinierte Module erstellt, ein solides Verständnis von account.move wird Zeit sparen und Fehler verhindern.
Brauchen Sie Hilfe bei Ihrer Odoo-Implementierung?
Dasolo hilft Unternehmen bei der Implementierung, Anpassung und Optimierung von Odoo. Wir sind auf API-Integrationen und Odoo-Entwicklung spezialisiert. Unser Team verfügt über umfassende Erfahrung mit der Odoo-Datenarchitektur und Modellen wie account.move.
Wenn Sie Hilfe bei Ihrer Odoo-Implementierung, benutzerdefinierten Modulen oder Integrationen benötigen, sind wir hier, um zu helfen. Buchen Sie eine Demo um Ihr Projekt zu besprechen.