ORDERS, DESADV, INVOIC: Nachrichtenfluss einer Bestellung

Eine Bestellung läuft im EDI als Kette von Nachrichten: Die Bestellung geht hinaus, Bestellantwort und Liefermeldung kommen zurück, am Ende steht die Rechnung. Für die Abbildung im ERP zählt je Nachricht zweierlei – welche Belegart sie ist und in welchem Segment welche Angabe steht. Der folgende Ablauf zeigt beides.

Welche Nachricht welchen Schritt trägt

Der Ablauf in Schritten, mit den tragenden Segmenten je Nachricht und dem, was daraus im ERP wird:

Schritt	Nachricht	Richtung	Tragende Segmente	Was daraus im ERP wird
1	ORDERS	Käufer an Lieferant	UNH, BGM (220), DTM (137, 2), NAD (BY), LIN, QTY (21), PRI, UNS, MOA (86), UNT	die Bestellung mit Mengen, Terminen und Lieferorten; je Position die Artikelidentifikation über die GTIN
2	ORDRSP	Lieferant an Käufer	UNH, BGM (231), QTY (21, 12, 83), QVR, UNS, MOA (79), UNT	Annahme, Änderungsvorschlag oder Ablehnung der Bestellung; eine Bestellung kann mehrere Antworten erhalten
3	DESADV	Lieferant an Käufer	UNH, BGM (351), RFF (ON, DQ), GIN (AW), QTY (12), CNT (2), UNT	den Inhalt der Sendung; der Empfänger kann den Wareneingang vorbereiten und mit der Bestellung vergleichen
4	RECADV	Käufer an Lieferant	UNH, BGM, RFF (ON, DQ), LIN, QTY (46, 194), CNT, UNT	was empfangen, akzeptiert oder abgelehnt wurde; sie ermöglicht dem Lieferanten die Rechnung
5	INVOIC	Lieferant an Käufer	UNH, BGM (380), RFF (ON, DQ, AAK), LIN, TAX, UNS, MOA (77, 9, 124), PAT mit DTM, UNT	die Zahlungsforderung; sie kann mehrere Bestellungen und Lieferungen zusammenfassen
6	REMADV	in beide Richtungen	UNH, BGM, DOC (Urbelegnummer), MOA (77, 11), UNS, MOA (9, 12), UNT	das Zahlungsavis mit Betrag und Regulierungsdatum zu einem oder mehreren Vorgängen
7	CONTRL	Empfänger an Absender	UNH, UCI, UCM, UCS, UCD, UNT	den Syntax- und Servicebericht: Erhalt der Übertragungsdatei und Syntaxfehler, nicht die Geschäftsdaten
8	APERAK	Empfänger an Absender	UNH, BGM, DOC, ERC, FTX, UNT	die Bestätigung und Fehlermeldung aus dem Anwendungssystem des Empfängers

Den genauen Informationsfluss gibt der Standard nicht vor: Nach der GS1-Beschreibung kann die Reihenfolge von Bestellung, Bestellantwort und Bestelländerung abweichen; die Vorgehensweise gehört in eine Austauschvereinbarung. RECADV läuft entgegen der Lieferrichtung und ist nach der GS1-Beschreibung die Rückmeldung, die dem Lieferanten die Rechnung ermöglicht. APERAK erzeugt ausdrücklich die Anwendungssoftware und nicht die Konvertersoftware; CONTRL dagegen bestätigt den Erhalt auf Syntaxebene. Für den Betrieb sind das zwei getrennte Fehlerwege.

Wie eine Nachricht aufgebaut ist

EANCOM 2002 ist das GS1-Subset ausgewählter UN/EDIFACT-Nachrichtentypen und beruht auf dem UN/EDIFACT Directory D.01B in der Syntaxversion 3; die Syntaxregeln selbst stehen in der Norm ISO 9735. Verbindlich wird eine Nachricht nicht durch den Standard allein, sondern über die Vereinbarung der Partner, in der GS1-Terminologie der EDI-Vertrag. Der Aufbau der Datei: Ein Umschlag aus UNA (Trennzeichen), UNB (Absender, Empfänger, Datenaustauschreferenz) und UNZ umschließt eine oder mehrere Nachrichten, jede von UNH bis UNT; für Nachrichtengruppen gibt es zusätzlich UNG und UNE.

Eine Nachricht gliedert sich in Kopf-, Positions- und Summenteil. Ob es einen Summenteil gibt und ob ihn ein UNS-Segment einleitet, hängt vom Nachrichtentyp ab: ORDERS, ORDRSP, INVOIC und REMADV setzen ein UNS vor ihren Summenteil, DESADV und RECADV enden nach dem Positionsteil mit CNT und UNT. Ob eine Nachricht Beträge führt, entscheidet dagegen das Partnerprofil: Die Anwendungsempfehlung DE Gesamt, aus der die Beispiele hier stammen, weist für DESADV und RECADV kein MOA-Segment aus; der allgemeine EANCOM-Standard lässt im DESADV optionale MOA im Kopf (Segment 8) und auf Positionsebene (Segment 43) zu, dort für Anhaltspreise, Vormeldungen und Angaben für die Zollabfertigung. Maßgeblich ist die Strukturliste des vereinbarten Profils. Innerhalb der Teile stehen Segmente und Segmentgruppen, deren Datenelemente ein Qualifier mit Bedeutung versieht. Den Aufbau einer einzelnen Nachricht erklärt EDIFACT-Nachrichtenaufbau.

Welches Segment welches ERP-Feld füllt

Die Beispiele stammen aus den Beispielnachrichten der deutschen GS1-Anwendungsempfehlung EANCOM 2002, Version 9.3, Profil „Gesamt“ (Beispieldaten, nicht Ihre Nummernkreise); Feldnamen sind neutral gehalten. Die Segmentangaben sind auf die genannten Datenelemente gekürzt, Auslassungen sind nicht als Punkte gekennzeichnet.

Nachricht	Segment	Beispiel	ERP-Feld
ORDERS	BGM	BGM+220::9:X+128576+9	Belegart Bestellung (220) und Bestellnummer
ORDERS	DTM	DTM+137:20181020:102	Belegdatum des Auftrags
ORDERS	DTM	DTM+2:20181028:102	gewünschtes Lieferdatum
ORDERS	NAD	NAD+BY+4398765000004::9	Käufer als GLN; beim Empfang der Bestellung der Kunde im Kundenstamm
ORDERS	LIN	LIN+3++4000004000033:SRV	Position und Artikel über die GTIN
ORDERS	QTY	QTY+21:20	bestellte Menge
ORDERS	PRI	PRI+AAA:10::LIU	Netto-Listenpreis je bestellter Einheit
ORDERS	MOA	MOA+86:121.99	Bestellwert im Summenteil, als Gegenrechnung zu den Positionen
ORDRSP	BGM	BGM+231:::X+128222+29	Belegart Bestellantwort (231), Antwortnummer und Nachrichtenfunktion 29 (akzeptiert ohne Änderung; 4 Änderung, 27 nicht akzeptiert)
ORDRSP	QTY	QTY+21:20, QTY+12:10, QTY+83:10	bestellte, ausgelieferte und nachzuliefernde Menge
ORDRSP	QVR	QVR+-4:21	Mengenabweichung gegenüber der Bestellung
ORDRSP	MOA	MOA+79:200	Gesamtpositionsbetrag im Summenteil
DESADV	BGM	BGM+351::9:X+87441+9	Belegart Liefermeldung (351) und ihre Nummer
DESADV	RFF	RFF+ON:4711, RFF+DQ:4714	Bestellnummer des Käufers, Lieferscheinnummer
DESADV	GIN	GIN+AW+340123450000000014	Nummer der Versandeinheit (SSCC)
DESADV	QTY	QTY+12:5	versendete Menge der Position
INVOIC	BGM	BGM+380:::KOSTENRECHNUNG+87441+9	Belegart Handelsrechnung (380), Rechnungsnummer und der Dokumentenname des Beispiels
INVOIC	RFF	RFF+ON:4711, RFF+DQ:4714, RFF+AAK:4714	Bestellnummer, Lieferscheinnummer, Liefermeldungsnummer
INVOIC	TAX	TAX+7+VAT+ABC123++:::19+S	Steuersatz und Steuerkennzeichen
INVOIC	MOA	MOA+77:121.99, MOA+9:141.99, MOA+124:16.83	Rechnungsbetrag, Zahlbetrag, Gesamtsteuerbetrag
INVOIC	PAT und DTM	PAT+3, DTM+13:20100415:102	Zahlungsbedingung und Fälligkeitsdatum
REMADV	MOA	MOA+77:100, MOA+11:97, nach dem UNS MOA+9:100, MOA+12:97	Rechnungsbetrag und regulierter Betrag je Beleg, danach Summe über alle Belege und regulierter Gesamtbetrag
alle	UNH und UNT	UNH+ME0001+ORDERS:D:01B:UN:EAN011, UNT+182+ME0001	Nachrichtentyp, Fassung und Segmentzahl, für die Prüfung der Datei
ORDERS, ORDRSP, INVOIC, REMADV	UNS	UNS+S	Beginn des Summenteils; DESADV und RECADV führen kein UNS, schließen mit CNT und UNT und führen in der Anwendungsempfehlung DE Gesamt auch kein MOA (der allgemeine EANCOM-Standard lässt im DESADV optionale MOA im Kopf und auf Positionsebene zu)

Zwei Dinge entscheiden über das Mapping. Erstens die Belegart im BGM: Derselbe Segmentaufbau trägt je nach Codewert Bestellung, Bestellantwort, Liefermeldung oder Rechnung – wer nur den Segmentbezeichner liest, wirft alle Belege in einen Topf. Zweitens der Qualifier: QTY braucht den Code 21 oder 12, sonst landet die versendete Menge im Feld der bestellten. RFF trägt mit ON, DQ und AAK drei Nummern, die im ERP drei Felder brauchen, weil die Buchhaltung die Rechnung über genau diese Nummern dem Auftrag und dem Lieferschein zuordnet, wie es der Dreifach-Abgleich verlangt.

Was Sie vor dem Mapping festlegen

• Belegarten zuordnen: 220, 231, 351 und 380 sind vier verschiedene Belegtypen, auch wenn sie in denselben Nachrichtenaufbau passen.
• Referenzen speichern: Wer ORDERS versendet, muss die eigene Bestellnummer aus dem BGM (DE 1004) in DESADV und INVOIC als RFF+ON wiederfinden; wer ORDERS empfängt, gibt sie in ORDRSP, DESADV und INVOIC mit dem Qualifier ON zurück. ORDERS selbst führt die Bestellnummer im BGM, nicht in einem RFF-Segment.
• Stammdaten vor Bewegungsdaten: Nach dem EANCOM-Handbuch werden Artikel über GTIN und Partner über GLN abgeglichen, bevor Bestellung, Lieferavis oder Rechnung laufen.
• Maßeinheit abstimmen: Das Mengensegment führt die Menge und die zugehörige Maßeinheit; ohne Abstimmung landen Stück und Karton im selben Feld.
• Fassung je Partner klären: Das UNH-Segment nennt Nachrichtentyp, Version, Release und Anwendungscode. Partner können unterschiedliche Fassungen fahren; legen Sie das Mapping deshalb je Nachrichtentyp über die volle Struktur an, nicht je Partner, wie EDI für den Mittelstand beschreibt.

So prüfen Sie eine Nachricht

1. Lesen Sie im BGM die Belegart und die Belegnummer und ordnen Sie den Beleg dem richtigen Objekt zu.
2. Prüfen Sie den Umschlag: Absender- und Empfänger-GLN sowie Datenaustauschreferenz im UNB, Nachrichtenreferenz, Typ und Fassung im UNH, Segmentzahl im UNT.
3. Ordnen Sie die Referenzen aus den RFF-Segmenten zu: Bestellnummer (ON), Lieferscheinnummer (DQ), Liefermeldungsnummer (AAK).
4. Rechnen Sie die Positionen nach: LIN identifiziert den Artikel, QTY die Menge, PRI den Preis. Einen Summenteil nach dem UNS-Segment mit Beträgen in MOA haben ORDERS, ORDRSP, INVOIC und REMADV; dort muss die Summe zu den Positionen passen. DESADV und RECADV führen kein UNS und schließen mit CNT und UNT; in der Anwendungsempfehlung DE Gesamt führen sie auch kein MOA, während der allgemeine EANCOM-Standard im DESADV optionale MOA im Kopf und auf Positionsebene zulässt.
5. Legen Sie die Rückmeldungen fest: CONTRL für Syntaxfehler, APERAK für Anwendungsfehler, mit Wiederholung und Abgleich, wie Schnittstellenfehler überwachen sie beschreibt.
6. Testen Sie mit echten Testdaten gegen das Partnerprofil und geben Sie erst danach frei; den Ablauf beschreibt Neuen EDI-Partner anbinden.

Ob Portal, EDI oder Shop zu Ihren Bestellungen passt, hängt von Partnern und Belegmenge ab (B2B-Bestellweg wählen); den Betrieb der Nachrichten behandelt EDI-Konverter oder Dienstleister.