Neuen EDI-Partner anbinden: Test- und Freigabeablauf

Zwischen dem Spezifikationsblatt eines Handelskunden und der ersten Echtbestellung liegt eine vereinbarte Testphase. In ihr wird nicht nur die eigene Software geprüft, sondern die ganze Kette aus Erzeugung, Übertragung, Prüfung und Verarbeitung einer Nachricht. Jede Phase endet mit einem Nachweis, den beide Seiten sehen können.

Was Sie vorab brauchen

• Die Partnerspezifikation mit Nachrichtenart, Fassung je Nachricht, Richtung, Übertragungsweg, Belegmenge, verlangten Quittungen (Bestätigungsnachrichten) und Ansprechpartnern auf beiden Seiten.
• GS1-Nummern: GLN für Unternehmen, Standorte und Organisationseinheiten, GTIN für Artikel und Artikelvarianten, SSCC/NVE für Transporteinheiten.
• Eine Übersetzungstabelle (Mapping), die die volle Struktur der Nachricht abdeckt; GS1 nennt sie einen der ersten Schritte einer EANCOM-Implementierung.
• Die EDI-Vereinbarung mit Testphase, Fehlerweg und Freigabebedingungen. GS1 Germany stellt dafür Mustervereinbarungen bereit.
• Ein Prüfwerkzeug für die eigenen Nachrichten: GS1 Germany prüft registrierten Nutzern mit dem EDI-Checker Bestellungen (ORDERS), Lieferavise (DESADV) und Rechnungen (INVOIC) der Anwendungsempfehlung Food/Non-Food auf inhaltliche und strukturelle Richtigkeit und liefert ein Prüf- und Fehlerprotokoll; GS1 Austria bietet einen kostenlosen EDI-Prüfservice, dem Sie erste Nachrichten per E-Mail senden.
• Auf beiden Seiten eine Testumgebung und je Nachricht einen Beispielbeleg mit dem erwarteten Ergebnis im Zielsystem.

EANCOM 2002 ist ein Subset ausgewählter UN/EDIFACT-Nachrichten auf Basis des Verzeichnisses D.01B; die EDIFACT-Syntax selbst steht in der kostenpflichtigen Normenreihe ISO 9735, die hier nur benannt wird. Verbindlich wird das erst durch die Vereinbarung der Handelspartner: Das GS1-Muster für INVOIC regelt Testphase, Kennzeichnung der Testdaten, Fehlerprozedere und Protokollierung; Deutschland, Österreich und die Schweiz haben eigene Nachrichtenbeschreibungen, und GS1 Germany und GS1 Austria prüfen Nachrichten in einem eigenen Dienst. Was die Vereinbarung nicht regelt, bleibt eine Lücke. Welches Betriebsmodell dahinter steht, klären Sie über EDI-Konverter oder Dienstleister; was ein Einstieg insgesamt umfasst, über EDI für den Mittelstand.

Die fünf Phasen im Überblick

Die Tabelle ordnet jeder Phase ihr Ergebnis und den Nachweis zu, mit dem sie abgeschlossen ist.

Phase	Ergebnis	Nachweis für die Freigabe
1 Spezifikation	Nachrichten je Richtung mit Fassung, Übertragungsweg und Quittungen	Partner bestätigt die Liste
2 Stammdaten und Mapping	GLN und GTIN abgeglichen, Übersetzungstabelle über die volle Struktur	Prüfservice nimmt die selbst erzeugte Nachricht an
3 Testnachrichten	jede vereinbarte Nachricht einmal je Richtung übertragen und verarbeitet	Verarbeitungsnachweis je Nachricht
4 Quittungen	jede vereinbarte Quittung wird erzeugt, gelesen und zugeordnet	jede vereinbarte Quittung im Test gesehen
5 Freigabe	Echtbetrieb, Fehlerweg und Vertretung stehen	schriftliche Freigabe, erster Echtbeleg kontrolliert

Die Phasen 3 und 4 laufen parallel: Eine Nachricht ist erst geprüft, wenn ihr Eingang im Zielsystem bestätigt ist und die vereinbarte Quittung gelesen wurde.

Schritt für Schritt: von der Spezifikation zur Freigabe

Schritt 1: Spezifikation des Partners auswerten

Tragen Sie je Nachricht ein, welche Fassung gilt, in welche Richtung sie läuft, welche Segmente Pflicht sind und welche Quittung erwartet wird. Klären Sie die Reihenfolge: welche Nachricht zuerst in den Echtbetrieb geht und welche später. Ende: Beide Seiten bestätigen dieselbe Liste als Umfang der Anbindung. Wie ein Bestellfluss vom Auftrag bis zur Rechnung aufgebaut ist, zeigt ORDERS, DESADV, INVOIC. Betrifft die Anbindung Rechnungen, ist zusätzlich die Rechtslage des jeweiligen Landes zu prüfen; für Deutschland steht sie in EDI und E-Rechnung.

Schritt 2: Stammdaten abgleichen

GS1 nennt den Datenabgleich den empfohlenen ersten Schritt beim Aufbau einer EDI-Beziehung, weil er die folgenden Schritte verlässlicher macht. Gleichen Sie GLN für Sender, Empfänger und Lieferstellen sowie GTIN je Artikel ab; für Versandeinheiten kommt SSCC/NVE hinzu. Die organisatorischen EDI-Prinzipien verlangen, die GS1-Nummernsysteme in den Nachrichten anstelle oder zusätzlich zu den eigenen Nummern zu verwenden. Ende: Jeder Artikel und jeder Partner trägt eine Nummer, die beide Seiten gleich schreiben.

Schritt 3: Übersetzungstabelle aufbauen

Ordnen Sie die Felder des ERP den Segmenten und Datenelementen der Nachricht zu. GS1 empfiehlt eine Tabelle über die volle Nachrichtenstruktur statt einer Tabelle je Partner, damit weitere Partner keinen Neubau erzwingen. Prüfen Sie dabei Format und Länge: Nach den organisatorischen EDI-Prinzipien sind führende Nullen nur zu senden, wenn sie bedeutsam sind, und es gilt die aktuelle Fassung der EANCOM-Codelisten. Ende: Eine selbst erzeugte Nachricht nimmt der Prüfservice ohne Strukturfehler an.

Schritt 4: Testphase vereinbaren und Testnachrichten senden

Vereinbaren Sie Testfenster, Testkennzeichen, Ansprechpartner und die Zahl der Belege je Nachricht. Artikel 9 der GS1-Mustervereinbarung für INVOIC sieht vor, auch in der Testphase Echtdaten zu nutzen und im UNB-Segment als Testdaten zu kennzeichnen; nach dieser Klausel verarbeitet der Empfänger die Testdaten, behandelt sie aber nicht wie Echtdaten, und die Kennzeichnung kann nach bilateraler Absprache alternativ beim Empfänger erfolgen. Ob Sie die Klausel übernehmen und wie die Testdaten gekennzeichnet werden, folgt aus Ihrer Vereinbarung. Lassen Sie sich je Beleg bestätigen, was im Zielsystem angekommen ist. Ende: Für jede Nachricht in jeder Richtung liegt ein Verarbeitungsnachweis aus dem Zielsystem vor.

Schritt 5: Quittungen einrichten und lesen

Die Konverterebene berichtet mit CONTRL über die Syntaxebene einer Übertragung, nicht über deren fachlichen Inhalt; nach der GS1-Beschreibung kann sie auf die reine Empfangsquittung beschränkt sein, die nur den Empfang bestätigt (Action Code 8; dafür werden UNB, UNZ und gegebenenfalls UNA geprüft). Der zweite mögliche CONTRL-Bericht enthält das Ergebnis der Syntaxprüfung. Die Anwendung des Empfängers kann den Erhalt der Nachricht mit APERAK bestätigen und meldet in ihr die Fehler, die bei der Verarbeitung in der Anwendung festgestellt wurden. Nach der GS1-Beschreibung erzeugt die APERAK die Anwendungssoftware und nicht die Konvertersoftware, und sie darf nicht den Eingang der Übertragungsdatei bestätigen; eine APERAK belegt keine erfolgreiche Verbuchung. Den Verarbeitungsnachweis führen Sie deshalb am Zielsystem, etwa über die Belegnummer des Beispiels. Für CONTRL gilt weiter: Nach der GS1-Beschreibung wird sie nur erzeugt, wenn der Empfänger den Empfang von CONTRL unterstützt, und sie geht immer als eigene Übertragung; auf eine empfangene Übertragungsdatei dürfen höchstens zwei CONTRL-Nachrichten antworten, und die zweite, der Bericht über die Syntaxprüfung, ist zu senden, wenn die Sendung im UNB-Segment eine Quittung anfordert. Ordnen Sie jeder vereinbarten Quittung eine lesende Person und eine Vertretung zu. Ende: Jede vereinbarte Quittung ist im Test angekommen und zugeordnet.

Schritt 6: Fehlerfall proben und freigeben

Erzeugen Sie einen Fall, den die Gegenseite abweisen soll, etwa eine nicht vereinbarte Fassung oder einen Codewert außerhalb der Codeliste, und verfolgen Sie den Weg vom Protokoll über die Korrektur bis zur zweiten Sendung. Dieses Probelaufen ist eine Empfehlung dieser Redaktion, keine Vorgabe eines Standards. Danach geben Sie schriftlich frei, mit Umschaltzeitpunkt, Zuständigkeit und Vertretung. Ende: Der Fehlerweg ist geübt, die Freigabe liegt vor, der erste Echtbeleg ist kontrolliert.

Wenn eine Testnachricht abgewiesen wird

Die Tabelle nennt Ablehnungsgründe, die in den geöffneten GS1-Dokumenten geregelt sind, und die jeweilige Abhilfe.

Ablehnungsgrund	Ursache	Abhilfe
Fassung wird nicht akzeptiert	jede EANCOM-Nachricht nennt ihre Subset-Fassung im Nachrichtenkopf; sie stimmt nicht mit der Vereinbarung überein	Fassung im Nachrichtenkopf prüfen; GS1 empfiehlt, zwei Fassungen desselben Nachrichtentyps gleichzeitig verarbeiten zu können
Senderkennung passt nicht	die GLN im UNB- oder NAD-Segment weicht von den hinterlegten Stammdaten ab	die Mustervereinbarung sieht eine Verarbeitung nur bei vollständiger Übereinstimmung vor; Nummern vor der zweiten Sendung abstimmen
Codewert unbekannt oder veraltet	die Codelisten sind nicht auf dem Stand der Anwendungsempfehlung; GS1 hat in Version 9.3 zum Beispiel den Codewert BJ für die SSCC-Angabe durch AW ersetzt	aktuelle Codelisten einspielen und den Ersatzcode mit dem Partner abstimmen
Format oder Länge weicht ab	führende Nullen, Maßeinheit oder Feldlänge passen nicht zur Vorlage	Formatvorlagen heranziehen; führende Nullen nur senden, wenn sie bedeutsam sind
Keine Quittung zu sehen	die Quittungsanforderung im UNB-Segment war nicht gesetzt, der Empfänger unterstützt den Quittungstyp nicht oder der Übertragungsweg passt nicht	Übertragungsweg, UNB-Segment und die vereinbarten Quittungstypen mit dem Partner prüfen; auf der Anwendungsseite muss die vereinbarte Bestätigung erzeugt werden, sonst fehlt die vereinbarte Rückmeldung über die Verarbeitung
Beleg wird doppelt verarbeitet	eine Sendung wurde ohne Quittung wiederholt	Dublettenprüfung beim Empfänger vereinbaren; die Mustervereinbarung nennt GLN, Rechnungsnummer, Anschrift, Belegart und Rechnungsdatum als Vergleichsmerkmale
Werte sind plausibel, passen aber nicht	die Mustervereinbarung lässt die Kern-Datenfelder untereinander und gegen die Stammdaten prüfen; Menge, Einheit oder Betrag weichen ab	Feldzuordnung kontrollieren und den Fall ins Fehlerprotokoll aufnehmen

Die Mustervereinbarung regelt dazu zwei Stufen: Ein Fehler in der Kennungsprüfung führt zur Nichtverarbeitung der ganzen Übertragungsdatei; betrifft er einzelne Belege, bleibt mindestens der fehlerhafte Beleg unbearbeitet, und fehlerfreie Belege kann der Empfänger verarbeiten. Jeder festgestellte Fehler gehört mit dem Fehlerprotokoll zum Versender.

So prüfen Sie die Freigabe

1. Jede vereinbarte Nachricht ist mindestens einmal in jeder Richtung angekommen und im Zielsystem verbucht; vergleichen Sie über die Belegnummer des Beispiels.
2. Jede vereinbarte Quittung ist gesehen: CONTRL für die Syntaxebene, also für den Empfang oder, im zweiten möglichen Bericht, für das Ergebnis der Syntaxprüfung; APERAK für den Erhalt der Nachricht in der Anwendung und dort festgestellte Verarbeitungsfehler. Eine APERAK belegt keine erfolgreiche Verbuchung; wo beide Quittungen vereinbart sind, deckt keine die Aussage der anderen ab; die Verbuchung prüfen Sie deshalb an Punkt 1 im Zielsystem.
3. Eine bewusst falsche Artikel- oder Lieferstellenangabe wird tatsächlich abgewiesen, statt still verbucht zu werden.
4. Der Fehlerweg ist einmal durchlaufen: Ablehnung, Protokoll, Korrektur, zweite Sendung.
5. Der erste Echtbeleg ist mit dem getesteten Beispiel verglichen und abgelegt.

Die fünf Punkte sind Prüfziele dieser Redaktion. Welche Testarten zu Mengen-, Fehler- und Wiederholungsfällen gehören, ordnet Schnittstellen vor dem Start testen ein.

Wann Sie Hilfe holen sollten

Holen Sie die Softwarebetreuung, den Dienstleister oder die GS1-Mitgliedsorganisation dazu, wenn der Partner keine schriftliche Spezifikation liefert, wenn eine Nachricht ankommt, aber eine vereinbarte Anwendungsbestätigung ausbleibt, wenn die Gegenseite die APERAK aus dem Konverter erzeugt, wenn Ablehnungen ohne verwertbares Fehlerprotokoll wiederkehren oder wenn eine zweite Nachrichtenfassung ansteht.

Den Betrieb nach der Freigabe behandelt Schnittstellenfehler überwachen und wiederholen.