Massgeschneiderte Odoo-Entwicklung

Eine Odoo-Entwicklung ist nie ein rein technischer Vorgang, wenn sie die Fakturierung, die MwSt, die Löhne oder die Buchhaltung betrifft. Sie bindet das Unternehmen langfristig, mit Schweizer gesetzlichen Pflichten, die sich nicht mit einem Pflichtenheft verhandeln lassen. Auf dem Westschweizer Markt stellt diese Realität oft zwei Profile gegenüber: Integratoren, die den Odoo-Code beherrschen, ohne den Schweizer Kontenplan, die QR-Rechnung oder die Swissdec-Normen zu kennen; und Treuhandgesellschaften, die die Buchhaltung beherrschen, aber selbst nichts entwickeln und jede Individualisierungsanfrage an einen Dritten weiterreichen. AX-Fiduciaire, offizieller Odoo-Partner, vereint beide Kompetenzen im selben Team: die Entwicklung (Module, Felder, Workflows, Berichte, Konnektoren) und die Treuhandexpertise (Buchhaltung, MwSt, Löhne, Schweizer Konformität). Diese Seite stellt unsere massgeschneiderte Odoo-Entwicklung vor: was sie abdeckt, die verfolgte Methode und die Grenzen, die wir uns selbst setzen.

Wann sich eine massgeschneiderte Entwicklung rechtfertigt

Odoo Standard deckt einen grossen Teil des Verwaltungsbedarfs eines KMU ab: Buchhaltung, Fakturierung, Einkauf, Lager, Verkauf, Personalwesen. Ein Teil dieses Bedarfs lässt sich ohne eine Zeile Code lösen, durch Konfiguration oder durch Odoo Studio. Eine massgeschneiderte Entwicklung rechtfertigt sich erst, wenn diese Optionen ausgeschöpft sind: ein wirklich unternehmensspezifischer Geschäftsprozess, eine Geschäftsregel, die der Standard nicht vorsieht, ein Konnektor zu einem externen System, der in keiner Modulform existiert, oder ein Dokument, dessen Struktur keinem mitgelieferten Vorlagenmodell entspricht.

Umgekehrt rechtfertigt sich eine Entwicklung nicht, wenn:

• der Bedarf bereits durch die Standardkonfiguration abgedeckt ist (zusätzliche Felder, Fakturierungsregeln, Sequenzen, Zugriffsrechte);
• Odoo Studio erlaubt, das Feld, die Ansicht oder die Automatisierung hinzuzufügen, ohne den Quellcode zu berühren;
• ein bestehendes OCA-Modul (Odoo Community Association) den Bedarf erfüllt, mit dem Vorteil, von einer Community statt von einem einzigen Anbieter gepflegt zu werden;
• der eigentliche Bedarf eine Änderung der Arbeitsgewohnheit ist, keine Grenze der Software.

Diese Disziplin bedingt das langfristige Überleben der Entwicklung. Ein Modul, das hinzugefügt wurde, um eine Gewohnheit nachzubilden, statt auf eine reale Anforderung zu reagieren, wird beim ersten grösseren Versionsupgrade zu einem zusätzlichen Arbeitsposten ohne klare Rechtfertigung. Das entscheidende Kriterium ist nicht die Anzahl der Funktionen, die eine Entwicklung hinzufügen kann, sondern ihre Fähigkeit, künftige Odoo-Versionen zu überstehen. Odoo 19 ist die aktuelle stabile Version; Odoo 20 wird am 24. September 2026 vorgestellt. Jede massgeschneiderte Entwicklung muss auf diese Kontinuität ausgelegt sein, nicht nur auf die Erfüllung des heutigen Bedarfs.

Diese Frage stellt sich mit besonderer Schärfe, sobald ein Modul die Buchhaltung, die MwSt oder die Lohnbuchhaltung betrifft. Ein zu einer Rechnung hinzugefügtes Feld, eine in einen Freigabe-Workflow eingefügte Berechnungsregel oder eine Automatisierung, die eine Buchung verändert, sind nie belanglose Entwicklungen: Sie laufen bei jeder Transaktion, oft ohne direkte menschliche Überwachung. Die Frage vor jeder Entwicklung lautet also nicht nur «ist es möglich», sondern «bleibt diese Entwicklung in zwei Jahren korrekt, mit einem anderen Team, auf einer anderen Odoo-Version». Diese Frage, mehr als die technische Machbarkeit, unterscheidet eine sinnvolle Entwicklung von einer, die zu einem Problem wird.

Was in Odoo entwickelt werden kann

Die massgeschneiderte Entwicklung in Odoo umfasst mehrere Ebenen, von der einfachsten bis zur strukturierendsten. Sie werden oft in ein und demselben Projekt kombiniert: Ein Konnektor geht fast immer mit einem neuen Datenmodell einher, um das Empfangene zu speichern, ein Workflow verändert meist eine Ansicht, um lesbar zu bleiben.

Module

Ein Odoo-Modul bündelt ein kohärentes Set an Funktionen: Datenmodelle, Ansichten, Geschäftsregeln, Zugriffsrechte. Ein massgeschneidertes Modul installiert sich neben den Standardmodulen, ohne sie zu verändern, was die Auswirkung auf künftige Versionsupgrades begrenzt. Das ist die Ebene, die wir standardmässig bevorzugen, statt direkt in den Code der von Odoo gelieferten Module einzugreifen.

Felder und Modelle

Ein Feld zu einem bestehenden Formular hinzufügen, ein neues Datenmodell erstellen, um eine unternehmensspezifische Information zu erfassen (eine Dossiernummer, eine interne Kategorie, einen spezifischen Status), und diese Informationen mit bestehenden Modellen verknüpfen — Kunden, Rechnungen, Bestellungen, Mitarbeitende. Das ist oft der Ausgangspunkt einer umfangreicheren Entwicklung: Sobald die Information gespeichert ist, muss sie angezeigt, gefiltert und manchmal in einem Dokument ausgegeben werden.

Ansichten

Die Anzeige eines Formulars, einer Liste oder eines Dashboards an den tatsächlichen Arbeitsablauf des Teams anpassen, ohne die Standardoberfläche mit für andere Nutzer unnötigen Optionen zu überladen. Eine schlecht durchdachte, für einen einzigen Arbeitsplatz hinzugefügte Ansicht stört am Ende oft alle anderen.

Workflows und Automatisierungen

Eine Abfolge von Schritten automatisieren — Validierung, Benachrichtigung, Statuswechsel — gemäss unternehmensspezifischen Regeln, innerhalb der Grenzen, in denen die Automatisierung für einen Menschen verständlich und korrigierbar bleibt. Eine undurchsichtige Automatisierung, die niemand erklären oder korrigieren kann, stellt ein grösseres Risiko dar als der Zeitgewinn, den sie bringt.

Berichte und Dokumente

Gedruckte oder PDF-Dokumente (Rechnungen, Abrechnungen, Lieferscheine, Analyseberichte) gestalten, die einem bestimmten Erscheinungsbild oder einer bestimmten Informationsstruktur entsprechen, dabei aber stets aus den tatsächlichen Odoo-Daten generiert werden, nie aus einer parallelen Quelle, die Gefahr liefe, davon abzuweichen.

Konnektoren und API

Odoo mit einem externen System verbinden — Bank, Kasse, E-Commerce-Plattform, branchenspezifisches Fachwerkzeug — über die Odoo-API (je nach Fall XML-RPC, JSON-RPC oder REST) oder über dedizierte Konnektoren für Schweizer Zahlungsstandards, ISO 20022 und QR-Rechnung. Ein schlecht isolierter Konnektor kann eine ganze Synchronisation wegen eines kleinen Fehlers im externen System scheitern lassen; die weiter unten beschriebene Wirkungsanalyse dient genau dazu, dieses Risiko zu begrenzen.

Portale

Einen begrenzten, gesicherten Zugang für Dritte öffnen — Kunden, Lieferanten, Mitarbeitende —, um Dokumente einzusehen oder hochzuladen, ohne ihnen Zugang zur vollständigen Verwaltungsoberfläche zu geben. Die Zugriffsrechte des Portals müssen mit derselben Sorgfalt definiert werden wie die eines internen Nutzers.

Die Methode für jede Entwicklung

Eine Odoo-Entwicklung, die Verwaltungsdaten betrifft, folgt unabhängig von ihrer Grösse einer festen Arbeitsabfolge.

Zwei Schritte dieser Methode werden von Integratoren, die die Schweizer Buchhaltung nicht kennen, oft vernachlässigt: die Wirkungsanalyse, die eine Lektüre der buchhalterischen und steuerlichen Folgen der Entwicklung einschliessen muss, und die Abnahme, die von einer Person validiert werden muss, die beurteilen kann, ob das erzielte Ergebnis buchhalterisch korrekt ist, nicht nur funktional.

Die Schweizer Besonderheit: was die doppelte Kompetenz verändert

Eine Entwicklung, die die Buchhaltung, die MwSt oder die Lohnbuchhaltung betrifft, ist nie eine neutrale Entwicklung. Sie muss den vom Unternehmen gewählten Kontenplan, die auf jede Geschäftsart angewandten Steuerpositionen, die Struktur der QR-Rechnung, den Zahlungsstandard ISO 20022 und die Swissdec-Anforderungen für die Lohnverwaltung einhalten. Ein Feld, das ohne Rücksicht auf diese Vorgaben hinzugefügt wird, kann eine falsche Buchung, eine falsche MwSt-Position oder eine nicht konforme QR-Rechnung erzeugen.

Odoo installiert automatisch die Schweizer Lokalisierung (Modul l10n_ch), sobald die Gesellschaft in der Schweiz konfiguriert ist, was eine korrekte Basis für den Kontenplan und die MwSt-Sätze legt — 8,1 %, 2,6 % und 3,8 % seit dem 1. Januar 2024. Diese Standardbasis entbindet nicht davon, bei jeder Entwicklung zu prüfen, dass die Individualisierung mit ihr übereinstimmt, statt sie zu umgehen.

Bei der Lohnbuchhaltung ist Odoo im Swissdec-Register auf der Stufe «swissdec certified basic» gelistet (Zertifikat Nr. 1203.25, für ELM 5.3, geprüft am 22.09.2026). Eine Entwicklung, die die Berechnung oder Übermittlung von Löhnen betrifft, muss diesen Zertifizierungsrahmen einhalten: Das ist kein Bereich, in dem man sich eine vom zertifizierten Standard abweichende Anpassung erlauben kann. Genau an diesem Schnittpunkt zählt die doppelte Kompetenz von AX-Fiduciaire: gleichzeitig zu verstehen, was der Code tun muss, und was das Schweizer Recht von diesem Ergebnis verlangt. Unsere Entwicklungen, die die Buchhaltung betreffen, sind mit unserem Angebot Odoo Buchhaltung verzahnt; jene, die die Löhne betreffen, mit unserem Angebot Odoo Lohn und HR.

Eine Entwicklung über die Zeit erhalten

Eine gelieferte Entwicklung ist keine abgeschlossene Entwicklung. Sie lebt mit dem Rest des Systems und muss mit dessen Weiterentwicklungen kompatibel bleiben. Das ist ein Punkt, den Projekte, die nur auf die anfängliche Inbetriebnahme ausgerichtet sind, oft vernachlässigen: Die Kosten einer Entwicklung bemessen sich nicht nur an ihrer Lieferung, sondern daran, was ihre Wartung über mehrere aufeinanderfolgende Versionen kostet.

• Versionsupgrades: Jede neue Hauptversion von Odoo kann APIs, Modelle oder Ansichten verändern, auf die sich ein massgeschneidertes Modul stützt. Ein gut konzipiertes Modul, ohne Änderung der Standardmodule, begrenzt dieses Risiko, ohne es zu beseitigen. Siehe unser Angebot Odoo-Migration.
• Technische Schulden: Jede zusätzliche Entwicklung vergrössert die zu wartende Fläche. Eine nicht dokumentierte, nicht getestete oder mit dem Standard redundante Entwicklung wird zu einer sich ansammelnden Last.
• Regressionstests: Bei jedem Update prüfen, dass bestehende Entwicklungen wie vorgesehen weiterfunktionieren.
• Dokumentation: festhalten, was entwickelt wurde, warum und nach welchen Geschäftsregeln, damit ein anderer Entwickler die Arbeit übernehmen kann, ohne die ursprünglichen Absichten erraten zu müssen.
• Reversibilität: Eine Entwicklung muss deaktiviert oder entfernt werden können, ohne den Rest des Systems zu beschädigen, falls der ursprüngliche Bedarf entfällt.

Diese langfristige Begleitung ist Teil unseres Angebots Odoo-Support, das sowohl Standardmodule als auch von AX-Fiduciaire realisierte Entwicklungen abdeckt.

Eine bestehende Entwicklung eines anderen Anbieters übernehmen

Wir intervenieren auch bei Odoo-Entwicklungen, die von einem früheren Anbieter realisiert wurden, sei es zur Korrektur einer Anomalie, zur Vorbereitung eines Versionsupgrades oder zur Übernahme der Wartung eines Systems, dessen ursprünglicher Anbieter nicht mehr verfügbar ist. Diese Übernahme beginnt stets mit einer Analyse des bestehenden Codes: was er tatsächlich tut, wie er aufgebaut wurde, ob er Standardmodule verändert oder in separaten Modulen lebt, und welche Risiken er für künftige Versionsupgrades birgt.

Diese Analyse kann zeigen, dass eine bestehende Entwicklung solide ist und unverändert beibehalten werden sollte, dass sie vor jedem weiteren Eingriff dokumentiert werden muss, oder dass sie teilweise überarbeitet werden muss, weil sie Standardmodule direkt verändert oder eine Buchhaltungsregel umgeht. In jedem Fall erfolgt die Übernahme auf Basis dessen, was besteht, nicht einer systematischen Neuschreibung.

Diese Art des Eingriffs ist häufig nach einem Versionsupgrade, das inkompatibel gewordene Entwicklungen offenlegt, oder wenn eine Entwicklung, die die Buchhaltung oder die Lohnbuchhaltung betrifft, von einem Anbieter ohne Treuhandexpertise realisiert wurde und inhaltlich, nicht nur formal, überprüft werden muss.

Was AX-Fiduciaire nicht tut

Diese Grenzen werden bereits bei der Bedarfsklärung gesetzt, nicht erst im Projektverlauf entdeckt.

• Entwickeln, was der Standard bereits abdeckt. Wenn eine Konfiguration, eine native Option oder ein bestehendes OCA-Modul den Bedarf erfüllt, schlagen wir keine massgeschneiderte Entwicklung als Ersatz vor.
• Eine Buchhaltungs-, Steuer- oder Lohnregel durch Code umgehen. Eine Entwicklung dient nie dazu, ein Ergebnis zu erzeugen, das vom Kontenplan, den MwSt-Positionen oder den geltenden Swissdec-Anforderungen abweicht.
• Ohne Tests liefern. Eine Entwicklung, die Verwaltungsdaten betrifft, durchläuft ausnahmslos Funktionstests und Regressionstests vor der Inbetriebnahme.