Moving Restaurant Guests to Another Table: What Should Happen to Their Open Order?

Moving guests to a different table should relocate their running order, not create a second meal order or make an unpaid bill disappear. Before commissioning a restaurant floor-plan screen, agree how a table move differs from joining two parties and from settling a bill.

The decision is about service during a visit. It is not about allocating advance reservations or choosing payment methods. A ready-made restaurant system may already handle the ordinary cases; start by demonstrating your service routine before deciding that custom development is needed.

Give the table and the order separate identities

In a fictional café, guests move from the terrace to an indoor table when it starts raining. The original order must remain recognisable after the move. Staff need to know where to deliver the food without entering the same items again.

Write down which information belongs to the order and which belongs to its current table assignment. A table number is a location, not a durable identity for the entire visit. Decide whether staff can see the former table, who performed the move and whether preparation staff need a location update.

These are proposed requirements, not evidence that a particular system retains every detail. Keep an ordinary relocation separate from changing products, cancelling dishes or making a financial adjustment.

Decide whether selecting a table means looking or occupying

The Odoo 19 restaurant documentation says that selecting a table in its floor plan, or accessing it through the table selector, automatically confirms occupancy. That is a concrete interaction rule, not a universal meaning of clicking a table.

For your own interface, settle whether a tap merely opens details or starts occupancy. A supervisor checking a table should not accidentally create a seated party if the intended action was inspection. Conversely, if selecting a table deliberately occupies it, make that behaviour clear and provide the appropriate authorised correction.

Do not describe an empty order as proof that the table is physically ready. Guests may be seated without having ordered; a departed party may leave a table needing clearing. Agree whether these distinctions belong in the software or in a separate staff routine.

Warn before a move becomes a merge

Odoo documents different outcomes for its Transfer/Merge action: choosing an available table transfers customers and their orders, while choosing an occupied table merges them. This matters when a staff member selects the wrong destination during a busy service.

Ask for a destination summary before a consequential merge. It should identify the target table and show that another party or order is already there. Agree which staff may merge and what happens to separate customer references, service notes and order ownership. Do not assume a single combined screen means the parties agreed to a single bill.

If guests only exchange seats or tables, demonstrate that exact scenario. Moving a whole party, moving selected items and joining two open orders are different operations. Leave unsupported operations out of the first release rather than using a misleading generic move button.

Keep location changes separate from payment and preparation

The cited documentation gives payment its own process, including selecting a payment method and validating it. A table transfer should not be presented as proof of payment. Specify what your integration permits once part of an order is already settled, and ask the supplier to demonstrate it rather than guessing from the floor-plan feature.

Likewise, ask how a changed location reaches the kitchen or food runner. The acceptance requirement is that staff can identify the new destination without preparing duplicate dishes. This article does not claim that Odoo automatically prints a transfer notice or prevents every duplicate kitchen action.

For a delayed or failed move, require an unambiguous outcome before staff try again. They should be able to find the existing order and its current table rather than creating a replacement because one screen stopped responding.

Test the service story, not only the floor drawing

Use harmless sample orders in your acceptance criteria. Demonstrate a move to a free table, an attempted move to an occupied one, an intentional merge, two staff acting on the same party and a move interrupted by a connection failure. Check the original order identity, new location, item quantities and outstanding amount after each permitted action.

Also demonstrate how mistaken occupancy is cleared. Odoo documents a Release table action when the cart is empty; that does not prove that any unpaid order may safely be discarded. For your system, make the allowed correction and its financial limits explicit.

Bring these scenarios to a restaurant workflow or integration discussion. The useful deliverable is continuity of service and a clear account of the open order, not merely a colourful map of tables.