Platform route
Odoo integration for Rithum, formerly CommerceHub
Rithum, which you may still know as CommerceHub, sits between suppliers and retailers on dropship and marketplace programmes as well as conventional retail EDI.
Rithum publishes an API boundary for a supplier's internal systems. Odoo belongs on that side of the route, where orders, stock, shipments and invoices need a deliberate mapping.
On this page
What Rithum (formerly CommerceHub) does for you
Rithum carries the connection to the retailer and, on dropship programmes, a good deal of the order routing that goes with it. Your customer nominates it and you exchange documents with the network.
Dropship changes the shape of the work. The order that arrives is usually one consumer's, the shipping expectations sit inside the programme rules, and the volume of small orders is what makes manual handling impossible.
Your customer
Rithum
Your Odoo
What is left on your side
The Odoo half, whichever route carries the document
Which fields the order lands on, what your item numbers have to look like, and what happens in your warehouse the morning a document arrives malformed.
The tracking number going back, inside their window
On a dropship programme the shipment confirmation is the document the consumer is waiting on, and the programme rules put a clock on it. Sent from a portal it is somebody copying a tracking number out of one screen and into another, hundreds of times a day, after the pick is done. That is the outbound half, it is where the programme measures you, and it is a different job from receiving the order.
What a consumer-level order should become in Odoo
On a dropship programme this is the question that catches people, along with what happens to your stock and your fulfilment when hundreds of them arrive in a single day.
The four dropship flows Rithum publishes, and where each lands in Odoo
Rithum's own overview of its first-party offering names the four flows a supplier manages on a dropship programme: purchase orders, shipment notifications, stock quantities and invoices. Its solution diagram places an API between the supplier's internal systems and Rithum for inventory, order management and shipments, and puts the retailer-facing side on EDI.
Purchase orders. On the retailer side this is usually the X12 850, and on a dropship programme each one is a single consumer's order. In Odoo it becomes a sales order where the retailer is the customer you invoice and the consumer is where it ships. With the Customer Addresses setting on, Odoo 19.0 carries a separate Invoice Address and Delivery Address on every quotation, which is the pair this order needs. The retailer's order number belongs in Customer Reference, because every document coming back quotes it.
Shipment notifications. Usually the 856, and on dropship it carries the tracking number the consumer is waiting on. It has to come from the validated delivery in Odoo, at the moment the parcel is packed.
Stock quantities. Usually the 846. The figure that goes out should be the quantity Odoo can actually promise, net of stock already reserved for orders in flight, because the retailer sells against it to consumers.
Invoices. Usually the 810. Rithum states its platform can generate retailer invoices from each shipment, which makes the shipment record in Odoo the source the invoice is built from. Which of these documents your programme runs, and in which version, is set by your retailer's guideline.
Where to read the rest
The two routes are set out side by side on the home page, the documents are explained on the transaction codes page, and what a mistake costs is on the deductions page, and the delivery work is set out on the Odoo EDI integration services page.
When you should not use us for this
If your volume through this network is small and stable
A person handling it may be cheaper than a project, and we will say so on the call.
If you are still deciding whether to take the programme
That decision comes before any integration question and it is not one we should be pricing.
Bring the guideline
Bring the guideline your customer sent you. Thirty minutes, Mountain Time, with the person who would do the work. You will leave knowing which parts of this are already covered by what you run and pay for, and which parts are work.
Book a 30-minute call