Format · Read and write
EDIFACT ORDERS D96A
The ORDERS purchase order message from directory D96A is still one of the most common ways to send orders electronically in retail and manufacturing. every-edi reads and generates ORDERS D96A directly: segment by segment, by fixed rules, without AI.
At a glance
- Standard
- UN/EDIFACT
- Message type
- ORDERS (purchase order)
- Directory
- D96A
- every-edi
- Read and write
- Processing
- Rule-based, no AI
What ORDERS D96A is for
UN/EDIFACT is the international standard for exchanging structured business documents. Each message type has a name (ORDERS is the purchase order) and is published in directories that have been revised over the years. D96A dates from 1996, yet many order flows still run on it: once a connection works, nobody is keen to change the directory.
An ORDERS message carries the same content as a paper order: order number, date, requested delivery date, buyer, delivery address, and lines with item number, quantity and price. The difference is the fixed structure, which an ERP system can take over without anyone retyping it.
Who requires ORDERS
Usually the large customers: retail chains, wholesalers, manufacturing groups and purchasing associations. For them EDI is the norm, and suppliers are expected to accept orders electronically. There is almost always a partner-specific specification as well (an implementation guideline or “message implementation guide”) that sets out which segments are mandatory and which codes apply.
In retail this often means EANCOM, the GS1 subset of EDIFACT. EANCOM 1997 is based on D96A; the newer EANCOM 2002 is based on D01B. We check your partner’s specification and a sample file to confirm their requirements are covered.
Example
A fictitious order with three lines. Each line is a segment: the apostrophe ends it, “+” separates data elements, and “:” separates components within a data element.
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'All names, numbers and GLNs in the example are fictitious.
| Segment | Meaning |
|---|---|
| UNA:+.? ' | Defines the delimiters: component, data element, decimal mark, release character, segment terminator. Optional; without UNA the default characters apply. |
| UNB+UNOC:3+…:14+…:14+261008:0930+1042 | Interchange header: character set UNOC (Latin-1, includes accented letters), syntax version 3, sender and recipient GLN (14 = GS1), date and time, interchange reference. |
| UNH+1+ORDERS:D:96A:UN | Message header: type ORDERS, directory D, release 96A, controlling agency UN. |
| BGM+220+4500012345+9 | Beginning of message: 220 = order, then the customer’s order number, 9 = original. |
| DTM+137:20261008:102 | Order date (137) in format 102, i.e. CCYYMMDD. |
| DTM+2:20261015:102 | Requested delivery date (2). |
| FTX+DEL+++Rampe 3?: … | Free text about delivery. The “?” before the colon is the release character; without it the colon would be read as a delimiter. |
| NAD+BY+4012345000009::9 | Buyer (BY), identified by GLN; 9 = GS1 code list. |
| NAD+SU+4098765000003::9 | Supplier (SU), meaning you. |
| NAD+DP+4012345000016::9 | Delivery party (DP), again given as a GLN rather than a written address. |
| CUX+2:EUR:9 | Order currency. |
| LIN+1++4012345678901:EN | Line 1, item identified by its GTIN (EN). |
| PIA+1+ART-7720:SA | Additional item number: your supplier article number (SA). |
| IMD+F++:::Hydraulikzylinder … | Item description as free text (F). |
| QTY+21:4:PCE | Ordered quantity (21): 4 pieces (PCE). |
| PRI+AAA:285.00 | Net price (AAA) per unit, with a full stop as decimal mark. |
| UNS+S | Separates the lines from the summary section. |
| CNT+2:3 | Control total: number of lines (2), here 3. |
| UNT+27+1 | Message trailer: number of segments from UNH up to and including UNT, plus the message reference from UNH. |
| UNZ+1+1042 | Interchange trailer: number of messages and the reference from UNB. |
Common pitfalls
-
GLN instead of customer number
Large customers identify buyers and delivery points by 13-digit GLNs. Your ERP knows the customer by its customer number. Without a clean mapping from GLN to customer number and delivery address, goods go to the wrong warehouse.
-
Qualifiers define the meaning
DTM+2 is the requested delivery date, DTM+137 the order date, DTM+64 and DTM+63 bound a delivery window. NAD+BY, NAD+DP and NAD+IV are different parties. Mix up the qualifiers and you read the wrong date or treat the invoice address as the delivery address.
-
Versions and subsets
D96A is not D01B, and a partner’s subset is not the full standard. A wrong message header or a segment missing from the partner specification gets the file rejected. Settle the version and specification before the first test run.
-
Character set and release character
Character sets UNOA and UNOB have no accented letters such as German umlauts; you need UNOC or an agreed alternative. A “+”, “:” or apostrophe in an item text must be escaped with “?”, or the segment falls apart.
-
Units and price basis
Units of measure arrive as codes (PCE, SET, MTR, KGM), not as “pcs”. Prices can be per unit or per price basis, for example per 100 pieces. Miss that and you invoice a hundred times the amount.
-
Control counts
UNT counts the segments in the message, UNZ the messages in the interchange. If either number is wrong, the partner’s system rejects the whole file.
What every-edi does with it
- Read: incoming ORDERS D96A are parsed directly, without AI, reproducibly and in seconds.
- Write: PDF, email, CSV or cXML orders can be turned into ORDERS D96A for your ERP or your existing EDI system.
- No learning phase for EDIFACT: known formats such as EDIFACT, cXML and known XML and CSV formats are parsed directly by rules. Only unknown formats (PDF, email, new CSV or XML layouts) are analysed once with AI on the first file; a person checks the result, and from then on the learned profile processes that sender’s documents without AI.
- Incomplete or implausible messages go to the review dashboard instead of straight into your ERP.
- Transport via SFTP, email or a watched folder; AS2 on request, X.400 and OFTP2 through partners.
What is not included (yet)
For EDIFACT, every-edi currently supports only the ORDERS purchase order in directory D96A. Other directories such as D01B (and therefore EANCOM 2002) and other message types such as invoice (INVOIC), despatch advice (DESADV) or order response (ORDRSP) are not included yet.
Other formats
every-edi also handles GEVIS XML (GEVISEDI01), CSV with header and line records (HDR/POS), free-form CSV tables via learned CSV profiles, and JSON over a REST interface.
Send us a real file.
The quickest way to find out whether every-edi fits your customers is with real examples: three orders and, if you have one, your partner’s specification. You get the result back in the target format.
Request a demo