Einleitung
Wenn beim Speichern eines Formulars in Odoo ein Eingabefeld plötzlich rot aufleuchtet, ist das die einfache Kontrollinstanz für Pflichtangaben. Hinter dieser visuellen Warnung steckt ein Mechanismus, der sicherstellt, dass bestimmte Felder nicht leer bleiben — ein kleiner, aber grundlegender Baustein für saubere Daten im System.
Egal ob Sie Odoo für Vertriebsteams einrichten, ein eigenes Datenmodell bauen oder als Entwickler anpassen: Wer weiß, wie die "required"-Eigenschaft funktioniert, vermeidet Fehler und gestaltet zuverlässigere Prozesse.
Dieser Beitrag erklärt kompakt, wie Pflichtfelder im Odoo-Framework arbeiten, wie Sie sie ohne Code oder per Python konfigurieren, in welchen Fällen sie wirklich Sinn machen und welche Fallstricke Sie vermeiden sollten.
Was bedeutet "Pflichtfeld" in Odoo?
In Odoo ist die Kennzeichnung als Pflichtfeld eine Eigenschaft auf Feldebene, die verhindert, dass ein Datensatz gespeichert wird, solange dieses Feld keinen Wert enthält. Das gilt für viele Feldtypen: Text, Zahlen, Auswahlfelder, Many2one-Relationen, Datumsfelder und ähnliche.
Die Eigenschaft gehört zum Kern des Datenmodells und ist eine der häufigsten Anpassungen bei Odoo-Projekten. Pflichtfelder sind die erste Verteidigungslinie gegen lückenhafte oder widersprüchliche Daten.
Wie es in der Benutzeroberfläche gezeigt wird
In der Odoo-Benutzeroberfläche erkennt man Pflichtfelder meist auf den ersten Blick. Im Bearbeitungsmodus zeigen solche Felder eine visuelle Markierung; beim Versuch zu speichern, ohne das Feld auszufüllen, macht Odoo das Feld sichtbar rot und gibt eine Fehlermeldung aus.
Dieses unmittelbare Feedback reduziert Fehlerquellen beim Erfassen von Daten, weil Anwender sofort sehen, was fehlt und korrigieren können.
Statische vs. dynamische Pflichtfelder
Man unterscheidet grundsätzlich zwei Varianten: Ein statisch verpflichtendes Feld ist immer auszufüllen. Ein dynamisch verpflichtendes Feld wird nur unter bestimmten Bedingungen nötig — zum Beispiel abhängig von anderen Feldwerten desselben Datensatzes.
Beide Varianten kommen in der Praxis vor; die Entscheidung richtet sich nach der zugrunde liegenden Geschäftslogik.
Wie das Pflichtfeld funktioniert
Technisches Verständnis des required-Mechanismus
Durchsetzung auf Anwendungsebene
Wichtig zu wissen: Die Prüfung, ob ein Feld ausgefüllt ist, erfolgt in Odoo auf Anwendungsebene — im ORM — und nicht automatisch als NOT NULL-Constraint auf Datenbankebene. Das heißt: Odoo kontrolliert die Eingaben, bevor sie in die Datenbank geschrieben werden.
Standardmäßig wird kein NOT NULL auf die PostgreSQL-Spalte gesetzt, wenn Sie required=True verwenden. Die Validierung läuft in Python innerhalb des Odoo-ORM ab.
Praxisfolge: Änderungen, die direkt in der Datenbank vorgenommen werden und Odoo umgehen, werden von dieser Prüfung nicht erfasst. Arbeiten Sie daher möglichst immer über das ORM oder die offiziellen APIs, um Datenintegrität zu gewährleisten.
Was passiert, wenn die Regel verletzt wird
Beim Speichern eines Datensatzes mit einem leeren Pflichtfeld geschieht typischerweise Folgendes:
- Das Feld wird im UI rot hervorgehoben und es erscheint eine Validierungsnachricht.
- Der Speichervorgang wird blockiert, bis das Feld ausgefüllt ist.
Und wenn die Prüfung programmiert ausgelöst wird — etwa per XML-RPC oder Serveraktion — wirft Odoo eine ValidationError-Ausnahme mit einem Hinweis auf das fehlende Pflichtfeld.
Dynamische Pflichtfelder mit Domains/Expressions
Im View-Layer lassen sich Pflichtregeln konditionell formulieren. In älteren Odoo-Versionen geschieht das über attrs im XML der Ansicht,
zum Beispiel: <field name="x_delivery_date" attrs="{'required': [('order_type', '=', 'delivery')]}" />
Neuere Odoo-Versionen erlauben eine direkt lesbarere Syntax im Field-Tag,
etwa: <field name="x_delivery_date" required="order_type == 'delivery'" />
Solche Regeln gelten nur für die jeweilige Ansicht. Ein mit required=True in der Modell-Definition gesetztes Pflichtfeld ist strenger — es gilt unabhängig davon, über welche Oberfläche der Datensatz erstellt wird.
Zusammenspiel mit ORM und API
Beim Aufruf von create() oder write() überprüft das ORM vor dem Schreiben alle Felder, die required=True gesetzt haben. Fehlt ein Wert oder wird False übergeben, löst Odoo eine ValidationError aus.
Dasselbe gilt für Aufrufe über die XML-RPC-API: Fehlende Pflichtfelder führen zu Fehlern beim Erstellen von Datensätzen, weil das Modell die Angaben erwartet.
Praktische Anwendungsfälle im Business
Konkrete Situationen aus der Praxis
1) CRM: Kundensegment als Pflichtangabe auf Leads
Vertriebsorganisationen wollen oft sicherstellen, dass jeder Lead einem Segment zugeordnet ist, bevor er in die Pipeline gelangt. Ohne Pflichtfeld passiert das Zuordnen leicht nicht — Auswertungen nach Segmenten werden dadurch unvollständig.
Ein als Pflicht markiertes Auswahlfeld für das Kundensegment auf dem Lead-Formular stellt sicher, dass diese Information gleich bei der Erfassung vorliegt.
2) Vertrieb: Lieferadresse als Pflicht auf Bestellungen
Für Firmen mit physischem Versand ist die Lieferadresse essenziell. Ist sie nicht verpflichtend, können Bestellungen bestätigt werden, obwohl die Logistik die notwendigen Angaben noch nicht hat.
Wer die Lieferadresse im Verkaufsauftrag zum Pflichtfeld macht, verhindert das Bestätigen von Aufträgen ohne Versandziel — ein häufiger Grund für Verzögerungen in der Auslieferung entfällt dadurch.
3) Lager: Chargen- oder Seriennummern bei Wareneingang
In regulierten Branchen (Lebensmittel, Pharma, Elektronik) ist die Rückverfolgbarkeit unverzichtbar. Odoo bietet Tracking-Funktionen, die de facto erfordern, dass bei bestimmten Produkten bei Lagerbewegungen eine Charge oder Seriennummer angegeben wird.
Bei selbst definierten Feldern auf Eingangsbelegen, etwa für Qualitätsprüfungen, sorgt ein Pflichtfeld dafür, dass Lagerpersonal diese Angaben beim Wareneingang nicht überspringt.
4) Buchhaltung: Kostenstelle auf Lieferantenrechnungen
Finanzabteilungen verlangen oft, dass jede Ausgabe einer Kostenstelle zugeordnet wird, damit Budgets sauber überwacht werden können. Ohne Kontrolle werden solche Felder leicht ausgelassen.
Ein Pflicht-Many2one zur Kostenstellen-Tabelle auf Rechnungen verhindert, dass Belege ohne Zuordnung gebucht werden — eine kleine Anpassung, die viel Klarheit in der Berichterstattung schafft.
5) Personalwesen: Vertragstyp vor Abschluss des Onboardings
Beim Mitarbeiter-Onboarding soll der Vertragstyp vor Abschluss dokumentiert sein. Ein Pflichtfeld im Mitarbeiterformular stellt sicher, dass HR nicht versehentlich unvollständige Mitarbeiterdatensätze speichert.
Ein Feld anlegen oder anpassen
Zwei Wege, ein Feld als Pflicht zu markieren
Studio: No-Code-Option
Mit Odoo Studio können Sie Felder ohne Programmierkenntnisse konfigurieren. Wählen Sie im Bearbeitungsmodus ein Feld aus und aktivieren Sie in den Eigenschaften einfach den Schalter „Pflichtfeld“.
Studio setzt damit eine Pflichtangabe in der Ansicht und legt die Eigenschaft am Modell an — eine schnelle Lösung für Standardfälle und für benutzerdefinierte Felder, die mit Studio erstellt wurden.
Die Grenze von Studio: Bedingte Pflichtfelder, die von anderen Feldwerten abhängen, erfordern meist direktes Bearbeiten der View-XML oder eine technische Implementierung.
Technisch: Pflichtfelder in Python definieren
In einem Modul legen Sie in der Regel ein Feld mit required=True an. Das ist die übliche Vorgehensweise bei der Odoo-Entwicklung mit Python-Feldern.
Beispiel (verkürzt): from odoo import fields, models
class SaleOrder(models.Model):
_inherit = 'sale.order'
x_customer_segment = fields.Selection(..., required=True)
x_cost_center_id = fields.Many2one('account.analytic.account', required=True)
Ein auf Modell-Ebene gesetztes required gilt unabhängig davon, über welche View ein Datensatz erzeugt wird — es lässt sich nicht so leicht umgehen.
Dynamische Pflicht im View-XML
Soll die Pflicht nur unter bestimmten Bedingungen gelten, definiert man sie in der Ansicht statt im Modell. In älteren Odoo-Releases mit attrs:
<field name="x_cost_center_id" attrs="{'required': [('order_type', '=', 'invoiced')]}" />In neueren Versionen ist die Inline-Syntax möglich:
<field name="x_cost_center_id" required="order_type == 'invoiced'" />Diese Regel greift nur, wenn die Ansicht genutzt wird — bei API-Aufrufen oder anderen Views ohne diese Definition bleibt sie wirkungslos.
Pflichtfelder programmgesteuert anlegen (API)
Sie können Pflichtfelder auch per XML-RPC anlegen, indem Sie bei ir.model.fields required setzen. Das ist praktisch für automatisierte Deployments oder Migrationsskripte.
Beispiel-Aufruf (verkürzt): models.execute_kw(db, uid, key, 'ir.model.fields', 'create', [{ 'name':'x_customer_segment', 'ttype':'selection', 'required': True, ... }])
Damit erzeugen Sie Feld und Pflichtregel in einem Schritt — nützlich für standardisierte Einrichtungsskripte.
Empfohlene Vorgehensweisen
Gute Gewohnheiten beim Einsatz von Pflichtfeldern
1) Pflichtfelder nur wo nötig setzen
Zu viele Pflichtfelder führen zu Frustration: Wenn Anwender Informationen nicht sofort haben, geben sie oft Platzhalter ein, und die Datenqualität leidet. Fragen Sie sich immer: Ist die Angabe beim Erfassen tatsächlich verfügbar?
Wenn nicht, prüfen Sie alternative Lösungen: Pflicht erst bei Bestätigung, dynamische Pflicht je nach Status oder Pflicht bei späteren Prozessschritten.
2) Validierung abhängig vom Status statt von Anfang an erzwingen
In mehrstufigen Prozessen (z. B. Opportunity-Phasen oder Fertigungsaufträgen) ist es oft sinnvoller, Prüfungen an konkrete Phasen zu koppeln. Das lässt sich über Python-Constraints oder Automatisierungen lösen und ist für Anwender angenehmer als alles sofort Pflicht zu machen.
Dieser Ansatz ist flexibler und vermeidet unnötigen Zeitdruck bei der Dateneingabe.
3) Sinnvolle Default-Werte kombinieren
Hat ein Pflichtfeld einen typischen Standardwert, legen Sie diesen als default fest. Das senkt den Aufwand für Nutzer, ohne die Pflichtprüfung zu unterlaufen.
4) Für kritische Daten: Modell-Ebene bevorzugen
Wesentliche Informationen (z. B. gesetzlich relevante Identifikatoren oder buchhalterische Felder) sollten am Modell selbst verpflichtend sein. View-only-Pflichten lassen sich leichter umgehen und bringen keine Garantie bei API- oder Import-Erstellungen.
5) Änderungen kommunizieren
Neue Pflichtfelder können laufende Nutzerarbeiten stören. Informieren Sie Ihr Team vor dem Rollout, damit niemand überrascht wird, wenn bestehende Datensätze bei der nächsten Bearbeitung die Validierung nicht bestehen.
6) Tests mit leeren und teilweisen Daten durchführen
Prüfen Sie neue Pflichtkonfigurationen vor dem Produktivstart: per UI, per API und über Integrationen. Das Auffinden von Problemen in Testläufen spart später viel Aufwand.
Häufige Fehlerquellen
Typische Stolperfallen und wie Sie sie vermeiden
Fehler 1: Pflicht auf einem Modell mit vorhandenen Datensätzen setzen
Wenn Sie required=True auf ein Feld setzen, das schon viele Datensätze ohne Wert enthält, führt das beim nächsten Bearbeiten dieser Datensätze zu Blockaden. Anwender können dann nichts mehr speichern, bis das Feld gefüllt ist.
Lösung: Vorab Datenmigration durchführen und vorhandene Datensätze befüllen, bevor die Pflicht erzwingt wird.
Fehler 2: Ansichtspflicht mit Modellpflicht verwechseln
Ein als Pflicht in der Ansicht markiertes Feld schützt nicht vor Datensatz-Erstellungen über API, Import oder andere Views. Wer eine harte Regel will, muss required im Python-Modell setzen.
Dieses Missverständnis ist ein häufiger Grund für Produktionsprobleme bei Odoo-Anpassungen.
Fehler 3: Automatisierungen & geplante Aktionen übersehen
Automatisch erzeugte Datensätze (Server-Aktionen, CRON-Jobs) müssen künftig alle Pflichtfelder befüllen. Wird das nicht berücksichtigt, brechen Jobs oder Aktionen nach einer Pflichtanpassung mit Fehlern ab.
Überprüfen Sie deshalb nach Änderungen alle Stellen, die Datensätze automatisch erzeugen.
Fehler 4: Importdateien ohne Pflichtfelder
Bei Datenimporten per CSV schlägt der Import fehl, wenn Pflichtfelder fehlen. Das ist korrekt, überrascht Anwender aber oft, wenn sie bisher Teilimporte genutzt haben.
Tipp: Importvorlagen mit allen Pflichtfeldern bereitstellen und dokumentieren, welche Felder zwingend sind.
Fehler 5: Komplexe Regeln mit required zu erzwingen
Required prüft nur auf Nicht-Leer. Für komplexe Validierungen — z. B. ein Datum in der Zukunft oder die Konsistenz mehrerer Felder — sind Python-Constraints (@api.constrains) die richtige Wahl.
Pflichtfelder allein für Geschäftslogik zu missbrauchen macht das System starr und schwer wartbar.
Fazit
Das Pflichtfeld ist ein kleines, aber mächtiges Werkzeug in Odoo: richtig eingesetzt erhöht es die Datenqualität und sorgt dafür, dass wichtige Angaben immer verfügbar sind. Falsch eingesetzt erzeugt es Frust und führt zu schlampigen Workarounds.
Entscheidend ist das Bewusstsein für den Unterschied zwischen Modell- und Ansichtsebene, ein überlegtes Setzen von Pflichtfeldern und das Mitdenken hinsichtlich Automationen und Integrationen.
Ob Sie einer Entwickleranleitung folgen, ein größeres Anpassungsprojekt durchführen oder nur ein Formular mit Studio anpassen: Wer die required-Eigenschaft versteht und gezielt einsetzt, schafft ein stabiles Odoo-System statt späteren Ärger nach dem Livegang.
Brauchen Sie Unterstützung bei Ihrer Odoo-Einführung?
Bei Dasolo unterstützen wir Unternehmen dabei, Odoo zu implementieren, anzupassen und zu optimieren — von einfachen Formanpassungen bis zu komplexen Datenmodellen. Unser Team verbindet funktionales Verständnis mit technischer Umsetzungskompetenz.
Haben Sie Fragen zu Pflichtfeldern oder anderen Aspekten Ihrer Odoo-Konfiguration? Wir beraten Sie gern. Kontaktieren Sie uns und erzählen Sie uns, was Sie vorhaben.