If you’ve ever watched a cashier fumble through a busy lunch rush because they couldn’t find the button to park an order and pick it up on another register, you know how small UI decisions can ripple into real operational headaches. Odoo just fixed one of those decisions in its Point of Sale module, and it’s the kind of change that matters more than it looks.
The “Save Order” button — the one that lets a cashier save a pending order and resume it on any other device in the same POS session — used to be conditionally hidden. It only appeared when the POS configuration had “trusted config IDs” set up, meaning most single-register shops or teams that hadn’t dug into the multi-device settings never saw it at all.
What Actually Changed
Odoo ripped out the conditional logic entirely. The getter method that checked whether trusted configurations existed —showSaveOrderButton— is gone. The XML templates for both mobile and desktop views no longer wrap the button in ant-if condition. The button is simply always there, sitting in the action pad alongside Pay and Customer, ready to be tapped whenever a cashier needs it.
Three files changed. Five lines of conditional logic deleted. Zero new configuration options added. This is the kind of simplification that makes software better by removing a decision point that shouldn’t have existed in the first place.
Why the Old Behavior Was a Problem
The original design assumed that only businesses with multiple trusted registers would need to save and transfer orders. That assumption was wrong in several ways. A single-register shop might still want to park an order while handling a quick transaction. A restaurant with one POS terminal might need to save a large catering order and come back to it between walk-in customers. A pop-up retail setup might add a second device mid-shift without reconfiguring trusted IDs.
By tying the button’s visibility to a backend configuration setting, Odoo was asking shop owners to solve a workflow problem through a settings panel they probably never opened. That’s the kind of friction that makes people think the feature doesn’t exist.
How Cross-Device Order Transfers Work Now
The workflow is dead simple. A cashier starts an order on Register A, taps Save Order, and the order is parked in the session. Any other device connected to the same POS session can pull up saved orders and resume them. The order carries over with all its line items, customer assignment, and any notes attached.
This matters most in restaurant and hospitality setups where orders might start at a kiosk, move to a server’s handheld, and finalize at a fixed register. But it’s equally useful in retail scenarios where a sales associate starts building an order on a tablet and hands the customer off to a checkout counter.
The key insight is that making the button always visible doesn’t add complexity for single-device setups. If there’s only one register, saving an order still works — it just parks the order for later on the same device. There’s no downside to having the button present, and the upside is that every POS user now discovers the feature without needing to read documentation or ask an administrator.
A Pattern Worth Watching
This change is part of a broader pattern in Odoo’s POS development: removing gatekeeping logic that hides useful features behind configuration requirements. The same session also landed fixes for combo product sequencing, category grouping with excluded products, and invoice layout spacing. Each one is small on its own, but together they signal a POS team that’s paying attention to the daily friction points that cashiers and store managers actually deal with.
For retailers running Odoo 19, the save button will simply appear the next time the POS loads. No migration, no setting to toggle, no action required. Which is exactly how it should have worked from the start.