Format · Lesen und Schreiben
EDIFACT ORDERS D96A
Die Bestellnachricht ORDERS im Verzeichnis D96A ist in Handel und Industrie bis heute einer der häufigsten Wege, Bestellungen elektronisch zu übermitteln. every-edi liest und erzeugt ORDERS D96A direkt: Segment für Segment, nach festen Regeln, ohne KI.
Auf einen Blick
- Standard
- UN/EDIFACT
- Nachrichtentyp
- ORDERS (Bestellung)
- Verzeichnis
- D96A
- every-edi
- Lesen und Schreiben
- Verarbeitung
- Regelbasiert, ohne KI
Wofür ORDERS D96A da ist
UN/EDIFACT ist der internationale Standard für den Austausch strukturierter Geschäftsdokumente. Jede Nachrichtenart hat einen Namen (ORDERS ist die Bestellung) und erscheint in Verzeichnissen, die über die Jahre fortgeschrieben wurden. D96A stammt aus dem Jahr 1996. Trotzdem laufen viele Bestellprozesse bis heute darauf, denn wer eine funktionierende Anbindung hat, wechselt das Verzeichnis selten.
Eine ORDERS-Nachricht enthält dasselbe wie eine Papierbestellung: Bestellnummer, Datum, Wunschtermin, Besteller, Lieferadresse und Positionen mit Artikelnummer, Menge und Preis. Der Unterschied ist die feste Struktur, die ein ERP ohne Abtippen übernehmen kann.
Wer ORDERS verlangt
Meist sind es die großen Kunden: Handelsketten, Großhändler, Industriekonzerne und Einkaufsverbände. Für sie ist EDI der Normalfall, und von Lieferanten wird erwartet, dass sie Bestellungen elektronisch annehmen. Dazu kommt fast immer eine eigene Spezifikation des Partners (Implementierungsrichtlinie oder „Message Implementation Guide“). Sie legt fest, welche Segmente Pflicht sind und welche Codes gelten.
Im Handel ist dabei oft EANCOM gemeint, das GS1-Subset von EDIFACT. EANCOM 1997 basiert auf D96A; die neuere Fassung EANCOM 2002 basiert auf D01B. Ob die Vorgaben Ihres Partners abgedeckt sind, prüfen wir an seiner Spezifikation und einer Beispieldatei.
Beispiel
Eine fiktive Bestellung über drei Positionen. Jede Zeile ist ein Segment: Das Apostroph beendet es, „+“ trennt Datenelemente, „:“ trennt Komponenten innerhalb eines Datenelements.
UNA:+.? '
UNB+UNOC:3+4012345000009:14+4098765000003:14+261008:0930+1042'
UNH+1+ORDERS:D:96A:UN'
BGM+220+4500012345+9'
DTM+137:20261008:102'
DTM+2:20261015:102'
FTX+DEL+++Rampe 3?: Anlieferung Mo-Fr 7-14 Uhr'
NAD+BY+4012345000009::9'
NAD+SU+4098765000003::9'
NAD+DP+4012345000016::9'
CUX+2:EUR:9'
LIN+1++4012345678901:EN'
PIA+1+ART-7720:SA'
IMD+F++:::Hydraulikzylinder HZ-200/100'
QTY+21:4:PCE'
PRI+AAA:285.00'
LIN+2++4012345678918:EN'
PIA+1+ART-3381:SA'
IMD+F++:::Dichtungsset DS-200'
QTY+21:4:SET'
PRI+AAA:42.50'
LIN+3++4012345678925:EN'
PIA+1+ART-9910:SA'
IMD+F++:::Hydraulikschlauch 2m DN10'
QTY+21:10:MTR'
PRI+AAA:18.90'
UNS+S'
CNT+2:3'
UNT+27+1'
UNZ+1+1042'Alle Namen, Nummern und GLNs im Beispiel sind fiktiv.
| Segment | Bedeutung |
|---|---|
| UNA:+.? ' | Legt die Trennzeichen fest: Komponente, Datenelement, Dezimalzeichen, Freigabezeichen, Segmentende. Optional; fehlt UNA, gelten die Standardzeichen. |
| UNB+UNOC:3+…:14+…:14+261008:0930+1042 | Kopf der Übertragung: Zeichensatz UNOC (Latin-1, mit Umlauten), Syntaxversion 3, GLN von Absender und Empfänger (14 = GS1), Datum und Uhrzeit, Übertragungsreferenz. |
| UNH+1+ORDERS:D:96A:UN | Nachrichtenkopf: Typ ORDERS, Verzeichnis D, Release 96A, herausgebende Organisation UN. |
| BGM+220+4500012345+9 | Beginn der Nachricht: 220 = Bestellung, danach die Bestellnummer des Kunden, 9 = Original. |
| DTM+137:20261008:102 | Bestelldatum (137) im Format 102, also JJJJMMTT. |
| DTM+2:20261015:102 | Gewünschter Liefertermin (2). |
| FTX+DEL+++Rampe 3?: … | Freitext zur Lieferung. Das „?“ vor dem Doppelpunkt ist das Freigabezeichen; ohne es würde der Doppelpunkt als Trennzeichen gelesen. |
| NAD+BY+4012345000009::9 | Besteller (BY), identifiziert über seine GLN; 9 = Codeliste von GS1. |
| NAD+SU+4098765000003::9 | Lieferant (SU), also Sie. |
| NAD+DP+4012345000016::9 | Lieferanschrift (DP), hier ebenfalls als GLN statt als ausgeschriebene Adresse. |
| CUX+2:EUR:9 | Währung der Bestellung. |
| LIN+1++4012345678901:EN | Position 1, Artikel identifiziert über die GTIN (EN). |
| PIA+1+ART-7720:SA | Zusätzliche Artikelnummer: Ihre Lieferanten-Artikelnummer (SA). |
| IMD+F++:::Hydraulikzylinder … | Artikelbeschreibung als Freitext (F). |
| QTY+21:4:PCE | Bestellmenge (21): 4 Stück (PCE). |
| PRI+AAA:285.00 | Nettopreis (AAA) je Einheit, mit Punkt als Dezimaltrennzeichen. |
| UNS+S | Trennt die Positionen vom Summenteil. |
| CNT+2:3 | Kontrollzahl: Anzahl der Positionen (2), hier 3. |
| UNT+27+1 | Nachrichtenende: Zahl der Segmente von UNH bis einschließlich UNT, dazu die Nachrichtenreferenz aus UNH. |
| UNZ+1+1042 | Ende der Übertragung: Zahl der Nachrichten und die Referenz aus UNB. |
Typische Stolperfallen
-
GLN statt Kundennummer
Große Kunden adressieren Besteller und Lieferorte über 13-stellige GLNs. Ihr ERP kennt den Kunden aber unter seiner Kundennummer. Ohne saubere Zuordnung von GLN zu Kundennummer und Lieferadresse geht die Ware ans falsche Lager.
-
Qualifier bestimmen die Bedeutung
DTM+2 ist der gewünschte Liefertermin, DTM+137 das Bestelldatum, DTM+64 und DTM+63 begrenzen ein Lieferfenster. NAD+BY, NAD+DP und NAD+IV sind verschiedene Parteien. Wer Qualifier verwechselt, liest das falsche Datum oder hält die Rechnungs- für die Lieferadresse.
-
Versionen und Subsets
D96A ist nicht D01B, und das Subset eines Partners ist nicht der ganze Standard. Ein falscher Nachrichtenkopf oder ein fehlendes Pflichtsegment aus der Partnerspezifikation führt zur Ablehnung. Version und Spezifikation gehören vor dem ersten Testlauf geklärt.
-
Zeichensatz und Freigabezeichen
Die Zeichensätze UNOA und UNOB kennen keine Umlaute; dafür braucht es UNOC oder eine vereinbarte Alternative. Ein „+“, „:“ oder Apostroph im Artikeltext muss mit „?“ maskiert werden, sonst zerfällt das Segment.
-
Einheiten und Preisbasis
Mengeneinheiten kommen als Codes (PCE, SET, MTR, KGM), nicht als „Stk“. Preise können je Einheit oder je Preisbasis gemeint sein, etwa je 100 Stück. Wer das übersieht, berechnet das Hundertfache.
-
Kontrollzählungen
UNT zählt die Segmente der Nachricht, UNZ die Nachrichten der Übertragung. Stimmt eine dieser Zahlen nicht, lehnt das System des Partners die ganze Datei ab.
Was every-edi damit macht
- Lesen: Eingehende ORDERS D96A werden direkt geparst, ohne KI, reproduzierbar und in Sekunden.
- Schreiben: Aus PDF-, E-Mail-, CSV- oder cXML-Bestellungen entsteht auf Wunsch eine ORDERS D96A für Ihr ERP oder Ihr bestehendes EDI-System.
- Keine Lernphase für EDIFACT: Bekannte Formate wie EDIFACT, cXML und bekannte XML- und CSV-Formate werden direkt nach Regeln gelesen. Nur unbekannte Formate (PDF, E-Mail, neue CSV- oder XML-Layouts) analysiert bei der ersten Datei einmalig die KI; ein Mensch prüft das Ergebnis, danach verarbeitet das gelernte Profil die Dokumente dieses Absenders ohne KI.
- Unvollständige oder unplausible Nachrichten landen im Prüf-Dashboard statt ungeprüft im ERP.
- Übertragung per SFTP, E-Mail oder überwachtem Ordner; AS2 auf Anfrage, X.400 und OFTP2 über Partner.
Was (noch) nicht dazugehört
Bei EDIFACT unterstützt every-edi derzeit ausschließlich die Bestellung ORDERS im Verzeichnis D96A. Andere Verzeichnisse wie D01B (und damit EANCOM 2002) sowie andere Nachrichtentypen wie Rechnung (INVOIC), Lieferavis (DESADV) oder Auftragsbestätigung (ORDRSP) gehören noch nicht dazu.
Weitere Formate
Außerdem verarbeitet every-edi GEVIS-XML (GEVISEDI01), CSV mit Kopf- und Positionszeilen (HDR/POS), frei aufgebaute CSV-Tabellen über gelernte CSV-Profile sowie JSON über eine REST-Schnittstelle.
Schicken Sie uns eine echte Datei.
Ob every-edi zu Ihren Kunden passt, klären wir am schnellsten an echten Beispielen: drei Bestellungen und, falls vorhanden, die Spezifikation Ihres Partners. Sie bekommen das Ergebnis im Zielformat zurück.
Demo anfragen