Online orders, kitchen tickets, and last-mile dispatch on one Odoo POS.

Each brand ran its own POS. Ordable was already taking digital orders and the customers were already using it. The gap was everything after the order arrived.

Someone had to see it. Kitchen and counter tickets were printed by hand, which is workable at eleven in the morning and not at eight in the evening. A missed ticket at peak is not a printing inconvenience, it is an order the kitchen never started. Nothing confirmed that a ticket had printed at the right station for the right brand, so the only verification available was a member of staff walking over to look.

Delivery lived in a second tool. Driver status sat there, not on the order the kitchen was working from. The printers were already in the outlets. Nothing drove them.

Around the three layers: recipe cost on the bill of materials, an unused-product flag, goods-receipt and period stock reports, and training videos inside Odoo so the floor could be taught without a second system to log into.

The hard part was never calling an ordering API. It was firing print at the right outlet, in the right language, for the right brand, and knowing that it happened.

Routing had to be configuration. Hardcoded outlet names work until the fourth brand opens, and then they are a code change instead of a settings change. Brand and station routing is configured per outlet.

Arabic on a thermal printer is its own problem. Reshaping, direction and encoding are not solved by taking a Latin receipt template and translating the labels. The ticket has to come out readable to a cook who is not going to debug it.

Print status had to come back. A print job that silently fails is worse than no automation, because staff stop checking. Success and failure land on the order, so the failure is visible where the order already is.

We evaluated Odoo’s IoT Box and left it. It did not hold on their network across multiple outlets. Print now runs through a dedicated Ubuntu print server. That was a mid-project reversal and it cost time. It was the right call, and a multi-outlet print estate is where we would expect to make it again.

Dispatch only counts if it lands on the printed ticket. Driver status in a second screen is a second list. It writes onto the order the kitchen already has.

Online orders print when they confirm. Nobody polls a screen. Kitchen and counter each get the correct brand’s ticket, and print status is on the order rather than in someone’s memory. Delivery reference and driver status sit on that same record. Catalogue, payments and refunds are in Odoo instead of a second back office that drifts by lunch. Operations can see print health, ordering sync and dispatch sync in one view.

No rates, no percentages. What changed is the operating shape, and that is checkable.

Built and taken live in 2026. The estate has been in production for a matter of weeks, not years, and is in support now.

Ordering platforms and dispatch APIs move on their own calendars, and print hardware does too. A POS estate is not finished at the first successful order; it is finished at the first platform change it survives without anyone noticing. That has not been tested yet here, and we would rather say so than imply a track record this engagement has not had time to build.

What we hold is the seams: status drift, payment mapping, print failures, and the places where three vendors meet one record. That is the standing work, and it does not have an end date.