Kitchen output

Kitchen output sends price-free preparation slips to the kitchen the moment a sale completes. It comes in two complementary forms that share one route profile: per-line labels and per-station grouped tickets. This page covers the basics - what prints, when it queues, and how to retry or reprint. For sending different items to different stations, see Multi-station kitchen routing.

Two complementary outputs

• Line labels - one immutable, price-free label per sale line per physical copy. Each label is dispatched as its own independently recoverable durable job, rendered either through the kitchen label RDLC report for page printers or as raw ESC/POS, ZPL, ePOS-Print, or WebPRNT for thermal and label hardware.
• Grouped tickets - one kitchen ticket per destination per copy, listing every enabled line routed to that station. Automatic ticket identity is exact per document, completion generation, destination, and copy.

Both forms route through Kitchen Label print destinations - you configure one destination per physical station and Bitta Retail POS uses that single route profile for both labels and tickets. Destination setup, transports, and the print queue are covered in Printers and hardware setup.

What decides whether an item prints

POS Categories provide the kitchen defaults: enabled state, destination, and copies. An individual POS Item can explicitly enable or suppress the category policy and independently override the destination or copy count. A copy count of zero inherits the default; effective kitchen copies are 1..20. Explicit routes are scope-checked against the sale's store and terminal.

What is on kitchen output

Content is operational only: order and document identity, order name and type, promised, completed, and request times, the source line, item description, variant code, quantity and unit of measure, preparation instructions, modifier summary, store, terminal, cashier, destination, and copy position. Price, tax, tender, payment, and card data are always excluded - kitchen output is price-free by design.

Every copy renders from a frozen JSON snapshot with parity across RDLC (a 4x3-inch page report), ESC/POS, ZPL, Epson ePOS-Print, and Star WebPRNT: the same captions, line list, variant, modifiers, notes, copy position, and reprint marker in every language.

When output queues

Automatic kitchen output is created only after the completed sale and payment transaction commits, inside an isolated runner. A printer-configuration, render, send, or extension failure can never roll back the sale or the money, and the label and ticket pipelines are isolated from each other, so a failure in one never suppresses the other.

Idempotency keys prevent duplicate automatic output if completion is invoked again: labels key on document + completion generation + line + purpose + copy; tickets on document + completion generation + destination + purpose + copy. Explicit user reprints intentionally create new jobs.

Retry vs reprint

The two recovery actions behave differently, and the difference matters:

• Retry frozen job (from POS Print Jobs) re-delivers the exact retained job: same destination, transport, language, copy, request time, and JSON model. It does not read changed item, category, or printer setup, and it does not repeat stations that already succeeded.
• Reprint current configuration creates brand-new reprint rows from the current route setup. Use Reprint Kitchen Output on the POS Sales card, the Select Kitchen Output page, or Printer -> Reprint Last Kitchen Output at the register. All of these recreate both labels and grouped tickets. Leaving Destination blank fans out to every routed station; picking a destination forces one station. Printing the configured copy count needs no approval, but any copies override requires the scoped supervisor PIN.

Failed jobs stay classified with a failure category (for example ConfigurationInvalid, RenderFailed, or the interactive-deferred case above) and actionable detail. Receipts aside, unresolved kitchen jobs can also be cancelled from POS Print Jobs.

Kitchen print audit

The POS Kitchen Print Audit report is a retained history of kitchen output: one row per physical copy showing output scope (grouped ticket or item label), destination, copy position, completion generation, reprint flag, status, attempt count, failure category, transport, and timestamps. Transport payloads and connection details are deliberately excluded. Filter by date, store, terminal, document, destination, status, reprint flag, generation, or transport.