Datetime-Felder in Odoo: Der umfassende Leitfaden

Einführung

Datum und Uhrzeit stecken in fast jedem Geschäftsprozess: Bestellzeitpunkt, Lieferfenster, Stempelzeit einer Anwesenheit. In Odoo wird diese Kombination aus Datum und genauer Uhrzeit über das Datetime-Feld abgebildet und abgespeichert — es ist das Standardwerkzeug, wenn Prozesse nicht nur ein Datum, sondern auch den exakten Zeitpunkt benötigen.

Im Unterschied zum reinen Date-Feld, das nur ein Kalendarium speichert, enthält ein Datetime-Feld zusätzlich die Uhrzeit (bis auf Sekunden genau). Das ist nicht nur eine Frage der Genauigkeit: Sobald mehrere Zeitzonen im Spiel sind oder Prozesse minuten- oder stundenbasiert gesteuert werden, entscheidet diese Wahl über die korrekte Abbildung und Auswertung von Ereignissen.

Dieser Leitfaden erklärt kompakt alles Wichtige zum Datetime-Feld in Odoo: welche Informationen es hält, wie es sich im Datenmodell verhält, wie Sie es per Studio oder per Code anlegen, und konkrete Praxisbeispiele aus verschiedenen Modulen und Geschäftsprozessen.

Was ist das Datetime-Feld in Odoo?

Technisch definiert das Odoo-ORM das Feld als fields.Datetime — eine Kombination aus Datum und Uhrzeit. In PostgreSQL entspricht das einem TIMESTAMP-Feld. Wichtig: Odoo speichert intern immer in UTC und wandelt beim Anzeigen in die jeweils eingestellte Zeitzone des aktiven Benutzers um.

Für Anwender erscheint das Datetime-Feld in Formularen als kombinierter Kalender- und Zeit-Selektor. In Listen oder Berichten wird der Wert nach Sprache- und Zeitzoneneinstellungen des Nutzers formatiert dargestellt, sodass die Anzeige lokal sinnvoll lesbar ist.

So definieren Entwickler ein Datetime-Feld in einem Python-Modell:

from odoo import fields, models

class SaleOrder(models.Model):
    _inherit = 'sale.order'

    x_confirmed_on = fields.Datetime(
        string='Confirmed On',
        default=fields.Datetime.now,
        readonly=True,
        copy=False,
    )

Die string-Option legt das Label in der Oberfläche fest. Mit default füllen Sie das Feld automatisch beim Anlegen eines Datensatzes. readonly verhindert manuelle Änderungen — typisch bei Prüftimestamps oder Auditfeldern.

In Odoo Studio heißt der Typ Date & Time. Felder, die über Studio angelegt werden, erhalten automatisch ein x_studio_-Präfix. Legen Sie das Feld per Code oder API an, bestimmen Sie selbst den technischen Namen.

Wie das Feld funktioniert

Bei Installation oder Upgrade eines Moduls erzeugt Odoo die passende Datenbankspalte automatisch. Sie müssen in der Regel keine manuellen SQL-Migrationen schreiben — das ORM übernimmt das für Sie.

Die Zeitzonen-Handhabung überrascht viele: Gespeichert wird immer UTC. Trägt ein Anwender in Paris ein Meeting um 15:00 ein, schreibt Odoo intern 13:00 UTC. Ein Kollege in New York sieht dann 09:00 in seiner Ansicht. Diese Konvertierung erledigt das ORM automatisch anhand der Zeitzone im Benutzerprofil.

Wichtige Feldeigenschaften

Die wichtigsten Attribute des Datetime-Feldes im Odoo-Framework sind:

• default: Häufig auf fields.Datetime.now gesetzt, um beim Erstellen eines Datensatzes automatisch die aktuelle UTC-Zeit zu setzen.
• required: Macht das Feld auf Formular- und Modellebene verpflichtend.
• readonly: Sperrt das Feld gegen manuelle Änderungen in der UI — üblich bei Systemtimestamps.
• compute: Verknüpft das Feld mit einer Python-Methode, die den Wert dynamisch aus anderen Feldern berechnet.
• store: In Kombination mit compute sorgt store=True dafür, dass der berechnete Wert in der Datenbank liegt und für Suchen und Reports verfügbar ist.
• copy: Bestimmt, ob der Wert beim Duplizieren eines Datensatzes übernommen wird. Standard ist True; für Ereignis-Timestamps empfiehlt sich False.
• index: Legt einen Datenbankindex an — sinnvoll für Datumsfelder, die in Filtern auf großen Tabellen häufig verwendet werden.

Darstellung in Views

Im Formular zeigt Odoo einen kombinierten Kalender- und Zeit-Input. In Listen wird der Datums-/Zeitwert je nach Spracheinstellung formatiert angezeigt. In Suchansichten unterstützen Datetime-Felder typische Bereichsfilter wie vor, nach oder zwischen zwei Zeitpunkten.

Für Terminfenster lässt sich das Feld mit dem date_range-Widget kombinieren — praktisch für Planungszeiträume oder verbindliche Zeitfenster im Workflow.

Datetime vs. Date: Welche Wahl passt?

Die Faustregel ist einfach: Nutzen Sie fields.Date, wenn die Uhrzeit keine Rolle spielt; wählen Sie fields.Datetime, wenn Sie auf Stunden- oder Minutenebene genau sein müssen.

Typische Einsatzfälle für Date: Fälligkeitstermine von Rechnungen, Geburtstage, Haltbarkeitsdaten, Vertragsverlängerungen.

Typische Einsatzfälle für Datetime: Bestätigungszeitpunkte von Bestellungen, Beginn von Meetings, Mitarbeiter-Check-ins, geplante Lagerbewegungen.

Ein Datetime-Feld unnötig einzusetzen bringt nur zusätzliche Komplexität durch Zeitzonen. Fragen Sie sich immer: Braucht der Prozess wirklich eine Uhrzeit oder reicht das Datum aus?

Typische Anwendungsfälle im Unternehmen

Das Datetime-Feld findet sich in nahezu allen Odoo-Modulen. Nachfolgend fünf praxisnahe Beispiele aus dem Tagesgeschäft.

CRM: Aktivitäten und Lead-Tracking

Im CRM werden Datetime-Felder genutzt, um wichtige Ereignisse zeitlich zu verankern: Wann wurde ein Lead in Bearbeitung genommen? Bis wann ist ein Follow-up geplant? Solche Felder helfen Managern, Reaktionszeiten zu messen, überfällige Leads zu identifizieren und Aktivitäten nachzuverfolgen. Zusätzliche, benutzerdefinierte Datetime-Felder können z. B. festhalten, wann ein Angebot verschickt oder ein Gespräch geführt wurde.

Vertrieb: Zeitstempel bei Auftragserstellung

Das Feld date_order auf sale.order ist ein Datetime-Feld und dokumentiert den exakten Bestätigungszeitpunkt einer Bestellung. Für Umsatzanalysen nach Stunden oder Tagen, Durchlaufzeitmessungen und Prüfungen nach Änderungen nach Bestätigung ist dieser Zeitstempel essenziell. Das Filtern nach diesem Feld gehört zu den Standard-Reports im Vertrieb.

Lager: Geplante Versand- und Empfangszeiten

Im Lager nutzt man scheduled_date auf stock.picking, um Ein- und Ausgänge terminiert zu planen. Automatisierungen können Workflows anstoßen, wenn ein geplanter Termin überschritten wird — etwa automatische Benachrichtigungen bei Verzögerungen, damit Kunden rechtzeitig informiert werden.

Fertigung: Produktionsstart- und Endzeiten

Fertigungsaufträge speichern Start- und Endzeitpunkte mit Datetime-Feldern. Diese Daten fließen in Kapazitätsplanung, Effizienzbewertungen und Schichtanalysen ein. Bei Mehrschichtbetrieb sind präzise Zeitangaben notwendig, um Soll- vs. Ist-Leistung zu vergleichen und Flaschenhälse nach Uhrzeit oder Maschine zu identifizieren.

HR: Anwesenheit und Abwesenheiten

Die HR-Attendance-Module verwenden Datetime-Felder für Ein- und Ausstempel-Zeiten; Urlaubsanträge können mit genauen Start- und Endzeitpunkten versehen werden. Lohn- und Überstundenberechnungen sind oft minutengenau — ungenaue oder fehlende Zeitstempel wirken sich direkt auf die Vergütung aus, weshalb hier Genauigkeit Pflicht ist.

Datetime-Feld anlegen oder anpassen

Feld anlegen: Drei Wege

Es gibt drei gängige Wege, ein Datetime-Feld zu einem Modell hinzuzufügen — je nach Know-how und gewünschtem Deployment-Prozess.

Per Odoo Studio (No-Code)

1. Odoo Studio ist das integrierte Customizing-Tool, mit dem Sie Felder ohne Programmierung anlegen können.
2. Studio öffnen,
3. zum gewünschten Formular navigieren,
4. ein Date & Time-Feld aus der Seitenleiste ins Formular ziehen,
5. Label, Pflichtfeld und optional Default in den Eigenschaften setzen,

Speichern — Studio legt das Feld mit x_studio_-Präfix an und regelt die Datenbankänderung automatisch. Für Business-User ist das die schnellste und sicherste Methode, neue Zeitstempel in bestehende Formulare einzufügen.

Per Python in einem Custom-Module

Entwickler erstellen Datetime-Felder in Python-Modellen — empfohlen, wenn Änderungen versioniert und in mehreren Systemen ausgerollt werden sollen:

from odoo import fields, models

class ResPartner(models.Model):
    _inherit = 'res.partner'

    x_last_contact_date = fields.Datetime(
        string='Last Contact Date',
        default=fields.Datetime.now,
        copy=False,
    )

Anschließend fügen Sie das Feld in die XML-View ein, damit es in der Oberfläche erscheint. Odoo legt die entsprechende TIMESTAMP-Spalte beim Installieren oder Upgrade automatisch an — manuelle SQL-Statements sind nicht erforderlich.

Über die XML-RPC-API

Wenn Sie Anpassungen automatisiert ausrollen oder per Skript Felder anlegen, bietet sich die XML-RPC-API an.

Beispielaufruf zur Feldanlage via API:

field_id = models.execute_kw( ODOO_DB, uid, ODOO_API_KEY, 'ir.model.fields', 'create', [{ 'name': 'x_last_contact_date', 'field_description': 'Last Contact Date', 'model_id': model_id, 'ttype': 'datetime', 'state': 'manual', }] )

Best Practices

Der Wert ttype: 'datetime' erstellt ein Datetime-Feld; state: 'manual' signalisiert, dass das Feld nicht Teil eines Moduls ist — typisch für Felder, die per Studio oder API angelegt werden.

1. fields.Datetime.now als Funktionsreferenz verwenden, nicht aufrufen

Setzen Sie default=fields.Datetime.now ohne Klammern. Ruft man die Funktion mit Klammern auf, wird der Zeitpunkt beim Laden der Klasse einmalig ermittelt und für alle späteren Datensätze wiederverwendet — ein klassischer, schwer auffindbarer Fehler. Ohne Klammern wird beim Anlegen jedes Datensatzes die aktuelle Zeit ermittelt.

2. copy=False für Ereignis-Timestamps setzen

Ereignisstempel wie Bestätigungs- oder Abschlusszeiten sollten nicht beim Duplizieren übernommen werden. Setzen Sie copy=False, damit Duplikate keine historischen Zeitstempel vom Original erben und Berichte sauber bleiben.

3. Beim Schreiben per API immer UTC verwenden

Schreiben Sie Datetime-Werte über die API im UTC-Format YYYY-MM-DD HH:MM:SS. Die API nimmt den String so, wie er ist, an — es findet keine automatische Zeitzonenanpassung statt. Lokalzeit zu übergeben führt zu stillen Offsets, die schwer zu diagnostizieren sind.

4. Readonly für automatisch gefüllte Timestamps

Automatisch erzeugte Zeitstempel sollten in der Oberfläche in der Regel schreibgeschützt sein. Falls doch eine Änderung nötig ist, regeln Sie das über Rechte und Feldsicherheitsregeln und nicht durch offenes Editieren des Feldes.

5. Date wählen, wenn die Uhrzeit keine Rolle spielt

Häufige Fehlerquellen

Ist nur ein Kalendertag wichtig (z. B. Fälligkeitsdatum), nutzen Sie fields.Date. Das vermeidet unnötige Zeitzonenlogik und macht das Datenmodell übersichtlicher.

Zeitzonenfallen beim Lesen roher Daten

Ein häufiger Stolperstein: Wer Rohdaten aus der DB oder über die API liest, sieht UTC-Zeiten. Berichte oder Integrationen, die diese Daten ungekonvertiert verwenden, liefern oft falsche Ergebnisse. Konvertieren Sie Zeitstempel clientseitig in die passende Zeitzone, bevor Sie sie Anwendern präsentieren.

Lokale Zeiten per API schreiben

Wenn Sie lokale Zeiten unverändert an die API übergeben, werden sie so in UTC abgespeichert — das führt zu falschen Anzeigen für lokale Nutzer (z. B. aufgrund von Sommer-/Winterzeit). Solche Fehler tauchen meist erst im Produktiveinsatz auf, wenn Nutzer aus verschiedenen Regionen reale Daten eingeben.

Default als fields.Datetime.now() mit Klammern verwenden

Wird fields.Datetime.now() mit Klammern als Default verwendet, entsteht ein subtiler Fehler: Der Wert wird beim Laden der Klasse fixiert und für alle zukünftigen Datensätze wiederverwendet. Die Timestamps sind formal vorhanden, aber alle identisch — ein schwer zu entdeckender Defekt für zeitbasierte Analysen.

copy=False bei Ereignis-Timestamps vergessen

Ohne copy=False übernehmen Duplikate alle Datetime-Werte des Originals. Das kontaminiert historische Daten still und macht Audit-Trails unzuverlässig — ein kleiner Konfigurationsfehler mit großer Auswirkung auf die Datenqualität.

Datetime statt Date verwenden, obwohl Zeit unnötig ist

Fazit

Wenn für ein Feld nur ein Datum relevant ist, verursacht Datetime nur zusätzlichen Aufwand: Nutzer sehen unnötige Zeitfelder, Zeitzonen werden bei jeder Anzeige berücksichtigt und die Oberfläche wird komplizierter. Wählen Sie immer den einfachsten Typ, der die Geschäftsanforderung korrekt abbildet.

Das Datetime-Feld ist extrem nützlich, wenn Präzision gefragt ist — von Lead-Öffnungszeiten über Produktionszeiten bis hin zu Anwesenheitsstempeln taucht es in nahezu jedem Modul auf.

Die wichtigste Erkenntnis ist das UTC-Speichermodell: Alles in der DB liegt in UTC, die Anzeige übernimmt die Konvertierung. Externe Lese- und Schreibzugriffe müssen dies explizit berücksichtigen — die meisten Zeitzonenfehler in Integrationen lassen sich auf dieses Missverständnis zurückführen. Ergänzend helfen korrekte Default-Syntax, copy=False an passenden Stellen und die Entscheidung für Date statt Datetime, das Datenmodell sauber zu halten.

Bei Dasolo unterstützen wir Firmen bei Implementierung, Anpassung und Optimierung von Odoo quer durch alle Abteilungen. Ob Datenmodell-Design, Feldanpassungen in Workflows oder die Entwicklung kompletter Module — unser Team begleitet Sie von der Idee bis zum produktiven System. Kontaktieren Sie uns und lassen Sie uns über Ihr Odoo-Projekt sprechen.