EDIFACT EDI: ORDERS, INVOIC and DESADV
EDIFACT EDI: turn the ORDERS files your retail customers send into sales orders, and send back INVOIC and DESADV, with the original kept.
Available for Odoo 16.0, Odoo 17.0, Odoo 18.0, Odoo 19.0. Technical name bambooforge_edifact.
EDIFACT EDI: ORDERS, INVOIC and DESADV
What this is for
Retail chains do not email purchase orders. They send EDIFACT, and a supplier who cannot read it does not get listed. Odoo has no EDIFACT support at all.
Setting up a trading partner
Sales ▸ EDI ▸ Trading Partners
Every chain runs the same standard slightly differently, so their habits live on a profile rather than in the code:
Their interchange ID and qualifier — usually a GLN with qualifier 14.
Ours — what we are called in the UNB segment.
Test interchanges — partners run a test phase and reject live files during it. Leave this on until they say otherwise.
Product code field — which of our fields carries the code they send in LIN. Retail chains almost always send an EAN.
Check prices on orders — compare the price on the incoming line with our own price list.
Confirm orders automatically — leave off until their files have been trusted for a while. An order that confirms itself also reserves stock and can start a delivery.
Receiving orders
An ORDERS interchange becomes a sales order: the buyer is resolved from NAD+BY by interchange identifier, products from LIN, quantities from QTY+21 and prices from PRI+AAA.
Three behaviours are worth knowing:
A price difference does not stop the order. The order is created and the difference is written on it, listing what they say against what our price list says. Price disputes are the expensive part of EDI trading and finding them at invoice time is too late.
An unknown buyer or product code fails loudly. The message goes to Error with the identifier that could not be matched, and the payload is kept. Fix the data and press Process Again.
A resent interchange does not become a second order. Partners resend; a gateway that takes the same order twice ships it twice.
Sending invoices and despatch advices
build_invoic on a posted customer invoice and build_desadv on a validated outgoing shipment produce the interchange. Neither will build from a draft invoice or an unvalidated picking — a despatch advice for goods that have not left is worse than none at all.
The payload
Stored exactly as sent or received, and never rewritten. When a partner disputes an order six months later, the file they actually sent is the only thing that settles it.
Known limits
This module reads and writes the files. It does not talk to a VAN or an AS2 gateway — those need credentials and a contract, and are usually a separate piece of infrastructure that drops files where Odoo can pick them up.
ORDERS, INVOIC and DESADV only. ORDRSP, RECADV, IFTMIN and friends are not implemented.
Syntax level A with the D96A directory, which is what the grocery trade runs on. A partner on a different directory version may need adjustments.
Screens
