Jedes Unternehmen hat eigene Informationsbedürfnisse. Wenn Standardsoftware Lücken lässt, sind benutzerdefinierte Felder in Odoo das Werkzeug, mit dem Sie genau die Daten erfassen, die Ihr Team wirklich braucht.
Anstatt Ihre Abläufe an ein starres Datenmodell anzupassen, erlaubt Odoo das Hinzufügen neuer Felder an fast jeden Datensatz – ob Kunde, Angebot, Produkt oder Rechnung. Sie bestimmen, welche Informationen gespeichert werden; Odoo verwahrt sie direkt neben den vorhandenen Standardfeldern.
Dieser Leitfaden erklärt das Wesentliche: was ein benutzerdefiniertes Feld ist, wie es im System verankert wird, welche Wege zur Erstellung es gibt (ohne und mit Code) und wie Sie Felder so nutzen, dass Ihre Odoo‑Instanz übersichtlich und wartbar bleibt.
Was versteht man unter einem benutzerdefinierten Feld in Odoo?
Ein benutzerdefiniertes Feld ist einfach eine zusätzliche Datenbankspalte, die Sie einem bestehenden Odoo‑Modell hinzufügen. Es hält eine einzelne Angabe zu einem Datensatz – ganz wie ein integriertes Feld.
In Odoo werden solche Felder technisch am Auge durch das Präfix x_ kenntlich gemacht. Studio‑Felder bekommen beispielsweise Namen wie x_studio_priority_level, bei projektspezifischen Anpassungen benutzt man häufig ein eigenes Präfix, etwa x_meinfirma_cost_center.
Für Anwender sieht ein Custom Field wie jedes andere Feld aus: es lässt sich in Formularen, Listen, Filterkriterien, Gruppierungen und Berichten darstellen und verhalten. Wer nicht in die Technik schaut, bemerkt keinen Unterschied.
Verfügbare Feldtypen
Odoo bietet eine breite Palette an Feldtypen für individuelle Anforderungen – von einfachem Text bis zu relationalen Verknüpfungen und Attachments.
- Text (Char): Kurze einzeilige Texte wie Codes oder Kürzel
- Mehrzeiliger Text: Notizen, Beschreibungen oder lange Kommentare
- Integer: Ganze Zahlen, z. B. Stückzahlen oder Bewertungen
- Decimal (Float): Zahlen mit Nachkommastellen für Maße oder Raten
- Monetary: Währungsspezifische Beträge, gekoppelt an ein Währungsfeld
- Boolean: Einfache Ja/Nein‑Checkbox
- Datum / Datum & Uhrzeit: Kalenderdatum oder Zeitstempel
- Selection: Vordefinierte Auswahlliste (Dropdown)
- Many2one: Verknüpfung zu genau einem Datensatz eines anderen Modells
- One2many: Liste verwandter Datensätze aus einem Fremdmodell
- Many2many: Mehrfache Verknüpfungen zu Datensätzen eines anderen Modells
- Binary: Dateianhang (z. B. Dokument, Bild)
- HTML: Rich‑Text‑Inhalt mit Formatierung
Die richtige Wahl des Feldtyps von Anfang an spart viel Aufwand. Wenn mögliche Werte vorher bekannt sind, ist ein Selection‑Feld fast immer besser als freier Text – es erzwingt Konsistenz und erleichtert Auswertungen.
Wie solche Felder technisch funktionieren
Odoo basiert auf dem sogenannten Odoo ORM (Object‑Relational Mapping). Jedes sichtbare Formular oder jede Listenansicht entspricht einem Python‑Modell, das auf eine Datenbanktabelle abgebildet ist. Sobald Sie ein benutzerdefiniertes Feld anlegen, registriert Odoo dieses Feld im ORM und legt automatisch die entsprechende Spalte in PostgreSQL an.
Das macht das Odoo‑Datenmodell flexibel: Sie verändern nicht den Quellcode, sondern erweitern das Modell über eine Metadatenebene, die in der Tabelle ir.model.fields liegt. Odoo liest diese Metadaten beim Start und baut die Felder dynamisch zusammen.
Felder im Code vs. Felder in der Datenbank
Bei klassischer Odoo‑Entwicklung werden Felder direkt in Python‑Modellen deklariert. Das ist der Standardweg für Entwickler und bietet klare Kontrolle über Felder und Logik.
Ein typisches Beispiel in einem Python‑Modell sieht so aus (verkürzt dargestellt): class SaleOrder(models.Model):
_inherit = 'sale.order'
cost_center = fields.Char(string='Cost Center')
Felder, die über die Oberfläche oder API angelegt werden, landen stattdessen mit state = 'manual' in ir.model.fields und werden zur Laufzeit geladen. Beide Wege erzeugen echte Datenbankspalten und verhalten sich für den Anwender gleich.
Beziehungen zwischen Modellen und Gegenseitigkeit
Bei relationalen Feldern ist Gegenseitigkeit wichtig: ein Many2one verlangt normalerweise die Gegenrichtung als One2many. So navigiert der ORM sauber zwischen verknüpften Datensätzen.
Wenn Sie z. B. auf dem Auftrag ein Feld x_project_id (Many2one auf project.project) anlegen, sollte auf der Projektseite ein Feld x_sale_order_ids (One2many zurück auf sale.order) vorhanden sein. Ohne die Gegenrichtung sind standardmäßige Verknüpfungen und Listenansichten eingeschränkt.
Berechnete (Computed) Felder
Computed‑Felder berechnen ihren Wert automatisch aus anderen Feldern statt manuelle Eingabe. Technisch implementieren Entwickler dafür eine Python‑Methode und verbinden sie über den Parameter compute. Solche Felder sind in der Regel schreibgeschützt und aktualisieren sich bei Änderung der Abhängigkeiten.
Computed‑Felder sind mächtig, erfordern aber Programmierarbeit. Über Odoo Studio lassen sie sich meist nicht ohne Developer‑Modus und Python‑Know‑how erstellen.
Typische Einsatzbereiche im Unternehmen
Bei unseren Odoo‑Projekten tauchen Custom Fields praktisch immer auf. Im Folgenden fünf aus der Praxis entnommene Anwendungsfälle.
1. Vertrieb (CRM): Leads präziser qualifizieren
Standard‑Leads enthalten Kontaktdaten und Phase, doch Vertriebsteams benötigen oft zusätzliche Merkmale. Ein Selection‑Feld wie „Branche“ oder ein Many2one zu einem internen Modell „Marktsegment“ hilft, Leads schneller einzuordnen und Pipeline‑Auswertungen nach Segmenten zu ermöglichen.
2. Verkauf: Interne Projektnummern erfassen
Wenn nach Projekten abgerechnet wird, muss jede Offerte oder Bestellung oft eine interne Projekt‑ oder Budgetreferenz tragen. Ein einfaches Char‑Feld „Projektcode“ auf sale.order genügt oft, erscheint auch auf Druckdokumenten und lässt sich in Reports filtern und gruppieren, ohne dass ein komplettes Projektmodul nötig ist.
3. Lager & Artikel: Produktspezifische Eigenschaften
Neben den Standard‑Produktattributen brauchen Hersteller oder Händler manchmal technische Spezifikationen. Typische Felder sind z. B. „Garantiezeit (Monate)“ (Integer), „Zertifizierungsstandard“ (Selection) oder „Herkunftsland“ (Many2one zu res.country). Solche Angaben fügen sich nahtlos in die Produktmaske und stehen für Inventur‑Reports zur Verfügung.
4. Buchhaltung: Kostenstellen und Budgetzuweisung
Finanzteams taggen Rechnungen und Buchungen gern mit Kostenstellen oder Budgetpositionen. Ein Many2one auf account.move zu einem benutzerdefinierten „Kostenstelle“-Modell ermöglicht detaillierte Auswertungen, ohne die Analytik‑Konfiguration zu ändern. Filter, Pivot‑Reports und Exporte arbeiten sofort mit dem Feld.
5. Personalwesen: Zusätzliche Onboarding‑Daten
Im HR entstehen oft länderspezifische Vertragsarten, interne Skills oder Fahrzeugzuweisungen, die in Standardfeldern nicht abgebildet sind. Custom Fields auf hr.employee halten diese Informationen in Odoo statt in Tabellenkalkulationen – dadurch bleiben sie durchsuchbar und auswertbar.
Wie man Felder anlegt oder anpasst
Zwei Hauptwege, ein Feld zu erzeugen – die Wahl hängt von Ihren Ressourcen und Anforderungen ab.
Variante 1: Odoo Studio (No‑Code)
Odoo Studio ist die schnellste und am meisten benutzerfreundliche Methode. Mit aktiviertem Studio können Anwender Felder per Drag & Drop in wenigen Schritten ergänzen:
- Öffnen Sie das Modul und das Formular, in dem das Feld erscheinen soll (z. B. Auftrag),
- aktivieren Sie den Studio‑Bearbeitungsmodus,
- ziehen Sie einen Feldtyp aus der Seitenleiste auf das Formular,
- vergeben Sie Beschriftung, technischen Namen und Eigenschaften,
- und speichern Sie die Änderung.
Studio legt das Feld in ir.model.fields mit x_studio_ Präfix an und fügt es direkt zur Ansicht hinzu – ohne Serverneustart oder Deployment. Für einfache Felder ohne Speziallogik ist dies der empfohlene Weg.
Variante 2: Technische Anpassung über API oder Modul
Für Entwicklerprojekte werden Felder programmatisch über die API (z. B. XML‑RPC) oder als Python‑Modul angelegt. Diese Methode ist sinnvoll, wenn Sie berechnete Felder, komplexe Domains oder versionierbare Codebasis benötigen.
Ein Beispiel mit der API: Ein Selection‑Feld auf dem Auftrag anlegen (verkürzt):
Zuerst die Modell‑ID abrufen, dann den Datensatz inir.model.fieldserzeugen – dabei werden Name, Beschreibung, Typ, Auswahloptionen und der Statusstate = 'manual'gesetzt. (Technische Details je nach Schnittstelle.)
Das ist Teil der üblichen Entwickler‑Arbeitsweise, wenn Felder ohne Änderung der Quelldateien hinzugefügt werden sollen. Es eignet sich besonders für automatisierte Deployments und Remote‑Konfigurationen.
Für dauerhafte, gut wartbare Anpassungen empfiehlt sich die Definition in einem Python‑Modul: Felder werden in Modellklassen deklariert und über ein Modul installiert; so landen sie in Versionierungssystemen und sind upgradesicher.
Feld in die Ansicht einfügen
Ein Feld existiert erst in der Datenbank – es wird nicht automatisch in die UI eingeblendet. Mit Studio geschieht das beim Anlegen. Bei Code‑Anpassungen müssen Sie die entsprechende View‑XML anpassen oder eine geerbte Ansicht erstellen, die das Feld an der gewünschten Stelle einfügt.
Empfehlungen für saubere Feldgestaltung
Gute Praktiken verhindern, dass die Feldlandschaft zur Wartungsfalle wird. Diese Regeln halten Ihre Implementierung sauber.
Wo möglich: Selection statt Freitext
Wenn die Wertemenge begrenzt ist, setzen Sie auf Selection‑Felder. Freitext führt zu uneinheitlichen Einträgen („Kunde“, „kunde“, „K"), die Auswertungen zerstören. Dropdowns sorgen sofort für Datenqualität.
Klare, einheitliche Benennung
Der technische Name sollte den Inhalt beschreiben, nicht die Position. Namen wie x_field_1 sind später kaum nachvollziehbar. Legen Sie eine Namenskonvention fest und dokumentieren Sie Zweck und Herkunft jedes Feldes.
Native Modelle nicht überfrachten
Zehn Custom Fields auf sale.order deuten oft darauf hin, dass ein eigenes Modell sinnvoll wäre. Wenn mehrere Felder zusammengehören und ein neues Geschäftsobjekt abbilden, legen Sie ein eigenes Modell an und verknüpfen es per Many2one.
Immer erst in einer Staging‑Instanz testen
Bevor Sie Änderungen live setzen: testen Sie auf einer Datenbankkopie. Ein falsch angelegtes Feld oder eine falsche View‑Änderung kann Anwenderfehler und Ausfallzeiten verursachen; Staging reduziert dieses Risiko erheblich.
Dokumentation aller Custom Fields
Führen Sie eine Liste aller benutzerdefinierten Felder: Modell, technischer Name, Zweck, Anforderer. Ohne Dokumentation wird schnell unklar, welche Felder noch gebraucht werden und welche gelöscht werden können.
Richtige Technik für berechnete Logik nutzen
Wenn Werte aus anderen Feldern abgeleitet werden sollen, implementieren Sie berechnete Felder statt manuelle Eingaben zu verlangen. Das reduziert Fehler und Arbeitsaufwand; computed fields sind Teil der Kernfunktionalität und gut dokumentiert für Entwickler.
Häufige Fehler und Fallstricke
Trotz Erfahrung treten immer wieder ähnliche Fallstricke auf. Die wichtigsten Probleme im Überblick.
Many2one erstellen, aber One2many vergessen
Das häufigste technische Versehen: eine Many2one‑Verknüpfung ohne entsprechende One2many‑Gegenrichtung. Folge: von der anderen Seite aus fehlt die Navigation auf verwandte Datensätze. Legen Sie immer beide Seiten an, wenn sinnvoll.
Felder löschen, die noch Daten enthalten
Beim Löschen verschwindet die Spalte und alle enthaltenen Daten unwiederbringlich. Sind Daten vielleicht später noch wichtig, archivieren oder verstecken Sie das Feld statt es zu löschen.
Änderungen direkt in der Produktion vornehmen
Direkte Anpassungen am Live‑System ohne Tests sind riskant. Schon kleine View‑Fehler erzeugen Laufzeitfehler für Nutzer. Validieren Sie deshalb Änderungen zuerst in einer Testumgebung.
Namenskonflikte mit später installierten Modulen
Odoo verhindert doppelte Feldnamen, aber Sie können später Module installieren, die ähnliche Felder mit anderen Bedeutungen hinzufügen. Ein projektspezifisches Präfix (z. B. x_meinfirma_) minimiert solche Konflikte.
Felder in Views platzieren, ohne UX zu bedenken
Nur weil ein Feld technisch einfügbar ist, heißt das nicht, dass es sichtbar sein sollte. Überladene Formulare verlangsamen Anwender. Zeigen Sie Felder kontextbezogen (Reiter, nur bei bestimmten Bedingungen) an.
Studio‑ und Code‑Felder unkoordiniert mischen
Kombinieren Sie Studio‑Anpassungen und Code nur mit abgestimmter Strategie. Ohne Plan entstehen doppelte oder widersprüchliche Felder. Entscheiden Sie früh, welche Anpassungen no‑code bleiben und welche per Modul erfolgen.
Zusammenfassung
Custom Fields sind ein schneller, wirkungsvoller Hebel, Odoo an Ihre Prozesse anzupassen. Sie benötigen keine Modifikation am Quellcode, fügen sich in die Plattform ein und erlauben exakte Datenerfassung ohne Workarounds.
Wichtig ist die Planung: wählen Sie passende Feldtypen, vergeben Sie klare Namen, halten Sie sich an relationale Konventionen und dokumentieren Sie Ihre Änderungen. Eine durchdachte Feldstruktur macht Ihre Odoo‑Instanz wartbarer und anpassungsfähiger mit dem Wachstum Ihres Unternehmens.
Ob Sie Odoo Studio für schnelle No‑Code‑Felder nutzen oder Python‑Module für dauerhafte Anpassungen erstellen: die Prinzipien bleiben gleich – Feld zum Bedarf passen, Modell sauber halten und vor Live‑Schaltung testen.
Bei Dasolo unterstützen wir Unternehmen dabei, Odoo so einzurichten, anzupassen und zu optimieren, dass die Software genau zu Ihren Arbeitsabläufen passt. Ob nur ein paar Custom Fields oder ein vollständiges, maßgeschneidertes Modul – unser Team begleitet Sie.
Kontaktieren Sie uns gerne für eine Überprüfung Ihrer Odoo‑Umgebung. Wir prüfen Ihre Konfiguration und empfehlen den klarsten, wartungsfreundlichsten Weg nach vorn.