Turns a partner's purchase order into an OroCommerce sales order.
The order has to pick up the buyer's negotiated account terms at this point, not the storefront's default price book, or everything downstream prices wrong.
AI Powered
EDI with expert operators
OroCommerce B2B
EDI Integration
The partner doesn't see an OAuth scope or a JSON:API payload. They see a purchase order that confirmed at the storefront's rate instead of their own, or an acknowledgement that never arrived before their own deadline passed. OroCommerce runs a REST API built to the JSON:API specification, versioned by path, with its own rules for what moves through the Batch API, and none of that explains itself to a buyer waiting on a confirmed order.
Five chargeback categories trace to the same starting account.
Four of these start the same way: a buyer's order prices against the storefront rate instead of the account's negotiated terms, and the dispute surfaces weeks later on the invoice. OroCommerce's CPQ and RFQ tools exist to set that rate, but it only holds if it reaches the sales order the purchase order created, not just the quote that sat before it.
- Delivery window
- Invoice discrepancy
- Late acknowledgement
- Late ASN
- ASN non-compliance
Four steps set the terms before the first order prices.
Before a buyer's first purchase order can turn into a correctly priced sales order, the account terms behind it need to exist somewhere OroCommerce actually reads them. That's account configuration, not storefront configuration, and it has to be done before go live, not discovered after the first disputed invoice.
- Confirm which OroCommerce account record carries the buyer's negotiated pricing
- Enable the API feature in System Configuration for both storefront and back office
- Set up OAuth credentials and confirm which sandbox endpoint matches live trading
- Map the 850 and 856 against the fields OroCommerce's JSON:API resources actually expose
Each document crosses a different handoff inside OroCommerce.
Five documents carry a wholesale order through OroCommerce and back out to the partner's dock, and each one depends on a different part of the account being right first.
Confirms what shipped, built once the order is picked and dispatch is recorded.
OroCommerce's order side has to hand off cleanly to whatever system packs the shipment, or the ASN goes out after the carrier has already collected.
Tells the buyer their purchase order was received and read correctly.
Without it, a buyer has no proof their PO reached anything beyond a web form that might have dropped it.
Carries stock position back to the partner, separate from the order itself.
Useful where a buyer checks availability before raising the next PO rather than trusting whatever figure the storefront last cached.
Invoices the order at whatever price actually got applied.
If the buyer's contract rate never reached the sales order, this is where the mismatch turns from a rounding error into a dispute.
Every one of these only works if the account terms attached to the buyer's record reached the order before it priced, not after.
Versioning sits in the path, not in a header.
OroCommerce versions its API by URI, so /v2/ sits alongside whatever came before it, and a feed built against one version keeps working until that path is retired rather than switching behaviour underneath it. Authentication runs through OAuth, paging follows the JSON:API standard so order history doesn't arrive as one unbounded list, and the API itself has to be switched on in System Configuration before any of this runs. Storefront and back office each have their own sandbox endpoints, which matters when a fix needs testing against the side a partner actually orders from.
- X12
- EDIFACT
- AS2
- SFTP
- Cloud storage
protocols
HTTP, HTTPS
authentication
OAuth
bulk operations
yes
paging
JSON:API standard
versioning
URI versioning (/v2/)
Confirmed against your instance during onboarding.
Two things get managed once OroCommerce is live.
Once an account is trading, the risk isn't the API failing, it's an account record drifting back to a default rate or a confirmation landing outside the partner's own window.
Price and terms
Checks that the buyer's negotiated rate is still the one attached to new sales orders, not a rate reset by a storefront price book update.
Dispatch confirmation
Checks the 997 and 856 land inside the partner's stated windows, not just inside OroCommerce's own order status.
Related
OroCommerce B2B integrationThe wider OroCommerce B2B integration work, beyond EDI./collections/orocommerce-b2b-integration-ipaas-agency
Ecommerce EDIThe other platforms in this category./collections/ecommerce-edi-integration
EDIHow EDI works across every platform we cover./collections/edi-integration
Questions that come up once OroCommerce is trading.
Our wholesale rep days push order volume well above a normal week. What does OroCommerce's Batch API actually do with that spike?
OroCommerce's Batch API and Synchronous Batch API take multiple records in one call rather than one order at a time, which is what a rep day or a seasonal order push needs. The thing worth checking beforehand is whether the API feature itself is switched on for the volume you expect, since it has to be enabled explicitly in System Configuration before any of this runs.
Inside OroCommerce, does a buyer's purchase order land against the customer account's negotiated terms, or the default price book?
It lands against whichever sales order gets created from the PO, and that order only carries the buyer's contract rate if the account record behind it was set up with those terms before the order arrived. OroCommerce's CPQ and RFQ tools are built for negotiated B2B pricing, but the rate has to be attached at the account level for the sales order to pick it up, rather than defaulting to the storefront price.
OroCommerce lists /v2/ in its API path today. If that version number changes, what happens to a feed already running?
URI versioning means the path itself carries the version, so a feed built against one version keeps calling that path until it's retired rather than silently switching behaviour on you. The practical check is whether the resources and fields a mapping depends on still exist under whatever version comes next.
Our wholesale buyer's dispatch cutoff falls not long after picking confirms. Can OroCommerce's order data turn into an ASN that fast?
The ASN depends on how quickly the order side records dispatch and hands that off to the 856, not on the API's own speed. Where picking confirmation and OroCommerce's order status update on the same step, the ASN can go out well before the cutoff. Where they sit on separate systems with a manual handoff between them, that's the point that slips.
The API has to be switched on in System Configuration before any of this runs. Does that step mean we need a developer on staff?
Turning the feature on is a configuration step, not a build. Keeping OAuth credentials current, mapping JSON:API resources correctly and watching the Batch API under load is ongoing work, and most accounts run that through Cogent² rather than carrying it as a headcount decision.
Need help with this?
Talk to a Cogent2 operator who has actually delivered this work. We will help you scope, plan and ship — without the agency overhead.