Legacy-ERP anbinden: Navision 2009 mit modernen Systemen verbinden

Kann ein Legacy-ERP mit einem modernen Shop zusammenarbeiten?

Ja, wenn die benötigten Geschäftsvorgänge über eine belastbare Schnittstelle erreichbar sind.

Ein moderner Shop kann seine Daten an einen Adapter übergeben, der sie in das Format und die Abläufe des älteren ERP übersetzt. Das löst jedoch weder fehlende Stammdaten noch eine nicht mehr tragfähige Betriebsumgebung.

Prüfen Sie zuerst den Engpass: Soll lediglich ein neuer Verkaufskanal hinzukommen, oder scheitern bereits Einkauf, Lager und Auftragsbearbeitung am bestehenden ERP? Im ersten Fall kann eine begrenzte Brücke sinnvoll sein. Im zweiten Fall droht eine aufwendige Anbindung nur den Austausch des eigentlichen Problems zu verschieben.

Legen Sie vor der Produktauswahl drei Ergebnisse fest: Welche Prozesse müssen funktionieren, welche Verzögerung ist je Datenfluss vertretbar und wie lange soll die Verbindung genutzt werden? Ein täglicher Produktabgleich kann genügen; ein täglich aktualisierter Bestand kann bei knapper Ware bereits zu spät sein.

Datenhoheit und Abläufe einer Shop-ERP-Verbindung planen

Was ist bei Navision 2009 technisch anders?

Microsoft dokumentierte für NAV 2009 die Veröffentlichung von Pages und Codeunits als Webservices.

Damit gibt es grundsätzlich einen vorgesehenen Integrationsweg über Anwendungsobjekte. Welche Objekte vorhanden sind und welche Geschäftslogik sie tatsächlich ausführen, muss Ihr NAV-Partner in Ihrer Installation prüfen.

Ein Konnektor für heutiges Dynamics 365 Business Central ist deshalb kein Nachweis für die Unterstützung von NAV 2009. Verlangen Sie die genaue unterstützte Version einschließlich Service Pack oder R2, Datenbankumgebung, benötigter Komponenten und kundenspezifischer Änderungen. Lassen Sie sich den vorgesehenen Zugriff an Ihrer Testinstallation zeigen.

Erfassen Sie dabei Client, Serverkomponenten und Datenbank getrennt. Der sichtbare Classic Client allein beschreibt noch nicht den verfügbaren Integrationsweg. Auch die Bezeichnung „Navision“ im Angebot ist zu ungenau: Entscheidend sind der konkrete technische Stand und die angepassten Anwendungsobjekte.

Die historische Microsoft-Anleitung beschreibt die damalige Technik. Übernehmen Sie daraus keine alten Beispieladressen, Authentifizierungs- oder Netzwerkeinstellungen ungeprüft in ein heutiges Betriebskonzept.

Welche Bestandsaufnahme braucht der Integrationspartner?

Sammeln Sie mehr als eine Versionsnummer.

Benötigt werden eine Liste der Anpassungen und Add-ons, vorhandene Import- und Exportjobs, Dokumentation der Schnittstellen, verantwortliche Partner sowie ein aktueller Wiederherstellungsnachweis. Klären Sie, ob Quellobjekte, erforderliche Lizenzen und kompetente Ansprechpartner tatsächlich verfügbar sind.

Beschreiben Sie die fachlichen Besonderheiten mit echten, bereinigten Beispielen: Varianten, Verkaufseinheiten, kundenabhängige Preise, mehrere Lager und Teilmengen. Eine Artikelnummer kann im ERP einen Karton und im Shop ein Stück meinen. Ohne eindeutige Umrechnung entstehen Fehler trotz technisch erfolgreicher Übertragung.

Geben Sie dem Partner eine repräsentative Auftragsauswahl statt nur eines einfachen Musterauftrags. Nehmen Sie eine abweichende Lieferadresse, einen Rabatt, einen Teilversand und eine Stornierung auf. Personenbezogene Daten sollten Sie für Entwicklung und Vorführung durch geeignete Testwerte ersetzen.

Direkte Schnittstelle, Middleware oder Dateiaustausch?

Wählen Sie den Weg nach Prozess und Wartbarkeit.

Eine zusätzliche Integrationsplattform lohnt sich nicht allein deshalb, weil sie modern klingt. Sie benötigt ebenfalls Betrieb, Zugriffsregeln und jemanden, der fehlerhafte Vorgänge bearbeitet.

Ein direkter Schreibzugriff auf ERP-Tabellen ist kein gleichwertiger Ersatz für eine geprüfte Anwendungsschnittstelle. Er kann fachliche Prüfungen und Buchungslogik umgehen. Die Microsoft-Beschreibung der NAV-Webservices betont dagegen die Ausführung der Trigger der verwendeten Page oder Codeunit. Prüfen Sie dennoch, ob das jeweilige Objekt alle benötigten Regeln abbildet.

Auch ein Dateiaustausch kann für einen begrenzten Prozess brauchbar sein. Vereinbaren Sie dann Dateiformat, Zeichensatz, Übertragungsweg, eindeutige Dateikennung, Bestätigung und Archivierung. Eine Datei im Zielordner beweist noch nicht, dass die Bestellung fachlich angenommen wurde.

ERP-Konnektor und Middleware anhand derselben Anforderungen vergleichen

Wie verbinden Sie Shop, PIM und Lager ohne widersprüchliche Daten?

Ordnen Sie die führende Quelle je Datenbereich zu.

Das PIM kann Beschreibungen und Bilder liefern, während das ERP Artikelnummern und kaufmännische Daten führt. Das Lager bestätigt physische Bewegungen. Für den im Shop angebotenen Bestand brauchen Sie eine eindeutige Regel, die Reservierungen und gegebenenfalls Sicherheitsbestände berücksichtigt.

Vermeiden Sie zwei unabhängige Verbindungen, die dasselbe Feld überschreiben. Wenn sowohl Lager als auch ERP den verfügbaren Shopbestand setzen, entscheidet sonst die zuletzt eingetroffene Meldung über das Angebot. Dokumentieren Sie außerdem Zeitstempel und Reihenfolge, damit eine verspätete Meldung keinen neueren Stand ersetzt.

Bei Shopify, Shopware, WooCommerce oder einer individuellen Plattform bleibt die Prüfung gleich: Welche Daten benötigt der aktuelle Shop, welche kann der vorhandene NAV-Adapter liefern und wo muss übersetzt werden? Eine Shopware-Navision-Schnittstelle für einen anderen Versionsstand belegt diese Kombination noch nicht.

Produktdaten zwischen PIM und Onlineshop organisieren

Was passiert bei Ausfällen und doppelt gesendeten Bestellungen?

Planen Sie die Verbindung als nachvollziehbare Verarbeitungskette: Eingang, Prüfung, Übergabe, fachliche Annahme und Rückmeldung.

Jeder Vorgang benötigt eine stabile Referenz aus Quellsystem und Shop. Eine verlorene Bestätigung darf bei einer Wiederholung nicht zu einer zweiten Bestellung im ERP führen.

Nach einem Abbruch muss erkennbar sein, ob das ERP den Auftrag bereits angelegt hat. Der Adapter muss diesen Zustand abgleichen können, bevor er erneut schreibt. Eine bloße Wiederholung nach Zeitablauf reicht für diesen Fall nicht aus.

Legen Sie einen Abgleich zwischen eingegangenen Shopbestellungen und übernommenen ERP-Aufträgen fest. Überwachen Sie neben Fehlermeldungen auch die älteste unbearbeitete Nachricht. Ein Dienst kann technisch laufen, während Aufträge seit Stunden in einer Warteschlange liegen.

Definieren Sie, wer fachliche Fehler klärt, wer technisch eingreift und wann der Verkauf bei veralteten Beständen eingeschränkt werden muss. Protokolle sollen die Bearbeitung ermöglichen, ohne Passwörter, Zahlungskartendaten oder unnötige Kundendaten zu sammeln.

Macht die Anbindung NAV 2009 wieder zukunftssicher?

Nein.

Eine Schnittstelle verlängert den Microsoft-Support des ERP nicht. Die Lifecycle-Seite für Dynamics NAV 2009 R2 weist das Ende des erweiterten Supports im Januar 2020 aus. Den Supportstand Ihrer konkreten Version und ihrer Betriebskomponenten müssen Sie gesondert erfassen.

Betrachten Sie daher nicht nur die Verbindung, sondern auch Windows, Datenbank, Sicherung und Wiederherstellung. Lassen Sie ein heutiges Zugangskonzept mit begrenzten Rechten, geschützten Verbindungen und möglichst geringer Erreichbarkeit erstellen. Ein zusätzlicher Adapter macht eine nicht mehr unterstützte Umgebung nicht automatisch sicher.

Eine Übergangslösung braucht ein Enddatum oder einen überprüfbaren Auslöser für die Neubewertung. Beispiele sind der geplante ERP-Wechsel, das Ende einer vereinbarten Partnerbetreuung oder ein neuer Prozess, den das Altsystem nicht mehr zuverlässig abbildet. Dokumentieren Sie die verbleibenden Risiken ausdrücklich.

Wann lohnt sich die Brücke – und wann die Migration?

Vergleichen Sie zwei vollständige Szenarien: Weiterbetrieb mit Anbindung und spätere Ablösung gegenüber einer früheren ERP-Migration.

Rechnen Sie Einrichtung, Lizenzen, Betrieb, Anpassungen, Tests, Fehlerbearbeitung und die spätere Umstellung der Schnittstelle ein. Pauschale Projektpreise ohne Kenntnis der Installation sind dafür keine belastbare Grundlage.

Die Brücke kann sinnvoll sein, wenn das ERP fachlich gut funktioniert, die erforderlichen Zugriffe nachweisbar sind und ein begrenzter Zeitraum überbrückt werden soll. Eine frühere Migration verdient Vorrang, wenn schon der Betrieb unzuverlässig ist, notwendige Expertise fehlt oder jede kleine Änderung weitere Sonderentwicklung auslöst.

Vereinbaren Sie für die Brücke ein fachliches Austauschformat und exportierbare Zuordnungen. Dadurch kann beim ERP-Wechsel ein Teil der Shopseite erhalten bleiben. Ob das tatsächlich möglich ist, muss die Architektur zeigen; allein das Wort Middleware garantiert es nicht.

ERP-Datenmigration mit Cutover und Abnahme vorbereiten

Welche Tests gehören vor die Freigabe?

Nehmen Sie die Verbindung mit realistischen Geschäftsfällen in einer getrennten Umgebung ab.

Prüfen Sie die Ergebnisse im Shop und im ERP, nicht nur grüne Statusanzeigen des Konnektors. Ein angenommener Datensatz ist noch kein korrekt bearbeiteter Auftrag.

Testen Sie zunächst den normalen Auftrag mit Variante, Rabatt und abweichender Lieferadresse. Ergänzen Sie einen Teilversand, eine Stornierung nach Übernahme und eine Retoure. Unterbrechen Sie anschließend die Verbindung vor und nach der ERP-Annahme. Wiederholen Sie denselben Auftrag und weisen Sie nach, dass keine Dublette entsteht.

Vereinbaren Sie messbare Grenzwerte für Aktualität und Verarbeitung anhand Ihres Geschäfts. Prüfen Sie außerdem einen Wiederanlauf nach längerer Unterbrechung und die Wiederherstellung aus einer Sicherung. Erst wenn Zuständigkeiten, Fehlersicht und Rückfall feststehen, ist aus der technischen Verbindung ein betreibbarer Ablauf geworden.