Printers and hardware setup

Bitta Retail POS prints receipts, kitchen output, and test pages through a single routing model: purpose-scoped Print Destinations delivered over five transports, backed by a durable print queue that survives failures and browser crashes. This page is the administrator's guide to configuring and troubleshooting that stack. For what cashiers see at the register, read Receipts at the register.

The Print Destination model

A POS Print Destination binds a purpose - Receipt, Cash Drawer, Kitchen Label, or Test - to a transport, a print language, an endpoint or printer identity (or a report ID), an active/default state, and a default copy count. Open the model from POS Setup via the Print Destinations and Print Jobs actions, or through Tell Me. The destination card hides the fields that do not apply to the chosen transport.

Destinations are scoped to a terminal, a store, or the company (blank store and terminal). Resolution is deterministic:

1. An explicit active destination wins.
2. Otherwise the terminal default for that purpose.
3. Then the store default.
4. Then the company default.

Two active defaults at the same exact scope for one purpose are rejected. A requested copy count of zero inherits the destination's Default Copies; destination copies run 1..99, and kitchen policy narrows effective copies to 1..20. Scoping lets one chain mix silent thermal printing at busy tills with browser printing elsewhere.

Transport and language compatibility is validated when you configure a row: Browser and BC Printer require RDLC (and a Report ID; BC Printer also a printer name); PrintNode accepts ESC/POS or ZPL; WebUSB requires ESC/POS; LAN requires Epson ePOS-Print or Star WebPRNT. A Test Destination action validates the row and creates a retained test print job.

The five transports

Transport	Silent?	Language(s)	Notes
Browser	No	RDLC	Fallback: prints through the browser's print dialog. Always available; the only interactive transport.
PrintNode	Yes	ESC/POS or ZPL	Raw payload via the PrintNode cloud to a registered thermal printer; also drives the drawer kick. API key held in Isolated Storage.
BC Printer	Yes	RDLC	Universal Print / Printer Management silent printing to a named BC printer. No ESC/POS channel, so no drawer kick or paper cut.
WebUSB	Yes	ESC/POS	Talks ESC/POS directly to a USB printer from the browser (WebSerial fallback). Free direct transport, no agent. Chromium only; needs one-time pairing.
LAN	Yes	ePOS-Print or WebPRNT	POSTs Epson ePOS-Print / Star WebPRNT XML to the printer's local endpoint on the same LAN. Use HTTPS when the BC page is HTTPS to avoid mixed-content blocking.

Pairing a USB printer (WebUSB)

WebUSB needs a real user gesture inside the add-in's own frame to open the browser's device picker, so pairing has its own page:

1. On the register, tap the status-bar Printer button -> Connect Receipt Printer.
2. On the pairing page, tap Connect receipt printer and pick the USB printer in the browser dialog.
3. Done - receipts now print silently. You pair once per till and browser origin.

If automatic draining does not start after pairing, return to the register and use Printer -> Process Print Queue. This claims the same durable job; it does not create a second receipt.

The durable print queue

WebUSB and LAN output (and the recoverable receipt path) are delivered by the browser, so the server first writes a durable Pending job carrying the frozen snapshot, the resolved delivery target, purpose, completion generation, and an exact Entry No. The register atomically claims one job at a time - marking it Processing, incrementing the attempt count, and stamping a unique Attempt Token - and waits for the matching success or failure callback before claiming another. Claiming never deletes the payload or snapshot, and a duplicate or late callback can never acknowledge a different job or attempt.

Processing jobs unacknowledged for 15 minutes are recovered. Receipt attempts recover company-wide and are classified DeliveryAcceptanceUnknown, because the printer may already have printed and a retry could duplicate. Other browser work recovers only within its own session, returning to Pending while attempts remain or ending Failed. Completed jobs are retained for 30 days; unresolved jobs are never swept by age.

The POS Print Jobs page

Administrators use POS Print Jobs (opening it triggers a company-wide stale-receipt recovery pass) to filter by status, purpose, destination, or document, read the classified failure category and detail, and act:

• Retry - resets a failed job into the current browser session for another attempt. Receipts prompt an "acceptance unknown - may duplicate" confirmation and retry the same frozen snapshot; kitchen and other jobs re-route through their pipeline.
• Cancel - removes an unresolved non-receipt job and its payload. Receipts and completed jobs cannot be cancelled; receipts are recovered or reprinted, not deleted.
• Create Reprint Using Current Configuration - builds a new receipt snapshot and reprint job from the retained sale using today's print destination, without touching the frozen failed job.

Error detail is sanitized before storage: authorization headers, bearer tokens, API keys, and URL query strings are redacted so provider secrets never land in the queue.

Cash-drawer kick

The drawer pulse fires on a qualifying cash sale (Open Drawer On Cash, or a tender method that opens the drawer) and on a No-Sale drawer opening. A lone drawer pulse never feeds or cuts paper. Support depends on the transport:

Transport	Drawer kick?
PrintNode	Yes (ESC/POS pulse)
WebUSB	Yes (dedicated open-drawer path)
LAN	Yes (ePOS drawer command)
Browser / BC Printer	No (no ESC/POS channel)

Kitchen and label destinations

Kitchen labels and grouped tickets route through Kitchen Label destinations using this same model and queue - see Kitchen output and Multi-station kitchen routing. Shelf and product barcode labels are covered in Item labels.