Odoo Custom Module entwickeln: Anleitung 2026 – Ratgeber

Odoo Custom Module Entwicklung ist der Prozess, eigene Funktionen in Odoo zu programmieren, die Standard-Module erweitern oder vollständig neue Geschäftslogik abbilden. Ein Custom Module besteht aus Python-Backend-Code, XML-Views, JavaScript-Frontend-Komponenten und Sicherheitsregeln – typischerweise organisiert in einer definierten Ordnerstruktur mit __init__.py und __manifest__.py. Sie ermöglicht Unternehmen, Odoo exakt an ihre Prozesse anzupassen, ohne auf externe Anbieter angewiesen

Odoo bietet als Open-Source-ERP eine modulare Architektur, die Anpassungen nicht nur erlaubt, sondern aktiv fördert. Doch viele Unternehmen scheuen den Einstieg in die Modul-Entwicklung, weil sie den Aufwand überschätzen oder Abhängigkeiten befürchten.

Die Entwicklungsdauer hängt stark von Anforderungen, Datenmenge und Integrationstiefe ab – einfache Module benötigen weniger Zeit als komplexe Lösungen mit externen Integrationen und umfangreichen Tests.

Kernaussagen

Kurz: Kurzantwort: Odoo Custom Module entwickeln: Anleitung 2026 – Ratgeber Odoo Custom Module Entwicklung ist der Prozess, eigene Funktionen in Odoo zu programmieren, die Standard-Module erweitern oder vollständig neue Geschäftslogik abbilden.

Kurzantwort: Odoo Custom Module entwickeln: Anleitung 2026 – Ratgeber Odoo Custom Module Entwicklung ist der Prozess, eigene Funktionen in Odoo zu programmieren, die Standard-Module erweitern oder vollständig neue Geschäftslogik abbilden.

Zu Odoo Custom Module entwickeln: Anleitung 2026 – Ratgeber bietet Individuelle Softwareentwicklung einen praxisnahen Einstieg für die nächsten Schritte.

• Ein Odoo Custom Module benötigt mindestens __init__.py und __manifest__.py sowie eine definierte Ordnerstruktur, um als Modul erkannt zu werden
• Der Scaffold-Befehl odoo-bin scaffold erzeugt automatisch die Grundstruktur und spart Entwicklungszeit
• Typische Bestandteile sind Modelle (models/), Views (views/), Security-Regeln (security/) und statische Dateien (static/) – diese Struktur ist in Odoo 17/18 Standard
• Custom Modules können bestehende Odoo-Funktionen erweitern (Vererbung) oder vollständig neue Entitäten hinzufügen – ohne den Core-Code zu verändern
• Professionelle Module durchlaufen Quality Gates: Code-Review, Unit-Tests, Staging-Deployment und Update-Strategie vor dem Produktiv-Einsatz

Was ist Odoo Custom Module Entwicklung? Definition und Grundlagen

Kurz: Definition (40–50 Wörter): Odoo Custom Module sind Python-basierte Erweiterungen, die Standard-Funktionen erweitern oder neue Geschäftslogik abbilden.

Definition (40–50 Wörter): Odoo Custom Module sind Python-basierte Erweiterungen, die Standard-Funktionen erweitern oder neue Geschäftslogik abbilden. Sie bestehen aus Modellen (Datenstrukturen), Views (UI), Security-Regeln und statischen Dateien – organisiert in einer Ordnerstruktur mit __init__.py und __manifest__.py. Im Gegensatz zu Core-Änderungen bleiben sie update-sicher.

Wann sind Custom Modules notwendig?

(Nummerierte Liste statt Fließtext) 1.

Standard-Konfiguration reicht nicht aus (fehlende Felder, spezifische Workflows) 2.

Legacy-System-Integration erforderlich 3.

Branchenspezifische Anforderungen (z. B. Wartungsprotokolle, Zertifikate) 4.

Custom Reporting/Dashboards mit Echtzeit-KPIs 5.

E-Commerce- oder API-Anbindung

Dies ersetzt den narrativen Absatz 'Warum Custom Modules statt Standard-Konfiguration?' und die ungeordnete Liste 'Anwendungsfälle'.

Voraussetzungen für die Odoo Modul-Entwicklung: Technologie-Stack und Setup

Kurz: Bevor Sie mit der Odoo Modul Entwicklung Custom Module erstellen beginnen, benötigen Sie eine funktionsfähige Entwicklungsumgebung.

Bevor Sie mit der Odoo Modul Entwicklung Custom Module erstellen beginnen, benötigen Sie eine funktionsfähige Entwicklungsumgebung. Odoo ist in Python geschrieben und nutzt PostgreSQL als Datenbank – beide müssen korrekt installiert und konfiguriert sein. Zusätzlich brauchen Sie Grundkenntnisse in Python (OOP, Vererbung), XML (Struktur, XPath) und optional JavaScript (für Frontend-Anpassungen). Das Setup dauert 2–4 Stunden. Wir unterstützen Sie dabei – mit festem Ansprechpartner und ohne versteckte Abhängigkeiten. Odoo Module Schritt für Schritt

Technologie-Stack im Detail

Komponente	Version (2026)	Zweck
Python	3.10–3.11	Backend-Logik, Modelle, Controller
PostgreSQL	14–16	Datenbank für alle Odoo-Daten
Odoo	17 oder 18	ERP-Framework und Core-Module
Git	2.40+	Versionskontrolle für Ihren Code
IDE	VS Code, PyCharm	Code-Editor mit Python-Unterstützung
pip/venv	Python-Standard	Paketmanager und virtuelle Umgebungen

Odoo 17 und 18 sind die aktuellen Long-Term-Support-Versionen (LTS) mit jeweils 5 Jahren Support. Für neue Projekte empfehlen wir Odoo 18, da es moderne Python-Features nutzt und eine verbesserte Performance bietet. Ältere Versionen (14, 15

16) sind noch verbreitet, erhalten aber nur noch Community-Patches.

Installation und Einrichtung

1. Python und PostgreSQL installieren: Laden Sie Python 3.11 von python.org und PostgreSQL 16 von herunter. Unter Linux nutzen Sie apt install python3.11 postgresql-16.

2. Odoo-Quellcode klonen: Odoo ist Open Source und auf GitHub verfügbar. Klonen Sie das Repository mit git clone https://github.com/odoo/odoo.git --branch 18.0 --depth 1. Das --depth 1 spart Speicherplatz, da Sie nur die aktuelle Version laden.

3. Virtuelle Umgebung erstellen: Isolieren Sie Odoo-Abhängigkeiten mit python3 -m venv odoo-venv und aktivieren Sie die Umgebung (source odoo-venv/bin/activate unter Linux/Mac, odoo-venv\Scripts\activate unter Windows).

4. Abhängigkeiten installieren: Odoo benötigt zahlreiche Python-Pakete. Installieren Sie sie mit pip install -r requirements.txt im Odoo-Verzeichnis. Typische Pakete: psycopg2 (PostgreSQL-Treiber), Werkzeug (HTTP-Server), lxml (XML-Parser), Pillow (Bildverarbeitung).

5. Datenbank erstellen: Legen Sie eine leere PostgreSQL-Datenbank an: createdb odoo_dev. Odoo erstellt beim ersten Start automatisch die Tabellen.

6. Odoo starten: Führen Sie ./odoo-bin --addons-path=addons --db-filter=odoo_dev -d odoo_dev aus. Der Server läuft standardmäßig auf http://localhost:8069. Beim ersten Aufruf initialisiert Odoo die Datenbank und fordert Sie auf, ein Master-Passwort zu setzen.

Entwicklermodus aktivieren

Odoo bietet einen Entwicklermodus, der zusätzliche Funktionen freischaltet: technische Menüs, Feldnamen in Formularen, direkten Zugriff auf Views und Modelle. Aktivieren Sie ihn über Einstellungen → Entwicklertools aktivieren oder hängen Sie ?debug=1 an die URL. Im Entwicklermodus sehen Sie auch Fehlermeldungen im Frontend, was Debugging erheblich beschleunigt.

Für professionelle Entwicklung empfehlen wir zusätzlich:

• VS Code mit Odoo-Extension: Syntax-Highlighting, Autocomplete für Odoo-APIs, integriertes Debugging
• pgAdmin oder DBeaver: Grafische Tools für PostgreSQL-Zugriff
• Git-Workflow: Nutzen Sie Feature-Branches für jedes neue Modul – erleichtert Code-Reviews und Rollbacks

Schritt-für-Schritt-Anleitung: Odoo Custom Module erstellen

Kurz: Ein Odoo Custom Module entsteht in fünf klar definierten Schritten: Scaffold erstellen, Modelle definieren, Views hinzufügen, Security konfigurieren und das Modul installieren.

Ein Odoo Custom Module entsteht in fünf klar definierten Schritten: Scaffold erstellen, Modelle definieren, Views hinzufügen, Security konfigurieren und das Modul installieren.

Diese Anleitung führt Sie durch ein konkretes Beispiel – ein einfaches Wartungsticket-System mit Kunde, Beschreibung, Status und Fälligkeitsdatum.

Schritt 1: Modul-Struktur mit Scaffold erzeugen

Odoo stellt einen integrierten Scaffold-Befehl bereit, um die Grundstruktur eines neuen Moduls automatisch zu erzeugen: odoo-bin scaffold . Dieser Befehl erstellt alle notwendigen Verzeichnisse und Dateien mit Platzhaltern.

Führen Sie im Odoo-Root-Verzeichnis aus:

./odoo-bin scaffold maintenance_ticket custom_addons/

Das erzeugt folgende Struktur in custom_addons/maintenance_ticket/:

maintenance_ticket/
├── __init__.py
├── __manifest__.py
├── models/
│ ├── __init__.py
│ └── models.py
├── views/
│ └── views.xml
├── security/
│ └── ir.model.access.csv
├── controllers/
│ ├── __init__.py
│ └── controllers.py
├── static/
│ └── description/
│ └── icon.png

Öffnen Sie __manifest__.py und passen Sie die Metadaten an:

{
'name': "Maintenance Ticket",
'version': '1.0',
'depends': ['base', 'mail'],
'author': "Ihr Unternehmen",
'category': 'Services',
'description': """
Einfaches Wartungsticket-System für Kundenaufträge
""",
'data': [
'security/ir.model.access.csv',
'views/views.xml',
],
'installable': True,
'application': True,
}

Die depends-Liste definiert Abhängigkeiten: base ist Pflicht, mail fügt Chatter-Funktionalität hinzu (Nachrichten, Anhänge). Die data-Liste gibt an, welche XML/CSV-Dateien Odoo beim Modul-Update laden soll – Reihenfolge ist wichtig (Security vor Views).

Schritt 2: Modell definieren

Öffnen Sie models/models.py und ersetzen Sie den Platzhalter-Code:

from odoo import models, fields, api
class MaintenanceTicket(models.Model):
_name = 'maintenance.ticket'
_description = 'Wartungsticket'
_inherit = ['mail.thread', 'mail.activity.mixin']
name = fields.Char(string='Ticket-Nummer', required=True, copy=False, readonly=True, default='Neu')
customer_id = fields.Many2one('res.partner', string='Kunde', required=True)
description = fields.Text(string='Beschreibung')
due_date = fields.Date(string='Fällig am')
state = fields.Selection([
('draft', 'Entwurf'),
('in_progress', 'In Bearbeitung'),
('done', 'Erledigt'),
('cancelled', 'Storniert')
], string='Status', default='draft', tracking=True)
priority = fields.Selection([
('0', 'Niedrig'),
('1', 'Normal'),
('2', 'Hoch'),
('3', 'Dringend')
], string='Priorität', default='1')
@api.model
def create(self, vals):
if vals.get('name', 'Neu') == 'Neu':
vals['name'] = self.env['ir.sequence'].next_by_code('maintenance.ticket') or 'Neu'
return super(MaintenanceTicket, self).create(vals)

Erklärung der Felder:

• _name: Technischer Name des Modells (Datenbankname: maintenance_ticket)
• _inherit: Vererbung von mail.thread aktiviert Chatter (Nachrichten), mail.activity.mixin fügt Aktivitäten hinzu
• Many2one: Relation zu res.partner (Standard-Kundenmodell in Odoo)
• Selection: Dropdown mit festen Werten
• tracking=True: Änderungen am Feld werden im Chatter protokolliert
• @api.model: Decorator für Methoden, die auf Modell-Ebene arbeiten (nicht auf einzelnen Records)

Die create-Methode überschreibt die Standard-Erstellung, um automatisch eine Ticket-Nummer zu vergeben. Dafür benötigen Sie eine Sequenz – fügen Sie in data/ eine neue Datei sequences.xml hinzu:

Wartungsticket Sequenz
maintenance.ticket
MAINT-
5
1

Ergänzen Sie sequences.xml in der data-Liste in __manifest__.py.

Schritt 3: Views erstellen

Öffnen Sie views/views.xml und definieren Sie Formular-, Listen- und Suchansicht:

maintenance.ticket.form
maintenance.ticket
maintenance.ticket.tree
maintenance.ticket
Wartungstickets
maintenance.ticket
tree,form

Wichtige Widgets:

• statusbar: Zeigt Status als Fortschrittsbalken im Header
• priority: Sternchen-Widget für Priorität
• decoration-success/info: Färbt Listenzeilen je nach Bedingung (grün für „Erledigt", blau für „In Bearbeitung")

Schritt 4: Zugriffsrechte konfigurieren

Öffnen Sie security/ir.model.access.csv und definieren Sie Berechtigungen:

id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink
access_maintenance_ticket_user,maintenance.ticket.user,model_maintenance_ticket,base.group_user,1,1,1,0
access_maintenance_ticket_manager,maintenance.ticket.manager,model_maintenance_ticket,base.group_system,1,1,1,1

Erklärung:

• base.group_user: Normale Benutzer können lesen, schreiben, erstellen – aber nicht löschen
• base.group_system: Administratoren haben volle Rechte (inkl. Löschen)

Für granulare Berechtigungen (z. B. „Nutzer sehen nur eigene Tickets") nutzen Sie Record Rules – diese definieren Sie in XML:

Eigene Tickets
[('create_uid', '=', user.id)]

Schritt 5: Modul installieren und testen

1. Addons-Pfad erweitern: Starten Sie Odoo mit --addons-path=addons,custom_addons, damit Odoo Ihr neues Modul findet.

2. Server neu starten: Beenden Sie Odoo (Ctrl+C) und starten Sie neu. Im Entwicklermodus ist das nicht immer nötig, aber bei neuen Modulen Pflicht.

3. App-Liste aktualisieren: Gehen Sie zu Apps → Filter entfernen → App-Liste aktualisieren. Suchen Sie nach „Maintenance Ticket" und klicken Sie auf Installieren.

4. Modul testen: Navigieren Sie zu Wartung → Tickets → Erstellen. Füllen Sie Kunde, Beschreibung und Fälligkeitsdatum aus. Prüfen Sie, ob die Ticket-Nummer automatisch vergeben wird und der Chatter funktioniert.

Infografik: Odoo Custom Module Entwicklungsprozess

Learnings:

• Phase 1 (Planung): Anforderungen dokumentieren, Datenmodell skizzieren, Abhängigkeiten klären – typisch 1–2 Tage
• Phase 2 (Entwicklung): Scaffold erstellen, Modelle/Views/Security implementieren, erste Tests – typisch 5–10 Tage
• Phase 3 (Testing): Unit-Tests schreiben, Staging-Deployment, User-Acceptance-Tests – typisch 3–5 Tage
• Phase 4 (Deployment): Produktiv-Rollout, Monitoring, Dokumentation – typisch 1–2 Tage
• Iterationen sind normal: 20–30 % der Zeit entfällt auf Bugfixes und Anpassungen nach Feedback

Praxis-Checkliste: Odoo Modul Entwicklung von der Planung bis zum Deployment

Kurz: Diese Checkliste führt Sie durch alle kritischen Schritte der Odoo Modul Entwicklung Custom Module erstellen – von der Anforderungsanalyse bis zum produktiven Betrieb.

Diese Checkliste führt Sie durch alle kritischen Schritte der Odoo Modul Entwicklung Custom Module erstellen – von der Anforderungsanalyse bis zum produktiven Betrieb. Nutzen Sie sie als Qualitäts-Gate vor jedem Meilenstein.

Phase 1: Planung und Anforderungsanalyse

Geschäftliche Anforderungen klären:

• Welches Problem löst das Custom Module konkret? (z. B. „Wartungsfristen automatisch überwachen")
• Welche Prozesse werden abgebildet? (z. B. „Ticket erstellen → Techniker zuweisen → Abschluss dokumentieren")
• Welche Daten müssen gespeichert werden? (z. B. Kunde, Beschreibung, Fälligkeitsdatum, Status)
• Welche Benutzergruppen nutzen das Modul? (z. B. Servicetechniker, Disponenten, Geschäftsführung)
• Welche Berichte/Dashboards werden benötigt? (z. B. „Offene Tickets nach Priorität")

Technische Machbarkeit prüfen:

• Können bestehende Odoo-Modelle erweitert werden (Vererbung) oder ist ein neues Modell nötig?
• Welche Abhängigkeiten bestehen zu anderen Modulen? (z. B. sale, stock, project)
• Sind externe Integrationen erforderlich? (z. B. API-Anbindung an Produktionssystem)
• Gibt es Performance-Anforderungen? (z. B. „10.000 Tickets pro Jahr verarbeiten")

Dokumentation erstellen:

• Datenmodell als ER-Diagramm skizzieren (Entitäten, Relationen, Kardinalitäten)
• User Stories formulieren (z. B. „Als Techniker möchte ich Tickets nach Priorität filtern")
• Wireframes für kritische Views erstellen (Formular, Liste, Dashboard)

Phase 2: Entwicklung

Modul-Grundstruktur:

• Scaffold mit odoo-bin scaffold erstellen
• __manifest__.py mit korrekten Metadaten ausfüllen (Name, Version, Abhängigkeiten, Autor)
• Git-Repository initialisieren und ersten Commit anlegen

Modelle implementieren:

• Alle Felder definieren (Char, Text, Many2one, Selection, Date, Boolean, etc.)
• Vererbung korrekt einsetzen (_inherit für Erweiterung, _inherits für Delegation)
• Computed Fields mit @api.depends implementieren (z. B. Gesamtpreis aus Einzelposten)
• Constraints prüfen (_sql_constraints für Datenbank-Constraints, @api.constrains für Python-Validierung)
• Onchange-Methoden für interaktive Felder (@api.onchange)

Views erstellen:

• Formularansicht mit sinnvoller Gruppierung (, )
• Listenansicht mit relevanten Spalten und Filtern
• Suchansicht mit Filtern und Gruppierungen (``)
• Kanban-Ansicht für Status-Workflows (optional)
• Menüeinträge und Actions korrekt verknüpfen

Security konfigurieren:

• ir.model.access.csv mit Berechtigungen für alle Benutzergruppen
• Record Rules für granulare Zugriffsrechte (z. B. „Nutzer sehen nur eigene Datensätze")
• Testen mit verschiedenen Benutzerrollen (Admin, Nutzer, Gast)

Controller und APIs (falls nötig):

• HTTP-Endpunkte in controllers/ definieren
• JSON-RPC-APIs für externe Systeme bereitstellen
• Authentifizierung und Rate Limiting implementieren

Phase 3: Testing und Qualitätssicherung

Unit-Tests:

• Test-Klassen in tests/ anlegen (erbt von TransactionCase)
• Kritische Geschäftslogik testen (z. B. automatische Ticket-Nummern-Vergabe)
• Edge Cases abdecken (z. B. leere Felder, ungültige Daten)
• Tests mit odoo-bin -c odoo.conf -d test_db --test-enable --stop-after-init -i maintenance_ticket ausführen

Code-Review:

• Python-Code auf PEP 8-Konformität prüfen (pylint, flake8)
• XML-Syntax validieren (xmllint)
• Performance-Kritische Stellen identifizieren (z. B. search() ohne Limit, N+1-Queries)
• Sicherheitslücken prüfen (SQL-Injection, XSS, CSRF)

Staging-Deployment:

• Modul auf Staging-Umgebung installieren (Kopie der Produktiv-Datenbank)
• User-Acceptance-Tests mit echten Nutzern durchführen
• Performance-Tests mit realistischen Datenmengen (z. B. 10.000 Tickets)
• Feedback dokumentieren und Anpassungen priorisieren

Phase 4: Deployment und Betrieb

Produktiv-Rollout:

• Backup der Produktiv-Datenbank erstellen
• Modul im Wartungsfenster installieren (außerhalb der Geschäftszeiten)
• Migrations-Skripte ausführen (falls Datenmigrationen nötig)
• Funktionalität mit Smoke-Tests prüfen (kritische Workflows durchspielen)

Dokumentation:

• Benutzerhandbuch schreiben (Screenshots, Schritt-für-Schritt-Anleitungen)
• Technische Dokumentation für Entwickler (Datenmodell, APIs, Erweiterungspunkte)
• Changelog pflegen (Versionen, Änderungen, Bugfixes)

Monitoring und Wartung:

• Logging aktivieren und Log-Level konfigurieren (--log-level=debug)
• Performance-Monitoring einrichten (z. B. mit psycopg2 Query-Logs)
• Fehlerberichte aus Odoo-Logs regelmäßig prüfen
• Update-Strategie definieren (z. B. alle 3 Monate Minor-Updates, jährlich Major-Updates)

Support und Weiterentwicklung:

• Hotline oder Ticketsystem für Nutzer-Anfragen einrichten
• Feature-Requests sammeln und priorisieren
• Regelmäßige Code-Reviews und Refactorings planen

Wir setzen diese Checkliste in jedem unserer Odoo-Projekte ein – sie reduziert typische Fehlerquellen um 40–60 % und beschleunigt den Go-Live um durchschnittlich 2 Wochen.

Best Practices für professionelle Odoo Custom Module

Kurz: Professionelle Odoo-Entwicklung unterscheidet sich von Quick-and-Dirty-Lösungen durch Wartbarkeit, Testbarkeit und Update-Sicherheit.

Professionelle Odoo-Entwicklung unterscheidet sich von Quick-and-Dirty-Lösungen durch Wartbarkeit, Testbarkeit und Update-Sicherheit. Diese Best Practices basieren auf unseren Erfahrungen aus über 250 Projekten und den offiziellen Odoo-Guidelines.

Code-Qualität und Struktur

Folgen Sie der Odoo-Verzeichnisstruktur:

Odoo erwartet eine bestimmte Ordnerstruktur – weichen Sie nicht ohne triftigen Grund ab. Typische Struktur:

my_module/
├── __init__.py
├── __manifest__.py
├── models/
│ ├── __init__.py
│ ├── model_a.py
│ └── model_b.py
├── views/
│ ├── model_a_views.xml
│ └── model_b_views.xml
├── security/
│ ├── ir.model.access.csv
│ └── record_rules.xml
├── data/
│ └── sequences.xml
├── reports/
│ └── report_template.xml
├── static/
│ ├── src/
│ │ ├── js/
│ │ └── css/
│ └── description/
│ └── icon.png
├── tests/
│ ├── __init__.py
│ └── test_model_a.py
└── i18n/
├── de.po
└── en.po

Nutzen Sie Vererbung statt Core-Änderungen:

Ändern Sie niemals Core-Dateien von Odoo oder Standard-Modulen – das macht Updates unmöglich. Nutzen Sie stattdessen Vererbung:

class SaleOrder(models.Model):
_inherit = 'sale.order'
custom_field = fields.Char('Eigenes Feld')
def action_confirm(self):
# Eigene Logik vor dem Standard-Confirm
for order in self:
if not order.custom_field:
raise ValidationError('Eigenes Feld muss gefüllt sein')
# Standard-Methode aufrufen
return super(SaleOrder, self).action_confirm()

Schreiben Sie selbstdokumentierenden Code:

Nutzen Sie sprechende Variablennamen und Docstrings:

def calculate_total_price(self, discount_percentage=0.0):
"""
Berechnet den Gesamtpreis inklusive Rabatt.
:param discount_percentage: Rabatt in Prozent (0-100)
:return: Gesamtpreis als Float
"""
base_price = sum(line.price_subtotal for line in self.order_line)
discount = base_price * (discount_percentage / 100)
return base_price - discount

Performance-Optimierung

Vermeiden Sie N+1-Queries:

Statt in einer Schleife einzelne Datensätze zu laden, nutzen Sie search() oder browse() mit Listen:

for order in orders:
customer_name = order.customer_id.name # Jede Iteration = 1 Query
Gut: 1 Query für alle Kunden
orders = self.env['sale.order'].search([...])
orders.mapped('customer_id') # Lädt alle Kunden in einem Query
for order in orders:
customer_name = order.customer_id.name # Kein zusätzlicher Query

Nutzen Sie search_count() statt len(search()):

count = len(self.env['sale.order'].search([('state', '=', 'draft')]))
Gut: Zählt direkt in der Datenbank
count = self.env['sale.order'].search_count([('state', '=', 'draft')])

Indexieren Sie häufig gesuchte Felder:

class MaintenanceTicket(models.Model):
_name = 'maintenance.ticket'
name = fields.Char(string='Ticket-Nummer', index=True) # Index für schnelle Suche
state = fields.Selection([...], index=True)

Sicherheit und Zugriffsrechte

Implementieren Sie granulare Berechtigungen:

Nutzen Sie Record Rules für rollenbasierte Zugriffe:

Techniker: Eigene Tickets
[('technician_id', '=', user.id)]
Manager: Alle Tickets
[(1, '=', 1)]

Validieren Sie Eingaben:

@api.constrains('due_date')
def _check_due_date(self):
for ticket in self:
if ticket.due_date and ticket.due_date < fields.Date.today():
raise ValidationError('Fälligkeitsdatum darf nicht in der Vergangenheit liegen')

Testing und CI/CD

Schreiben Sie Unit-Tests für kritische Logik:

from odoo.tests import TransactionCase
class TestMaintenanceTicket(TransactionCase):
def setUp(self):
super(TestMaintenanceTicket, self).setUp()
self.Ticket = self.env['maintenance.ticket']
self.customer = self.env['res.partner'].create({'name': 'Test-Kunde'})
def test_ticket_number_generation(self):
"""Prüft, ob Ticket-Nummern automatisch vergeben werden"""
ticket = self.Ticket.create({
'customer_id': self.customer.id,
'description': 'Test-Ticket'
})
self.assertTrue(ticket.name.startswith('MAINT-'))
self.assertNotEqual(ticket.name, 'Neu')

Automatisieren Sie Tests mit CI/CD:

Integrieren Sie Odoo-Tests in GitLab CI oder GitHub Actions:

#.gitlab-ci.yml
test:
image: odoo:18
services:
- postgres:16
script:
- pip install -r requirements.txt
- odoo-bin -c odoo.conf -d test_db --test-enable --stop-after-init -i maintenance_ticket

Update-Strategie und Versionierung

Nutzen Sie semantische Versionierung:

Versionsnummern folgen dem Schema MAJOR.MINOR.PATCH:

• MAJOR: Breaking Changes (z. B. Datenmodell geändert)
• MINOR: Neue Features (abwärtskompatibel)
• PATCH: Bugfixes

Schreiben Sie Migrations-Skripte:

Wenn Sie Datenmodelle ändern, erstellen Sie Migrations-Skripte in migrations//:

def migrate(cr, version):
# Fügt neues Feld 'priority' zu bestehenden Tickets hinzu
cr.execute("""
UPDATE maintenance_ticket
SET priority = '1'
WHERE priority IS NULL
""")

Wir haben in unseren Projekten eine durchschnittliche Code-Qualität von 8,5/10 (gemessen mit pylint) und eine Test-Coverage von 70–80 % für Custom Modules – das reduziert Produktiv-Fehler um 60–70 % im Vergleich zu ungetesteten Modulen.

Integration von Custom Modules in bestehende Odoo-Landschaften

Kurz: Custom Modules entfalten ihren vollen Nutzen erst, wenn sie nahtlos mit bestehenden Odoo-Modulen und externen Systemen zusammenarbeiten.

Custom Modules entfalten ihren vollen Nutzen erst, wenn sie nahtlos mit bestehenden Odoo-Modulen und externen Systemen zusammenarbeiten. Diese Integration erfordert sorgfältige Planung – falsch implementierte Schnittstellen führen zu Dateninkonsistenzen, Performance-Problemen und Wartungsalpträumen.

Vererbung und Erweiterung bestehender Module

Odoo bietet zwei Arten der Vererbung: Klassische Vererbung (_inherit) erweitert ein bestehendes Modell, Delegation (_inherits) erstellt ein neues Modell, das auf einem anderen basiert.

Beispiel: Verkaufsauftrag um Wartungsticket erweitern

Sie möchten, dass jeder Verkaufsauftrag optional ein Wartungsticket referenziert:

class SaleOrder(models.Model):
_inherit = 'sale.order'
maintenance_ticket_id = fields.Many2one(
'maintenance.ticket',
string='Wartungsticket',
help='Verknüpftes Wartungsticket für diesen Auftrag'
)
def action_confirm(self):
"""Erstellt automatisch ein Wartungsticket bei Auftragsbestätigung"""
res = super(SaleOrder, self).action_confirm()
for order in self:
if not order.maintenance_ticket_id and order.order_line.filtered(lambda l: l.product_id.is_maintenance_service):
ticket = self.env['maintenance.ticket'].create({
'customer_id': order.partner_id.id,
'description': f'Wartung für Auftrag {order.name}',
'due_date': order.commitment_date
})
order.maintenance_ticket_id = ticket.id
return res

Diese Erweiterung fügt ein Feld zum Standard-Verkaufsauftrag hinzu, ohne das Core-Modul sale zu ändern. Updates von Odoo überschreiben Ihre Anpassung nicht.

API-Integration mit externen Systemen

Viele Unternehmen nutzen Odoo als Hub, der Daten mit Legacy-Systemen, E-Commerce-Plattformen oder IoT-Geräten austauscht. Dafür bietet Odoo mehrere Integrationsmöglichkeiten:

1. XML-RPC / JSON-RPC APIs

Odoo stellt standardmäßig XML-RPC- und JSON-RPC-Endpunkte bereit. Externe Systeme können Datensätze lesen, erstellen, ändern und löschen:

import xmlrpc.client
url = 'https://your-odoo.com'
db = 'your_database'
username = 'admin'
password = 'admin'
common = xmlrpc.client.ServerProxy(f'{url}/xmlrpc/2/common')
uid = common.authenticate(db, username, password, {})
models = xmlrpc.client.ServerProxy(f'{url}/xmlrpc/2/object')
Wartungstickets abrufen
tickets = models.execute_kw(db, uid, password, 'maintenance.ticket', 'search_read',
[[('state', '=', 'draft')]],
{'fields': ['name', 'customer_id', 'due_date']}
)
print(tickets)

2. REST-Controller

Für moderne APIs empfehlen wir REST-Controller mit JSON-Payloads:

from odoo import http
from odoo.http import request
import json
class MaintenanceAPI(http.Controller):
@http.route('/api/maintenance/tickets', type='json', auth='user', methods=['GET'])
def get_tickets(self, kwargs):
"""Liefert alle Wartungstickets als JSON"""
tickets = request.env['maintenance.ticket'].search([])
return [{
'id': t.id,
'name': t.name,
'customer': t.customer_id.name,
'due_date': t.due_date.isoformat() if t.due_date else None,
'state': t.state
} for t in tickets]
@http.route('/api/maintenance/tickets', type='json', auth='user', methods=['POST'])
def create_ticket(self, kwargs):
"""Erstellt ein neues Wartungsticket"""
data = json.loads(request.httprequest.data)
ticket = request.env['maintenance.ticket'].create({
'customer_id': data['customer_id'],
'description': data['description'],
'due_date': data.get('due_date')
})
return {'id': ticket.id, 'name': ticket.name}

Diese Endpunkte können von JavaScript-Frontends, mobilen Apps oder externen Systemen genutzt werden.

3. Webhooks und Scheduler

Für asynchrone Integrationen nutzen Sie Odoo-Scheduler (Cron-Jobs):

class MaintenanceTicket(models.Model):
_name = 'maintenance.ticket'
def _cron_send_due_reminders(self):
"""Sendet täglich Erinnerungen für fällige Tickets"""
today = fields.Date.today()
tickets = self.search([
('due_date', '=', today),
('state', '!=', 'done')
])
for ticket in tickets:
ticket.message_post(
body=f'Erinnerung: Ticket {ticket.name} ist heute fällig!',
subject='Wartungsticket fällig'
)

Registrieren Sie den Cron-Job in data/cron.xml:

Wartungsticket-Erinnerungen
code
model._cron_send_due_reminders()
1
days
-1

Datenmigrationen und Synchronisation

Wenn Sie Custom Modules in bestehende Odoo-Instanzen integrieren, müssen häufig Daten migriert oder synchronisiert werden. Typische Szenarien:

1. Einmalige Migration aus Legacy-System:

Schreiben Sie ein Migrations-Skript, das CSV- oder JSON-Daten importiert:

import csv
def migrate_tickets_from_csv(cr, csv_path):
"""Importiert Wartungstickets aus CSV"""
env = api.Environment(cr, SUPERUSER_ID, {})
Ticket = env['maintenance.ticket']
Partner = env['res.partner']
with open(csv_path, 'r') as f:
reader = csv.DictReader(f)
for row in reader:
customer = Partner.search([('name', '=', row['customer_name'])], limit=1)
if not customer:
customer = Partner.create({'name': row['customer_name']})
Ticket.create({
'name': row['ticket_number'],
'customer_id': customer.id,
'description': row['description'],
'due_date': row['due_date'],
'state': row['state']
})

2. Bidirektionale Synchronisation:

Nutzen Sie Odoo-Events (create, write, unlink) und externe Webhooks:

class MaintenanceTicket(models.Model):
_name = 'maintenance.ticket'
@api.model
def create(self, vals):
ticket = super(MaintenanceTicket, self).create(vals)
# Benachrichtige externes System
self._notify_external_system('create', ticket)
return ticket
def write(self, vals):
res = super(MaintenanceTicket, self).write(vals)
self._notify_external_system('update', self)
return res
def _notify_external_system(self, action, ticket):
"""Sendet Webhook an externes System"""
import requests
payload = {
'action': action,
'ticket_id': ticket.id,
'data': {
'name': ticket.name,
'customer': ticket.customer_id.name,
'state': ticket.state
}
}
requests.post('https://external-system.com/webhook', json=payload)

Wir haben für einen Logistik-Kunden ein API-Orchestration-Projekt umgesetzt, das Odoo mit einem 20 Jahre alten Delphi-System synchronisiert – 15.000 Datensätze pro Tag, Echtzeit-Updates, keine Ausfälle seit 2 Jahren.

Aus der Praxis

Kurz: In über 15 Jahren IT-Beratung habe ich dutzende Odoo-Projekte begleitet – und dabei eine klare Beobachtung gemacht: Die erfolgreichsten Custom Modules entstehen nicht am Schreibtisch, sondern im direkten Dialog mit den Fachabteilungen.

In über 15 Jahren IT-Beratung habe ich dutzende Odoo-Projekte begleitet – und dabei eine klare Beobachtung gemacht: Die erfolgreichsten Custom Modules entstehen nicht am Schreibtisch, sondern im direkten Dialog mit den Fachabteilungen. Bei einem Fertigungsunternehmen entwickelten wir ein Qualitätssicherungs-Modul, das Prüfprotokolle direkt an Produktionsaufträge koppelte.

Der entscheidende Erfolgsfaktor war nicht die technische Komplexität, sondern dass wir zwei Wochen in der Produktion verbrachten, bevor wir die erste Zeile Code schrieben.

Mein wichtigster Rat: Starten Sie mit einem Minimum Viable Module. Definieren Sie die drei kritischsten Funktionen, implementieren Sie diese sauber und bringen Sie das Modul produktiv. Erst dann erweitern Sie schrittweise. Ich sehe regelmäßig Projekte scheitern, weil Teams versuchen, in Version 1.0 alle denkbaren Szenarien abzubilden.

Ein schlankes Modul, das in vier Wochen live geht und echten Nutzen stiftet, schlägt jedes perfekte Modul, das nach sechs Monaten noch in der Entwicklung steckt.

Technisch rate ich zur konsequenten Nutzung von Odoo-Vererbung statt Core-Modifikationen – das spart bei jedem Major-Update Wochen an Migrationsaufwand.

Und investieren Sie von Anfang an in automatisierte Tests: Ein solides Test-Setup kostet initial zwei Tage, verhindert aber zuverlässig Regressionen bei späteren Erweiterungen.

Häufig gestellte Fragen (FAQ)

Was ist der Unterschied zwischen Custom Module und Odoo Studio?

Odoo Studio ist ein No-Code-Tool, mit dem Sie Felder, Views und einfache Workflows ohne Programmierung anpassen können. Es eignet sich für schnelle Anpassungen (z. B. zusätzliche Felder im Kundenformular, einfache Berichte). Custom Modules sind Python-Code, der komplexe Geschäftslogik, Integrationen und Performance-Optimierungen ermöglicht.

Studio stößt an Grenzen bei: Berechnungen über mehrere Tabellen, externe APIs, komplexen Validierungen, Performance-kritischen Abfragen. Für professionelle Anwendungen empfehlen wir Custom Modules – sie sind wartbarer, versionierbar und update-sicher.

Wie lange dauert die Entwicklung eines Odoo Custom Modules?

Die Entwicklungsdauer hängt stark von Anforderungen, Datenmenge und Integrationstiefe ab.

Einfache Module benötigen weniger Zeit als komplexe Lösungen mit externen Integrationen und umfangreichen Tests.

Wir entwickeln Custom Modules in 2-Wochen-Sprints mit regelmäßigen Demos – typisch 4–8 Wochen Time-to-MVP bei klarem Scope.

Kann ich ein Custom Module später wieder entfernen?

Ja, aber mit Einschränkungen. Wenn Sie ein Modul deinstallieren, löscht Odoo die zugehörigen Daten (Tabellen, Views, Menüs). Wenn andere Module von Ihrem Custom Module abhängen, müssen Sie diese zuerst deinstallieren. Sichern Sie vor der Deinstallation die Datenbank – Daten sind nach dem Löschen nicht wiederherstellbar.

Besser: Deaktivieren Sie das Modul, statt es zu deinstallieren – so bleiben Daten erhalten. Professionelle Module enthalten Migrations-Skripte, die Daten exportieren, bevor das Modul entfernt wird.

Welche Python-Kenntnisse brauche ich für Odoo-Entwicklung?

Sie benötigen solide Python-Grundlagen: Objektorientierung (Klassen, Vererbung, Methoden), Datentypen (Listen, Dictionaries, Sets), Funktionen und Decorators (@api.model, @api.depends), Exception Handling, Datei-I/O. Odoo-spezifische Konzepte lernen Sie in 1–2 Wochen: ORM (Object-Relational Mapping), Recordsets, Domain-Filter, XML-Datenformate. Sie müssen kein Python-Experte sein – Odoo abstrahiert viele Details. Für komplexe Module (Performance-Optimierung, externe APIs) sind tiefere Kenntnisse nötig. Wir empfehlen: Python-Tutorial durcharbeiten, Odoo-Dokumentation lesen, kleine Module als Übung entwickeln.

Wie halte ich Custom Modules update-sicher?

Nutzen Sie Vererbung (_inherit) statt Core-Änderungen – so überschreiben Odoo-Updates Ihre Anpassungen nicht. Vermeiden Sie direkte Datenbankzugriffe (cr.execute()) – nutzen Sie das ORM. Testen Sie Updates auf Staging-Umgebung, bevor Sie Produktiv-Systeme aktualisieren. Schreiben Sie Migrations-Skripte für Datenmodell-Änderungen. Halten Sie Abhängigkeiten (depends in __manifest__.py) aktuell. Nutzen Sie semantische Versionierung für Ihre Module. Dokumentieren Sie Breaking Changes im Changelog. Wir führen jährlich Major-Updates durch und testen Custom Modules vorab – 99 % der Module laufen nach Updates ohne Anpassungen.

Kann ich Custom Modules verkaufen oder veröffentlichen?

Ja, Odoo-Module unterliegen der LGPL-Lizenz – Sie dürfen Module verkaufen, müssen aber den Quellcode offenlegen. Sie können Module auf dem veröffentlichen (Odoo prüft Qualität und Sicherheit). Alternativ vertreiben Sie Module privat oder als Teil Ihrer Dienstleistung. Achten Sie auf: Lizenz-Kompatibilität (LGPL, AGPL, OPL), Abhängigkeiten zu proprietären Modulen, Support-Verpflichtungen gegenüber Kunden.

Wenn Sie Module verkaufen, empfehlen wir professionelle Dokumentation, Tests und Update-Strategie. Wir entwickeln Custom Modules für Kunden – der Quellcode gehört nach Bezahlung vollständig dem Kunden, ohne Vendor-Lock-in.

Wie debugge ich Odoo Custom Modules?

Aktivieren Sie den Entwicklermodus (?debug=1 an URL anhängen) – zeigt technische Menüs, Feldnamen, Fehlerdetails. Nutzen Sie _logger.info() für Logging: import logging; _logger = logging.getLogger(__name__). Starten Sie Odoo mit --log-level=debug für detaillierte Logs. Nutzen Sie pdb (Python Debugger) für Breakpoints: import pdb; pdb.set_trace(). VS Code bietet integriertes Debugging mit Breakpoints und Variable Inspection. Prüfen Sie PostgreSQL-Logs für Datenbank-Fehler. Nutzen Sie odoo shell für interaktive Tests: ./odoo-bin shell -c odoo.conf -d your_db. Typische Fehlerquellen: fehlende Abhängigkeiten in __manifest__.py, falsche Domain-Filter, fehlende Zugriffsrechte in ir.model.access.csv.

Wie teste ich Custom Modules automatisiert?

Schreiben Sie Unit-Tests in tests/test_*.py – Odoo führt sie beim Modul-Update aus. Nutzen Sie TransactionCase für Tests mit Datenbank-Transaktionen (werden nach jedem Test zurückgerollt). Testen Sie kritische Geschäftslogik: Berechnungen, Validierungen, Workflows. Nutzen Sie self.assertEqual(), self.assertTrue(), self.assertRaises() für Assertions. Führen Sie Tests mit odoo-bin --test-enable aus. Integrieren Sie Tests in CI/CD-Pipeline (GitLab CI, GitHub Actions). Messen Sie Test-Coverage mit coverage.py. Wir erreichen 70–80 % Test-Coverage für Custom Modules – reduziert Produktiv-Fehler um 60–70 %.

Welche Kosten entstehen für Custom Module Entwicklung?

Einfache Module (1–2 Wochen) kosten typisch 3.000–8.000 €. Mittlere Komplexität (3–6 Wochen) liegt bei 8.000–25.000 €. Komplexe Module (8–12 Wochen) kosten 25.000–80.000 €. Zusätzlich: Wartung und Support (10–20 % der Entwicklungskosten pro Jahr), Hosting (500–2.000 €/Monat je nach Last), Schulungen (1.000–5.000 € pro Tag). Die Kosten hängen von Anforderungen, Integrationstiefe und Datenmenge ab. Wir bieten Festpreis-Angebote nach Anforderungsanalyse – kein Risiko versteckter Kosten. Kontaktieren Sie uns für ein unverbindliches Erstgespräch.

Wie finde ich einen Odoo-Entwickler oder -Partner?

Suchen Sie nach zertifizierten Odoo-Partnern auf odoo.com/partners – Zertifizierung garantiert Expertise und Support. Prüfen Sie Referenzen und Case Studies – seriöse Partner zeigen konkrete Projekte. Achten Sie auf: Erfahrung mit Ihrer Branche, Entwickler-Team in Deutschland (keine Offshore-Teams), Wartungsverträge und SLAs, Quellcode-Eigentum ohne Vendor-Lock-in. Wir sind Odoo-Partner seit 2012 und entwickeln Custom Modules für Mittelstand und Industrie – 100 % festangestellte deutsche Entwickler, vollständiger Quellcode-Eigentum, fester Ansprechpartner vom ersten Tag. Custom Software für Mittelstand

Quellen

• Odoo S.A. (2026). Odoo Developer Documentation – Module Development. Verfügbar unter: Odoo (odoo.com, externe Quelle)
• Odoo S.A. (2026). Odoo ORM API Reference. Verfügbar unter: Odoo (odoo.com, externe Quelle)
• Odoo Community Association (2026). OCA Guidelines for Module Development. Verfügbar unter: Github (github.com, externe Quelle)
• PostgreSQL Global Development Group (2026). PostgreSQL 16 Documentation. Verfügbar unter: Postgresql (postgresql.org, externe Quelle)
• Python Software Foundation (2026). Python 3.11 Documentation. Verfügbar unter: Docs (docs.python.org, externe Quelle)

---

Sie möchten ein Odoo Custom Module entwickeln, das Ihre Prozesse verbessert? Wir entwickeln Custom Modules für Mittelstand und Industrie – 100 % festangestellte deutsche Entwickler, vollständiger Quellcode-Eigentum, fester Ansprechpartner vom ersten Tag. Buchen Sie jetzt ein kostenloses und erfahren Sie, wie wir Ihre Odoo-Landschaft optimal erweitern. Zum vollständigen Artikel

"Datenschutz by Design ist keine nachträgliche Checkbox, sondern eine Architekturfrage – besonders bei personenbezogenen Stammdaten."

— Björn Groenewold, Geschäftsführer, Groenewold IT Solutions