There’s a particular kind of bug that doesn’t crash anything, doesn’t throw an error, and doesn’t show up in any log file. It just quietly charges your customers the wrong amount. That’s exactly what was happening in Odoo’s restaurant self-order system when customers ordered combo meals from their phones.
The scenario was specific but not uncommon: a customer opens the self-order interface on their mobile device, builds a combo with multiple products, and orders the same combo more than once. Everything looks fine on the phone. But when the order arrives at the restaurant’s POS backend, the price is different. Not by a lot — but enough to create a discrepancy that cascades through end-of-day reconciliation.
Where the Math Went Wrong
The root cause was in how the system split combo items between “free” and “extra” categories during price recomputation on the backend. Every combo has items that are included in the base price and items that cost extra. When the backend recalculated prices, it needed to figure out how many of each type existed per combo unit.
The problem: it wasn’t accounting for parent line quantities. If a customer ordered two of the same combo, each child item line had a quantity of two. But the system was treating those as two individual items rather than two instances of one item per combo. This threw off the free-vs-extra split, which threw off the unit price, which threw off the total.
The fix introduces a qty_per_linecalculation that divides each child line’s quantity by its parent combo’s quantity. That gives the system the correct per-combo count for splitting between free and extra tiers. The remaining total and original total calculations were also adjusted to account for multiple combo quantities when distributing unit prices.
Why This Was Hard to Catch
Single-combo orders worked perfectly. The bug only manifested when the same combo was ordered multiple times in a single transaction. And even then, the prices on the customer-facing mobile interface looked correct — the miscalculation happened during backend recomputation. So the customer saw one price, the kitchen saw another, and the difference only showed up when someone bothered to cross-check the two.
This is the kind of bug that lives happily in production for months. Most restaurants don’t audit individual combo line items against the self-order interface. They notice when the numbers don’t add up at the end of the day, and they chalk it up to something else. Meanwhile, the pricing engine is quietly miscalculating every multi-combo order that comes through mobile self-ordering.
The Broader Self-Order Context
Odoo’s self-order module has been gaining traction in restaurants that want to reduce counter wait times without installing dedicated kiosk hardware. Customers scan a QR code at their table, browse the menu on their phone, customize their combo, and submit the order directly to the kitchen. It’s a slick workflow when it works — and pricing accuracy is the one thing that absolutely cannot be wrong.
The fix also landed with a comprehensive test case that validates unit prices match correctly across multiple combo quantities. That test didn’t exist before, which explains how the bug shipped in the first place. Combo pricing with quantity multipliers is one of those edge cases that’s easy to skip in initial QA because single-unit orders pass every check.
For restaurant operators running Odoo’s self-order system, this fix resolves a source of silent revenue leakage. The correction ships with the standard update cycle — no manual intervention needed, no database migration, just corrected math where it matters.