Project

General

Profile

Wiki »

01 Business process and document types (2DOC, 4DOC etc.)

01 From business process to document chain

Every delivery between a supplier and a buyer follows the same real-world cycle: the buyer orders goods, the supplier ships them, the buyer receives and checks them, and finally the parties settle the payment. Each step of this cycle has always been accompanied by a paper document — a purchase order, a waybill, an acceptance act, an invoice.

EDI does not change the business process itself. It replaces each paper document with a structured electronic message that is delivered directly between the ERP systems of the partners. This is why EDI message types map one-to-one to the steps of the delivery process:

Step in the business process Traditional document EDI message
Buyer orders goods Purchase order ORDER
Supplier confirms what can be delivered Order confirmation ORDRSP
Supplier ships the goods Waybill / delivery note DESADV
Buyer accepts the goods and records discrepancies Acceptance act RECADV
Supplier requests payment Invoice INVOICE

The set of messages the partners exchange is called the message chain. The chain is agreed between the trading partners and reflects how their real process works — in retail it is usually dictated by the chain's requirements (see 09_Organizations_requirements).

02 2DOC and 4DOC

  • 2DOC — simplified two-document chain: ORDER → INVOICE. Suitable when deliveries rarely differ from the order (services, stable assortment, small volumes): the invoice is issued directly from the order.
  • 4DOC — full four-message chain: ORDER → DESADV → RECADV → INVOICE. The standard process with most retail chains.

The business value of 4DOC is in the RECADV step: the invoice is issued based on what the buyer actually accepted, not on what was ordered or shipped. Shortages, damaged goods and substitutions are recorded before invoicing, so the invoice matches reality from the start — no credit notes, corrections or payment disputes afterwards.

03 4DOC process flow

  1. ORDER — the retailer creates an order in its ERP; it is delivered automatically into the supplier's system.
  2. DESADV — the supplier sends a dispatch advice, the electronic equivalent of shipping documents.
  3. RECADV — the retailer confirms the goods actually received (with reasons for non-acceptance), so a correct invoice can be issued.
  4. INVOICE — the supplier issues the invoice based on the RECADV; it is loaded automatically into the retailer's system.

02 Document types

Delivery chain:

Message Direction Purpose
ORDER Buyer → Supplier Purchase order
ORDRSP Supplier → Buyer Order response / confirmation
DESADV Supplier → Buyer Dispatch advice (waybill data)
RECADV Buyer → Supplier Receiving advice — goods actually accepted
INVOICE Supplier → Buyer Invoice; credit note — see Credit_note

Master data:

Message Direction Purpose
PRICAT Supplier → Buyer Product and price catalogue

Logistics (3PL warehouse):

Message Direction Purpose
IFTMAN Client → 3PL Arrival notice — goods arriving at the warehouse (inbound)
IFTMANRSP 3PL → Client Confirmation of warehouse receiving with actually received quantities
INSDES Client → 3PL Instruction to despatch goods from the warehouse (outbound)
INSDESRSP 3PL → Client Confirmation of despatch with actually shipped quantities

Returns:

Message Direction Purpose
RETANN Buyer → Supplier Announcement for returns — goods to be returned and reasons

Besides the delivery chain itself, partners may exchange supporting messages. PRICAT keeps the buyer's product and price data in sync before any ordering starts. When goods are stored and shipped from a 3PL warehouse, the process extends to the logistics operator: the client announces inbound deliveries (IFTMAN), instructs the warehouse to ship (INSDES), and receives back confirmations with actual quantities (IFTMANRSP, INSDESRSP) — so the client's ERP always reflects real warehouse stock movements. RETANN closes the cycle on the buyer's side by formalising returns.

Technical formats of these messages are described in 05_Document_formats; transmission channels in 04_Transmission_communication_channels_and_API.

03 More on docura.net

  • "EDI-Sales — process