EDI-Schnittstelle: Aufbau, Formate, Test

Eine EDI-Schnittstelle überträgt Geschäftsbelege als strukturierte Nachrichten zwischen zwei Unternehmen: Bestellung, Auftragsbestätigung, Lieferavis und Rechnung laufen ohne Formular und ohne PDF. Für die eigene Anwendung heißt das, fremde Nachrichtenformate in das eigene Datenmodell zu übersetzen und beide Richtungen lückenlos zu protokollieren.

EDI-Schnittstelle: Nachrichten statt Formulare

Das Kürzel steht für Electronic Data Interchange und ist älter als das Web. Der Gedanke dahinter: Zwei Unternehmen einigen sich auf Aufbau und Bedeutung ihrer Belege, sodass die Software der einen Seite die Nachricht der anderen ohne menschliches Zutun verarbeitet. Nicht das Übertragungsmittel macht den Austausch aus, sondern die vereinbarte Struktur — dieselbe Bestellung kann über einen gesicherten Dateiübertrag, ein Postfach oder einen Web-Aufruf ankommen.

Im Entwurf trennt man deshalb sauber zwischen drei Ebenen: dem Transportweg, dem Nachrichtenformat und der fachlichen Vereinbarung darüber, welche Felder gefüllt sein müssen. Wer diese Ebenen vermischt, baut eine Anbindung, die nur mit einem einzigen Partner funktioniert und beim zweiten von vorn beginnt.

EDIFACT, EANCOM und die neueren Formate

Im deutschsprachigen Raum begegnen einem vier Familien:

• EDIFACT. Der internationale Standard der Vereinten Nationen, segmentweise aufgebaut, sehr kompakt und ohne Werkzeug kaum zu lesen.
• EANCOM. Die im Handel verbreitete Auswahl daraus: dieselben Nachrichten, aber mit festgelegten Pflichtfeldern und der weltweit eindeutigen Artikelnummer als Anker.
• VDA und Odette. Die Formatfamilie der Fahrzeugindustrie mit eigenen Nachrichten für Lieferabrufe.
• XML und JSON. Neuere Formate, darunter die Rechnungsformate der öffentlichen Verwaltung; leichter zu lesen, aber ohne die Prüfstrenge der älteren Standards.

Die Formatwahl trifft in aller Regel nicht der Lieferant, sondern der größere Partner. Für die eigene Anwendung folgt daraus eine Bauregel: Das Datenmodell im Haus bildet den eigenen Ablauf ab und nicht das Format eines Partners; übersetzt wird am Rand.

Bestellung, Bestätigung, Lieferavis, Rechnung

Vier Nachrichtenarten tragen den Handelsverkehr, und sie bilden eine Kette:

1. Bestellung (ORDERS). Der Kunde nennt Artikel, Menge, Preis, Termin und Lieferort.
2. Auftragsbestätigung (ORDRSP). Der Lieferant bestätigt, korrigiert Mengen oder meldet Nichtlieferbarkeit — hier entscheidet sich, ob der Rest der Kette glattläuft.
3. Lieferavis (DESADV). Die Ankündigung der Sendung mit Packstruktur und Nummer der Versandeinheit; der Wareneingang bucht damit ohne Zählen.
4. Rechnung (INVOIC). Der Beleg selbst, der gegen Bestellung und Lieferung maschinell geprüft wird.

Dazu kommen Quittungen, die den Empfang bestätigen. Sie sind der einzige Beleg dafür, dass eine Nachricht angekommen ist, und gehören deshalb in dieselbe Ablage wie die Nachrichten selbst.

EDI-Schnittstelle im eigenen System anbinden

Im Aufbau der Anwendung liegt der Austausch nicht im Fachkern, sondern als eigene Schicht davor. Sie besteht aus vier Bausteinen:

• Annahme. Nachrichten werden entgegengenommen, unverändert abgelegt und erst danach verarbeitet. Das Original bleibt Beweismittel.
• Umwandlung. Segmente und Felder werden auf das eigene Datenmodell abgebildet, mit ausdrücklicher Regel für Einheiten, Währungen, Steuersätze und Datumsangaben.
• Schlüsselzuordnung. Artikelnummer des Partners, eigene Artikelnummer und weltweit eindeutige Nummer werden in einer Tabelle geführt, nicht im Programmcode.
• Zustandsführung. Jeder Beleg trägt seinen Stand: angenommen, umgewandelt, verarbeitet, quittiert, gescheitert. Ohne diesen Stand ist eine Störung nicht nachvollziehbar.

Ob die Verbindung über einen Dienstleister für den Nachrichtenaustausch oder unmittelbar läuft, ändert an dieser Schicht wenig. Der Umbau des Bestands, der eine solche Schicht in gewachsenen Anwendungen erst möglich macht, gehört zur Legacy-Modernisierung.

Testfälle, Testpostfach und Abnahme

Geprüft wird ohne echten Partner, sonst prüft niemand genug. Grundlage sind aufgezeichnete Nachrichten aus dem Echtbetrieb, vom Personenbezug befreit und als Testfälle abgelegt: eine vollständige Bestellung, eine mit unbekannter Artikelnummer, eine mit abweichender Menge, eine Rechnung mit Rundungsdifferenz, eine Nachricht mit fehlendem Pflichtfeld.

Die Partner selbst verlangen vor der Freischaltung einen eigenen Durchlauf im Testpostfach — jede Nachrichtenart einzeln, mit Quittung. Was dabei als bestanden gilt, wird vorher schriftlich festgelegt und ist später der Maßstab der Abnahme. Der Übergang alter Belege in die neue Ablage folgt den Regeln der Datenmigration.

Stolpersteine beim ersten Anschluss

Die häufigsten Fehler liegen neben der Technik. Erstens werden Stammdaten unterschätzt: Ohne gepflegte Artikelnummern auf beiden Seiten scheitert ein großer Teil der Nachrichten an der Zuordnung. Zweitens fehlt eine Zuständigkeit für gescheiterte Belege — eine Nachricht, die niemanden erreicht, wenn sie liegen bleibt, fällt erst durch eine Mahnung auf. Drittens werden Änderungen des Partners nicht verfolgt, obwohl sie angekündigt werden.

Viertens unterschätzen Anwendungen die Menge: Was im gewöhnlichen Tagesgeschäft läuft, kippt in einer Aktionswoche, wenn Nachrichten einzeln und ohne Warteschlange verarbeitet werden.

Wir schneiden eine solche Anbindung deshalb je Nachrichtenart und nicht als ein großes Paket: Bestellung, Bestätigung, Lieferavis und Rechnung bekommen eigene Abnahmekriterien, einen eigenen Probelauf gegen die Unterlagen des Handelspartners und einen Abgleich gegen das Quellsystem. Jede Nachrichtenart läuft dabei neben dem bisherigen Weg mit, und wer sich um liegengebliebene Belege kümmert, ist benannt, bevor die erste Meldung produktiv geht. Welche Arbeiten dazugehören, steht auf der Seite Integrationen.