Update production status

In this article

Before you start

• The operator is signed in to Harbor Demo Group with Harbor Soho selected, an active service session, and an open ticket such as TPV_TICKET_ID.
• KDS is enabled in TPV/KDS settings before the operator changes production status.
• The ticket belongs to Harbor Soho and is not void. Current TPV and KDS screens avoid closed tickets, but the confirmed backend rejection is for void tickets.
• The operator has a mutating permission such as kds:use, kds:manage, tpv:kitchen-manage, tickets:manage or tpv:manage. kds:view is read-only.
• At least one visible item is eligible for the requested stage. Kitchen-routed items can use sent, preparing and ready; non-kitchen items can only use draft, served or cancelled.
• A kitchen printer or KDS output device is active and selectable when the operator expects pending kitchen output after sending items.

Instructions

1. 1.

   Open a production surface

   Open the KDS board or the active ticket detail for Harbor Soho. Production status changes only from these two surfaces: use KDS for kitchen item movement, and ticket detail when sending the current ticket items to kitchen or moving one item between stages.

2. 2.

   Choose the item and target stage

   Select a visible item row. Kitchen items normally move draft, sent, preparing, ready and served; non-kitchen items can move from draft directly to served or cancelled.

3. 3.

   Send draft items to kitchen

   From ticket detail, use the send-kitchen action for draft kitchen items. The UI moves selected items to sent while suppressing duplicate output, then requests a kitchen_order output job for the selected items.

4. 4.

   Advance work on KDS or from the ticket detail

   On KDS, move one item between visible stages as the kitchen works. In the POS account detail, whether in Tables, Accounts, All accounts or the full ticket detail screen, swipe an item row and use Change to <status> or Back to <status>; this needs KDS enabled and kitchen management permission. Served and cancelled items leave the visible KDS board.

5. 5.

   Review the downstream queue

   After sending items, review the Print and KDS queue when output should be created. Antylogic records pending output jobs; physical printing or KDS delivery is handled by the separate output-job flow.

Validations and limits

• The target status must be draft, sent, preparing, ready, served or cancelled.
• The request must identify at least one item_id or one valid from_statuses value after blanks and duplicates are removed.
• Each explicit item_id must belong to the current ticket, or the backend rejects the selection.
• A direct item update cannot force a non-kitchen item into sent, preparing or ready. Bulk movement skips non-applicable non-kitchen items instead of failing the whole request.
• The backend rejects production-status changes when TPV settings have enable_kds disabled.
• The backend rejects production-status changes for void tickets; closed-ticket backend behaviour should not be documented as rejected without separate validation.
• If no item matches the selectors, or every selected item is already in the target status, the backend returns the current ticket detail and does not create output jobs.
• Only a move to sent can create output jobs from the production-status endpoint, and only when output is not suppressed and a selectable output device exists. Terminal routing belongs to the separate ticket print request, not the production-status endpoint.

Expected result

The selected ticket items move to the requested production stage, state-specific timestamps are updated, TPV and KDS refresh their visible rows, and sent kitchen items can leave pending kitchen printer or KDS jobs for the separate output workflow.