Ausgangslage
Im Unternehmen war Microsoft Dynamics NAV 2018 (Navision) über Jahre als zentrales ERP gewachsen und verwaltet Stammdaten, Produkte, Angebote, Aufträge, Rechnungen und Gutschriften. Der Vertrieb sollte parallel auf Zoho CRM umziehen, weil das ERP für die tägliche Vertriebsarbeit zu schwerfällig war. Damit lagen plötzlich zwei führende Systeme nebeneinander, die dieselben Kunden- und Belegdaten betreffen — ohne dass eine Standard-Schnittstelle die beiden Welten zuverlässig und in Echtzeit verbinden konnte.
Die Herausforderung
Die zentrale Frage war nicht nur, wie Daten zwischen NAV und Zoho CRM fliessen, sondern auch, welches System bei widersprüchlichen Änderungen gewinnt. NAV spricht ausschliesslich SOAP/XML über exponierte Web-Services, Zoho CRM dagegen REST/JSON über die API v8 im EU-Datacenter — zwei sehr unterschiedliche technische Welten, die sauber aufeinander abgebildet werden mussten. Hinzu kam, dass der Sync bidirektional sein sollte und das Unternehmen sich perspektivisch einen Wechsel von NAV auf Business Central offenhalten wollte.
- Zwei führende Systeme nebeneinander (ERP für Belege, CRM für Vertrieb)
- Unterschiedliche Protokolle: NAV via SOAP/XML, Zoho CRM via REST/JSON (API v8, EU-DC)
- Bidirektionaler Sync über mehrere Entitäten hinweg (Accounts, Kontakte, Produkte, Angebote, Aufträge, Rechnungen, Gutschriften)
- Klare Konfliktregeln nötig — welches System gewinnt bei gleichzeitiger Änderung?
- Status-Writeback (z. B. Angebotsstatus aus dem CRM zurück nach NAV)
- Vermeidung von Sync-Schleifen und doppelten Datensätzen
- Spätere Migration auf Business Central sollte ohne kompletten Neubau möglich sein
Die Lösung
Es entstand eine eigene Python-Middleware, die als Brücke zwischen NAV und Zoho CRM dient. Sie übersetzt zwischen den beiden Protokollwelten, hält über eine PostgreSQL-Datenbank den Sync-Zustand jedes Datensatzes nach und steuert eine definierte Conflict-Resolution. So arbeitet der Vertrieb durchgängig im CRM, während Buchhaltung und Auftragsabwicklung im ERP bleiben — beide Systeme sehen denselben, konsistenten Datenstand. Architektonisch wurde die Middleware bewusst adapter-basiert (hexagonal) aufgebaut, damit das ERP später gegen Business Central getauscht werden kann, ohne die gesamte Synchronisationslogik neu zu schreiben.
Technische Umsetzung
Im Kern steht eine in Python entwickelte Middleware, die als Docker-Container betrieben wird und ihren Sync-Zustand in einer PostgreSQL-Datenbank verwaltet. Auf der ERP-Seite kommuniziert sie über die SOAP/XML-Web-Services von NAV 2018, auf der CRM-Seite über die REST/JSON-API v8 von Zoho im EU-Datacenter. Ein zentrales Mapping bildet die unterschiedlichen Datenmodelle aufeinander ab, eine State-Tabelle erkennt Änderungen und verhindert Schleifen. Die hexagonale Architektur trennt die fachliche Sync-Logik strikt von den system-spezifischen Adaptern.
- Python-Middleware, containerisiert via Docker, State-Tracking in PostgreSQL
- ERP-Adapter über die SOAP/XML-Web-Services von Dynamics NAV 2018
- CRM-Adapter über die Zoho-CRM-REST-API v8 (JSON, EU-Datacenter)
- Bidirektionaler Sync von Accounts, Kontakten, Produkten, Angeboten, Aufträgen, Rechnungen und Gutschriften
- Definierte Conflict-Resolution mit Vorrangregeln und Status-Writeback nach NAV
- Schleifen- und Dubletten-Vermeidung über persistentes State-Tracking und eindeutige Referenzen
- Hexagonale, adapter-basierte Architektur als Vorbereitung auf einen späteren Wechsel zu Business Central
Ergebnis
Die Middleware verbindet heute NAV und Zoho CRM im laufenden Betrieb. Die doppelte Datenerfassung zwischen ERP und CRM entfällt, Stammdaten sind in beiden Systemen konsistent, und jeder Bereich arbeitet dort, wo es am besten passt — der Vertrieb im CRM, die Buchhaltung im ERP, automatisch synchron. Über die definierte Conflict-Resolution ist nachvollziehbar, welcher Stand bei widersprüchlichen Änderungen gilt, statt dass Daten still überschrieben werden. Durch die adapter-basierte Architektur bleibt der Weg zu einer künftigen Business-Central-Migration offen, ohne die Schnittstelle komplett neu bauen zu müssen.
Nutzen für den Kunden
- Schluss mit doppelter Datenerfassung zwischen ERP und CRM
- Stammdaten in NAV und Zoho CRM konsistent gehalten
- Vertrieb arbeitet im CRM, Buchhaltung im ERP — automatisch synchron
- Nachvollziehbare Conflict-Resolution statt stiller Überschreibungen
- Bidirektionaler Sync über alle relevanten Belegarten hinweg
- Robuster produktiver Betrieb dank persistentem State-Tracking
- Zukunftssicher durch hexagonale Architektur — Wechsel auf Business Central ohne Neubau möglich