EDI across the supply chain in Odoo

The whole chain

The chain begins before a truck moves. A buyer issues an order, the supplier answers with what it can fulfil, the warehouse records what it packed, and the invoice reports what should be paid. Later documents explain payment differences and channel activity.

Each handoff has two views of the same event. The buyer has its purchase order while the supplier has an Odoo sales order. The warehouse has a packed delivery while the buyer expects an advance ship notice. Integration keeps those views connected by references both sides recognize.

The order-to-cash document flow

• 850 Purchase Order

  The buyer's order arrives with its item numbers, location codes, quantities, prices and requested dates. It becomes a sales order after those identifiers resolve in Odoo.

• 855 Order Acknowledgment

  The supplier answers each line with the quantity and date it can meet. The answer should come from the availability and decisions held in Odoo.

• 856 Advance Ship Notice

  The validated delivery and recorded packing become the buyer's shipment notice. Its quantities and package hierarchy need to match the freight that leaves the floor.

• 810 Invoice

  The invoice carries the purchase-order references, shipped quantities and agreed prices that the buyer's accounts-payable system will try to match.

Read the documents in full: 850, 855, 856 and 810. When the buyer revises an order that is already in flight, the 860 purchase order change has to reach the same sales order.

When a third-party warehouse sits in the middle

A supplier using a 3PL has another handoff to control. Odoo sends the warehouse a 940 shipping order. The warehouse answers with a 945 shipping advice stating what it actually shipped. That answer updates the delivery facts used for the retailer-facing 856 and the invoice.

The useful comparison is the gap between instructed and shipped. A short quantity, changed carton count or missing tracking reference belongs in an exception queue before the retailer's receiving dock discovers it.

The warehouse pair: 940 shipping order and 945 shipping advice.

What comes back after fulfilment

• 820 Remittance Advice

  The payment is broken into invoices and adjustments. Keeping each deduction tied to its invoice lets finance reconcile while operations can still see the cause.

• 812 Credit/Debit Adjustment

  A trading partner communicates a credit or debit adjustment. The reference and reason need to survive beside the Odoo accounting entry.

• 824 Application Advice

  A receiving application reports what it made of another document. It can expose an error after the transport and syntax checks already passed.

• 852 or 867 Activity Reports

  Channel activity comes back by item, location and period. It becomes useful only after the partner's identifiers resolve to stable internal records.

Follow the downstream documents: 820 remittance advice, 812 credit or debit adjustment, 824 application advice, 852 product activity and 867 product transfer and resale report.

Where the chain breaks

The common break is identity. A retailer orders under its item number and location code while Odoo uses another product reference and a different address record. One unresolved identifier can stop an otherwise valid document.

The next break is state. A file can be transmitted, parsed, rejected by the receiving application, corrected and resent. If the integration stores only sent or received, support cannot tell which business event is still open.

The third break is physical. A ship notice describes packing recorded by a warehouse. When cartons and pallets are built outside Odoo with no structured feedback, the document has no dependable source and somebody reconstructs it after the work happened.

What belongs in an implementation scope

A useful scope names each transaction set and direction, the Odoo record behind it, the identifiers that need cross-references, the event that triggers it and the responses that close it. It also names the owner for every exception that cannot be resolved automatically.

Testing follows the same map. A happy path proves the basic flow. Duplicate, unknown-item, changed-order, short-ship and rejection cases prove whether the controls survive the morning when real data refuses to cooperate.

The connection itself may use an EDI platform API, a VAN, AS2 or SFTP. That choice changes the boundary and support model. It does not remove the mapping and operating decisions inside the supplier's business.

Continue with EDI API integration, the services scope, or the full transaction-set catalog.

Official sources

X12 publishes the transaction-set definitions linked below. Your trading partner's current implementation guide still decides which documents it requires and how each one is used.

X12 supply chain transaction flow · X12 850 Purchase Order · X12 856 Ship Notice · X12 810 Invoice