EDI-Schnittstelle

Zweck

Diese Seite beschreibt die EDI-Schnittstelle in Automotive von der Grundkonfiguration über Partner- und Nachrichtenarten bis zur operativen Verarbeitung ein- und ausgehender Nachrichten. Sie dient als zentrale Orientierung für alle Szenarien, in denen Abrufe, Rechnungen, Lieferscheindaten oder Transportinformationen automatisiert mit Partnern ausgetauscht werden.

Fachlicher Nutzen

• Sie wählen einen passenden Übertragungsweg für Ihre Partnerkommunikation.
• Sie richten Partner, Nachrichtenarten und Nummernserien so ein, dass Nachrichten eindeutig erzeugt, erkannt und archiviert werden.
• Sie verstehen den Unterschied zwischen eingehender und ausgehender Nachrichtenverarbeitung.
• Sie nutzen Protokoll und Historie für Fehleranalyse, Nachweis und Wiederanlauf.

Grundlogik der EDI-Verarbeitung

Die EDI-Schnittstelle verbindet Business Central mit Konvertern, Webservices oder Dateiablagen. Der Prozess folgt dabei immer derselben Grundlogik:

1. Eine Nachricht wird empfangen oder erzeugt.
2. Partner, Nachrichtenart und Richtung werden erkannt.
3. Die Nachricht wird verarbeitet, validiert und gegebenenfalls in einen Beleg überführt.
4. Status, Protokoll und Archivierung sichern die Nachvollziehbarkeit.

graph LR;

%% Nodes
A[Partner oder System]
B[Nachricht empfangen oder erzeugen]
C[Partner und Nachrichtenart erkennen]
D[Nachricht verarbeiten]
E[Beleg oder Statusaktualisierung]
F[Protokoll und Historie]

%% Flow
A -.- B
linkStyle 0 stroke:#ffffff
B ==> C
C ==> D
D ==> E
D ==> F

%% Classes
class A btProcessTitle
class B,C,D,E,F btProcessActive

Einordnung in den BC-Dokumentfluss

Für Endanwender ist ein Punkt besonders wichtig: EDI ist in Automotive keine Parallelwelt neben Business Central. EDI liest Daten in Business Central ein oder schreibt Daten aus vorhandenen BC-Belegen nach außen. Die Nachrichtenliste selbst ist deshalb nur selten der eigentliche Abschluss des Prozesses.

graph LR;

%% Nodes
A[Partner]
B[EDI Inbound Messages]
C[Pruefen und verarbeiten]
D[Automotive Auftrag oder Einkaufsbeleg]
E[Warehouse oder Wareneingang]
F[Gebuchter Beleg]
G[EDI Outbound Messages]
H[Partner]
I[Protokoll und Archiv]

%% Flow
A -.- B
linkStyle 0 stroke:#ffffff
B ==> C
C ==> D
D ==> E
E ==> F
F ==> G
G ==> H
C ==> I
G ==> I

%% Classes
class A btProcessTitle
class B,C,D,E,F,G,H,I btProcessActive

Für die tägliche Arbeit hilft folgende Leseregel:

1. Prüfen Sie in der EDI-Liste, ob die Nachricht technisch angekommen oder versendet wurde.
2. Wechseln Sie danach in den erzeugten oder betroffenen Fachbeleg.
3. Prüfen Sie erst dort, ob der Vorgang fachlich vollständig abgeschlossen ist.

EDL-Informationsfluss als Referenzmodell

Die Leistungsbeschreibung ergänzt die EDI-Sicht um ein klares Austauschmodell für EDL-Szenarien zwischen Lieferant, EDL und Kunde.

Zum Vergrößern anklicken

Für die operative Einordnung in Automotive ist vor allem diese Reihenfolge wichtig:

1. Lieferabruf oder Feinabruf wird als VDA-Aufruf gestartet.
2. Lieferschein-Transportdaten werden als VDA 4913 bereitgestellt.
3. EDL bestätigt Eingänge und liefert Bestandsinformationen zurück.
4. Lagerabrufe und Lieferscheindaten laufen zwischen EDL und Kunde ebenfalls über VDA 4913.
5. Rechnungsdaten laufen über VDA 4906, Gutschriften über VDA 4908.

Damit wird sichtbar, dass EDI nicht nur Aufruf- und Rechnungsverkehr abdeckt, sondern auch die laufende Bestands- und Versandkommunikation entlang des physischen Flusses.

Übertragungswege bewusst wählen

Die Bestandsdokumentation beschreibt drei Grundmodelle für die Übertragung:

Im aktuellen Cloud-Code ist die auswählbare Standard-Übertragungsart auf Web Interface und Azure File Share eingeschränkt. Die dateibasierte Logik ist im Code weiterhin vorhanden, spielt für den aktuellen Produktstand aber vor allem als Alt- oder Spezialfall eine Rolle.

Die globale Übertragungsart kann zusätzlich partnerbezogen überschrieben werden. Prüfen Sie deshalb früh, ob wirklich alle Partner denselben Weg nutzen sollen oder ob Mischszenarien erforderlich sind.

EDI-Einrichtung und Nummernserien

In der zentralen EDI-Einrichtung werden Aktivierung, Archivierung, Pfade und Nummernserien definiert. Nummernserien sind dabei kein Nebenthema, sondern eine Grundvoraussetzung für eine stabile Verarbeitung.

Der Code stellt auf der Seite EDI Setup dazu eigene Gruppen für General, Nos. Series, Import, Export, Web Service und Azure File Share bereit. Zusätzlich gibt es dort direkte Aktionen für:

• Create EDI Standard Data
• Create EDI Standard Data with Paths
• Aufruf der EDI Partner List
• Aufruf der EDI Message Types

Besonders wichtig sind Nummernserien für:

• EDI-Partner
• eingehende Verkaufsbelege
• eingehende Einkaufsrechnungen
• eingehende Lieferscheindaten
• ausgehende Verkaufs- und Einkaufsnachrichten
• Gutschriften und weitere Folgebelege

Fehlen diese Nummernserien, scheitern Erzeugung oder Zuordnung oft nicht fachlich sichtbar, sondern technisch in der Verarbeitung.

Prüfen Sie auf der Setup-Seite zusätzlich bewusst diese Felder:

• Interface is Active
• Mandatory Information
• Archive Messages, Archive Type und Archive Grouping
• Inbound Message Error Handling und Max. No. of Attempts to Proc
• Web Service Provider, Web Service URL, Web Service Timeout und die Provider-spezifischen Servicepfade
• Azure File Share Account Name, Access Key sowie Inbound-, Outbound- und Archiv-URLs

Partner und Partnerzeilen einrichten

Jeder EDI-Partner bildet die Verbindung zwischen Business-Central-Stammdaten und Nachrichtenlogik. Dazu gehören:

• Partner Type, im aktuellen Cloud-Stand typischerweise Customer oder Vendor
• Partner No. und gegebenenfalls Ship-to Address
• Partner ID als Kennzeichen für eingehende Nachrichten
• Sender ID als eigene Kennung für ausgehende Nachrichten
• Transmission Type je Partner
• Mandatory Information einschließlich GLN-bezogener Pflichtlogik
• Parameter wie Sender-/Empfänger-ID, Odette-IDs und weitere Partnermerkmale

Über die Partnerzeilen wird gesteuert:

• ob die Zeile Active ist
• welche Direction und welcher Message Type Code gilt
• ob Create Document, Automatic Processing oder Send Message aktiv sind
• welcher Message Filename und welche Message Extension verwendet werden
• ob ein eigenes Message Location genutzt wird
• welche Leitfäden für Delivery, Incoming, Invoice oder Shipping gelten

Wichtig für die Pflege: Der Code blockiert Änderungen an Partner Type und Partner No., sobald bereits Partnerzeilen existieren. Diese Stammdaten sollten deshalb vor der eigentlichen Nachrichtenkonfiguration stabil sein.

Für ausgehende Partnerzeilen ist der Dateiname nicht nur Komfort, sondern Pflichtfeld. Ohne ihn scheitert die spätere Ausgabe oft erst im Versandprozess.

Nachrichtenarten verstehen

Nachrichtenarten definieren, wie eine Nachricht erkannt und verarbeitet wird. Dazu gehören Format, Richtung, Record-Typ oder XML-Knoten sowie die Frage, ob daraus ein Beleg erzeugt werden darf.

Die Seite EDI Message Types zeigt dafür im Code unter anderem diese Felder:

• Code
• Direction
• Description
• Type
• Test Mode
• Create Message
• Automatic Processing
• Send Message
• Message Format
• Root Element
• Record Type
• Method Delivery EDI und Method Invoice EDI

Zusätzlich gibt es die Aktion Create Default Message Types. Sie ist der vorgesehene Standardweg, um die Nachrichtenarten-Grundmenge nicht manuell von null aufzubauen.

Die Quelle verweist unter anderem auf VDA- und erweiterte VDA-Szenarien wie:

• Lieferabrufe
• Feinabrufe
• Lieferschein- oder Transportdaten
• Rechnungsdaten
• Gutschriften

Entscheidend ist: Nachrichtenart, Partnerzeile und Leitfaden müssen zusammenpassen. Sonst wird eine Nachricht zwar technisch empfangen, aber fachlich nicht richtig verarbeitet.

Der Code zeigt außerdem, dass die Leitfadenlogik weit über eine reine Auswahlbox hinausgeht. Spezifische Varianten für BMW, Porsche, Daimler, PSA, Nissan, VW, Jaguar, Motherson und weitere OEM- oder Partnerfälle beeinflussen die spätere Generierung und Verarbeitung tatsächlich.

Eingehende Nachrichten verarbeiten

Bei eingehenden Nachrichten läuft der Prozess typischerweise in drei Schritten:

1. Nachrichten einlesen
2. Nachrichten verarbeiten
3. Ergebnis prüfen und gegebenenfalls akzeptieren, zurückweisen oder erneut verarbeiten

Die Listenseite EDI Inbound Messages bildet diesen Ablauf direkt ab. Wichtige Aktionen im Code sind:

• Import Messages
• Import Message File
• Check Message
• Process Message
• Reprocess Message
• Toggle Test Mode
• Delete Message

Typische eingehende Objekte sind:

• Abrufe für Verkauf oder Einkauf
• Rechnungen oder Gutschriften
• Lieferscheindaten
• weitere partnerbezogene Belege im Nachrichtenkontext

Für die operative Prüfung sind auf der Liste besonders wichtig:

• Status
• Test Mode
• EDI Partner No., Partner No. und Partner Name
• Filename mit Drilldown auf den Nachrichteninhalt
• Last Error Message
• No. of Attempts to Process

Gerade bei eingehenden Verkaufsbelegen ist wichtig, dass die automatische Verarbeitung nicht die fachliche Kontrolle ersetzt. Nutzen Sie Prüfansichten, Status und Fehlermeldung, bevor Sie Belege endgültig freigeben.

Im BC-Kontext bedeutet das konkret: Eine erfolgreich verarbeitete Nachricht ist erst dann fachlich wertvoll, wenn der zugehörige Auftrag, Abruf, Wareneingang oder Folgebeleg auch inhaltlich plausibel ist.

Ausgehende Nachrichten verarbeiten

Ausgehende Nachrichten entstehen aus Business-Central-Belegen oder Statusänderungen. Sie können automatisch oder manuell versendet werden. Typische Beispiele sind:

• ausgehende Lieferabrufe
• ausgehende Rechnungsdaten
• Transport- oder Versanddaten
• Gutschrift- oder Folgedokumente

Die Seite EDI Outbound Messages stellt dafür im Code unter anderem diese Aktionen bereit:

• Send Message
• Update Delivery Status
• Manually Set Status to Processed
• Toggle Test Mode
• Delete Message

Prüfen Sie vor dem Senden:

• ist die richtige Nachrichtenart aktiv?
• ist der Partner korrekt zugeordnet?
• ist Dateiname, Leitfaden und Pfadlogik vollständig?
• befindet sich die Nachricht im Test- oder Produktivmodus?

Bei Webservice-Szenarien kommen in der Ausgabeliste zusätzlich Converter Status, Converter Status Text und Converter Send Time hinzu. Diese Felder sind wichtig, wenn die technische Übertragung nicht am Versand selbst, sondern erst beim Konverter oder Webservice hängen bleibt.

Auch hier gilt: Ein technischer Sendestatus ist nicht automatisch die fachliche Freigabe. Prüfen Sie bei Rückfragen immer zusätzlich den Ursprungbeleg, zum Beispiel Abruf, Transportdatensatz, gebuchte Lieferung oder Rechnung.

Archivierung, Protokoll und Historie

Archivierung und Protokoll sind die zentrale Nachweisschicht der EDI-Verarbeitung. Sie helfen nicht nur beim Debugging, sondern auch bei Rückfragen von Partnern, Audits oder Wiederanläufen.

Nutzen Sie insbesondere:

• Protokoll mit Richtung, Zeitpunkt, Datei, Status und Fehlermeldung
• Eingangs- und Ausgangsarchive
• Fehlerarchive für nicht erfolgreich verarbeitete Dateien
• Historie für empfangene Lieferscheindaten oder weitere Folgeobjekte

Ohne sauberes Archiv ist eine technische Wiederholung oft möglich, eine fachliche Nachvollziehbarkeit jedoch nicht.

Webservice- und Plattformanbindung

Für Webservice-Szenarien beschreibt die Bestandsdokumentation insbesondere Anbindungen an Ecosio und Eddyson. Wichtig sind dabei:

• Service-URL
• Sende-, Empfangs- und Callback-Pfade
• Benutzerkennung oder API-Schlüssel
• Company- oder Partner-ID
• Timeouts und Testumgebung

Diese Parameter sollten nur in abgestimmter Test- und Produktivkonfiguration gepflegt werden. Fehler in URL oder Authentifizierung wirken sich sofort auf Ein- oder Ausgangsnachrichten aus.

Zusätzlich prüft der Code die Webservice-Verbindung bereits beim Ändern der URL im Hintergrund. Nutzen Sie diesen Punkt bewusst früh und nicht erst beim ersten fachlichen Testversand.

Kontrollschritte im Tagesgeschäft

Typische Fehlerbilder

Migrations-Checkliste aus dem Altbestand

Für eine sichere Migration aus älteren EDI-Dokumentationen sollten Sie mindestens folgende Nachweise je Partnergruppe führen:

Diese Checkliste adressiert vor allem die Lücken in Fehlerbehandlung und operativem Monitoring, die in der Altdokumentation häufig detaillierter beschrieben waren.

Ergebnis

• Sie verstehen die Grundarchitektur der EDI-Schnittstelle in Automotive einschließlich der tatsächlichen Arbeitsseiten im Code.
• Sie können Übertragungswege, Partner, Partnerzeilen und Nachrichtenarten fachlich sauber einordnen.
• Sie nutzen Ein- und Ausgangslisten, Konverterstatus, Protokoll und Historie als operative Kontroll- und Nachweisschicht für den Nachrichtenaustausch.