Einführung
In Odoo legen Modelle die Form und Struktur Ihrer Geschäftsdaten fest. Alles, was Sie im Tagesgeschäft anlegen oder auswerten — Rechnungen, Angebote, Kontakte — basiert auf einem Modell und wird in der Datenbank entsprechend organisiert.
Sowohl technische als auch funktionale Anwender sollten Modelle verstehen: Sie sind die Grundlage der Odoo-Datenarchitektur. Modelle definieren Felder, Beziehungen und die Regeln, die auf Daten angewendet werden.
Dieser Beitrag konzentriert sich auf eines der zentralen Modelle in Odoo: res.partner. Ob Sie Module anpassen, externe Systeme anbinden oder Geschäftsabläufe konfigurieren — mit res.partner kommen Sie immer wieder in Kontakt.
Was ist das res.partner-Modell
Das res.partner-Modell bildet Personen, Kunden, Lieferanten und Firmen ab. Hier laufen alle Informationen zu Geschäftspartnern zusammen, von Adressen über Steuerdaten bis zu Verantwortlichen.
Fast jedes Modul in Odoo greift auf res.partner zurück: Vertrieb, CRM, Buchhaltung, Einkauf und E‑Commerce nutzen dieselben Partnerdaten. Ein Kunde, ein Lead oder ein Lieferant ist letztlich immer ein res.partner-Datensatz.
Die Basisdefinition steht im base-Modul; andere Module erweitern das Modell per Vererbung. CRM fügt etwa Felder für Leads hinzu, die Buchhaltung ergänzt Zahlungs- und Kreditinformationen — die Kernstruktur bleibt dabei bestehen.
Wichtige Felder im Modell
Die folgenden Felder sind für die tägliche Arbeit mit Partnern besonders relevant. Ein solides Verständnis dieser Felder erleichtert Konfiguration, Integration und Reporting.
1. name
Typ: Char. Beinhaltet den Namen des Partners — Firmenname oder vollständiger Personenname. Dieses Feld ist das prägnanteste Label für Partner in Listen und Formularen.
2. create_date
Typ: Datetime. Zeitpunkt der Erstellung des Datensatzes. Wird automatisch gepflegt und ist nützlich für Audits und zeitbasierte Auswertungen.
3. write_date
Typ: Datetime. Zeitpunkt der letzten Änderung. Ebenfalls automatisch aktualisiert und hilfreich, um Änderungsverläufe nachzuvollziehen.
4. email
Typ: Char. Primäre E‑Mail-Adresse für Kommunikation, Portalzugang und Rechnungsversand. Odoo prüft die Formatvalidität, wenn möglich.
5. phone
Typ: Char. Haupttelefonnummer, sichtbar in Kontaktformularen und für Kommunikationsprozesse.
6. mobile
Typ: Char. Mobilfunknummer, wird oft für SMS‑Benachrichtigungen oder kurzfristige Kontakte genutzt.
7. street
Typ: Char. Erste Adresszeile; Teil des Standardadressblocks für Dokumente und Formulare.
8. street2
Typ: Char. Zweite Adresszeile für Zusätze wie Etage, Gebäude oder ergänzende Hinweise.
9. city
Typ: Char. Stadt bzw. Ort; Adressformatierungen können je nach Land variieren.
10. zip
Typ: Char. Postleitzahl; wichtig für Validierung und Versandkalkulationen.
11. state_id
Typ: Many2one (res.country.state). Bundesland oder Region; die Auswahl wird länderspezifisch gefiltert. Nicht jedes Land verwendet Bundesländer.
12. country_id
Typ: Many2one (res.country). Landangabe, die Adressformat, Steuerszenarien und Lokalisierungen beeinflusst.
13. is_company
Typ: Boolean. Kennzeichnet, ob es sich um eine Firma oder eine Privatperson handelt. Firmen können Unterkontakte haben; Personen können über parent_id mit einer Firma verbunden werden.
14. parent_id
Typ: Many2one (res.partner). Verweist bei Kontakten auf die zugehörige Firma. Erlaubt Hierarchien und Vererbung von Adressdaten und Einstellungen.
15. child_ids
Typ: One2many (res.partner). Umgekehrte Beziehung zu parent_id: listet alle Kontakte einer Firma auf und erleichtert die Navigation.
16. company_id
Typ: Many2one (res.company). In Multi‑Company‑Szenarien zeigt dieses Feld, zu welcher Odoo‑Firma der Partner gehört und beeinflusst Sichtbarkeit sowie Zugriffsregeln.
17. vat
Typ: Char. Umsatzsteuer‑ oder Steueridentifikationsnummer. Länderspezifische Validierung möglich; wichtig für Rechnungsstellung und Compliance.
18. customer_rank
Typ: Integer. Kennzeichnet den Kundenstatus; Odoo erhöht den Wert bei Verkaufsaktivität. Nützlich für Filter, Segmentierung und Priorisierung.
19. supplier_rank
Typ: Integer. Kennzeichnet Lieferantenstatus; wird bei Einkaufsaktivität erhöht und hilft bei der Identifikation von Anbietern.
20. user_id
Typ: Many2one (res.users). Der zuständige Vertriebsmitarbeiter oder Betreuer, relevant für CRM‑Zuordnungen und Aktivitäten.
21. type
Typ: Selection. Adresstyp für Unterkontakte: Kontakt, Rechnung, Lieferung oder Sonstiges. Entscheidet, welche Adresse auf Dokumenten verwendet wird.
22. ref
Typ: Char. Interne Referenz oder Code, praktisch für Abgleiche mit externen Systemen und individuelle Nummernschemata.
23. website
Typ: Char. Webadresse des Partners; erscheint im Kontaktformular und im E‑Commerce‑Kontext.
24. comment
Typ: Html. Interne Notizen und Hinweise, sichtbar für interne Anwender — häufig für Verkaufstipps oder spezielle Vereinbarungen genutzt.
25. active
Typ: Boolean. Soft‑Delete‑Flag: bei False ist der Partner archiviert und aus Standardansichten ausgeblendet, wird aber nicht gelöscht.
26. lang
Typ: Selection. Bevorzugte Sprache des Partners; beeinflusst die Lokalisierung von E‑Mails und Dokumenten und kann vom Parent übernommen werden.
27. image_1920
Typ: Binary. Partnerbild oder Firmenlogo; Odoo verwaltet mehrere Größen für Formulare, Berichte und Webseiten.
28. category_id
Typ: Many2many (res.partner.category). Tags zur Segmentierung und Filterung — nützlich für Marketinglisten und kundenspezifische Klassifizierungen.
Einsatzbereiche in Geschäftsprozessen
1. Vertrieb und CRM
Bei der Angebotserstellung wählt der Vertrieb einen Partner aus res.partner. Dasselbe Partnerprofil begleitet Lead, Opportunity und Auftrag; Felder wie customer_rank oder user_id steuern Zuordnung und Auswertung.
2. Rechnungswesen
Rechnungen und Eingangsrechnungen verweisen auf den Partner für die Rechnungsadresse. VAT‑Informationen fließen in die Steuerberechnung ein; Zahlungskonditionen und Kreditlimits werden oft auf Partner‑Ebene gepflegt.
3. Einkauf und Lieferanten
Bestellungen und Lieferantenrechnungen nutzen res.partner für Adressen und Stammdaten. supplier_rank hilft dabei, aktive Lieferanten zu identifizieren; buyer_id weist einen zuständigen Einkäufer zu.
4. E‑Commerce und Portal
Website‑Nutzer können beim Registrieren einen Partnerdatensatz anlegen. Dieser Datensatz steuert Bestellungen, Angebote und den Portalzugang — Adresse und Kontaktdaten stammen vom Partner.
5. Multi‑Company und Konsolidierung
In Multi‑Company‑Setups kann dieselbe juristische Einheit in mehreren Firmen als eigene Partner vorkommen. company_id und Intercompany‑Regeln legen fest, wie Daten geteilt und konsolidiert werden.
Wie Entwickler das Modell erweitern
Entwickler erweitern res.partner auf verschiedene Arten; die gängigste ist die Odoo‑Modellvererbung.
Modellvererbung
Mit _inherit = 'res.partner' erweitern Sie das Modell: neue Felder hinzufügen, Methoden überschreiben oder Constraints ergänzen. Änderungen bleiben in eigenen Modulen und vereinfachen Upgrades.
Felder ergänzen
Neue Felder werden in der geerbten Klasse definiert. Wählen Sie passende Feldtypen (Char, Many2one, Boolean, Integer, Text, Selection) und denken Sie an unternehmensabhängige Felder bei Multi‑Company‑Anforderungen.
Erweiterungen in Python
Überschreiben Sie create, write oder unlink, um Logik einzubetten — rufen Sie dabei super() auf, um bestehendes Verhalten nicht zu zerstören. Achten Sie besonders auf berechnete Felder und Dependency‑Deklarationen.
Odoo Studio
Odoo Studio erlaubt das Hinzufügen von Feldern ohne Code — praktisch für schnelle Anpassungen. Für komplexe Logik oder langfristige Wartbarkeit sind Custom‑Module jedoch die nachhaltigere Wahl.
Empfohlene Vorgehensweisen
- Erzeugen Sie die Firma zuerst und legen Sie dann Kontakte mit parent_id an, um die Hierarchie korrekt abzubilden.
- Pflegen Sie country_id für korrekte Adressformate und steuerliche Regeln.
- Nutzen Sie commercial_partner_id, wenn Sie die oberste wirtschaftliche Einheit für Konsolidierung, Kreditlimits oder Reporting benötigen.
- Für API‑Integrationen nutzen Sie XML‑RPC oder JSON‑RPC: res.partner ist über beide Schnittstellen vollständig erreichbar. Stimmen Sie externe IDs sorgfältig ab.
- Bei eigenen Feldern verwenden Sie das Präfix x_ oder ein Modulpräfix, um Konflikte mit künftigen Odoo‑Versionen zu vermeiden.
Häufige Fehler
- Duplizieren von Partnern statt vorhandene Datensätze zu suchen. Nutzen Sie email_normalized oder ref, um Dubletten zu erkennen und zu vermeiden.
- Verwechslung zwischen parent_id und company_id. parent_id bildet die Kontakt‑Firma‑Beziehung, company_id gehört zum Multi‑Company‑Konzept.
- Das Nichtsetzen des Typs bei Unterkontakten. Rechnungs‑ und Lieferadressen müssen den korrekten Typ haben, damit Dokumente die richtigen Adressen verwenden.
- Core‑Methoden zu überschreiben ohne super() aufzurufen. Dadurch können andere Module oder künftige Updates beschädigt werden.
- Pflichtfelder hinzugefügt, aber keine Standardwerte definiert. Bestehende Datensätze können dann bei Migrationen oder Upgrades Validierungsfehler auslösen.
Fazit
Das res.partner‑Modell ist ein zentraler Baustein in Odoo: Kontakte, Kunden und Lieferanten werden hier verwaltet. Wer die Felder und Erweiterungsmöglichkeiten kennt, kann Odoo sicher konfigurieren und integrieren.
Egal ob Sie Prozesse abbilden oder Module entwickeln — fundiertes Wissen über res.partner spart Zeit und reduziert Fehlerquellen.
Brauchen Sie Unterstützung bei Ihrer Odoo‑Einführung?
Dasolo begleitet Unternehmen bei Implementierung, Anpassung und Optimierung von Odoo. Unser Fokus liegt auf API‑Integrationen und individueller Entwicklung; wir kennen die Odoo‑Datenarchitektur und Modelle wie res.partner sehr genau.
Wenn Sie Hilfe bei Implementierung, individuellen Modulen oder Integrationen benötigen, unterstützen wir Sie gerne. Demo vereinbaren und Ihr Projekt mit uns besprechen.