Warum eigene Module statt Eingriffe in den Odoo-Core
Wir entwickeln in Odoo 17, 18 und 19 nach einem klaren Prinzip: Anpassungen entstehen in separaten Modulen, nicht durch Änderungen am Standardquellcode. Über den Mechanismus _inherit erweitern wir Modelle, Views und Geschäftslogik, ohne die Kernklassen zu überschreiben. Ein direkter Fork des Core mag kurzfristig schneller wirken, blockiert aber jedes spätere Update. Bei der Migration auf eine neue Hauptversion müssten Sie dann jede Eigenänderung manuell nachziehen. Saubere Custom-Module bleiben dagegen versionsfähig und lassen sich mit Werkzeugen wie OpenUpgrade gezielt anheben.
Technisch arbeiten wir mit dem Odoo-ORM, dem Frontend-Framework OWL und QWeb-Templates. Schnittstellen realisieren wir über XML-RPC, REST oder Webhooks, etwa zur Anbindung von DATEV, Versanddienstleistern oder Ihrer bestehenden Fachsoftware. KI binden wir direkt im ERP an: belegnahe Extraktion aus Eingangsrechnungen, citation-grounded RAG auf Ihren Stammdaten, Vorschlagslogik in Workflows, betrieben auf offenen Modellen über unsere ESTAYA AI Platform auf eigenen Servern in Deutschland.
Ein typisches Projekt durchläuft Prozessaufnahme, Datenmodell, modulare Umsetzung in Etappen, Testdaten-Migration und Schulung. Das passt zum Mittelstand mit gewachsenen Abläufen, der heute Excel-Tabellen, Access-Datenbanken und Insellösungen ablösen will. Statt Prozesse in fremde Software zu pressen, bilden wir Ihre Logik im Datenmodell ab.
- Erweiterung per _inherit statt Core-Fork, damit Updates möglich bleiben
- Migration zwischen Odoo-Versionen mit OpenUpgrade-Skripten
- Integrationen über XML-RPC, REST und Webhooks
- Ablösung von Excel-, Access- und Insellösungen mit sauberem Datenmodell
- KI im ERP auf offenen Modellen, Daten bleiben im Haus