Kitchen Order Routing: Which Station Should Receive Each Product?

A restaurant order containing drinks and hot food may need to reach different preparation stations. Before connecting a point-of-sale app to printers, define which products belong at each destination and what staff should do when a product has no route. A working printer is not enough if the wrong team receives the work.

This is a commissioning guide for preparation routing, not food-safety advice or a guarantee of compatible hardware. Have kitchen procedures and equipment compatibility reviewed separately. Routing decides where instructions go; course controls decide when preparation is released.

Write a station map before configuring devices

Use a small sample menu to describe the desired outcome. A hypothetical café might send drinks to the bar and cooked dishes to the kitchen. Decide whether a combined order should produce separate station tickets, and what context each needs to identify the same order.

The Odoo 19 restaurant documentation gives a specific configuration example. Preparation printers have a Printed Product Categories field, and the guide requires a PoS Product Category for kitchen-order printing. This is a category-based routing example, not evidence that every app automatically understands which station prepares a product.

Assign responsibility for maintaining the map. Adding a new menu item should include checking its preparation destination, not only its customer-facing description and selling price. Do not assume a website navigation category is necessarily the same category used for preparation.

Specify missing and shared destinations

What happens if a product is uncategorised or its category is not assigned to a station? Ask the proposed implementation to expose that case during configuration and demonstrate the agreed behaviour during service. A missing route must not look like confirmed kitchen receipt.

Also decide whether any product genuinely needs instructions at several stations. If so, identify each station's responsibility. Two copies of the same instruction are not automatically two meals, and a duplicate destination should not accidentally create duplicate work.

These are proposed requirements. The cited Odoo section establishes category selection and the category prerequisite; it does not establish every overlap, inheritance or missing-category outcome. Test those behaviours in the actual version and configuration rather than inferring them from a category tree.

Keep device identity and work identity separate

Name the destination so staff can recognise its operational role. Record the actual connected device separately. Replacing the bar printer should not require guessing which business rule an old network address represented.

Odoo documents both an IoT-connected printer route and an Epson configuration route, each with its own setup requirements. This does not make an arbitrary printer compatible. Have the developer verify the intended model, network and connection method before purchasing or promising a supported installation.

Agree who notices a failed destination and how work is reconciled with the station. An app recording a send attempt does not prove paper emerged or a cook read it. Specify release timing and reprints alongside routing, rather than letting the routing feature create another independent preparation trigger.

Test a mixed order and a menu change

Use fictional products to demonstrate a kitchen-only item, a bar-only item, a mixed order, a deliberately unmapped item and any permitted multi-station item. Inspect the actual output at each agreed destination, including its order context. Then change a product's category and show what future orders do without claiming earlier instructions have moved.

Disconnect one destination in an authorised test environment and demonstrate the fallback procedure. Record the expected outcomes in the acceptance criteria. Accept the complete product-to-station path, not a successful test page from one printer.

Evidence boundary

The official Odoo 19 restaurant documentation source, read on 26 October 2026, supports preparation-printer categories, the PoS category prerequisite and the documented connection choices. Missing-route warnings, station ownership, duplicate-work controls and failure reconciliation are requirements for separate implementation and testing. No physical printer was tested for this article.