POS (Point of Sale)

The POS screen is the workstation for waiters and admins to punch in orders right in the admin panel. An order is assembled from menu tiles in a few taps, bound to a table, and instantly lands in the kitchen and the shared orders feed.

Open: Admin panel → POS (admin.cenaly.ge). The screen is optimized for tablets — menu tiles on the left, the current order ticket on the right (on a phone — "Menu" and "Order" tabs).

Who can use the POS#

There is no fixed list of "POS roles" any more: access is granted by the POS section inside a job role. Roles are built with the role constructor on the Staff page — 21 built-in presets plus as many custom roles as you need.

The POS section is granted by default to: Owner, Manager, Waiter, Shift administrator, Cashier, Sales assistant, Bartender, Receptionist and Pickup point operator. Cook and Courier do not have it — they work on the Kitchen (KDS) and Courier screens. Any role can be given or denied the section.

Besides access itself, every role has its own POS permissions:

If the order is created by a waiter, it is automatically bound to that waiter — visible in the order and in reports.

Creating an order#

1. Pick a location (if you have several) — at the top of the screen.
2. Bind a table (for dine-in orders): "Scan QR" — point the camera at the table's QR code, or "Pick table" — choose from your client codes. If the QR belongs to another location, the POS switches to it automatically.
3. Add dishes: tap the tiles. Search and category filters are available. If a dish has variants and add-ons, the options picker opens.
4. Set the order type: Dining area, Pickup or Delivery — or one of the location’s own types (Banquet, Catering, Staff). Own types are added in the location settings, the “Own order types” block (Locations section): a name and the basic type it works as — dine-in, takeaway or delivery. The own type shows on the kitchen screen and in Finance → Sales, the “By order type” block — revenue, checks and average check per type. In the POS apps for Android, Windows and Ubuntu you choose the type the same way: Dining area, Pickup or an own type based on dine-in or takeaway. Delivery orders are not taken in the apps — an open delivery order shows a 🚚 Delivery badge, and its type can’t be changed there. Packaging for a pickup order from the app is calculated by the server from the location settings and appears in the bill once the order is saved.
5. Add an order note if needed.
6. Send — the order appears in Orders, on the Kitchen (KDS) screen and on the orders monitor.

Quantities are changed with "+/−" right in the ticket; an item can be removed before sending.

Tables and open orders#

• The POS shows open orders on the selected table — you can continue an existing order (add a course) or start a new one.
• "Unlink table" removes the binding when the order has no table.
• The table list comes from Client codes — every table QR code acts as a "table" for the POS. See Floor Plan for arranging tables.

Park a ticket and return to it#

If a guest steps away to get their wallet while the next guest is ready to order, save the current ticket and free the register.

1. Choose Park ticket. The order is saved and the POS opens a blank ticket. Saving sends the order to the kitchen under the usual rules; it does not hold preparation.
2. Serve the next guest.
3. Open Open tabs and select the saved order to continue. The caption beside the command — for example, Open: 4 — shows the number of open orders.

The command works in the web POS in Table, Bar and Counter modes, but visibility depends on the screen layout. It is hidden by default: add Park ticket through Customize screen → Library and save the layout. The ready-made café and retail layouts already include it. If the button is disabled, check that the ticket has items, no save is running and the ticket is not locked.

The layout is saved for the location, with variants by device class. Check Applies to if another screen has no button. The Android app does not yet have a separate Park ticket command.

Idle auto-lock is configured separately for this device or all registers at the location — see POS devices.

Enter items by code (PLU)#

Instead of finding a tile, a bar cashier can enter 3 × 105 — for example, three identical drinks if code 105 resolves to that item.

1. In POS appearance settings, choose r_keeper-like or enable Code-entry numpad. It is off in the standard appearance.
2. Choose 🔢 Enter by code, then enter the quantity, × and the code.
3. Check the item name in the preview and press ✓. The POS adds the item with the entered quantity.

Lookup follows this order: the item’s own code → weighted-item PLU → barcode → tile number in the current POS menu order. Tile numbers start at 1 and are shown on a tile when the item has no code of its own.

The item’s own code#

A code a cashier can memorise (“cappuccino — 101”) is set on the item card: Menu → item → POS code (PLU). For a shop product, the field is on the Pricing tab.

• Digits only, up to 13. An empty field means no code.
• The code is unique in the account. It cannot match another item’s code, a weighted item’s PLU or a barcode. If the code is taken, the owner item’s name appears under the field and the previous code stays unchanged.
• The code works on the Enter by code numpad and in the POS search field: type the code and press Enter to add the item. If the item has variants, the POS asks you to pick one.
• Weighted items still get their PLU from inventory. The tile number stays a fallback code and changes when tiles are rearranged; the item’s own code does not.
• In the POS apps for Android, Windows and Ubuntu, the code shows on the tile when Code-entry numpad is on, and it works in search and in the 🔢 Enter by code window. There you type the code alone, without “quantity ×”. If the item has no item code, the POS looks for a barcode or PLU; the apps do not use tile numbers. A code set earlier reaches the apps after the next edit to the location’s menu.

Unknown barcode: bind it to an item#

The product is on the shelf, but its barcode is not in the catalog, so the POS says “not found”. For staff with the Edit right in the Catalog section, the POS offers to bind the code straight away:

1. Scan the product. The Unknown barcode window opens.
2. Find an item on this location’s menu by name or its own code and select it.
3. Confirm with Bind. The barcode is added to the item; its existing codes are kept.
4. Press Add to ticket, or simply scan the product again — the item is added.

Undo binding in the same window removes a wrong binding at once. Later, remove the code on the item card. Every binding and undo goes to the Risky operations log (statistics) with the code, item and cashier.

The POS does not bind a weighted barcode (prefixes 20–29), a marking code, or a code that already belongs to another item. For items with variants (size, colour), bind the barcode to the variant on the item card. Staff without the right to edit the catalog still see “not found”, with a hint about who can bind it.

In the POS apps for Android, Windows and Ubuntu the window is called Link to an item:

1. Scan the product on the order-entry screen. The POS plays the scan-error tone and opens the window with “Code … is not in the catalog”.
2. Find the item in the search field by name or by its own item code. The search covers every item on the location’s menu, in all categories, not only the one open on screen; the list shows up to 30 matches, and an item with its own code shows a “code …” chip.
3. Select the item and confirm with Link (Back returns to the list).
4. Press Add to ticket — the item is added just like a tile tap, with options and the stop-list check. Scanning the product again on this register adds the item straight away. Undo link in the same window removes a mistake.

The cashier does not need the Edit right in Catalog: without it, after Link the POS asks for the PIN of an employee who has that right, and the same PIN confirms Undo link. The Risky operations log then also shows the name of the employee who confirmed. If linking is refused, the POS shows the reason in the window: a weight label, a marking code, a box code, an item with variants (set the code on the variant in the item card), a code that already belongs to another item, or an item with no card on the server (link the code in Menu). Without a network connection, over the payment window or another open window, the POS shows “not found” as before.

Rearranging tiles can change their numbers, so check the preview before adding. If you see Not found, check the code and whether the item is in this register’s menu.

POS appearance has location settings and device overrides. Check the scope before saving so that you do not unintentionally change other registers.

Share a bill across devices#

Beta, web POS only, including a phone browser: several staff members add items to the same bill, and one device takes payment.

1. Build a ticket and choose Share bill, then Make shared. The bill is saved; saving a new order also triggers the usual kitchen sending flow.
2. In Shared bill, under Open on another device, scan the QR code with the second device or use Copy link. Sign in there as a staff member of this location. You can also select a bill under Shared bills of this location and choose Join.
3. Check for Shared bill · N, showing the number of connected devices. Both staff members see the shared contents; added items are saved and synchronised automatically.
4. Agree which register will take payment. That register obtains a payment lock; the others see This bill is already being paid on … and cannot change the items while payment is in progress.

If the connection drops, changes stay on the device until it reconnects. A shared bill cannot be paid offline. Delivery orders and hotel room accounts cannot enter shared mode. The Android and Windows apps work with the bill without shared mode. This is collaborative editing; a separate read-only viewing mode is not available yet.

Payment at the till#

Once the order is assembled, the cashier moves to the payment screen inside the ticket: cash (with change calculation), card through a terminal, and online providers where connected (see Online payment). A payment can be split across several methods. An open cash shift is required to take payment.

Split bill. The bill is split at the till in two ways: by items (the guest marks their dishes) and equally (the total divided by the number of guests). Each part is closed with its own payment method; the order counts as paid once all parts are closed. The guest cannot split the bill on their side.

Corporate account. A company employee pays for lunch from a corporate balance: the cashier enters the phone number and account code, the system checks the daily allowance and deducts the amount. If the order is cancelled, the deduction is reversed automatically. See Corporate accounts.

Gift cards. A card is accepted right at the till: the cashier picks the “Gift card” tender and types or scans the code — the till shows the balance and takes the amount needed. The server caps the amount against the live balance, so you cannot spend more than the card holds and a double tap cannot charge it twice. The part covered by the card becomes its own line on the receipt and the remainder is closed by any other method; the card works alongside bill splitting, corporate accounts and loyalty. The same card applies to an order once — to cover a remainder, use a second card or a regular tender.

Selling a certificate. The “Sell a certificate” action issues a card for the chosen value: the guest pays as usual, the code is printed on the receipt and e-mailed to the recipient when an address is given. Selling a certificate is not revenue but a liability of the venue: the “issued / redeemed / outstanding” summary lives in Finance. In Russia the sale is fiscalised as a prepayment, and redemption enters the goods receipt as offsetting a prepayment — redemption is never rung up as a second sale.

“On account” (deferred payment). The familiar café tab is built into the till: the “On account” tender closes an order without money and records the amount against a guest — searched by phone or name, and a new guest can be created right in the payment window. When a credit limit is set for the location, going over it is blocked: a member of staff with approval rights, or a manager entering a PIN, can let it through, and that approval lands in the risky-operations log. The order gets an “On account” badge in the orders panel and the receipt journal, and the guest's balance is visible in Customers and in Needs attention. Repayment goes through the same window — the “Take a debt payment” action: cash or card, partial amounts allowed. In Russia the sale on account is fiscalised as “transfer on credit”, and the repayment as a “credit payment” receipt. A company's debt on postpaid corporate accounts is paid off with a separate “Company debt payment” action in the “More” menu: cash or card, a “credit payment” receipt with the company's tax ID.

Loyalty. The "Loyalty" panel looks the guest up by phone, shows the stamp and point balances and applies a reward or a redemption as an ordinary discount — see Loyalty program.

Pre-check (the guest bill)#

Before payment the waiter brings the guest a pre-check — a bill with items, service charge and total. It is a non-fiscal document, and it says so on the paper. The "🧾 Pre-check" button is not limited to the dining room — it is available at the bar and at the counter too.

Where the paper comes out, in order:

1. the receipt printer through Cenaly Hardware Bridge;
2. the fiscal register, as a service (non-fiscal) document. This is the main path for a venue that never bought a separate receipt printer: a guest bill is not a fiscal document, and printing it through the till registers nothing. On paper it comes out marked "not a fiscal document" and laid out to the real width of the till's paper;
3. the browser — if there is nothing to print with, or the till cannot print free text.

From a waiter's tablet or phone with no bridge of its own, the bill prints on the till's hardware through the cloud relay — all it needs is the order's location.

The outcome is reported honestly rather than as "printed / not printed": five states — printed by the receipt printer, printed by the fiscal till (not a fiscal receipt), printer offline so the bill is not printed yet, printed in the browser, not printed at all.

Guests and serving courses#

In Table mode with a dine-in order, ticket items can be assigned to individual guests. If serving courses are enabled, staff can hold later courses and fire them when the table is ready. Firing courses requires the role’s hall-management permission. Courses and their names are shared across all locations in the account.

When entering payment in Table mode with held courses remaining, the POS shows Still on hold: … with Continue to payment and Back to the order. See serving courses for details.

Upsell prompter#

After an item is rung up, "Suggest with this" chips appear above the ticket — what is most often bought together with that dish.

Sources of the suggestion, in priority order:

1. manual pairings set by the owner on the dish card — you know your menu better than any statistic;
2. "frequently bought together" — statistics from your own orders.

There is no AI involved: everything is computed from order facts. Dishes on the "86" stop list or outside their schedule never appear — suggesting what you don't have is the fastest way to teach a cashier to ignore suggestions. The chip price is the price "right now", happy hour included.

The toggle is ⚙ → POS appearance → "Upsell hints" (on by default).

Items sold by weight#

For dishes sold by weight (canteen, deli, salad bar), the dish card has a price by weight option: the guest sees a price per kilogram and the final amount is computed from what is weighed at the pass.

If scales are connected to the till through the hardware bridge, the weight is filled into the line automatically — no typing needed.

Hall panel#

The 🗺 button opens the Hall panel — the host's eight tabs, in this order: "Now", "Waitlist", "Scheme", "Reservations", "Calls", "Day" (who is on shift right now: planned vs actual timesheet, clock-in and clock-out by PIN), "Tasks" and "Analytics".

Next to the hall panel there is the hall monitor — a full-screen floor scheme for a TV or tablet in the dining room: pan-zoom, live badges with the open order total and a timer since seating, and for a hotel the guest, nights and folio balance. It opens with the 📺 button on the Floor Plan (see Floor Plan).

Printing#

Sale and refund receipts, the pre-check and X/Z reports print through Cenaly Hardware Bridge; when the bridge is unavailable, through the browser. Kitchen tickets per station and item stickers go only through the bridge.

The exception is a venue whose only hardware is a fiscal register. The bridge will not push our documents through it: the guest receipt is printed by the till itself as a fiscal document, while our slip would look like a receipt without being one. The browser fallback does not kick in here — the POS explains that "the till prints the receipt itself". Only a test print and the pre-check are allowed through the register.

The POS header shows a print queue indicator: if the printer is offline the job is not lost, but there is physically no paper yet. You can also print to a printer attached to another PC — over the cloud, with no VPN: the POS sends the job to the location's bridge, not only to the bridge on its own computer. In full — Kitchen and front-of-house printing.

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.

If the fiscal till refuses, the cashier sees a reason and the steps to take instead of the raw driver text: the shift has been open for more than 24 hours and needs a Z report, the till is not in the right mode, wrong operator password, an unclosed receipt is hanging, out of paper, fiscal memory full, the bridge is offline, the till could not reach the tax server. The message does not disappear after a couple of seconds — the sale is stuck and it has to be read.

Control of risky operations#

Manual discounts, cancellations, voids of items already sent to the kitchen, refunds, opening the drawer without a sale and reprints are logged against the current cashier (quick PIN switching counts). Some operations can be gated behind a supervisor's PIN approval.

If a bridge camera is connected to the location, a short video clip is attached to the event. Rules, thresholds and the owner digest — Loss control.

Pick the variant first#

Web POS only. A guest says “medium mocha”, and the size comes before the drink. “📏 Variant first” lets you pick the variant before the item. It is an option in the screen library: add it in design mode (“✏️ Customize screen”); the café and bar starter layouts keep it under “More”.

1. Tap “📏 Variant first” and pick a variant, for example “Medium”. You can pick up to three values at once: “Medium” and “Iced”. Not in the list? Type it into “Own variant”: the window only shows variants of items this register has already opened.
2. Tap “Apply”: the button now says “Next: Medium”.
3. Tap the item tile. The variant is filled in. If there is nothing else to choose, the item goes straight to the ticket; if it has other variant groups, add-ons or combo slots, the usual window opens with the variant already selected.

The choice applies once, like “×N”. An item without that variant is added as usual and the choice stays for the next one. Names are compared ignoring case, in any language of the item card. For a product with a SKU matrix, the variant is picked only when the chosen values leave a single SKU; otherwise the variant window opens. To cancel, tap the button again.

Location links on the POS#

Web POS only. The “🔗 Links” button opens pages staff need at hand: the opening checklist, a supplier menu, a guide. It is an option in the screen library: the starter layouts for restaurant, café, bar and retail already have it in the “More” menu; add it to your own layout in design mode (“✏️ Customize screen”).

Links are set up by staff who may change POS settings:

1. Tap “🔗 Links” → “Set up links”.
2. In “Allowed domains” enter one domain per line, for example docs.example.com. A domain allows its subdomains too.
3. Tap “＋ Add link”, enter a label (“Opening checklist”) and the page address.
4. Tap “Save”.

Only https:// addresses on a domain from the location’s list open; an address with a login or password cannot be saved. The page opens in the POS window. Many sites forbid being shown inside another page: the window then stays blank and “Open in browser” helps.

POS appearance#

Open ⚙ in the menu panel to adjust the POS display. The “POS appearance” window includes a “Work” tab with the keyboard shortcut toggle and guide.

Keyboard shortcuts#

To work with a physical keyboard, open ⚙ → “POS appearance” → “Work” → “Keyboard shortcuts”. The toggle is on by default and is saved for this device. A shortcut guide appears below it; the pay and save buttons also show their shortcuts in tooltips.

While a window is open, the search, pay and save shortcuts do not run: pressing F12 again does not confirm payment. Shortcuts cannot bypass cashier permissions or disabled buttons. In a text field, / remains text; function keys also work from fields, while Ctrl+Enter is not intercepted in multiline text. Holding a key does not repeat its action.

A keyboard-wedge scanner enters a code as a fast sequence of characters. A / inside that sequence does not move focus to search. Keys assigned to voice mode remain reserved for it.

Programmable keypad. The “POS keypad” window binds a key, key combination or exact macro string ending in Enter to an action: add an item, select a category, open search or payment, save or cancel an order, apply a discount, open the drawer, switch cashier or open settings. Bindings stay on this device; JSON export and import let you transfer them. Keys do not grant extra permissions for POS operations.

What you need to get started#

• Any computer or tablet with a browser. The POS is a page in the admin panel; you do not need to buy dedicated hardware. The layout is built for a tablet, and on a phone it is compact.
• An open cash shift. Until a shift is open, payment is blocked — see Cash shift.
• An employee role and PIN. The real permission layer on the POS is role plus PIN, not a cosmetic narrowing of the interface: deleting items, discounts, refunds and reprints above the threshold require a manager's confirmation.
• A menu with prices — the POS tiles come from the same catalog as the guest storefront.
• The bridge on the same computer — if you need receipt printing, a fiscal printer, scales, a scanner, a customer display or a bank terminal: Cenaly Hardware Bridge.
• A service mode — hall, bar or counter; the default comes from the venue type, and the toggle sits in the ticket header (Bar mode).

Limitations#

• The receipt registry runs on the AWS contour. On the Russian brand (cenaly.ru) functions built on the analytics databases are unavailable — taking payments is unaffected, but receipt history is not built there.
• Offline support depends on the mode and version. The web POS uses its own storage and its own PC’s bridge; native apps have a beta local-network mode. Online payments and bank authorisation need a connection — If the internet goes down.
• The bridge only serves its own computer. A browser cannot reach a bridge on a neighbouring PC: either install the bridge on every POS device, or print through the cloud to a "ported" printer on another PC.
• PIN thresholds cover POS operations only. Risky inventory actions (write-offs, adjustments above an amount) are not yet behind a separate threshold.
• Changing a price right in the pre-bill is planned but the button does not exist yet.
• POS voice commands are in beta: recognition quality depends on the language, and accuracy in production has not been measured.
• The "on account" ledger is last-write-wins (concurrent edits are not locked), and one gift card applies to an order once.
• Cashier biometrics are deliberately postponed.

Troubleshooting#

The payment button is inactive. No cash shift is open. Open one with a float — Cash shift.

An item is missing from the tiles. Check the schedule and the 86 list: the dish may be outside its availability window or taken off as "86". The second place to look is the item's visibility and price at this location.

The receipt does not print. It is not the POS: check that the bridge on this computer is "connected" and a printer is selected — Cenaly Hardware Bridge, Printing.

The POS asks for a manager PIN. By design: deleting items, discounts, refunds and reprints above the threshold are confirmed by a manager and written to the risk log.

An order paid with a corporate account will not merge with another bill. That is a deliberate restriction — an order paid from an organization's account cannot be merged (Corporate accounts).

Loyalty points were not credited for a POS sale. Crediting requires the guest's phone number on the receipt: without it the guest is not identified and loyalty is not counted.

Related#

• Orders — order lifecycle, statuses, orders monitor
• Hall panel — waitlist, seating, calls and the heat map
• Kitchen and front-of-house printing — printers, queue and code pages
• Loss control — the risky-operations log and the rules
• Loyalty program — stamps, points and the regular-guest discount
• Corporate accounts — paying for lunches from a company account
• Kitchen (KDS) — the kitchen screen receiving POS orders
• Floor plan & reservations — table layout and QR binding
• Staff & shifts — waiter roles and order binding

FAQ#

Do I need special hardware?#

No. The POS runs in a browser on any tablet, phone or computer. Just sign in to the admin panel with your staff account.

Can guests order by themselves, without the POS?#

Yes — guests scan the table QR and order via the QR menu. The POS is for orders taken by staff (by phone, at the counter, tableside).

What happens after the order is sent?#

The order gets the "New" status and shows up on every work screen: Orders, Kitchen (KDS), orders monitor. The kitchen then takes it — see Kitchen (KDS).

Is the order bound to a waiter?#

Yes. An order created by a waiter is bound automatically. A waiter can also be assigned to tables in the "Waiters" mode of the Floor Plan page.

Sell a weighed item#

1. Select an item configured for sale by weight at the POS. The weight window shows its name and unit price.
2. Read the weight from connected scales or enter it manually. Check the unit and decimal value: this window uses kilograms.
3. Confirm the line and verify its quantity and total. Correct an incorrect weight before taking payment.

Unavailable scales do not block manual entry. Convert grams before entering a value in a kilogram field.

Correct an erroneous paid sale#

Open the original receipt and follow the refund procedure above. For a full refund, select all remaining refundable quantities, specify the reason and payment method, and check whether goods should return to stock. After confirmation, verify the refund document and the original receipt's remaining refundable quantities.

The original sale remains in history. Create the correct order separately. Recording a refund does not automatically cancel a national fiscal document or a bank payment in every integration.