Multi-station kitchen routing

Multi-station kitchen routing sends one POS Category or POS Item to several physical kitchen stations at once - grill, bar, expo, packing - each with its own output form, priority, and copy count. This page covers the routing model; the basics of what kitchen output contains and how it queues are in Kitchen output.

Stations are destinations

Every physical station is one active Kitchen Label print destination - create one for each station, for example Grill, Bar, Expo, or Packing. Configure copies and the language compatibility (ESC/POS, ZPL, RDLC, ePOS-Print, or WebPRNT) on each destination as described in Printers and hardware setup.

From POS Categories or POS Items, open Kitchen Routes and map the source to every station it should reach. Each route selects:

• Output - Both, Labels, or Tickets. A station can receive per-line labels, a grouped ticket, or both.
• Priority - orders the delivery attempts. Priority is not failover: every resolved station is attempted regardless of what happened at a higher-priority station.
• Copies - per-route copy count; effective kitchen copies are 1..20.

Kitchen Route Mode

Each POS Item declares how its own routes combine with its category's routes via Kitchen Route Mode:

Mode	Behavior
Legacy	Preserves the old single-destination item/category fields. This is the default for existing items after upgrade.
Inherit	Uses the category's route set as-is.
Add	Unions the item's and the category's destinations; where both define a route to the same station, the item's route properties win.
Replace	Uses only the applicable item route bucket. Requires at least one active item route.

Scope precedence

Routes, like destinations, can be scoped. Resolution walks terminal, then store, then company, and the first nonempty active bucket replaces the lower scopes - scope levels are never unioned. That means a terminal-scoped route set for an item completely overrides that item's store- and company-scoped routes, not adds to them.

Delivery and recovery

Automatic label identity includes the destination and copy, so completing a sale produces exactly one durable job per station per physical copy - see the idempotency rules in Kitchen output. Labels and tickets retain their resolved delivery fields and frozen JSON model:

• Retry frozen job re-delivers the exact retained row to the same station with the same model. It does not re-read current routing and does not repeat stations that already succeeded.
• Reprint current configuration builds new rows from the current route set - use it after you change routing and want the sale's output to follow the new map.

All kitchen output remains price-free regardless of how many stations it fans out to.

Upgrade behavior

The routing upgrade is additive. Upgrading creates no Kitchen Route rows; every existing item remains in Legacy mode with its old scalar item/category fields intact until an administrator changes it, and retained queue rows remain readable. You can migrate one category or item at a time with no big-bang cutover.