Ordable orders that land in Odoo
Ordable already takes the order
Ordable is a cloud ordering and POS storefront. Customers place pickup or delivery there. The catalogue, the slot, the address and the tender live on that side first.
Odoo does not replace that storefront. The work is to make a confirmed Ordable ticket into a POS order on the right branch, with stock, payment and reporting following, rather than a second back office that drifts by lunch.
We do not resell Ordable. You hold the Ordable account. We configure Odoo against it.
- Platform
- Ordable (ordering / POS storefront)
- Odoo side
- Point of Sale, products, partners, payments
- Direction
- Two-way on catalogue and orders. Incoming webhooks for new orders, status, payment, product active/inactive.
- Geography we have run
- Kuwait
- Availability
- Built to order. Not a module on the Apps Store.
The demo order is not the failure
The first ticket appearing in Odoo is the easy hour. Production is the rest of the week.
The branch is wrong. Ordable branches and Odoo companies are not the same object. If the map is loose, an order prints in the wrong kitchen.
The catalogue forks. English name in Odoo, Arabic on the storefront, image cropped to a size Ordable will not accept, a modifier group that is required on one side and optional on the other. Staff then sell a product the other system does not know.
Payment lands as a note. Ordable’s tender name is not an Odoo payment method. Unmapped, the order sits unpaid in POS while the customer has already paid.
Refunds are one-sided. Cancelled on Ordable, still a sale in Odoo. Month-end is when finance finds it.
Status is a screenshot. Received, preparing, driver pending, out for delivery, ready to collect: if that string dies in a log, the kitchen is still watching a tablet.
Each of those has an answer below.
One POS order, the full life of the ticket
Branch map. Each Ordable branch is bound to one Odoo company and one open POS. Incoming orders open on that session, not on a generic catch-all.
Catalogue the storefront can publish. Products, POS categories and modifier groups push out with Arabic names and descriptions. Images are resized to what Ordable requires. Auto-sync can be on per product so a price or name change does not wait for a manual export. Modifier groups carry required/optional and min/max choices.
Orders as POS, not as a comment. A new Ordable order becomes a POS order: lines, toppings, extras, discount, delivery fee, special remarks, pickup vs delivery. Kuwait address sits on the customer (area, block, street, building, avenue, floor, apartment, PACI, GPS) and a delivery zone. The slot sits on the order.
Status on the record. New, received, preparing, driver pending, out for delivery, ready to collect, cancelled, refunded, complete. Updates write onto that order. Cashiers see address and zone inside the POS session.
Tenders mapped, refunds posted. Ordable payment methods map to Odoo POS methods. When Ordable marks paid, Odoo records the payment. Cancel or refund on Ordable creates the matching refund in Odoo rather than leaving a ghost sale.
Print, if the outlet needs it. On this estate, a confirmed online order alerts the open POS and prints to the role assigned for that brand (counter vs kitchen). Print success or failure is stored on the order. That printer work is part of the POS estate, not a second project with a different owner. Detail sits on the case study, not here.
In-store POS orders can also be sent the other way to Ordable when the storefront has to show them.
Three branches, one estate
One customer, three branches, Ordable and Odoo POS kept in agreement on products, categories, inventory, orders and payments, plus kitchen and counter print on the incoming ticket. The operator is unnamed.
That is the Integration Engineering proof card already on the hub. This section links the case study. The pattern is the proof; the name is not.
- Delivered
- Catalogue, orders, payments, refunds, delivery slots, Kuwait address, auto-print
- Branches on that estate
- 3
- Client
- Unnamed
- Also on that estate
- Roboost dispatch
Foodics is a different till. It is not this engagement. Foodics →
Credentials you hold, mapping we write down
An Ordable account, API access, and a sandbox you will actually place test orders in. We do not hold your keys after handover.
A stable map: Ordable branch → Odoo company → POS. Written before the first webhook is turned on.
Payment-method names from Ordable matched to Odoo tenders, including the ones used once a month.
Arabic copy on products you sell in Arabic. We can carry the fields. We cannot invent the words.
An open POS session on each branch that should receive online orders. A closed session is how tickets queue in the wrong place.
If kitchen print is in scope: printers reachable from a print server, and a role per station. Odoo IoT Box is not assumed. We have already left it on a network that would not hold it.
We will not start against production only. The messy cases (partial payment, refund after print, modifier-only line) have to happen in sandbox first.
Which storefront is taking orders Odoo cannot see?
Send the platform, the number of outlets, and whether print and dispatch are in the same conversation. We can usually tell you in one reply whether that is a mapped integration or a second back office you should stop feeding.