Dynamics 365 EDI-Integration — der automatisierte elektronische Austausch von Geschäftsdokumenten mit Handelspartnern — gehört zu den komplexesten Integrationsszenarien für Unternehmen, die Microsoft Dynamics 365 Finance & SCM einsetzen. Jede gesendete Bestellung, jeder empfangene Kundenauftrag, jede ausgetauschte Rechnung oder Lieferavis ist eine Automatisierungsmöglichkeit. Ohne EDI laufen diese Dokumente über E-Mail oder PDF, erfordern manuelle Eingaben in D365 und bringen an jeder Stelle Fehler und Verzögerungen mit sich.
Dieser Leitfaden erklärt alles Wesentliche zur Dynamics 365 EDI-Integration: Was EDI ist, wie Order-to-Cash- und Purchase-to-Pay-Prozesse elektronisch ablaufen, welche Dokumenttypen beteiligt sind und wie FlexxLink die D365-seitige EDI-Verarbeitung übernimmt.
→ Zurück zum Dynamics 365 Integration Leitfaden — Übersicht aller Integrationsszenarien
Was ist Dynamics 365 EDI-Integration?
Electronic Data Interchange (EDI) bezeichnet den automatisierten, strukturierten Austausch von Geschäftsdokumenten zwischen Unternehmen — Lieferanten, Kunden und Logistikdienstleistern — ohne manuelle Eingriffe. In einem Dynamics 365 Finance & SCM-Kontext bedeutet Dynamics 365 EDI-Integration, dass Dokumente wie Bestellungen, Auftragsbestätigungen, Rechnungen und Lieferavise automatisch zwischen dem ERP und den Systemen der Handelspartner fliessen.
EDI ersetzt E-Mail-Anhänge und manuelle Dateneingaben durch eine direkte, elektronische Verbindung. Ein Kunde gibt eine Bestellung in seinem System auf — sie kommt in D365 als Kundenauftrag an, validiert und bereit zur Verarbeitung. Ein Wareneingang wird in D365 gebucht — die Lieferantenrechnung trifft ein, abgeglichen und bereit zur Buchung. Der entscheidende Vorteil ist nicht nur die Geschwindigkeit: Es ist die Vermeidung von Übertragungsfehlern, die Reduktion des administrativen Aufwands und die Schaffung eines vollständig nachvollziehbaren Dokumentenpfads.
In einer D365 EDI-Integration arbeiten drei Ebenen zusammen:
- Das ERP (D365) — wo Geschäftsdaten liegen: Bestellungen, Lagerbestände, Lieferanten, Kunden
- Der EDI-Client (FlexxLink) — innerhalb von D365 installiert, übernimmt Empfang, Validierung, Staging und Buchung von EDI-Dokumenten
- Die Middleware-Ebene — Plattformen wie Seeburger BIS, Lasernet oder Azure Logic Apps, die die Formatkonvertierung zwischen partnerspezifischen EDI-Formaten (EDIFACT, ANSI X12, OpenTrans) und dem REST/JSON-Format von FlexxLink übernehmen
Warum Dynamics 365 EDI-Integration komplexer ist als erwartet
EDI gibt es seit Jahrzehnten — dennoch bleibt die saubere Integration in ein modernes ERP wie D365 eine anspruchsvolle Aufgabe. Mehrere Faktoren machen es schwieriger als es erscheint:
Jeder Handelspartner ist anders. Jeder Partner kann ein anderes EDI-Format verwenden (EDIFACT vs. ANSI X12), eine andere Nachrichtenstruktur, andere Identifikationsschemas (GLN, GTIN, interne Artikelnummern) und andere Prozesserwartungen haben. Was für einen Lieferanten funktioniert, muss für den nächsten neu konfiguriert werden.
D365 ist keine EDI-Plattform. D365 bietet out-of-the-box keine native EDI-Verarbeitungsfunktion. Ohne eine dedizierte Integrationsschicht wird jede Handelspartneranbindung zu einem eigenen Entwicklungsprojekt — mit eigener Logik, eigenem Fehlerhandling und eigenem Wartungsaufwand.
Validierung ist entscheidend. Eine EDI-Nachricht mit einer ungültigen Artikelnummer, einem fehlenden Lieferdatum oder einem falschen Lagerortcode schlägt fehl — aber nur, wenn etwas sie abfängt. Ohne eine strukturierte Validierungsschicht treten Fehler erst nach der Buchung auf, nicht vorher, und verursachen kostspielige Korrekturen.
Transparenz ist fragmentiert. In einem manuell oder lose integrierten EDI-Setup erfordert die Statusverfolgung eines bestimmten Dokuments — Hat die Bestellung den Lieferanten erreicht? Wurde die Bestätigung empfangen? Wurde die Rechnung abgeglichen? — die Prüfung mehrerer Systeme. Es gibt keinen einzigen Wahrheitspunkt.
→ Mehr Infos: Warum Point-to-Point-Integration in D365-Umgebungen scheitert
Die zwei zentralen EDI-Prozesse in D365
1. Order-to-Cash (O2C) — Verkaufsseite
Der Order-to-Cash-Prozess umfasst den gesamten kundenseitigen Dokumentenfluss — vom Zeitpunkt einer Kundenbestellung bis zum Zahlungseingang. Mit Dynamics 365 EDI-Integration kann jeder Schritt dieses Prozesses automatisiert werden:
- Kundenauftragseingang — Kundenbestellungen kommen elektronisch per EDI an und werden automatisch in D365 angelegt, vor der Buchung gegen Stammdaten (Artikelnummern, Kundenkonten, Lieferadressen) validiert
- Auftragsänderungen — Modifiziert ein Kunde seine Bestellung, trifft die Änderung als ORDCHG-Nachricht ein und aktualisiert den bestehenden Kundenauftrag in D365
- Auftragsbestätigung — Sobald der Auftrag in D365 bestätigt ist, wird automatisch eine ausgehende Bestätigung (ORDRSP) an den Kunden gesendet
- Lieferavis (DESADV) — Bei Warenversand wird ein Advance Shipping Notice an den Kunden übermittelt, mit Versanddetails, Mengen und Verpackungsinformationen
- Rechnung — Ausgehende Rechnungen werden elektronisch an den Kunden gesendet, mit Unterstützung für Formate wie INVOIC, xRechnung und ZUGFeRD
→ Mehr Infos: Kundenaufträge mit EDI in Dynamics 365 verarbeiten
2. Purchase-to-Pay (P2P) — Einkaufsseite
Der Purchase-to-Pay-Prozess umfasst den lieferantenseitigen Dokumentenfluss — vom Versand einer Bestellung bis zur Buchung der Lieferantenrechnung. EDI automatisiert jeden Übergabepunkt zwischen D365 und dem Lieferanten:
- Bestellübertragung — In D365 erstellte Bestellungen (aus Produktprogrammplanung, Bestellanforderungen oder manueller Anlage) werden in Echtzeit elektronisch an den Lieferanten übermittelt
- Auftragsbestätigungseingang — Die Lieferantenbestätigung (ORDRSP) trifft in D365 ein, aktualisiert den Bestellstatus und kann Folgeschritte wie Ladungsträgeranlage oder Lagerbuchungen auslösen
- Lieferaviseingang (DESADV) — Advance Shipping Notices des Lieferanten kommen vor der Ware in D365 an und ermöglichen die Vorbereitung des Wareneingangs
- Rechnungseingang — Eingehende Lieferantenrechnungen werden empfangen, gegen Bestellung und Wareneingang validiert und zur Buchung in D365 bereitgestellt
→ Mehr Infos: Bestellungen mit EDI in Dynamics 365 verarbeiten
Unterstützte EDI-Dokumenttypen
FlexxLink unterstützt folgende Dokumenttypen für die Dynamics 365 EDI-Integration:
| Dokument | Richtung | EDIFACT-Nachricht |
|---|---|---|
| Kundenauftrag anlegen | Eingehend | ORDERS |
| Kundenauftrag ändern | Eingehend | ORDCHG |
| Auftragsbestätigung | Ausgehend | ORDRSP |
| Bestellung anlegen | Eingehend / Ausgehend | ORDERS |
| Bestellung ändern | Ausgehend | ORDCHG |
| Bestellbestätigung | Eingehend / Ausgehend | ORDRSP |
| Lieferavis (DESADV) | Eingehend / Ausgehend | DESADV |
| Rechnung | Eingehend / Ausgehend | INVOIC |
Wie FlexxLink die Dynamics 365 EDI-Integration abwickelt
FlexxLink wird als Independent Deployable Package direkt in Dynamics 365 Finance & SCM über Lifecycle Services (LCS) installiert. Es sitzt nicht ausserhalb von D365 als separate Integrationsschicht — es läuft nativ im ERP.
Im Kern ist FlexxLink ein REST-basierter EDI-Client für D365. Externe Systeme und Middleware-Plattformen senden EDI-Nachrichten an die eingehenden REST-Endpunkte von FlexxLink. FlexxLink sendet ausgehende Nachrichten an externe REST-Endpunkte. Das bedeutet:
- Jede Middleware-Plattform, die REST/HTTP-Aufrufe senden oder empfangen kann, lässt sich mit FlexxLink verbinden
- FlexxLink konvertiert EDI-Formate wie EDIFACT oder ANSI X12 nicht nativ — die Formatkonvertierung übernimmt immer die Middleware-Ebene (Seeburger BIS, Lasernet, Azure Logic Apps)
- FlexxLink verarbeitet die D365-Seite: Empfang, Validierung, Staging und Buchung von Dokumenten in D365-Geschäftsprozesse
Handelspartner werden in FlexxLink als Integrationsparteien konfiguriert. Jede Partei verfügt über eine eigene Endpunktkonfiguration, ein eigenes Validierungsprofil und eigene Schnittstelleneinstellungen — was partnerspezifisches Verhalten ohne individuelle Entwicklung ermöglicht.
EDI-Validierung in D365
Jede eingehende EDI-Nachricht, die FlexxLink verarbeitet, wird vor dem Eintrag in eine Stagingtabelle gegen D365-Stammdaten validiert. Das Validierungsframework funktioniert wie folgt:
- Validierungsregeln werden pro Schnittstelle (Kundenauftrag, Bestellung, Rechnung usw.) definiert und in Validierungsprofilen zusammengefasst, die pro Handelspartner zugewiesen werden
- Regeln prüfen Felder wie Artikelnummern, Debitoren-/Kreditorenkonten, Lagerortcodes, Lieferdaten und Mengen gegen bestehende D365-Stammdaten
- Jeder Regel wird ein Schweregrad zugewiesen: Warnung (Dokument wird verarbeitet, Problem wird markiert) oder Fehler (Dokument wird blockiert bis zur Behebung)
- Stopp bei Fehler hält die weitere Validierung an, sobald eine kritische Regel fehlschlägt, und verhindert kaskadierte Folgefehler
- Dokumente können direkt im Staging-Arbeitsbereich genehmigt, abgelehnt (mit Ablehnungsgrund) oder korrigiert werden
Das bedeutet: Ein eingehender Kundenauftrag mit einer unbekannten Artikelnummer oder einem ungültigen Lagerortcode wird abgefangen, bevor er D365 erreicht — nicht danach.
EDI-Transparenz und -Monitoring
FlexxLink enthält einen dedizierten Integrationsmonitor-Arbeitsbereich innerhalb von D365, der zentrale Transparenz über alle EDI-Vorgänge bietet:
- Fehleransicht — alle Nachrichten im Fehlerstatus mit Details zur Fehlersuche
- Verarbeitungsansicht — erfolgreich verarbeitete Nachrichten
- Jobhistorie — vollständiges Protokoll aller eingehenden und ausgehenden EDI-Nachrichten, filterbar nach Zeitraum, Richtung, Handelspartner und Schnittstelle
- Status-Push-Benachrichtigungen — wenn ein Dokument einen definierten Status erreicht, kann FlexxLink automatisch ein externes System benachrichtigen
Der B2B-Arbeitsbereich zeigt den EDI-Status auch direkt auf den Debitoren- und Kreditorenformularen in D365 — ohne den Datensatz zu verlassen.
Middleware-Konnektoren für D365 EDI
FlexxLink liefert vorgefertigte Integrationspakete für die am häufigsten eingesetzten EDI-Middleware-Plattformen:
Seeburger BIS
FlexxLink enthält ein vollständiges Deployment-Paket für die Seeburger Business Integration Suite, einschliesslich vorgefertigter Mappings, Kontokonvertierungstabellen und Klassifizierungsmappings. Der zweistufige Konvertierungsansatz (D365 XML → SEEXML → partnerspezifisches EDIFACT/X12/OpenTrans-Format) hält die D365-Integrationsschicht sauber von der partnerspezifischen Formatverarbeitung getrennt. Unterstützte EDIFACT-Nachrichten umfassen ORDERS, ORDCHG, ORDRSP, DESADV, INVOIC und REMADV.
Seeburger BIS ist in On-Premises-, Cloud-, iPaaS- und Full-Service-Bereitstellungsmodellen verfügbar — FlexxLink verbindet sich mit allen über REST.
→ Mehr Infos: EDI mit Seeburger BIS und FlexxLink — Einrichtung und Architektur
Lasernet
FlexxLink arbeitet mit Lasernet von Formpipe in einem ergänzenden Modell zusammen: Der Lasernet-Server übernimmt die Generierung und Übertragung ausgehender EDI-Dokumente, während eingehende Nachrichten von Lasernet empfangen und zur Verarbeitung in D365 an die REST-API von FlexxLink weitergeleitet werden. Das ermöglicht kosteneffiziente EDI-Kommunikation mit vollständiger partnerspezifischer Formatanpassung.
→ Mehr Infos: B2B EDI mit Lasernet und FlexxLink
Azure Logic Apps
FlexxLink verbindet sich mit Azure-basierten EDI-Workflows über Azure Logic Apps und ermöglicht so AS2-Kommunikation — ein Protokoll für den sicheren, verschlüsselten Austausch von EDI-Dokumenten zwischen Geschäftspartnern. Azure Logic Apps übernimmt die AS2-Kodierung, digitale Signaturen und partnerspezifische Sicherheitsanforderungen, während FlexxLink die resultierenden Nachrichten innerhalb von D365 verarbeitet.
→ Mehr Infos: AS2-Datenübertragung mit Azure Logic Apps und FlexxLink
Implementierung: Was zu erwarten ist
FlexxLink wird über Lifecycle Services (LCS) als Standard-D365-Paket installiert. Das B2B/EDI-Modul wird vorkonfiguriert ausgeliefert; der Implementierungsaufwand konzentriert sich auf:
- Integrationspartei-Einrichtung — Konfiguration jedes Handelspartners mit Endpunkt, Identifikationsschema (GLN, GTIN, intern) und Schnittstellenparametern
- Validierungsprofil-Einrichtung — Definition welche Validierungsregeln für welche Schnittstellen und Partner gelten
- Middleware-Verbindung — Konfiguration der Middleware-Ebene (Seeburger, Lasernet, Azure) mit den REST-Endpunkten von FlexxLink und den partnerspezifischen Formatmappings
- Schnittstellenaktivierung — Aktivierung der relevanten ein- und ausgehenden Schnittstellen pro Handelspartner
- Testing — End-to-End-Nachrichtenfluss-Tests mit echten oder Testdaten pro Dokumenttyp und Handelspartner
Für eine definierte Anzahl von Handelspartnern mit Standarddokumenttypen ist ein Go-live typischerweise innerhalb weniger Wochen erreichbar. Die Implementierungszeit skaliert mit der Anzahl der Handelspartner und der Komplexität der partnerspezifischen Mapping-Anforderungen in der Middleware-Ebene.
Lizenzierung und Verfügbarkeit
FlexxLink ist auf dem Microsoft Marketplace verfügbar und wird von der Soluvine GmbH entwickelt, einem ISV für Microsoft Dynamics 365 Finance & SCM. Es folgt der One-Version-Strategie von Microsoft und unterstützt die drei aktuellsten D365 Finance & SCM-Releases unter vollständigem Support.
Die Lizenzierung erfolgt über ein Flat-Subscription-Modell ohne Transaktionsgebühren — die Kosten steigen nicht mit wachsendem EDI-Nachrichtenvolumen. Eine 30-tägige kostenlose Testversion ist verfügbar.
Häufig gestellte Fragen
Unterstützt FlexxLink EDIFACT oder ANSI X12 nativ?
Nein. FlexxLink kommuniziert über REST-API und übernimmt die D365-seitige EDI-Verarbeitung — Empfang, Validierung, Staging und Buchung von Dokumenten. Die Konvertierung von EDIFACT, ANSI X12 und OpenTrans übernimmt immer eine Middleware-Plattform (Seeburger BIS, Lasernet, Azure Logic Apps), die sich über REST mit FlexxLink verbindet. FlexxLink und Middleware ergänzen sich — sie sind keine Alternativen.
Kann FlexxLink direkt mit einem Handelspartner ohne Middleware kommunizieren?
Ja, wenn der Handelspartner REST/HTTP-Aufrufe direkt senden und empfangen kann. In diesem Fall ist keine Middleware erforderlich. Middleware ist dann nötig, wenn eine EDI-Formatkonvertierung (EDIFACT, ANSI X12, OpenTrans) notwendig ist.
Wie werden verschiedene Handelspartner konfiguriert?
Jeder Handelspartner wird in FlexxLink als Integrationspartei angelegt, mit eigener Endpunktkonfiguration, Identifikationsschema (GLN, GTIN oder interne Artikelnummern), Validierungsprofil und Schnittstelleneinstellungen. Partnerspezifisches Verhalten wird über Konfiguration gesteuert, nicht über individuelle Entwicklung.
Was passiert, wenn eine eingehende EDI-Nachricht ungültige Daten enthält?
FlexxLink validiert jede eingehende Nachricht gegen D365-Stammdaten vor der Buchung. Dokumente mit Validierungsfehlern werden im Staging-Arbeitsbereich blockiert und mit dem spezifischen Fehler markiert. Sie können korrigiert, genehmigt oder abgelehnt werden — mit einem Ablehnungsgrund, der an den Handelspartner zurückgemeldet werden kann.
Unterstützt FlexxLink sowohl Cloud- als auch On-Premises-D365-Deployments?
Ja. FlexxLink unterstützt sowohl Dynamics 365 Cloud-Umgebungen als auch On-Premises-Deployments.
Welche Seeburger BIS-Bereitstellungsmodelle werden unterstützt?
FlexxLink verbindet sich mit Seeburger BIS in allen Bereitstellungsmodellen: On-Premises, Public Cloud, iPaaS und Full-Service. Die Verbindung erfolgt über Standard-REST, unabhängig davon, wo Seeburger BIS gehostet wird.
Ist FlexxLink auf Microsoft AppSource verfügbar?
Ja. FlexxLink ist auf dem Microsoft Marketplace gelistet und kann direkt dort getestet werden.
