EDIFACT ORDERS: Purchase Order Segments and Example

ORDERS is the first message in nearly every EDIFACT order cycle. If you are taking on a UK or European retail customer, it is the message your system has to read first and get right, because every response you send afterwards (ORDRSP, DESADV, INVOIC) quotes back what it contained. Misread one quantity or one delivery point here and the error travels through the despatch advice, the invoice and the remittance.

This guide uses the GS1 EANCOM 2002 layout of ORDERS (directory D.01B), which is what most retail partners base their specifications on. Every example below is live: it is parsed in your browser by the same engine as our EDIFACT inspector, so you can expand each segment, check the counts and open it in the full tool. If EDIFACT syntax is new to you, start with EDIFACT explained.

What is an EDIFACT ORDERS message?

ORDERS is the UN/EDIFACT purchase order message: a buyer's request to a supplier for goods or services, with quantities, prices, dates and delivery locations. It is defined in the UN/EDIFACT directories (for example D.96A and D.01B) and profiled for retail by GS1 EANCOM, which restricts it to the segments and codes the consumer goods sector uses.

The message has three sections:

• Header: order number and type, dates, references, parties, currency, payment and delivery terms.
• Detail: one segment group per line item, always starting with LIN.
• Summary: UNS+S marks the end of the detail section, then optional totals (MOA) and a CNT control count.

GS1's own principle for the message is simple: one purchase order for one delivery to one location at one time. Everything else (split deliveries, blanket orders, call-offs, promotions) is a variation on that, and each has a defined place in the structure.

When ORDERS is sent in the order-to-cash flow

ORDERS starts the cycle. Everything after it refers back to its order number in an RFF+ON segment.

The full catalogue of messages is in EDIFACT message types. UK grocery suppliers often see the TRADACOMS order file instead of, or alongside, ORDERS; see TRADACOMS ORDHDR for that format.

Example 1: a standard order, segment by segment

A fictional UK retailer, Harbour Lane Stores, orders three homeware lines from a fictional supplier, Kestrel Valley Homeware, for delivery to its distribution centre. Every identifier is a made-up GS1-style number with a valid check digit.

The association code at the end of the UNH (EAN010 here) tells you which EANCOM subset version the sender built to. Partners name the exact value in their implementation guide. GS1's current ORDERS manual shows EAN010 in its worked example while its UNH code list has moved on to EAN011, which is a good reminder to validate against your partner's guide rather than a single global rule.

ORDERS segment reference

The table follows the EANCOM 2002 message structure. Status is M (mandatory) or C (conditional), and repeats are the maximum the manual allows. "SG" is the segment group the segment sits in.

In practice a typical retail order uses perhaps a dozen of these. The rest exist for specific business cases, which is why the partner's implementation guide matters more than the full list.

Qualifier and code tables

BGM: order type and function

BGM+220+HL-PO-88231+9' has three parts: the document name code, the order number, and the message function.

EANCOM recommends the more specific code where one applies, rather than the general 220. A blanket order (221) sets a global quantity per line over a period, and later call-offs (226) draw down parts of it with their own dates and locations.

A fourth element can ask for a response: BGM+220+HL-PO-88231+9+AC' requests an acknowledgement with detail and changes, while NA says no acknowledgement is needed. If a partner sends AC, treat an ORDRSP as required for that order.

DTM: date qualifiers

Format 102 is CCYYMMDD and 203 is CCYYMMDDHHMM, so DTM+63:202610181430:203' means "deliver by 14:30 on 18 October 2026". A delivery window is two segments: DTM+64 and DTM+63.

NAD: party qualifiers

BY buyer and SU supplier are mandatory. DP delivery party and IV invoicee are added when they differ from the buyer; SN store number and CO corporate office also appear. Parties are identified by GLN, with 9 in the agency position. EANCOM allows a full name and address only where a coded identity cannot be used, so most partners send the GLN alone and expect you to hold the address in master data.

PIA: other product codes

PIA+1+KV-1001:SA' adds the supplier's article number and PIA+1+...:IN the buyer's item number. PIA+2 offers a substitute GTIN, PIA+X1 says no substitution is accepted, and PIA+5 carries the primary code for a product with no GTIN. EANCOM makes the GTIN in LIN mandatory whenever one exists.

QTY and PRI

EANCOM is firm on one point: the calculation price in an order is always the net unit price. Allowances and charges in the same order are there for information, so do not subtract them again from PRI+AAA.

Example 2: multi-drop order with deliveries to several stores

Here the buyer orders for three stores at once. There is no header delivery party; instead, each line carries a LOC+7 group per store with its own split quantity (QTY+11) and delivery date.

Three rules make split deliveries work:

1. The split quantities must add up. EANCOM requires the QTY+11 values in the LOC groups to equal the line's QTY+21. Line 1 orders 36 and splits 12, 12 and 12.
2. The line-level location overrides the header. If the header has a NAD+DP, it is the default delivery point for lines without their own LOC groups.
3. Each location becomes its own delivery. Your warehouse needs one pick, one despatch advice and usually one invoice per store, all quoting the same order number.

This is where ERP imports most often go wrong. A sales order that can hold only one ship-to will either take the first LOC and send everything there, or reject the order. Decide before go-live how a multi-drop order becomes sales orders in your ERP (one per location is the usual answer), and keep the buyer's order number on each so the despatch advice and invoice can quote it.

Example 3: promotional order with free goods

Retailers order differently for promotions: larger quantities, a promotional price, sometimes free stock. EANCOM handles this with a promotion reference at header level and promotional price and free goods codes at line level.

What to check on a promotional order:

• RFF+PD is the promotion deal number. Carry it through to your invoice, because promotional pricing is usually reconciled against it.
• PRI+AAA:7.20::PRP' is still the net price you will be paid; PRP in the price specification position flags it as promotional. If it differs from your price list, that is expected for the promotion period, not a pricing error to reject.
• QTY+192:24' is a free goods quantity: pick and despatch it, but do not invoice it at the line price.
• Header DTM+15 (promotion start) is only used when there is no promotion reference. With RFF+PD present, the dates live in your promotion agreement.

Example 4: order with a line allowance and order totals

Some buyers show how the net price was reached: a list price, a discount and the resulting net price, with order totals in the summary.

On line 1, ALC+A+++1+TD' is an allowance (A), calculation step 1, of type trade discount (TD). PCD+3:5' makes it 5 percent and MOA+204:29.40' gives the amount (5% of 60 x 9.80). PRI+AAF:9.80' is the list price for information, PRI+AAA:9.31' the net price that counts, and MOA+203:558.60' the line amount. In the summary, MOA+79 totals the line amounts and MOA+260 the allowances. Because PRI+AAA is already net, a mapper that applies the ALC discount again will under-price the order by 5%. Map the allowance to a separate, informational field.

ORDERS vs the X12 850

The structural difference is that X12 packs a line into one PO1 segment by position, while EDIFACT uses a group of small qualified segments. At the business level the two map cleanly, which is how one system can take both. See the EDI 850 guide for the X12 side and EDIFACT explained for the envelope differences (UNB/UNZ against ISA/IEA).

UK retailer ORDERS requirements

UK grocers split between EANCOM ORDERS and the older TRADACOMS order file, and some run both. These are the points that shape your ORDERS mapping. Specs change, so confirm the current version with each retailer during onboarding.

Tesco

• Purchase orders arrive as EANCOM ORDERS or as TRADACOMS ORDHDR, depending on your setup, so check which one your account uses before you build.
• Tesco trades over OpenText's network (formerly GXS Trading Grid). Connect directly or through a provider that is already connected.
• Expect to pass testing with Tesco's EDI onboarding team before the first live order.

See the Tesco EDI requirements page for the full message set.

Morrisons

• Morrisons trades EDIFACT D96A: ORDERS, ORDCHG, DESADV and INVOIC.
• Purchase order amendments arrive as ORDCHG. Apply each one to the open order before you pick, or you will ship the original quantities.
• Connect through OpenText's TRADANET network or a direct AS2 connection, then pass Supplier Onboarding Verification testing and a live-proving phase.

See the Morrisons EDI requirements page.

Marks & Spencer

• M&S sends purchase orders and expects an order response back.
• Whether your category trades EDIFACT or TRADACOMS varies, so confirm it with M&S before mapping.
• Testing covers business scenarios such as different delivery types, so include them in your sample orders.

See the Marks & Spencer EDI requirements page.

Retailers that order in TRADACOMS

Sainsbury's, Asda, Ocado, Waitrose, Boots and the Co-op send purchase orders as TRADACOMS order files rather than EANCOM ORDERS. The TRADACOMS ORDHDR guide covers that file line by line, and maps each field to its ORDERS equivalent.

Common ORDERS errors and how to fix them

Paste a failing file into the EDIFACT inspector to see which of these applies: it checks UNT, UNZ and CNT counts, GTIN and GLN check digits, dates and segment tags.

Testing and onboarding checklist

Before going live with a new ORDERS partner:

1. Get the implementation guide. Note the directory (D:96A or D:01B), the EANCOM association code, the character set (UNOA or UNOC) and whether the partner sends a UNA.
2. Exchange GLNs. Confirm the interchange GLNs in UNB, and get the full list of buyer, invoicee and delivery party GLNs with addresses.
3. Load the item master. Every GTIN the partner may order, with its pack size and whether it is a consumer unit or a case.
4. Agree on responses. Is ORDRSP required, and within what time? Is a CONTRL expected for every interchange?
5. Ask for sample files covering a standard order, a split delivery, a promotional order and a replacement (BGM function 5).
6. Run every sample through a validator and your mapping, then compare the ERP sales order line by line with the file.
7. Test the edge cases: escaped characters in names, a GLN you do not know, a GTIN you do not stock, a line with a zero quantity.
8. Run parallel for the first live orders: check each one manually against the ERP before trusting automation.

Frequently Asked Questions

What does BGM+220 mean?

220 is the UN/EDIFACT document name code for an order. It tells the receiver the message is a standard purchase order rather than, for example, a blanket order (221), a rush order (224) or a call-off (226). The second element is the buyer's order number and the third is the message function, usually 9 for an original.

What is the difference between ORDERS D96A and D01B?

They are two directory releases of the same message. D.96A underlies EANCOM 1997 and D.01B underlies EANCOM 2002. The core segments (BGM, DTM, NAD, LIN, QTY, PRI) work the same way in both, but code lists and some segment groups differ, so map to the version your partner puts in the UNH.

How do I cancel an EDIFACT order?

The buyer sends an ORDCHG (purchase order change) with BGM document code 230 and function 1 (cancellation), referencing the original order number. ORDERS itself has no cancellation function, though a buyer can replace an order with BGM function 5. See the ORDCHG guide.

Do I need a GLN to receive EDIFACT orders?

For EANCOM-based retail partners, nearly always. They identify you in the UNB and NAD segments by GLN. UK companies get GLNs through GS1 UK membership. See GS1's GLN overview.

Can one ORDERS message deliver to several locations?

Yes. Each line can carry up to 9,999 LOC+7 groups, each with a split quantity and date. GS1 still recommends one order per delivery location where possible, and many partners send one ORDERS per store or depot for that reason.

Is ORDERS the same as the TRADACOMS order?

No. TRADACOMS is a separate, older UK standard. Its order is a file of messages (ORDHDR, ORDERS, ORDTLR) with different syntax. See TRADACOMS ORDHDR and TRADACOMS file types.

How do I respond to an EDIFACT order?

With an ORDRSP if the partner requires one: BGM 231, quoting the order number in RFF+ON, with 29 for accepted, 4 for changed or 27 for not accepted. A CONTRL may also be required to confirm receipt of the interchange.

Related guides

• EDIFACT explained: syntax, envelopes and EDIFACT vs X12
• EDIFACT message types: every message in the order-to-cash cycle
• EDIFACT ORDRSP: accept, change or reject the order
• EDIFACT ORDCHG: buyer changes and cancellations
• EDIFACT DESADV: the despatch advice that follows
• EDIFACT INVOIC: the invoice
• EDIFACT CONTRL and APERAK: syntax and application acknowledgements
• EDIFACT PRICAT: the price catalogue that orders are priced from
• EDI 850 purchase order: the X12 counterpart

Sources

• EANCOM 2002 S3: ORDERS purchase order message, GS1 (message structure, segment layouts and code lists used throughout this guide)
• EANCOM 2002 S3: ORDERS BGM segment, GS1
• EANCOM 2002 S3: ORDERS PRI segment, GS1 (net calculation price rule)
• UN/EDIFACT D.01B ORDERS message, UNECE
• Global Location Number (GLN), GS1

Check your partner's sample orders in the free EDIFACT inspector, or see how OrderSync automates X12 850 purchase orders and EDIFACT orders into your ERP.