Original PO Reference
The EDI 850 purchase order number and date being modified.
EDI-860
The EDI 860 is the ANSI X12 transaction a buyer uses to request a change to a purchase order that was already sent as an EDI 850. Instead of cancelling the order and issuing a brand-new one, the buyer references the original PO and sends only what changed - a revised quantity, a new delivery date, an updated price, or an added or removed line item.
The EDI 860 is the ANSI X12 transaction a buyer uses to request a change to a purchase order that was already sent as an EDI 850. Instead of cancelling the order and issuing a brand-new one, the buyer references the original PO and sends only what changed - a revised quantity, a new delivery date, an updated price, or an added or removed line item.
Because the 860 always ties back to an existing order, it keeps the buyer and supplier working from the same record. The supplier updates the order in place, confirms the change with an EDI 865, and both systems stay in sync without a break in the procurement or fulfillment process.
The 860 can also run in reverse: a supplier can propose a change (for example, when a quantity can't be fulfilled as ordered), and the buyer accepts or counters it through the same document type. This back-and-forth continues until both sides agree, all without a phone call, an email thread, or a duplicate order in the system.
Because the 860 always ties back to an existing order, it keeps the buyer and supplier working from the same record.
The EDI 850 purchase order number and date being modified.
What kind of change is being requested (BCH01).
Revised quantity, unit of measure, price, or product identifiers.
Buyer SKU, vendor item number, UPC or GTIN for accurate matching.
Revised delivery date, ship date, or cancel-after date.
Used when one line has multiple requested delivery dates.
Buyer, seller, and Ship-To details, including any address change.
Line-item count used to validate the file on receipt.
A buyer typically issues an 860 after demand shifts, inventory changes, or a delivery delay makes the original PO terms no longer accurate.
A common example: a buyer sends PO #10025 for 100 units through an 850, then a week later needs 120 units for the same delivery window. Rather than cancelling PO #10025 and issuing a new order, the buyer sends an 860 referencing #10025 with the revised quantity. The supplier applies the change and responds with an 865 confirming, rejecting, or modifying the request.
| Document | Direction | Purpose |
|---|---|---|
| EDI 850 | Buyer → Seller | Creates the original purchase order |
| EDI 855 | Seller → Buyer | Acknowledges the original purchase order |
| EDI 860 | Buyer → Seller | Requests a change or cancellation to an existing PO |
| EDI 865 | Seller → Buyer | Accepts, rejects, or modifies the 860 request |
| EDI 856 | Seller → Buyer | Provides shipment (ASN) details once the order ships |
| EDI 810 | Seller → Buyer | Provides the invoice |
A 997 or 999 only confirms that the file was technically received and passed syntax validation - it does not mean the requested change was accepted. Business acceptance comes from the 865 (or, with some trading partners, a revised 855). The typical sequence looks like this:
Buyer sends the original purchase order.
Supplier acknowledges the order.
Buyer sends a change request against that order.
Technical acknowledgment that the 860 file was received correctly.
Supplier's business response: accepted, rejected, or accepted with modification.
Shipment notice once the revised order ships.
Invoice reflecting the final, applied terms.
Update an existing purchase order without a full cancellation, so procurement history and downstream documents stay intact.
Automated validation and routing means a requested change reaches the right order in minutes instead of waiting on a manual email or phone confirmation.
Structured, code-based data removes the manual re-entry that typically introduces mismatched quantities, dates, or terms.
Every original, requested, and applied value is logged against the 860 and its matching 865 - useful for both operations and finance reconciliation.
Suppliers can respond quickly to inventory or production constraints, and buyers get a documented, timestamped answer instead of an informal one.
Vraja Technologies builds direct, Odoo-native EDI 860 processing - no third-party middleware required. An incoming 860 is validated, matched to the corresponding Sales Order, and either applied automatically or routed for manual review, based on the order's current fulfillment status.
| 860 Request | Odoo Action |
|---|---|
| Add line | Create a new Sales Order line |
| Change quantity | Update the ordered quantity |
| Delete line | Cancel or zero out the line |
| Change price | Update price after tolerance validation |
| Change delivery date | Update the commitment/requested date |
| Change Ship-To | Update delivery address and picking |
| Cancel order | Cancel the Sales Order and open operations |
Changes that are safe to apply automatically - an order that hasn't shipped, valid product identifiers, a quantity within agreed tolerance - flow straight through.
Anything riskier is held for manual review: a partially shipped order, a price that doesn't match the agreed pricelist, a quantity reduced below what's already shipped, or a Ship-To change after stock has been allocated.
Our team implements EDI 860 alongside the full purchase-order document set - 850, 855, 865, 856, 810, and 997 - directly inside Odoo, so purchase order changes update your Sales Orders, inventory reservations, and invoicing in real time. We handle envelope and segment validation, duplicate and out-of-sequence detection, trading-partner-specific mapping, and the safety rules that keep an automated change from overwriting an order that's already shipped or invoiced.
Whether you're a buyer who needs faster, cleaner change requests out to your suppliers, or a supplier who needs incoming 860s applied to Odoo without manual re-keying, we design the mapping around your trading partners' implementation guides - not a generic template.
No. The 860 references the original PO and carries only the requested changes, so the order history, PO number, and downstream documents stay linked instead of being replaced.
No. The 860 is a request. The supplier's EDI 865 - or in some trading relationships, a revised 855 - confirms whether the change was accepted, rejected, or accepted with modification.
The 860 is buyer-initiated and requests a change. The 865 is the supplier's response, confirming, rejecting, or modifying that request.
It can be requested, but most implementations flag this for manual review, since it affects warehouse selection, tax, freight, and delivery lead time after allocation has already happened.
It's typically mapped alongside 850, 855, and 865 as one connected workflow, since a change request only makes sense in the context of the original order and its acknowledgment.
Don't let outdated, manual processes slow down order changes. With EDI 860 integrated directly into Odoo, quantities, prices, and delivery dates update in real time - with a full audit trail and automated 997/865 responses built in.

