Review the Print and KDS queue
Use the Harbor Soho TPV queue to review receipt, kitchen, control, invoice and KDS output jobs for the active service and selected terminal without changing job state.
In this article
The Print and KDS queue gives floor supervisors and KDS supervisors one place to check what the active Harbor Soho service has sent to printers, kitchen tickets, invoices and kitchen displays.
This guide covers the read-only list action. Marking a job printed, retrying a failed job, failing a job or completing a KDS job are separate lifecycle actions.
Before you start
- The operator is signed in with Harbor Demo Group and Harbor Soho selected.
- A Harbor Soho service session is active, for example Soho lunch service.
- For the TPV queue, the operator can open TPV and has print or manage access for the queue.
- For the KDS board, KDS is enabled in TPV settings and the operator has KDS access.
- If the TPV asks for staff identification, select Olivia Hart before opening More POS actions.
- Visible rows require matching `tpv_output_jobs` for the active service and terminal; otherwise the empty queue state is the correct result.
Instructions
- 1.
Open Harbor Soho TPV
Open the TPV floor view for the configured terminal at `/:orgId/:locationId/tpv?tab=floor&terminalId=:terminalId`. If staff identification appears, choose Olivia Hart and wait for the active service context.
- 2.
Open the queue from More POS actions
Open More POS actions and choose Print and KDS queue. This opens a TPV modal for the current service; it is not a standalone output-jobs page.
- 3.
Review the counters and rows
Use the Pending, Completed and Failed counters to read the queue state. Recent rows can show job kind, status, ticket or service reference, output device, requester, error detail and requested time.
- 4.
Keep the action read-only
Do not press Mark printed, Retry or any row action when documenting this list action. Those controls mutate output-job state and belong in sibling guides.
- 5.
Handle empty, loading and error states
If no rows match the active service and terminal scope, use the implemented empty state. While the request is pending the panel shows loading text, and permission or request failures show an error state.
- 6.
Use KDS only as supporting context
Open `/:orgId/:locationId/kds?terminalId=:terminalId` only to show how KDS consumes KDS jobs. KDS-only access must not be described as access to receipt, kitchen-order, control-order or invoice rows.
Validations and limits
- The list route is `GET /api/app/{orgId}/{locationId}/tpv-output-jobs`; detail and update routes are separate.
- Accepted list filters are `service_session_id`, `ticket_id`, `invoice_id`, `output_device_id`, `terminal_id`, `job_kind` and `status`, but the TPV modal does not expose these as manual controls.
- Location scope comes from request context, not from a `location_id` query parameter.
- Rows are ordered newest first by requested time and creation time. The implemented route has no pagination, limit or offset.
- The TPV panel shows up to eight recent rows and applies selected-terminal scope using `terminal_id` and `claimed_by_terminal_id`.
- The TPV counters group completed as Completed, failed as Failed and every other status as Pending.
- KDS-only backend access is constrained to `job_kind=kds`; requesting another kind without TPV access returns permission denied.
- Valid job kinds are `ticket_receipt`, `kitchen_order`, `control_order`, `invoice` and `kds`; valid statuses are `pending`, `claimed`, `completed`, `failed` and `cancelled`.
Expected result
The operator can inspect the active service output queue, understand whether output work is pending, completed or failed, and decide whether a separate lifecycle action is needed without changing any job from this list view.