Odoos größte Stärke ist gleichzeitig sein größtes Risiko: die Anpassbarkeit. Richtig eingesetzt, formt es sich exakt um Ihre Prozesse. Falsch eingesetzt, entsteht ein System, das bei jedem Update auseinanderfällt.
Die drei Ebenen des Odoo Customizing
Ebene 1: Konfiguration (kein Code)
Odoo bietet innerhalb der Module umfangreiche Einstellungen: Felder ein-/ausblenden, Workflows anpassen, Automatisierungen definieren, Berichte gestalten. Das Studio-Modul erlaubt sogar Drag-and-Drop-Anpassungen der Benutzeroberfläche.
Vorteil: Keine Entwicklung nötig, upgrade-sicher, sofort wirksam.
Grenze: Nur möglich, was die Konfiguration hergibt. Komplexe Logik oder komplett neue Prozesse gehen so nicht.
Ebene 2: Custom Module (eigener Code, sauber getrennt)
Ein eigenes Modul erweitert bestehende Funktionen, ohne den Kern-Code zu verändern. Es "erbt" von bestehenden Models und Views und fügt neue Felder, Logik oder Ansichten hinzu.
Vorteil: Upgrade-fähig, da der Kern-Code unverändert bleibt. Das Custom Module wird separat gepflegt.
Grenze: Erfordert Odoo-Entwicklungskompetenz. Schlecht geschriebene Module können trotzdem Upgrade-Probleme verursachen.
Ebene 3: Kern-Modifikation (direkt am Quellcode)
Den Original-Code von Odoo-Modulen verändern. Das passiert, wenn ein Entwickler "schnell mal" etwas im Quellcode anpasst, statt ein eigenes Modul zu schreiben.
Vorteil: Schnell.
Nachteil: Jedes Upgrade überschreibt die Änderungen. Die Modifikationen müssen bei jedem Update manuell nachgezogen werden. Das ist der häufigste Grund, warum Odoo-Installationen auf veralteten Versionen feststecken.
Fünf Regeln für nachhaltiges Customizing
1. Konfiguration vor Code. Prüfen Sie zuerst, ob die gewünschte Anpassung per Konfiguration oder Studio möglich ist. 60% der Anforderungen lassen sich ohne eine Zeile Code umsetzen.
2. Immer eigene Module. Jede Code-Änderung gehört in ein eigenes Modul. Nie den Kern verändern. Das gilt auch für "kleine" Anpassungen — die wachsen erfahrungsgemäß.
3. Odoo-Conventions folgen. Vererbung (inherit) statt Override. XML-IDs statt Hardcoded-Werte. ORM statt Raw SQL. Wer gegen Odoo-Konventionen arbeitet, baut technische Schulden auf.
4. Tests schreiben. Jedes Custom Module braucht Unit Tests. Vor einem Upgrade werden alle Tests ausgeführt — Fehler werden sofort sichtbar, nicht erst im Live-Betrieb.
5. Upgrade-Plan von Tag 1. Odoo veröffentlicht jährlich eine neue Major-Version. Planen Sie von Anfang an, wie Ihre Custom Module migriert werden. Budget und Zeitfenster dafür reservieren.
Typische Customizing-Projekte und Aufwand
| Anpassung | Ebene | Aufwand |
|---|---|---|
| Neue Felder in Formularen | Konfiguration/Studio | 1–4 Stunden |
| Automatisierte E-Mail bei Statuswechsel | Konfiguration | 2–4 Stunden |
| Custom Report / PDF-Layout | Custom Module | 8–24 Stunden |
| Neue Geschäftslogik (z.B. Rabattstaffel) | Custom Module | 16–40 Stunden |
| Schnittstelle zu externem System | Custom Module | 24–80 Stunden |
| Komplett neues Modul (neuer Prozess) | Custom Module | 40–160 Stunden |
Community-Module: Chance und Risiko
Der Odoo App Store enthält über 40.000 Community-Module. Viele sind gut, einige brillant, manche gefährlich. Vor der Installation prüfen:
- Letzte Aktualisierung: Ist das Modul für die aktuelle Odoo-Version gepflegt?
- Downloads/Bewertungen: Weit verbreitete Module haben mehr Community-Support
- Code-Qualität: Ein Blick in den Quellcode zeigt, ob Conventions eingehalten werden
- OCA-Module bevorzugen: Die Odoo Community Association pflegt qualitätsgeprüfte Module
Fazit
Odoo Customizing ist mächtig — wenn es richtig gemacht wird. Die goldene Regel: So viel Konfiguration wie möglich, so wenig Code wie nötig, und jede Zeile Code in einem eigenen Modul. Wer das beherzigt, hat ein System, das mit dem Unternehmen wächst und bei jedem Upgrade mitzieht.