How to configure kitchen routing for a product
Use the product form to decide whether a product enters the kitchen/KDS production flow and optionally give it a shorter kitchen-facing name. This does not enable KDS, configure stations, or set printers; it only stores the product-level kitchen flag and display name.
In this article
Kitchen routing is configured on the product itself. When a product is marked as requiring kitchen, new ticket items for that product can enter the KDS production flow instead of staying in the normal served-or-cancelled path.
The product form also lets the team set a kitchen-facing name. If that field is blank, KDS falls back to the short name and then the full product name, so Harbor Soho products such as Fish and chips can still appear with a compact kitchen label.
Before you start
- An organisation is selected. For location catalogue edits, a location such as Harbor Soho is also selected.
- The product exists in the editable scope being opened, or the operator is creating a new product from the product form.
- The operator can view the product with catalog:view or catalog:manage; saving requires catalog:manage.
- The product still has valid required catalogue data: name, price, product type, and tax category.
- To verify the result in KDS, KDS must be enabled for TPV settings and the operator needs the relevant KDS or TPV permission.
Instructions
- 1.
Open the product
Open the product from Products or by the direct product detail route. In the GB demo, location products such as Fish and chips or Beef pie are suitable examples because they are already kitchen-required.
- 2.
Check the required fields
Before changing kitchen settings, make sure the name, price, product type, and tax category remain valid. Saving uses the full product form, so unrelated required fields must still be acceptable.
- 3.
Set Requiere cocina
Turn on the field shown as Requiere cocina when new ticket items for this product should enter the kitchen/KDS production flow. Turn it off for products that should stay outside KDS, such as normal drinks or items served directly.
- 4.
Add Nombre cocina if useful
Use the field shown as Nombre cocina for a short kitchen-facing label. Leave it blank when the short name or full product name is already clear enough for the kitchen team.
- 5.
Save the product
Save becomes available only when the form has changes and the full product remains valid. The save sends the complete product payload, including requires_kitchen and kitchen_name alongside price, type, tax, image, allergens, and specifications.
- 6.
Verify the KDS effect
After the product is used on a ticket, the backend enriches ticket items with the kitchen flag and display labels. KDS shows Kitchen name first, then Short name, then Name.
Validations and limits
- A location route cannot edit an organisation product unless the product belongs to the exact editable location scope.
- Deleted items, read-only routes, or users without write access leave the product form in read-only mode and do not expose a save action.
- Name must not be empty, price must be parseable, non-zero, and not negative, and the frontend requires product type and tax category.
- If a product type is sent, it must belong to the same organisation or location scope as the product.
- Requires kitchen is a boolean field and has no extra required validation.
- Kitchen name is optional; blank text is normalised so the backend stores no kitchen name. No maximum length or format rule was found.
- If there are no changes, the form does not call the API.
- This action does not enable KDS, configure kitchen stations, set output devices, or set printers.
- Changing the product does not directly rewrite existing ticket items.
Expected result
The product stores its kitchen routing flag and optional kitchen name. New ticket items for that product can be treated as kitchen work, and KDS displays the best available kitchen label using kitchen_name, then short_name, then name.