Advance KDS Item
Move one visible kitchen item on the Harbor Soho KDS board to its next production stage with a left swipe, keeping the board and returned ticket detail in sync.
In this article
Use this guide when a KDS operator needs to advance one live kitchen item during the Harbor Soho service. The workflow is row-level: one visible item, one swipe, one production-stage change.
The item moves through draft, sent, preparing, ready and served. Served and cancelled items are not shown on the KDS board, so a ready item advanced to served leaves the board after refresh.
Before you start
- Harbor Demo Group and Harbor Soho are selected as the current organisation and location.
- The Harbor Soho KDS board is open at /:orgId/:locationId/kds?terminalId={TPV_TERMINAL_ID}.
- KDS is enabled in the location TPV settings.
- There is an active service session for Harbor Soho, such as Soho lunch service.
- The ticket is open, not void, and contains at least one visible KDS kitchen item in draft, sent, preparing or ready.
- The operator has kds:use or kds:manage for Harbor Soho. kds:view can load the board but cannot advance rows.
Instructions
- 1.
Open the KDS board
Open the Harbor Soho KDS route for the demo terminal. The board loads active-service tickets and groups visible kitchen items by production stage.
- 2.
Choose one visible item
Choose a single item row that belongs to the kitchen flow. The item must require kitchen preparation or already be in sent, preparing or ready.
- 3.
Swipe left to advance
Swipe the item row left until the next-stage action commits. The board calculates the next status as draft -> sent -> preparing -> ready -> served.
- 4.
Check the refreshed board
After the request succeeds, the returned TicketDetail refreshes the board. The item moves into its next visible stage, or disappears when ready advances to served.
Validations and limits
- Rows are read-only for users who only have kds:view; use kds:use or kds:manage for this workflow.
- If no organisation, location, active service session, or enabled KDS setting is available, the board blocks the operation before the swipe can run.
- The KDS client uses POST /api/app/{orgId}/{locationId}/tickets/{ticketId}/items/production-status with item_ids, from_statuses, to_status and suppress_output.
- When this KDS swipe moves an item from draft to sent, suppress_output is true, so it does not create kitchen output jobs.
- The backend also accepts PUT on the same production-status route, but the Harbor Soho KDS board uses POST.
- If from_statuses no longer matches the item current production status, the backend returns the current TicketDetail without changing the item.
- Current en-GB captures may show Spanish fallback KDS stage labels if no runtime translation source provides kdsPage.* strings.
Expected result
The selected item advances by one production stage and the KDS board redraws from the refreshed ticket detail.