TRADACOMS DLCHDR: Delivery Confirmation Explained

The delivery confirmation is the retailer telling you what it actually received. Not what you picked, not what your delivery note says, but what was counted at goods-in. If those differ, this file is your first warning, and it usually arrives before the deduction on your remittance does.

Not every UK retailer sends one. Where they do, it is the document to invoice against. M&S's EDI guides for Food suppliers say it plainly: the proof of delivery tells suppliers the quantities M&S received, and suppliers should invoice those quantities. This guide explains how a DLCHDR file is built, how to read its variance codes, and how it maps to the EDIFACT RECADV receiving advice.

What is a TRADACOMS DLCHDR file?

DLCHDR is the delivery confirmation file in TRADACOMS, the UK retail EDI standard created by the Article Numbering Association, now GS1 UK. The customer sends it to the supplier to confirm the goods and quantities delivered at a location. Its transaction code, 0670, is defined in the TRADACOMS code list as "Confirmation of Delivery: confirms the goods and quantities which have been delivered at a location".

Do not confuse it with DELHDR, the delivery notification file. They flow in opposite directions:

DLCHDR file structure

STX   Start of transmission (customer to supplier, APRF DLCHDR)
│
├── MHD DLCHDR   Delivery confirmation header    once per file
│     TYP  SDT  CDT  FIL  (DNA  FDT)
│   MTR
│
├── MHD DLCDET   Delivery confirmation details   once per delivery, repeats
│     CLO                                        where it was delivered
│     ODD                                        order, delivery note, POD reference
│     DST                                        overall delivery status
│     DCD  (DPI  DNB) ...                        one per product line received
│     RCD  (RPI  RNB) ...                        one per product line returned
│     DCT                                        number of DCD and RCD lines
│   MTR
│
├── MHD DLCTLR   Delivery confirmation trailer   once per file
│     COT                                        confirmations in this file
│   MTR
│
END   End of transmission (number of messages)

Each message carries its own version number in MHD, and for this file they are not 9. The TRADACOMS table in IBM's Gentran:Server documentation lists version 4 for all three release 9 delivery confirmation messages, so the examples below use 4. Other tools list other versions, so use whatever your partner's guide names.

Example: confirmation with one damaged case

Fictional retailer Harbour Lane Stores confirms a delivery from fictional supplier Kestrel Valley Homeware to its northern distribution centre. Forty cases of chopping boards were ordered and delivered, but one case arrived damaged. The other two lines were received in full. Identifiers are made up, with valid GS1 check digits.

How partners record damaged stock varies. Splitting a product across two DCD lines with different stock status codes, as here, is one way the segment allows; others send a single line with the accepted quantity and a variance reason. Check your partner's guide.

Segment reference

Release 9 layouts. "M" is mandatory and "O" optional in the standard. The EANCOM column gives the closest equivalent in the RECADV receiving advice.

DLCHDR: file header

DLCDET: one per delivery

DLCTLR: file trailer

Reading DST and DCD

The delivery status segment DST gives the overall result; each DCD gives the line.

DST delivery condition codes (code list 21), the ones you will see most:

DCD line layout:

Reasons for variance (code list 17) appear in both DST and DCD. Common ones: A out of stock, C refused delivery, D damaged goods, E driver short delivered, N over delivery, Q product delivered not ordered, V late delivery, Z substitute product, and AA confirmation of no variance. The optional second component is an action: C cancel or R rebook.

Like every TRADACOMS quantity, DELQ and AQTY count traded units, so 39 here means 39 cases of 6, not 39 boards.

Example: a file covering two store deliveries

Store suppliers often receive one file covering several drops. Here the Leeds store received only two of three cases of tea towels (reason E, driver short delivered), while York received its order in full. The supplier details travel once, in the header.

The Leeds shortfall is now on record from the customer's side. Invoice two cases, not three, or expect a debit note for the third and send a credit note (CREHDR) with reason code 38 to match it.

What to do when a DLCHDR arrives

1. Match it to the delivery. Use the order number and delivery note number in ODD to find your despatch record.
2. Compare line by line. For each DCD, compare DELQ with what you despatched, not just what was ordered. Look at SSTC for damaged or out-of-date stock.
3. Read the reason. E driver short delivered points at the carrier; D damaged goods at packing or transit; A out of stock usually means you short-shipped and already know.
4. Invoice the confirmed quantity, where your partner asks for that. M&S's Food guides ask suppliers to invoice the POD quantities.
5. Dispute quickly. If you hold a signed delivery note or carrier proof showing a different count, raise it now, while the delivery is recent.

DLCHDR to EANCOM RECADV

M&S publishes the same proof of delivery flow both ways: its TRADACOMS guides name DLCHDR, and its EANCOM proof of delivery guide is built on the RECADV message. Here is how the content lines up.

The X12 counterpart is the 861 receiving advice.

Which UK retailers send DLCHDR

Public evidence is thinner for DLCHDR than for orders and invoices, because fewer retailers send it.

• M&S sends a proof of delivery to Food suppliers. Its TRADACOMS implementation guides name DLCHDR as the TRADACOMS message and its EANCOM guide for the same flow uses RECADV. See the Marks & Spencer page.
• Sainsbury's lists proof of delivery among the messages commonly set up with suppliers, and trades both EDIFACT and TRADACOMS, per Cegedim. Which standard carries it for your account is for Sainsbury's EDI team to confirm. See the Sainsbury's page.

If your partner does not send one, you will usually learn about shortages from a debit note or a remittance deduction instead, which is later and harder to dispute.

Common DLCHDR problems

1. Reading DELQ as consumer units. Delivered quantities are traded units, with the pack size in UNOR.
2. Treating it as the despatch notice. DLCHDR comes from the customer after receipt. Your outbound notice is DELHDR, or DESADV in EANCOM.
3. Ignoring stock status. A line can show the full quantity delivered with SSTC 2 (damaged). Count it as a shortfall for invoicing.
4. Not matching on the delivery note. One order can arrive in several deliveries. Match on the order number and the delivery note number in ODD together.
5. Envelope counts. As with every TRADACOMS file, MTR counts from MHD to MTR inclusive and END counts every message, so a file with two confirmations has END=4. Checking COT against the number of DLCDET messages catches truncated files.

How OrderSync handles DLCHDR

OrderSync reads delivery confirmations in TRADACOMS and EANCOM and matches each line to the order and despatch already in your system, so a short or damaged line becomes an exception to review before you invoice, not a deduction you find a month later. Paste a file into the free EDIFACT inspector to see what it contains first.

Frequently Asked Questions

What is DLCHDR in EDI?

DLCHDR is the TRADACOMS delivery confirmation file used in UK retail. The customer sends it after goods are received to confirm what arrived. It contains a DLCHDR header, one DLCDET message per delivery and a DLCTLR trailer.

Is DLCHDR the same as a proof of delivery?

In practice, yes. Retailers that send a proof of delivery in TRADACOMS use the delivery confirmation file, and the ODD segment carries the proof of delivery number and the date of delivery. M&S's EDI guides use the terms together.

What is the difference between DLCHDR and DELHDR?

DELHDR is the delivery notification the supplier sends before or at despatch, saying what is on its way. DLCHDR is the delivery confirmation the customer sends after receipt, saying what arrived. They are the TRADACOMS counterparts of DESADV and RECADV.

What is the EDIFACT equivalent of DLCHDR?

The EANCOM RECADV receiving advice, with document code BGM+632. In X12, the closest equivalent is the 861 receiving advice.

What does DST=0 mean in a delivery confirmation?

DST is the delivery status segment and 0 means the delivery was made as instructed. 1 means there is a variance from the instruction, and the second element gives the reason, such as D damaged goods or E driver short delivered.

Should I invoice the ordered or the confirmed quantity?

Invoice what your partner will pay for. Where a retailer sends a delivery confirmation, that is usually the confirmed quantity: M&S tells Food suppliers to invoice the POD quantities. Invoicing more leads to a debit note and a credit note to clear it.

Related guides

• TRADACOMS explained: syntax, STX and END, and how files work
• TRADACOMS file types: every file type and its EANCOM equivalent
• TRADACOMS INVFIL: invoicing the confirmed quantities
• TRADACOMS CREHDR: crediting shortages and damages
• EDIFACT RECADV: the EANCOM receiving advice

Sources

• TRADACOMS release 9 DLCDET layout, KA Software schema reference, including the DLCHDR, DLCTLR, DST, DCD, DCT, COT and TYP code list pages
• M&S Purchase Order implementation guide (TRADACOMS) and M&S Proof of Delivery implementation guide (EANCOM RECADV), Marks & Spencer via GXS
• Using proprietary TRADACOMS standards, Gentran:Server technical bulletin, IBM: the TRADACOMS header, detail and trailer message table with message versions
• Connect to Sainsbury's via EDI, Cegedim
• TRADACOMS, Wikipedia: the delivery confirmation file in the list of 25 transaction files
• Ending support for TRADACOMS, GS1 UK

Check a DLCHDR's structure and counts in the free EDIFACT inspector.