Skip to Content
N° 01 Integration Engineering · Logistics

Roboost status, on the Odoo order

A POS order that needs a driver becomes a Roboost dispatch task. The reference comes back. Pickup, on-the-way, delivered, failed and cancelled write onto that same order, so kitchen and dispatch are not running two lists.
N° 02 What Roboost already is

Roboost already runs the driver

Roboost is last-mile dispatch in Kuwait. Stores hand it a task; it assigns a driver and reports status. It is not a warehouse system and it is not the ordering storefront.

Odoo does not replace Roboost. The work is to create the task from a POS order and to bring driver status back, instead of a dispatcher retyping the address into another screen.

The account and the store code stay yours.

Platform
Roboost (Kuwait last-mile dispatch)
Odoo side
Point of Sale orders, customer address
Direction
Odoo → Roboost on order create. Roboost → Odoo on driver status.
Geography we have run
Kuwait
Availability
Built to order. Not a module on the Apps Store.

DelhiveryOne is the published India shipping module. Logistra is the Nordic carrier connector. Roboost is this Kuwait dispatch shape. Logistics

N° 03 Where it breaks in production

A driver update nobody filed is a lost delivery

Sending the task is not the job. The job is that the POS order still tells the truth two hours later.

The address is not a street line. Kuwait delivery needs area, block, street, building, avenue, floor, apartment, and usually GPS. A single street field is how the driver calls the customer from the wrong block.

Cash vs paid is a dispatch fact. Roboost has to know whether the driver collects. If Odoo sends the wrong tender type, the drop-off becomes an argument at the door.

Status dies in a callback. On the way to pickup, picked up, arrived, delivered, cannot deliver, cancelled: if that callback hits a URL nobody owns, the kitchen still thinks the order is waiting.

The order existed before dispatch. In-store POS and Ordable tickets both need drivers. A connector that only listens to one source leaves the other on paper.

N° 04 What we do about each

One task out, every status back

Send on create, when the company is on. If Roboost is enabled for that company, a POS order becomes a dispatch task: store code, order number, customer, Kuwait address and GPS, lines, totals, tax, discount, delivery fee, payment type, planned pickup from the delivery slot when one exists. Roboost returns a reference stored on the order.

Address as Kuwait uses it. Area, block, street, building, avenue, floor, apartment and coordinates travel on the customer, not as a note the driver has to parse.

Tender type on the task. Cash vs other is sent as a dispatch field, not hoped from the order comment.

Status on the same record. Roboost posts driver status onto that POS order: on trip, on the way to pickup, arrived to pickup, picked up, on the way, arrived to dropoff, delivered, cannot deliver, cancelled. Staff read it next to the ticket, not in a second login.

Manual send when automatic did not. If a task failed validation (missing mobile, missing street), operations can send it once the record is complete, without re-creating the order.

On the unnamed three-branch estate, Ordable creates the POS order and Roboost takes the delivery ones. Print is a separate layer on that same order. Ordable

N° 05 Proof

Dispatch on the POS estate, client unnamed

Kuwait, three branches, Ordable tickets becoming Odoo POS orders, delivery ones handed to Roboost, driver status back on the ticket the kitchen already printed. The operator is not named.

That is logistics proof sitting inside a POS estate, which is why this page and the Ordable page point at each other. This section links the case study.

Delivered
Task create, reference stored, driver status callbacks, per-company on/off and store code
Runs with
Odoo POS. On one estate, orders originate in Ordable.
Client
Unnamed
Not this page
DelhiveryOne labels; Logistra Nordic rates. Those stay on logistics.
N° 06 What you need in place

A store code, and an address the driver can use

A Roboost account, API token, sandbox vs production URLs, and the store code for each Odoo company that dispatches.

Customer records that actually hold Kuwait address parts and a mobile number. We will not invent GPS.

A rule for which POS orders go out (delivery vs pickup, which companies). Pickup tickets must not create driver tasks.

A public callback URL Odoo can receive status on. A local database with no HTTPS endpoint will take the task and never hear the driver.

Sandbox deliveries you will cancel and fail on purpose. “Delivered” is the payload everyone tests. “Cannot deliver” is the one operations will hit.

We do not book Roboost capacity or hold driver contracts. Credentials stay yours.

Which courier is updating a board Odoo cannot read?

Send the dispatch platform, the city, and whether orders start in POS or on a storefront. If it is Roboost in Kuwait, that is this page. If it is a carrier with labels and rates, start on logistics instead.

Talk to us