Kitchen and front-of-house printing
Kitchen tickets and cashier documents can be sent through Cenaly Hardware Bridge — a small program on the computer that serves the printers. With this connection, a browser cannot talk to a thermal printer directly: it sends the document to the bridge, and the bridge speaks ESC/POS to the hardware.
Through the bridge you print: kitchen tickets per station, item and bag stickers, sale and refund receipts, the pre-check, X and Z reports, and the bag manifest on the handoff screen.
What you need to get started#
- The bridge on the computer sending tickets — Cenaly Hardware Bridge.
- A network ESC/POS printer reachable from that computer over TCP (usually port 9100), with its address configured. Alternatively, add a printer served by another PC’s bridge through the cloud. USB, COM and OS printer queues are not yet supported for printers through the bridge.
- A "station → printer" mapping — otherwise there is nothing to route tickets by.
- A roll of the right size for item and bag labels.
- KDS stations — a station ticket is assembled from items of the categories chosen in the station (KDS, “Stations”).
Bluetooth on Android is a separate workflow. The warehouse (TSD) mode in the administrator and waiter apps implements label and price-tag printing over TCP, Bluetooth SPP and BLE, with ESC/POS, TSPL, ZPL and CPCL drivers. This does not connect a kitchen printer to the bridge over Bluetooth. Bluetooth/BLE have not yet been verified on physical hardware; test your printer before a shift.
A fiscal register connected over USB/COM is configured separately: see Hardware and Fiscalisation. Its connection does not make an ordinary USB printer work through the bridge.
Kitchen tickets per station#
A ticket has to arrive where the dish is cooked: cold station to its own printer, grill to its own, bar to its own.
Configuration lives in Kitchen (KDS) → the "Stations" panel, in the "station → printer" table inside it. For each station you set:
| Field | What it means |
|---|---|
| Printer | a specific bridge device; empty means "any printer with the kitchen role" |
| Backup printer | where the ticket goes if the main one doesn't answer |
| Printed by | Not printed, POS, when sent to kitchen or This KDS screen, on arrival |
| Paper width | 42 characters (80 mm paper) or 32 (58 mm) |
| Code page | see below |
| Item stickers | print labels when a ticket is bumped to "ready" |
The printer list comes from the local bridge. Configure the station on the computer that will send tickets: its list must contain the network printer or the printer added from another PC.
What goes on the ticket. A large font (the cook reads the slip across a table), dish name, quantity, modifiers on their own lines under the dish, the note ("no onions"), the guest number and the course if the order is split by them. There are no prices or totals on a kitchen ticket.
Only new lines print. A second tap by the waiter does not produce a second ticket: the system remembers which lines already went to the station. If an item was added or its quantity increased, an "addition" ticket goes out — not a full duplicate of the order.
Route the bar and hot kitchen separately#
- In KDS, select the location and open Stations. Save station presets with the relevant categories: drinks for the bar, hot dishes for the hot kitchen. An empty category list means all items; select categories explicitly for a dedicated station.
- Under Station printers, set each station’s Printer and Printed by. For example, let POS send tickets when the order is sent to the kitchen.
- Send a test order with a drink and a hot dish: each printer should receive its own items. Add another dish and check the addition ticket.
If an item already sent is removed or its quantity reduced, the ticket marks the removed portions as VOID. The cook sees what no longer needs preparing; the full order is not printed again.
Guest numbers on kitchen tickets#
To serve dishes by seat, enable the Seats (guests) block in POS, assign a guest to each relevant item and send the order to the kitchen. Lines assigned to guests print Guest 1, Guest 2, and so on. Enabling the block alone is not enough: the item needs a guest number.
Other stations' items on the ticket#
The hot kitchen benefits from seeing that a salad from the cold station is going to the same table, so the steak does not go out before the starter. Each station has a Show other stations' items checkbox:
- In Kitchen (KDS) → Stations → Station printers, tick it for the station you need (for example, the hot kitchen). The checkbox is shown only for stations with selected categories: an "all items" station already sees the whole order.
- Send an order with a steak and a salad. At the bottom of the hot-kitchen ticket, after its own dishes, a block in regular print appears: Also in order: Salad ×1 (Cold) — the name, quantity and the station that cooks it.
- The same line is shown in small print above the ticket items on that station's kitchen screen.
Identical items from one station are combined into one line, cancelled items are not printed, and a long list is cut at 12 lines with a mark such as "…+3". The block is for reference only: the station's own items and add-ons print as before, and a new item for another station does not trigger a new ticket by itself — it appears in the block of the station's next ticket.
If the hot-kitchen printer fails on Friday evening#
Prepare a backup before the shift so the cook does not have to look for the order at the till:
- Add the spare printer to the bridge and test it. Under Stations → Station printers, select a Backup printer with suitable paper for the hot kitchen.
- If the main printer stops responding, check the queue. For an accepted but stuck job, the system checks retry attempts, cancels the original job and sends it to the backup. If the main printer is already printing, no backup copy is sent.
- Collect the ticket from the backup and take it to the hot kitchen. Before printing another copy manually, check both queues and the paper output so the cook does not prepare the order twice.
Printing across locations#
| Level | What is configured |
|---|---|
| Account | Station presets and categories; a shared station-printer mapping if saved without a selected location; the equipment register for all locations |
| Location | Its station’s main and backup printers and print source; serving bridges and the default bridge for cloud commands |
| Computer with a bridge | Network addresses and device roles: receipt (receipt_printer) and kitchen (kitchen_printer) printers; printers added from other PCs |
The selected location’s station mapping takes priority; otherwise the shared mapping applies. A new location can use a shared setting, but this does not create the required printer on its computer: assign real devices and test printing at each location before opening. The default bridge for cloud commands does not replace the station’s printer selection on the local bridge.
Item and bag stickers#
Label a takeaway dish#
A sticker helps staff find the right box and check the guest's requests before handoff.
- Open the station's print settings on KDS and enable 60×40 item stickers.
- Select a Sticker printer if needed. Automatic routing uses a device assigned the label-printer role first, then the station's main printer.
- When the food is ready, move the ticket to Ready. KDS prints stickers for non-cancelled items, with separate copies for multiple portions.
- Check the name, options and order number, then attach the sticker to the packaging.
| On the item sticker | Source |
|---|---|
| Name and options | Order line, including selected modifiers |
| Comment | Item request and order-wide comment, when provided |
| Allergens and diets | Line labels passed by KDS |
| Channel | Order source, when available |
| #number · Item i of n | Order number and sticker sequence |
The label format also supports a guest name and ready time, but automatic KDS printing currently does not fill these in. Do not rely on seeing them on a KDS sticker.
Stickers only for changed items, and the location logo#
When the station's stickers are on, two more settings appear next to them:
- Only items with options or a comment instead of "Sticker on every item". Only what the guest changed gets a sticker: a chosen variant, an add-on, a combo choice, a text on a cake or a comment ("Latte · oat milk", "Burger ! no onion"). A plain croissant gets none — the roll lasts longer, and at handoff it is clear which box to check. Allergens, diets and portion weight do not count as changes — they belong to the dish. If an order has no changed items, no stickers are printed at all; "Item i of n" counts only the printed ones.
- Location logo on stickers — the same black-and-white logo as on the guest bill (see "Location logo on the pre-check and receipt copy" below) is printed as the first line of the item sticker. The bridge scales it down to the label width. No logo uploaded — the sticker prints without it.
Label several bags#
On Expo, press Bag stickers, answer How many bags?, and print. The large BAG i OF n line helps the courier take every bag.
Below it are the order number, guest, channel and order lines, including options and comments. The bridge version adds a Contents: heading; the browser version prints the lines without that heading. “Contents” means ordered items, not a dish's recipe. Entering a bag count does not allocate items between bags automatically: check the actual packing.
A separate bag manifest with the full order can go inside; it is also printed from Expo.
Choose a printer#
Priority is: selected Sticker printer → device with the label-printer role → the station's main printer supplied as a fallback. Without a supplied fallback, the bridge uses its own receipt-printer fallback route.
The document is designed for 60×40 mm. Through the bridge, it is a narrow 32-character ESC/POS document with no cut command; this workflow does not support native TSPL/ZPL. If the bridge is absent or does not accept the job, an HTML 60×40 page opens for browser printing. Choose the printer and paper size in the print dialog.
Expiry labels are separate#
For prepared stock or an opened pack, use Shelf-life control in inventory. Its label includes Use by / Best before, Made, Opened and Thawed milestones from the tracked unit, plus a code and optional QR. It is a separate label, not an extension of an order sticker. Start with Inventory.
Cashier documents#
| Document | Via bridge | Note |
|---|---|---|
| Sale / refund receipt | yes | falls back to browser printing |
| Pre-check (guest bill) | yes | non-fiscal, explicitly marked as such on paper |
| X and Z reports | yes | see Cash shift |
| Bag manifest | yes | the Expo screen |
| Kitchen ticket | yes | browser printing if the bridge did not accept the job; accepted jobs are not duplicated |
| Item and bag stickers | yes | HTML 60×40 through the browser when no bridge is available |
Pre-check: identical items on one line and a large total#
In a bar, four beers on the guest bill are easier to read as one line "4× Beer". Both settings are in POS → ⚙ POS appearance → Bill features, set separately for each location:
| Setting | What changes on paper |
|---|---|
| Merge identical items on the guest bill | Lines with the same name, options, comment, discount and unit price print as one line with the quantity and total amount. Items with different modifiers or prices stay separate |
| Large total line | The total on the pre-check, and the total and change on the printed receipt copy, use double-size print centred on the paper |
These settings do not change the fiscal receipt: the fiscal register prints it under the country's rules (in Russia the register itself aggregates the items).
The same place has Bill code on the guest bill: a small QR “Bill code for the register” is printed at the bottom of the pre-check, and scanning it on any register of the location opens that bill or offers to merge it into the open one (details).
Seller details on X and Z reports#
If the location has Seller details for the tax invoice filled in (legal entity, address and tax number — INN, VAT and so on) in the location settings, the POS-printed X and Z reports carry them in the header under the location name, just like a receipt. This is needed when paper reports are checked or audited. In Russia, the fiscal register's own X/Z reports are printed by the register with its own details.
Location logo on the pre-check and receipt copy#
Each location can have its own logo at the top of guest paperwork — a chain of two cafés prints each café's own mark on its bills. Upload the logo in POS → ⚙ POS appearance → Bill features → Logo, header and footer of the guest bill with the Upload logo button:
- Pick a PNG or JPEG image. An ordinary logo works: the POS scales it down to 512 dots wide and converts it to black and white — a thermal printer prints only black.
- Check the preview next to the button — this is how the logo will come out on paper. If it turns out blank or solid black, the POS warns you: use a higher-contrast version (a black mark on a white or transparent background).
- Print a pre-check — the logo sits above the location name, centred. On 58 mm paper the bridge scales it down to fit.
The logo is printed on the pre-check and on the printed receipt copy from the receipt printer; browser printing shows it as an image. The fiscal receipt does not get it: the fiscal register has its own header (cliché), and a logo there is set up on the register itself (for ATOL — the cliché picture in the bridge's Register settings, Receipt tab). A pre-check printed through the fiscal register as a service document comes out without the logo — the register prints such documents as text only. To remove the logo, use Remove logo.
Own header and footer per order channel#
The same block holds header lines (under the location name — opening hours, address, Wi-Fi) and footer lines (instead of the standard "Thank you") — up to 6 lines of 48 characters. Lines can be common or specific to an order channel:
| Lines for | When they print |
|---|---|
| All orders | on every pre-check and receipt copy of the location |
| Dine-in, Takeaway, Delivery, Aggregator | only on orders of that channel; an empty channel field prints the lines for all orders |
Example: the Delivery footer says "Thank you for your order! The courier will call you before arrival", the common footer says "Thank you for your visit!". A delivery pre-check prints the first, a dine-in pre-check prints the second. The pre-check channel is the order type on the POS (dine-in, takeaway, delivery); the receipt copy channel comes from the order the receipt belongs to, and an order from a delivery service (Glovo, Wolt and so on) counts as the Aggregator channel. On the pre-check, footer lines sit above the "This is not a fiscal receipt" note, which always prints. On a refund, "Refund" stays the first footer line. The fiscal receipt is not affected.
Guest bill from the waiter apps. The logo and lines also print on the bill a waiter prints from the Android phone app or from Cenaly Team on Windows: before printing, the app reads the same location POS appearance as the web POS. The channel is the order type (dine-in, takeaway, delivery); an order from a delivery service counts as Aggregator. The logo and lines are set up only in the web admin — the apps cannot change them. If the app cannot get the settings (no connection and no saved copy), the bill prints as before, without the logo and your own lines.
Your own QR code or barcode in the bill footer#
The same Logo, header and footer of the guest bill block has an Own code in the footer field: a QR code with a link (review, survey, menu, loyalty programme) or a Code 128 barcode (order number for pickup). The code is printed as the last block under the footer, with a caption below it ("Rate us — scan the code").
- Choose QR code or Barcode (Code 128).
- In Code content enter a link or text with substitutions — the POS replaces them with the data of that particular document:
| Substitution | What is inserted |
|---|---|
{order} |
order number |
{receipt} |
receipt number (receipt copy only) |
{total} |
amount due, 1250.00 |
{table} |
table (pre-check only) |
{location} |
location ID — your website can tell which café of the chain is being rated |
{locationName} |
location name |
{date} |
document date, 20261028 |
Example: https://example.com/review?order={order}&point={location}. In a link the values are encoded automatically — "Table 5" will not break the address.
3. In Print on choose: guest bill and receipt copy, guest bill only, or receipt copy only. An example of the finished code is shown under the field.
A barcode accepts only Latin letters, digits and symbols, up to 30 characters — use a QR code for links. If the finished code does not fit (longer than 300 characters, or a barcode with non-Latin letters), the document is printed without it. Refund receipts carry no code. The fiscal receipt is not changed: its details and verification QR code are printed by the fiscal register as the law requires; a pre-check printed through the fiscal register as a service document carries the code as text instead of an image.
Reprinting an issued receipt is always written to the risky-operations log; it asks for a manager PIN only for roles where "reprint under PIN" is enabled — see Loss control.
A fiscal receipt is a separate story: it is printed by the fiscal register and follows the country's law, see Fiscalisation.
The print queue and what the outcome means#
The bridge has a restart-safe queue with retries: if the printer is offline, the job isn't lost — it waits and is retried. A queue indicator is shown in the POS header.
A stuck job can be cancelled. The classic kitchen disaster: a printer jams, it is fixed half an hour later, and on power-up it spits out fifty stale tickets. Jobs are cancelled one at a time from the queue in the till header: the bridge marks the job cancelled and simply skips it when the printer comes back. If the job has already gone to print, the cancel says so honestly — that paper will come out.
The "cancel" button appears only on stuck jobs — the ones that have been waiting for the printer for more than three minutes. Fresh jobs are listed but cannot be cancelled, and that is deliberate: a momentary hiccup (the printer woke up, a cable was nudged) is normal and the bridge will finish printing on its own, while a cancel button next to such a job would mean a lost receipt.
The print outcome has four states, and for a cashier they are very different news:
| Outcome | What happened |
|---|---|
| Printed | the bridge confirmed physical printing |
| Queued | the bridge accepted the job but the printer is unavailable — the guest has no receipt in hand |
| Browser | no bridge, or it refused the document, so printing went through the browser dialog |
| Failed | nothing printed |
On "queued" the browser fallback does not kick in — otherwise one receipt would print twice.
Jobs are idempotent: re-sending the same document does not produce a second slip.
Code pages and non-Latin scripts#
A thermal printer has no idea what UTF-8 is: it draws one glyph per byte from the currently selected single-byte table. That is why the code page is set per configured printer:
| Value | What it does |
|---|---|
auto (default) |
Cyrillic found → switches the head to CP1251; Latin and extended Latin (Turkish, Polish, Albanian) are left as they are |
cp1251 / cp866 |
an explicit Cyrillic table — cheap heads ship with one of the two |
georgian-academy / georgian-ps / georgian-expert |
font-ROM layouts of Georgian devices |
utf8 |
historical behaviour: mojibake on any non-Latin text |
About Georgian, honestly. Which table a given print head speaks is a property of the physical unit and is absent from the protocol spec; that is why the table is chosen per device. If none fits, the text is romanised: a line reading bazuri tarifi is legible to the guest at the till, ?????? ?????? is not. Georgian does get printed in Georgian letters after all: when the head speaks no suitable table, the bridge renders the line as an image (raster printing with a built-in font) and sends it to the printer as graphics — the receipt carries real Georgian text rather than a romanisation. Romanisation stays as the fallback for devices that cannot do raster either.
Turkish, Polish and Albanian Latin are deliberately not forced through CP1251, where ş, ğ, ą would turn into ?.
Limitations#
- The bridge only prints from its own computer. A browser cannot reach a bridge on a neighbouring PC: install the bridge on every POS device, or use cloud printing to a printer on another PC.
- TSPL/ZPL label printers have not been verified on live hardware — order stickers use ESC/POS; the bridge can rasterize unsupported characters.
- The device decides the paper width. It is taken from the printer setting, otherwise from the fiscal printer model, otherwise a safe value is assumed; an 80 mm document width is not carried over to a fiscal printer, because such a printer does not wrap a line — it truncates it together with the amounts.
- A pre-bill does not stay in the queue. If a receipt printer is configured but offline, the guest's bill is printed on the fiscal printer: the paper is needed now, and a copy an hour later on top of a paid order is a second piece of paper. A sales receipt behaves differently — it does wait for a retry.
- The logo needs a bridge version with image support. An older bridge leaves an empty line instead of the logo — the bill prints as before; the logo appears after the bridge updates. A printer that does not understand
GS v 0raster will not print the logo. - Your own footer code is web POS only. The guest bill from the Android waiter app and from Cenaly Team on Windows prints the logo and the per-channel header and footer, but not your own QR code or barcode in the footer. The POS app on Android, Windows and Linux prints the receipt copy and the guest bill without the logo, your own lines or your own code. There is no bill printing on iPhone.
- "Changed items only" stickers and the logo on stickers work on the browser KDS. The logo on a sticker needs a bridge with image support; TSPL/ZPL label printers are not supported separately — stickers go as ESC/POS.
- A pre-bill is never sent to a kitchen printer — for a guest bill such a printer is considered unsuitable, and the job goes to the POS instead.
Troubleshooting#
| Symptom | Cause | What to do |
|---|---|---|
| Neither main nor backup prints | No backup selected, sending bridge unavailable, or backup job also queued | Check Backup printer, the queue and both printers; for another PC’s printer, check both bridges and their cloud connection |
| No Guest N on the ticket | The item has no guest assigned | Assign the item to a guest in Seats (guests) before sending it to the kitchen |
| Ticket did not print | Printer is unavailable or the bridge did not accept the job | Check the bridge and queue. Only an accepted job can wait for a retry |
| No sticker after Ready | Station stickers are disabled or printing failed | Check 60×40 item stickers, the printer and queue; without a bridge, check the browser print window |
| Output goes to the wrong printer | Station printer is unset or a fallback route was used | Check Sticker printer, the label-printer role and the station's main printer |
| Squares instead of letters | The printer cannot render the selected code page's characters | Enable raster printing for scripts covered by the font; see limitations above |
| Lines are cut off or size is wrong | Paper width does not match the setting | Set the printer's actual width; for browser stickers, check 60×40 mm |
FAQ#
The ticket printed twice — why?#
Most likely the station has printing enabled on both POS and KDS. Those are two different devices with two bridges, and each printed its own copy. Leave one value in "Printed by".
The printer was unplugged — are the orders lost?#
If the bridge accepted the job, it stays queued. With a backup configured, a stuck ticket may move there; otherwise it waits for the main printer to recover. While the job is queued, there is no paper copy. If the bridge did not accept it, check the browser print window.
Can I print to the kitchen without the bridge?#
Kitchen tickets use the bridge; if it does not accept the job, a browser print window opens. Allow the pop-up and choose a printer. A queued job is not printed again through the browser. Item and bag stickers also have an HTML 60×40 browser-printing option. Cashier documents have a browser fallback: printing through the ordinary print dialog. The exception is a venue whose only hardware is a fiscal register: there the till prints the receipt itself and the browser fallback is not used.
Why is the printer list empty?#
The list comes from the bridge on this computer. Check that the bridge is running and the printer is configured in it. For a printer on another PC, first set up “Print from another PC” in Hardware, then reopen the station settings.
Are modifiers printed on the bag manifest?#
Yes. Order-line formatting includes the item name, options and comments so staff can check the order against the package.
Related sections#
- Cenaly Hardware Bridge — installing the bridge, device list, printer roles
- Kitchen (KDS) — stations, courses and print settings
- POS — receipt, pre-check, reprint
- Expo — bag manifest and stickers
- Cash shift — X and Z reports
- Loss control — reprint as a risk event