Odoo 19 anpassen: Konfiguration, Studio oder eigene Module?

Jedes Odoo-Projekt kommt irgendwann an dieselbe Frage: Der Standardablauf passt fast, aber nicht ganz zu dem, was das Unternehmen möchte. Sollten Sie eine Einstellung ändern, Odoo Studio öffnen oder einen Entwickler bitten, ein eigenes Modul zu schreiben? Die Antwort hat langfristige Folgen für Kosten, Stabilität und vor allem für Upgrades.

Bei 1CBMS folgen wir in jeder Implementierung einer einfachen Regel: zuerst Konfiguration, dann Studio, dann eigene Module. Jede Stufe auf dieser Leiter bringt mehr Flexibilität, aber auch etwas, das das Unternehmen über die gesamte Lebensdauer des Systems besitzen und pflegen muss.

Ein Hinweis zu den Quellen: Dieser Artikel folgt der offiziellen Odoo-Dokumentation für Version 19.0. Menüs und Optionen können sich je nach Version, Edition und Hosting-Art unterscheiden. Prüfen Sie das Verhalten daher immer in einer Testdatenbank, bevor Sie die Produktion ändern.

Ebene eins: Konfiguration vor allem anderen

Odoo bringt in jeder App eine große Zahl an Einstellungen, Optionen und konfigurierbaren Datensätzen mit. Viele Anfragen, die nach Anpassungen klingen, sind in Wirklichkeit Standardfunktionen, die nur noch nicht aktiviert wurden – etwa zusätzliche Workflow-Schritte, Belegvorlagen oder optionale Felder, die erscheinen, sobald eine Funktion eingeschaltet ist.

Bevor Sie eine Spezifikation für Studio oder Code schreiben, gehen Sie mit den Key-Usern des Prozesses folgende Prüfungen durch:

• Sehen Sie sich die Einstellungsseite jeder beteiligten App an und lesen Sie, was jede Option aktiviert.
• Prüfen Sie, ob die Anforderung durch konfigurierbare Datensätze wie Phasen, Tags, Teams, Vorgangsarten oder E-Mail-Vorlagen abgedeckt ist.
• Nutzen Sie für Logos, Farben, Schriftarten und Fußzeilen die Einstellungen zum Dokumentlayout des Unternehmens, statt Berichtsvorlagen zu bearbeiten.
• Fragen Sie, ob das Unternehmen seinen Prozess an den Standardablauf anpassen kann, denn Standardabläufe werden von Odoo getestet und upgegradet.

Konfiguration ist die am günstigsten zu unterhaltende Ebene. Sie ist Teil des Standardprodukts, wird vom Upgrade-Prozess übernommen und erzeugt keine eigene Codebasis, die jemand pflegen muss.

Ebene zwei: Was Odoo Studio kann

Die Odoo-Dokumentation beschreibt Studio als Werkzeugkasten, mit dem sich Odoo ohne Programmierkenntnisse anpassen lässt. Geöffnet wird es über das Symbol „Studio umschalten“, während Sie sich in der App und dem Modell befinden, das Sie ändern möchten, und geschlossen über die Schaltfläche „Schließen“.

Laut offizieller Dokumentation deckt Studio folgende Bereiche ab:

• Felder: einfache Felder wie Text, Ganzzahl, Dezimalzahl, Währungsbetrag, Datum, Kontrollkästchen, Auswahl, Datei und Bild sowie relationale Felder wie Many2One, One2Many, Zeilen, Many2Many, Tags und verknüpfte Felder.
• Ansichten: Formular-, Aktivitäts-, Such-, Kanban-, Listen-, Karten-, Kalender-, Kohorten-, Gantt-, Pivot- und Diagrammansichten.
• Modelle und Apps: neue, von Grund auf erstellte Modelle mit vorgeschlagenen Funktionen wie Chatter, Pipeline-Phasen, Tags, Archivierung und Zeilen, um die Erstellung zu beschleunigen.
• Automatisierungsregeln: Auslöser auf Basis von Wertänderungen, E-Mail-Ereignissen, Zeitbedingungen, Erstellung oder Löschung von Datensätzen, Änderungen in der Benutzeroberfläche und externen Webhooks.
• Genehmigungsregeln: an Schaltflächen gebundene Freigabeschritte mit Genehmigenden, die als Benutzer, Gruppen oder beides definiert sind. Studio deckt außerdem Webhooks und Sicherheitsregeln ab.
• PDF-Berichte: Bearbeiten von statischem Text sowie Einfügen dynamischer Felder, Tabellen, Spalten und Bilder in Berichtsvorlagen; beachten Sie, dass sich die Bearbeitung von Kopf- oder Fußzeile eines Berichts auf alle Berichte auswirkt.

Wenn Sie eine Ansicht per Drag-and-drop ändern, erstellt Studio automatisch die passende geerbte Ansicht und den XPath, statt die Standardansicht zu überschreiben. Sämtliche Studio-Arbeit wird in Ihrer Datenbank in einem Modul namens studio_customization gebündelt, das als ZIP-Datei exportiert und in eine andere Datenbank importiert werden kann.

Studio ist eine App von Odoo Enterprise. Die offizielle Seite weist zudem darauf hin, dass die Installation von Studio in einer Datenbank mit dem Preisplan Standard einen Wechsel auf den Plan Custom auslöst – klären Sie die kommerziellen Auswirkungen daher mit Ihrem Odoo-Account-Manager, bevor Sie es aktivieren. Community-Datenbanken enthalten kein Studio; dort erfolgt alles, was über die Konfiguration hinausgeht, über technische Einstellungen im Entwicklermodus oder über Module.

Ebene zwei, Fortsetzung: die Grenzen von Studio

Studio ist leistungsfähig, doch die Dokumentation selbst nennt mehrere Grenzen und Risiken, die jedes Projekt beachten sollte:

• Der technische Name eines Feldes lässt sich nach der Erstellung in Studio nicht mehr ändern, und eigene Felder müssen mindestens das Präfix x_ behalten, wobei Studio-Felder x_studio_ verwenden.
• Die Aktivitätsansicht und bedingte Blöcke in Berichten lassen sich nur durch Bearbeiten von XML ändern, wofür der Entwicklermodus erforderlich ist.
• Von der direkten Bearbeitung von Standard- oder geerbten Ansichten wird abgeraten, da diese Änderungen bei Updates oder Modul-Upgrades zurückgesetzt würden und verloren gingen.
• Odoo empfiehlt dringend, einen Standardbericht zu duplizieren und die Kopie zu bearbeiten, und warnt, dass eine direkte Änderung des Bericht-XML bei Upgrades Probleme verursachen kann.
• Die Aktion „Code ausführen“ in Automatisierungsregeln führt Python aus, und laut Dokumentation ist die Wartung von eigenem Code nicht in den Plänen Standard oder Custom enthalten und verursacht zusätzliche Gebühren.
• Webhooks sollten gemeinsam mit einem Entwickler oder einer technischen Rolle konzipiert werden, da falsch konfigurierte Webhooks die Datenbank stören können.
• Exportierte Studio-Anpassungen lassen sich nur in eine Datenbank derselben Odoo-Version mit denselben installierten Apps und Modulen importieren.

In der Praxis ist Studio ideal für Datenerfassung, Layout, einfache Automatisierung und Genehmigungen. Riskant wird es, wenn damit echte Programmierung in XML-Änderungen oder in Aktionen vom Typ „Code ausführen“ versteckt wird, die niemand dokumentiert.

Ebene drei: Wann ein eigenes Python-Modul gerechtfertigt ist

Ein eigenes Modul ist eine separate Codebasis, die Odoo über Modelle, Ansichten, Sicherheit, Datendateien und Python-Logik erweitert und mit demselben Framework entwickelt wird, das Odoo für seine eigenen Apps verwendet. Es ist das richtige Werkzeug, wenn die Anforderung über das hinausgeht, was Konfiguration und Studio sauber abbilden können.

Typische Situationen, in denen wir ein eigenes Modul empfehlen:

• Komplexe Geschäftsregeln, Berechnungen oder Einschränkungen, die automatisierte Tests und Versionskontrolle erfordern.
• Integrationen mit externen Systemen, die eine robuste Fehlerbehandlung, Wiederholungsversuche und Protokollierung erfordern.
• Änderungen an der Standard-Geschäftslogik, etwa daran, wie Belege validiert oder Werte berechnet werden, und nicht nur daran, wie sie angezeigt werden.

Das Hosting spielt hier eine Rolle. Laut offizieller Dokumentation ist Odoo Online nicht mit eigenen Modulen oder Modulen aus dem Odoo Apps Store kompatibel. Eigene Module erfordern Odoo.sh oder eine On-Premise-Installation, daher müssen Hosting-Entscheidung und Anpassungsstrategie gemeinsam getroffen werden.

Auswirkungen jeder Option auf Upgrades

• Konfiguration: Teil des Standardprodukts und wird durch den Standard-Upgrade-Prozess migriert.
• Studio: Die in der Odoo-Dokumentation beschriebenen Upgrade-Services umfassen das Upgrade aller mit der App Studio erstellten Anpassungen, solange Studio installiert und sein Abonnement aktiv ist.
• Eigene Module: Eine Datenbank mit eigenen Modulen kann erst upgegradet werden, wenn eine Version dieser Module für die Ziel-Odoo-Version verfügbar ist, und es liegt in der Verantwortung des Modul-Maintainers, sie kompatibel zu machen.

Der Odoo-Leitfaden für das Upgrade einer angepassten Datenbank empfiehlt, die Entwicklung einzufrieren, zu prüfen, welche eigenen Funktionen inzwischen nativ bereitgestellt werden, jedes Modul so anzupassen, dass es sich sauber in einer leeren Datenbank der Zielversion installieren lässt, Upgrade-Skripte für umbenannte Modelle, Felder und externe IDs zu schreiben und das Upgrade zu proben, bevor die Produktion angefasst wird.

Unabhängig von der Ebene: Testen Sie die upgegradete Datenbank gründlich. Die Dokumentation rät, Geschäftsabläufe durchgängig zu testen, einschließlich Integrationen, automatisierter Aktionen, Serveraktionen und Berichte, und erinnert daran, dass Testdatenbanken neutralisiert sind, mit deaktivierten geplanten Aktionen und ausgehenden E-Mails.

Governance: Anpassungen unter Kontrolle halten

Anpassungen scheitern selten am ersten Tag. Sie scheitern Jahre später, wenn sich niemand mehr erinnert, warum ein Feld existiert oder wer eine Automatisierungsregel geschrieben hat. Ein schlankes Governance-Modell verhindert das.

• Führen Sie ein Anpassungsregister, das jedes Studio-Feld, jede Ansichtsänderung, Automatisierungsregel, Genehmigungsregel, jeden Bericht und jedes eigene Modul mit Verantwortlichem und geschäftlichem Grund auflistet.
• Nehmen Sie alle Änderungen zuerst in einer Test- oder Staging-Datenbank vor und übertragen Sie sie dann über einen kontrollierten Prozess in die Produktion.
• Beschränken Sie Studio und den Entwicklermodus auf geschulte Administratoren; die Dokumentation selbst warnt, dass einige Entwicklerwerkzeuge fortgeschritten sind und Risiken bergen.
• Prüfen Sie das Register vor jedem Upgrade und entfernen Sie Anpassungen, die die neue Version nativ abdeckt.
• Halten Sie den Code eigener Module mit Tests in einer Versionskontrolle und stellen Sie sicher, dass eine Wartungsvereinbarung dafür besteht.

Eine Entscheidungsmatrix für Workshops

Wenn eine neue Anforderung aufkommt, gehen wir diese Fragen der Reihe nach durch und halten bei der ersten Ebene an, die sie erfüllt.

• Lässt sich der Bedarf mit einer Standardeinstellung, einem konfigurierbaren Datensatz oder einer Prozessänderung decken? Konfiguration verwenden.
• Geht es um ein neues Feld, eine geänderte Ansicht, eine einfache Automatisierung, einen Genehmigungsschritt oder eine geänderte Formulierung in einem Bericht? Studio verwenden.
• Sind Python-Logik, automatisierte Tests, eine komplexe Integration oder die Wiederverwendung über Datenbanken hinweg nötig? Ein eigenes Modul verwenden.
• Läuft die Datenbank auf Odoo Online? Bei Konfiguration und Studio bleiben oder zuerst einen Wechsel zu Odoo.sh oder On-Premise planen.

Wie 1CBMS Sie unterstützen kann

1CBMS unterstützt Unternehmen in Ägypten und im Irak dabei, Lösungen mit Odoo 19 Enterprise zu konzipieren, die nah am Standard bleiben. Wir führen Fit-Gap-Workshops durch, um Konfiguration von echten Lücken zu trennen, erstellen disziplinierte Studio-Anpassungen, entwickeln und pflegen eigene Module, wenn sie wirklich nötig sind, und erstellen Anpassungsregister und Upgrade-Testpläne, damit Ihr System wartbar bleibt. Kontaktieren Sie uns über www.1cbms.com, um Ihre bestehenden Anpassungen prüfen zu lassen oder eine neue Implementierung zu planen.