Introducing the Alumio Route Builder
Now connect, orchestrate, and govern integrations at scale from one visual interface
The return requests Bol sends back have a clock on them, so Odoo receives each one as it is raised and the seller can still answer inside the window rather than after it has quietly closed.
Selling on Bol means agreeing to be judged on how returns are handled, not just on how quickly parcels leave. A buyer raises a return, the seller has a window to respond, and if nobody does the marketplace settles it for them. Odoo holds the original order and the stock the goods will come back into, but it hears about the return when somebody logs into the seller portal and notices. Connecting Odoo and Bol brings the request in as it is raised, against the order it belongs to, so responding is part of the day's work instead of something discovered on a Friday afternoon.
DATA THAT FLOWS BETWEEN THEM
Offers
Stock levels
Marketplace orders
Return requests
Shipment confirmations
Customer details
A Bol return request reaches Odoo against its original order as it is raised, so somebody can act on it inside the window instead of finding it in the portal afterwards.
When a returned item is received, the Odoo stock position moves and the Bol offer follows, so a unit that is sellable again is offered again without anybody adjusting two screens.
Because the Bol order and its return share the same Odoo record, a refund and a restock describe one event rather than two entries somebody has to connect later on.
Returns handled inside Bol's window stop showing up as marks against the account, so a seller rating reflects the operation rather than how often the portal was checked.
A buyer raises a return on Bol and Alumio creates it in Odoo against the original order with its reason attached, so the team sees what is coming back and why while there is still time to respond to the marketplace.
When the goods are received back and marked sellable in Odoo, Alumio publishes the new figure to the Bol offer, so the unit is on sale again rather than sitting in a bay waiting for somebody to remember to relist it.
A Bol order is created in Odoo as it arrives with its marketplace reference kept, so it is picked and dispatched alongside every other order and the confirmation goes back to the channel as the parcel leaves the building.
Alumio sits between sales channels and fulfillment systems as a governed integration backbone. Orders are routed, transformed, and validated, while status updates return to every channel.
Authenticate your systems using Alumio's pre-built connectors. Choose from 200+ connector packages in the marketplace, plus unlimited custom integrations.
Define how data fields map between systems in a visual interface. Adjust formats, enrich records, and apply business logic, no custom code required.
Configure flows to run in real time on events, on a schedule, or both. Reduce manual data entry and let Alumio handle movement and transformation between systems.
.svg){kind=icon}
Once your first integration is live, adding your ERP, PIM, WMS, or CRM connects to the same hub. Existing flows keep running. No rebuilding from scratch.
Without something watching the tax side, selling into a second country on Bol quietly creates obligations nobody has looked at. Bol reaches buyers in more than one market, Odoo records the sale, and neither is responsible for telling you when a threshold has been crossed. Alumio holds a connection to the service that does alongside this one, so the question is answered by a system rather than remembered.
Yes, and the offer and the promise behind it travel together. Alumio publishes the Odoo figure you nominate to each Bol offer on the schedule you choose, brings orders in as they arrive, and brings return requests in as they are raised. Keeping the return on the same route as the order is what lets it be matched to the sale rather than arriving as a separate thing to reconcile. Raising the return depends on what Odoo offers over its interface.
No, this is configured rather than coded. The habit it replaces is somebody re-uploading an offer file when the figures have drifted far enough to be noticed. Which Odoo warehouses count towards a Bol offer, what buffer is held back, and how often it publishes are settings in Alumio. Where a channel price is calculated on a rule of the business's own, the Code Transformer takes that step.
At the end of the response window, and that is the reason to bring the request in rather than watch for it. Bol gives a seller a period to accept, query or resolve a return, and once it passes the marketplace decides, which is rarely the outcome the seller would have chosen. Getting the request into Odoo as it is raised turns the window into something a person can actually use rather than something that expires quietly.
An offer still selling stock that has already moved in Odoo is the failure with a cost attached, because Bol counts the cancellation against the seller. Alumio monitors each publish live and records the offer and the quantity it carried, so an update the channel refuses raises an alert naming the offer and the reason. Retries run where configured, and the previous figure stays live, so nothing is quietly left stale.
Talk to an Alumio integration specialist. We'll map the right architecture for your systems, at the right scale, so your operations stay reliable through every change.
.svg)
