EDIFACT ORDERS — Purchase Order
The buyer's electronic purchase order in UN/EDIFACT—the same business role as X12 850, with BGM document codes, NAD parties, and LIN line items structured for European and global trade.
✦ What It Does
ORDERS carries the commercial order from customer to supplier: contract references, requested delivery dates, item identifiers (EAN, buyer item number, supplier article), quantities, prices, and ship-to locations. Trading partners typically enforce a specific directory release (for example D.01B ORDERS) plus a subset message implementation guideline.
Unlike X12's BEG/PO1 pattern, ORDERS groups data under BGM (beginning of message) for document type and order number, NAD loops for BY (buyer), SU (supplier), DP (delivery party), and line grids built from LIN with QTY, PRI, MOA, and IMD for descriptions. Allowances and charges often appear as ALC with accompanying MOA or PCD.
Retail, automotive, and industrial ORDERS implementations vary widely: some partners require RFF for buyer contract references, TDT or TSR for routing, and PAC for packaging hints. Mapping must align qualifier codes and code lists to your ERP's order object model.
⚡ When It's Used
- A retailer or manufacturer releases a new purchase in the ERP and the integration emits ORDERS to the supplier.
- Replenishment or VMI logic calculates need and transmits ORDERS without manual buyer intervention.
- A distributor converts a customer order into a supplier ORDERS for upstream fulfillment.
- Cross-border trade where the hub partner mandates EDIFACT instead of X12.
- Testing and certification cycles with a new European trading partner before go-live.
Who Uses EDIFACT ORDERS
Retail & CPG
European retailers and global brands exchange ORDERS with suppliers and co-packers. Item identification often leans on GTIN and buyer catalog numbers; delivery windows use DTM with qualifier patterns from the partner MIG.
Manufacturing & Automotive
OEMs send ORDERS or combine ORDERS with schedule messages (DELFOR/DELJIT) for component supply. Line release references may link to long-term agreements in RFF segments.
3PL & distributors
When the 3PL buys on behalf of the brand or receives a direct ORDERS for stock transfer, the message seeds WMS and TMS workflows that later produce DESADV and IFTSTA.
Key Segments & Constructs
EDIFACT uses a hierarchical structure: UNH (message header) opens the transaction; BGM (beginning of message) carries the document name and reference; party data uses NAD; lines often use LIN with QTY, PRI, and MOA. Exact segment requirements depend on the message directory (D.96A, etc.) and your trading partner's implementation guide.
UNH / UNT
UNH identifies the message type (ORDERS), version, and control reference; UNT closes the message and must match segment counts for syntactic validation.
BGM
Document/message name, function code (e.g., original, change), and the buyer's order number—the primary key carried into ORDRSP, DESADV, and INVOIC.
NAD and RFF
NAD identifies parties with qualifiers (BY, SU, DP); RFF carries secondary references such as contract, project, or department codes required for routing and AP matching.
LIN / QTY / PRI
LIN introduces each line with product IDs in C212; QTY states ordered quantity with unit of measure; PRI communicates net or gross prices and price basis.
Related Messages
X12 Purchase Order
North American equivalent transaction set when partners use ASC X12 instead of EDIFACT.
Despatch Advice
ASN-style shipment notification that references the ORDERS line and quantities actually shipped.
Need Help with EDIFACT ORDERS?
Better EDI maps, tests, and operates EDIFACT alongside X12—same platform, translation when partners use different standards.
Talk to an EDI Expert