Odoo
EDI Integration
In Odoo, a partner's purchase order has to settle into a sales order carrying the line and price they actually sent, because the invoice that follows reads from whatever record sits against that order rather than the product's standard price. Cogent² files that document chain over Odoo's JSON-2 API, the HTTPS path Odoo now recommends ahead of the XML-RPC and JSON-RPC routes it is retiring. Each call runs in its own database transaction, so an order, its acknowledgement and its invoice are separate writes that have to agree with each other rather than one atomic step.
Short ship and PO accuracy disputes usually trace to a sales order line that was revised after a 860 arrived but before the delivery was validated. Invoice discrepancy follows when the 810 prices from the product record instead of the sales order the partner's 850 actually created, and nobody catches it until the remittance arrives short. Late acknowledgement and late ASN show up when the gap between order confirmation and delivery validation in Odoo runs past the partner's window. ASN non-compliance and delivery window issues usually come down to the same gap, read from the carton or carrier side instead.
Onboarding starts before any document moves, because Odoo won't tell you later that the wrong database or the wrong field is being written to. Confirm the company and database the partner's orders have to land in, scope the access the account needs, then map the fields that decide whether an invoice prices correctly.
Each one reads from or writes to the sales order Odoo holds for that partner, and the order is the only record the invoice should ever price against.
The 810 has to draw its price and quantity from the sales order the partner's 850 created, because Odoo's own invoice run will fall back on the product's standard price if that order isn't the record in use. Cogent² checks the invoice against the sales order before it posts.
The order lands with the partner's own lines and price, matched against what they actually sent rather than product master data, before anything downstream reads it. A missing field such as customer phone can stop the order flowing until it's added.
The 855 reports what Odoo actually holds against that order number, line by line, so a mismatch surfaces before stock moves rather than after the invoice is raised.
Because each JSON-2 call runs in its own transaction, the ASN write and the invoice write are separate steps. If delivery validation and the ASN build fall out of step, the notice can describe stock Odoo hasn't actually released.
A 860 that arrives after the invoice has posted leaves the order and the invoice disagreeing, since Odoo won't re-price an invoice automatically once it exists as a separate record.
This confirms the transmission arrived, which is a separate question from whether Odoo accepted the order itself, since validation and field checks happen afterward.
Every document here routes through the same transaction-per-call model, so timing between them matters as much as the content of any single message.
Cogent² authenticates to Odoo with a bearer token API key over HTTPS, using the JSON-2 path introduced in Odoo 19 rather than the XML-RPC or JSON-RPC routes Odoo is scheduled to remove around Odoo 22 in late 2028. JSON-2 doesn't document a paging model, so Cogent² works call by call; the legacy RPC path still offers offset and limit where that's needed. Access to this API sits behind Odoo's Custom pricing plans, and every write lands under PostgreSQL's Repeatable Read isolation inside its own transaction, which is why a multi-step change needs an action method rather than a chain of separate calls.
Confirmed against your instance during onboarding.
None of this is a one-off setup. Keys expire, orders can duplicate, and a revision that lands late can leave an invoice pricing against the wrong line.
Odoo caps a key at three months and rate-limits generation to ten per user by default. Cogent² tracks expiry and rotates keys before a feed goes quiet.
Each JSON-2 call writes in its own transaction. Cogent² checks that a multi-step update, such as an order revision followed by its invoice, lands as a consistent pair rather than two records that disagree.
Cogent² checks that every invoice draws its unit price and quantity from the sales order Odoo holds for that purchase order number, and flags any line that would otherwise price from the product master.
Cogent² AI watches for a repeated order ID or a missing field such as customer phone, and holds the record before it writes twice into Odoo, not after a second sales order has already posted.
JSON-2 doesn't document a paging limit, so volume is handled call by call rather than in one batch, and each write still runs under its own transaction regardless of how many arrive. The practical limit sits with the API key itself: Odoo rate-limits key generation to ten per user by default, so Cogent² manages key scope ahead of a known peak rather than requesting new access mid-surge.
It has to resolve against the sales order Odoo created from that purchase order, not the product's standard price field. Cogent² checks the invoice line against that order before it posts, because Odoo's invoice run will otherwise read whichever price is active in the product record at the time.
Nothing changes for a feed already filed against JSON-2, since that's the current path and the one Odoo is directing integrations towards. The change only hits accounts still filing through the legacy RPC routes, which lose offset and limit paging and the authentication model tied to them once those paths close around late 2028.
Cogent² updates the mapping on the Odoo side. The buyer's team doesn't need to touch the sales order configuration or the API key scope to pick up a changed field reference on an acknowledgement.
It can, provided the delivery validation and the ASN build are sequenced as the action method they need to be rather than treated as two independent calls that might land out of order. Cogent² builds that sequence so the 856 reflects stock Odoo has actually released by the time it goes out.
No. Cogent² tracks the expiry window and rotates the key within Odoo's three month cap and its rate limit on new key generation, so the account doesn't need a developer on payroll to keep the connection authenticated.
Talk to a Cogent2 operator who has actually delivered this work. We will help you scope, plan and ship — without the agency overhead.
We use essential cookies to keep this site secure and working. We do not run advertising or analytics tracking. You can accept optional cookies or keep only the essentials. See our Cookie Policy.
