Kurzantwort

Die Antwort in Kürze

EDI automatisiert den strukturierten Austausch von Geschäftsdokumenten zwischen Unternehmen. Eine Integrationsschicht übersetzt Partnerformate in das interne ERP-Modell, validiert Pflichtangaben und überwacht den Prozess. Provider wie Transus oder Procuros können Partnernetz und Protokolle vereinfachen; die fachliche Verantwortung bleibt im Unternehmen.

Operative Einordnung

EDI und Logistikintegration verbinden Geschäftsdokumente mit realen Warenbewegungen

EDI wird häufig als Dateiformat verstanden, tatsächlich geht es um verbindliche Geschäftsprozesse zwischen Unternehmen. Bestellung, Bestätigung, Lieferavis, Wareneingang und Rechnung müssen in einer fachlich richtigen Reihenfolge verarbeitet werden. Partner nutzen unterschiedliche Nachrichtenvarianten, Pflichtfelder und Identifikatoren. Deshalb reicht eine technisch gültige Nachricht nicht aus; sie muss auch zum vereinbarten Prozess und zum konkreten Geschäftsvorgang passen.

Die Logistikanbindung ergänzt diese Dokumentenkette um physische Ereignisse. Versandauftrag, Packstücke, Carrier, Tracking und Zustellung verändern den Status eines Auftrags und können weitere Dokumente auslösen. Besonders bei Teillieferungen und mehreren Lagern muss klar sein, auf welcher Ebene eine Meldung gilt. Eine eindeutige Referenz über Auftrag, Lieferung, Packstück und Nachricht verhindert, dass Teams Fehler mühsam über mehrere Systeme zusammensuchen.

Für den Betrieb werden fachliche und technische Überwachung getrennt betrachtet. Eine Nachricht kann übertragen, aber wegen falscher Mengen oder unbekannter Artikel fachlich abgelehnt worden sein. Dashboards müssen deshalb Transportstatus, fachliche Bestätigung und offene Klärfälle zeigen. Partner-Onboarding, Mapping-Versionen und Eskalationswege gehören genauso zum System wie die eigentliche Schnittstelle.

Für jeden EDI-Partner dokumentieren

  • Nachrichtenfolge und fachliche Bestätigung
  • Identifikatoren, Einheiten und Pflichtfelder
  • Umgang mit Teilmengen und Korrekturen
  • Monitoring, Ansprechpartner und Eskalationsweg
01

Was EDI im Handelsprozess leistet

Electronic Data Interchange bezeichnet den strukturierten elektronischen Austausch von Geschäftsdokumenten. Statt Bestellung, Lieferschein oder Rechnung manuell aus E-Mail und Portal zu übertragen, tauschen Systeme standardisierte Nachrichten aus. Transus und Procuros beschreiben automatisierte Dokumentflüsse zu Handelspartnern.

EDI ist nicht gleichbedeutend mit einem einzigen Format. EDIFACT, XML, JSON, CSV, API oder providerabhängige Varianten können beteiligt sein. Der Nutzen entsteht durch gemeinsame Semantik, Validierung und automatisierte Verarbeitung.

02

Die wichtigsten Nachrichten von Bestellung bis Rechnung

Ein typischer Prozess beginnt mit ORDERS, der elektronischen Bestellung. ORDRSP bestätigt Annahme, Mengen oder Abweichungen. DESADV kündigt die Lieferung mit Packstück- und Versandinformationen an. INVOIC übermittelt die Rechnung. Je nach Partner kommen weitere Nachrichten hinzu.

Die Abkürzung allein reicht nicht. Jeder Handelspartner definiert Pflichtfelder, Codes, Fristen und Prüfregeln. Das gleiche Nachrichtenschema kann dadurch unterschiedliche Mappings benötigen.

  • ORDERS – Bestellung
  • ORDRSP – Auftragsantwort
  • DESADV – Lieferavis
  • INVOIC – Rechnung oder Gutschrift
  • PRICAT – Produkt- und Katalogdaten
  • RECADV – Wareneingangsbestätigung
03

ERP, WMS, TMS und EDI-Provider zusammendenken

Das ERP führt typischerweise Kunden, Artikel, Auftrag und Rechnung. Ein WMS steuert Lagerbewegungen, ein TMS oder Spediteur Transportaufträge und Status. Der EDI-Provider verbindet Partner und Protokolle. Middleware orchestriert Übergaben und übersetzt das externe in das interne Datenmodell.

Die Systemgrenze muss für jeden Status klar sein. Ein im ERP bestätigter Auftrag ist noch nicht versendet; ein gedrucktes Label ist noch keine Übergabe an den Carrier. Präzise Ereignisse verhindern falsche Rückmeldungen.

04

Mapping und Stammdaten sind der Kern

Partnernummern, Lieferadressen, GLN, Artikelnummern, EAN/GTIN, Einheiten, Verpackungsebenen, Steuercodes und Incoterms müssen eindeutig zugeordnet werden. Viele EDI-Fehler sind keine Transportprobleme, sondern widersprüchliche Stamm- oder Referenzdaten.

Mappings gehören versioniert und fachlich dokumentiert. Für unbekannte Artikel, abweichende Mengen oder neue Lieferorte braucht es eine definierte Behandlung. Stille Ersatzwerte erzeugen langfristig schwer auffindbare Fehler.

05

Partner-Onboarding mit Transus, Procuros oder Direktverbindung

Ein Provider kann vorhandene Partnernetze, Protokolle, Validierung und Onboarding bereitstellen. Transus beschreibt den Austausch über ERP, Portal oder automatische API. Procuros positioniert vorkonfigurierte Händlerverbindungen und automatische Prüfungen. Ob Provider oder Direktanbindung sinnvoller ist, hängt von Partnerzahl, Formaten, Volumen und Kompetenz ab.

Auch bei einem Provider bleiben Entscheidungen notwendig: Welche Nachricht löst welchen ERP-Schritt aus? Wer klärt abgelehnte Dokumente? Welche Daten dürfen übertragen werden? Ein Dienstleister reduziert technische Komplexität, ersetzt aber kein Prozessdesign.

06

Logistik- und Speditionsanbindung erweitern

Speditionen, Paketdienste und Fulfillment-Partner benötigen Transportauftrag, Abholadresse, Packstücke, Maße, Gewichte, Service und Zeitfenster. Zurück fließen Label, Sendungsnummer, Status, Zustellnachweis und Ausnahmen. Stückgut, Palette und Paket haben unterschiedliche Anforderungen.

Bei mehreren Partnern lohnt ein kanonisches internes Versandmodell. Carrier-spezifische Codes werden an einer Stelle übersetzt. Dadurch muss das ERP nicht für jeden neuen Dienstleister vollständig angepasst werden.

07

Validierung vor der Verarbeitung

Technische Validierung prüft Format und Pflichtfelder. Fachliche Validierung fragt zusätzlich, ob Partner, Artikel, Einheit, Preis und Lieferort im Kontext zulässig sind. Fehler werden mit verständlicher Ursache und Verantwortlichkeit versehen.

Bei ausgehenden Nachrichten verhindert eine Vorprüfung, dass fehlerhafte Belege den Partner erreichen. Eingangsnachrichten können je nach Risiko automatisch verarbeitet, geparkt oder zur Freigabe vorgelegt werden.

08

Monitoring, Nachvollziehbarkeit und Wiederholung

Jedes Dokument erhält eine Ende-zu-Ende-Korrelation: externe Referenz, interne Belegnummer, Nachrichtenstatus, Zeitpunkte und Partnerantwort. Damit lässt sich ein fehlendes Lieferavis gezielt finden.

Wiederholungen müssen sicher sein. Eine erneut gesendete Bestellung darf keinen zweiten Auftrag erzeugen; eine korrigierte Nachricht muss bewusst verarbeitet werden. Alarmierung orientiert sich an geschäftlicher Dringlichkeit und Fristen.

09

Test und Go-live pro Handelspartner

EDI wird pro Partner und Nachrichtentyp abgenommen. Testfälle enthalten Standard, Mengenabweichung, unbekannten Artikel, Teillieferung, Storno, mehrere Packstücke, fehlerhafte Referenz und erneute Zustellung. Kontrollsummen und Belegabgleich sichern Vollständigkeit.

Der Go-live beginnt idealerweise mit begrenztem Volumen und paralleler Kontrolle. Ansprechpartner auf beiden Seiten, Supportfenster und Eskalationsweg stehen fest. Nach Stabilisierung werden manuelle Parallelprozesse kontrolliert beendet.

  • Partner- und Nachrichtenumfang fixieren
  • Mapping mit realistischen Beispieldaten prüfen
  • fachliche Abnahme in ERP und Lager
  • Monitoring vor Aktivierung testen
  • erste Produktivtage täglich abgleichen
10

Business Case und Kennzahlen

Der Nutzen entsteht durch weniger manuelle Erfassung, kürzere Durchlaufzeit, geringere Fehlerquote und bessere Skalierbarkeit. Dem gegenüber stehen Provider-, Implementierungs-, Test- und Betriebskosten. Besonders wertvoll ist EDI bei hohen Belegmengen oder verbindlichen Partneranforderungen.

Kennzahlen umfassen Automatisierungsquote, abgelehnte Dokumente, manuelle Nacharbeit, Durchlaufzeit, fristgerechte DESADV/INVOIC-Nachrichten und Zeit bis zur Fehlerlösung. Damit wird sichtbar, ob die Integration den Prozess verbessert.

Zum Abschluss

Häufige Fragen zum Thema

Was ist der Unterschied zwischen EDI und API?+

EDI beschreibt den strukturierten Geschäftsdokumentaustausch und seine Prozesse; eine API ist ein möglicher technischer Übertragungsweg.

Brauche ich einen EDI-Provider?+

Nicht immer. Ein Provider ist besonders hilfreich bei vielen Handelspartnern, unterschiedlichen Protokollen und Onboardinganforderungen.

Welche Dokumente werden typischerweise ausgetauscht?+

Häufig ORDERS, ORDRSP, DESADV und INVOIC. Je nach Prozess kommen Produktkataloge, Bestandsberichte oder Wareneingänge hinzu.

Kann VisionConnect Transus und Procuros anbinden?+

VisionConnect ist als Integrationsschicht für ERP-, EDI- und Partnerdatenflüsse positioniert. Der konkrete Umfang, Providerzugang und das Mapping werden je Projekt geprüft.

Quellen und weiterführende Links