---
title: "Selling at the till"
description: "The terminal is the full-screen selling screen: the shelf on the left, the ticket on the right, and everything a cashier needs between them."
---
> Documentation Index
> Fetch the complete documentation index at: https://docs.beelocity.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Selling at the till
The terminal is the full-screen selling screen: the shelf on the left, the ticket on the right, and
everything a cashier needs between them. Open it from **Point of Sale → Terminal**, pick the
register you are standing at, and open a [session](./sessions.html) — the shift the day's takings
belong to.
If the terminal opens on **No register to sell on**, the shop has no till set up yet — a register
is the counter a sale is rung up on, and it sets which warehouse the goods leave and which prices
the customer is quoted. The **New register** button takes you straight to the form; see
[Registers](./registers.html). If it says **Every register is deactivated** instead, the tills are
set up and merely switched off: **Open the register list** and reactivate the one you are standing
at. Either button only appears if your role is allowed to do that — otherwise the screen tells you
to ask an administrator.
The **⋮** button in the top bar has an **About the till** entry. It explains parked baskets, the
opening float, tax-included prices, cash rounding, voids and refunds, and the keyboard shortcuts,
without leaving the screen.
On the terminal, tap products, or scan a code into the search box — the till matches a variant's
barcode or code first, then the product's own **barcode**, its code and its name, and a single
match adds straight to the ticket. Give each simple product its barcode on the product page (a
product sold in several variants carries a barcode per variant instead), and every item in the
shop scans. When your products are filed into
[categories](../products/product-categories.html), a row of chips above the shelf filters it to one
group at a time — **All** brings the whole shelf back. The row only appears once at least one
product carries a category. If nothing matches, or
several things do, it tells you rather than sitting there — and so does a scan that lands in the
first moment after the register opens, before the shelf has finished loading: scan again. After
each sale the box takes focus again so the next customer starts with a scan. Then tap **Pay**: the register works out what the ticket
comes to and the panel becomes the payment screen — no window on top — with **Cash already selected
and the exact total entered**, so an exact-change sale is just Pay, then Confirm. The figure on the
payment screen is the register's own, worked out the moment you press Pay, which is why it is the
one to read out to the customer: it is exactly what the sale will be recorded for, down to the
centime. Key what the customer actually hands over — the first
digit replaces the entered total, nothing to clear — and the **Change** row appears beside the
total: a 1,190.00-DA ticket paid with 2,000 DA shows 810.00 DA. The payment methods are keys on
the keypad itself, each wearing the name you gave it — press **Carte CIB**, say, to split the
ticket: its row arrives already filled with what is left to pay, and whatever you key onto it
instead, Cash follows with the rest on its own. The **←** arrow returns to the ticket exactly as
it was.
## What is left on the shelf
Each tile shows how many the till's own warehouse still holds — **7 left** — and says **None left**
when the shelf is empty, in warning colour. Products that come in sizes carry the figure per size,
in the picker.
The register refuses a sale it has no stock for unless it was set up to allow negative stock, so
this is there to be read *before* the cash is counted out, not after. The count follows every sale,
refund and void as it happens.
On a register that allows selling past its stock, the count stops at zero rather than going below
it, and the sale still records everything that crossed the counter — the difference is what a stock
count later puts right. Cancelling or returning such a sale gives back only what the count actually
had to give: a shelf of 3 that sold 10 and then voided the ticket goes back to 3, not to 10.
If your account cannot see stock levels, the tiles simply show no figure — never a zero.
## Products that come in sizes and colours
A product with variants is not sold as itself — the customer buys the XL, not "the shirt". Its
tile shows **from** the cheapest price the till can charge for it, and tapping it asks which one:
one row per variant, with its size or colour, its code, and its own price. Tap the row and it goes
on the ticket, named so the receipt says which one left the shop.
**Scanning is faster still.** The barcode on a garment's label belongs to that exact variant, so
scanning it puts the right one on the ticket with no picker in between.
A variant with no unit of measure is shown greyed, reading "No unit" — a size that is on the shelf
and missing from the screen would only send you hunting for it. Give it a unit on the variant and
it becomes sellable.
## The keypad
Most tills are a touch panel with no keyboard attached, so the terminal carries a **keypad** —
permanently, under the ticket. It edits **whichever line is selected**: tap a line on the ticket
to select it (the line lights up), key the figure, done. Tapping a product on the shelf selects
its line as it lands, so ringing something up and typing its quantity is one motion — tap, 1, 2,
and the line reads twelve.
The first digit **replaces** what the line held, so selecting a line and keying 3 means 3, not 13.
Use **⌫** to take a digit back off the end.
**Pay is the keypad's own bottom key**, and it says just "Pay" — the total reads in the bar
directly above the keypad, said once. On the payment screen the same key becomes **Confirm sale**,
so finishing a sale is always the same spot under the same finger.
The row above the digits says what they mean:
- **Quantity** — how many (or how much, for goods [sold by weight](#selling-by-weight)). This is where
the keypad returns every time a product is rung up.
- **Disc %** — the line's discount, in percent. The mode only exists on a register set up to allow
discounting, and it will not take more than the register's ceiling — a till set to 10% holds you
at 10, because anything above it is refused when you take payment, which is the worst possible
moment to find out. The line states the discount and the money it takes off.
- **Price** — greyed out for now. Price overrides need a manager's approval, and arrive with a
later update.
The **bin** beside the modes takes the selected line off the ticket: a line leaves because you
said so. Nothing has been charged at this point, so a line removed by mistake is simply tapped
back onto the ticket.
The dialogs that take an amount — opening a session, counting the drawer at close — carry the same
keypad, where it follows the box you tapped: the counted cash, one of the denomination boxes. The
payment screen has no boxes at all: each method in the split is a row above the total, selected
and typed over exactly like a ticket line. The cash row opens selected with the exact total in
it, and the first digit replaces it — a customer handing over 2,000 DA against a 1,190.00-DA
ticket keys 2-0-0-0 and gets 2,000, not 11902000.
## The lines on the ticket
Each line shows the product, how many and what **one** of them costs — `2 × 119.00 DA` — and what
the line comes to, with the discount and what it takes off when there is one. Goods sold by weight
read in their own unit: `0.250 kg × 1,200.00 DA/kg`.
The line itself is not edited — select it and use the keypad, as above.
By default the sale is anonymous (the "walk-in customer"). Tap the customer button to attach a real
one — the list filters as you type — when they want the purchase on their account; their tickets
get their own invoice at closing.
## Selling by weight
Whether a product sells by the piece or by the fraction is decided by its **unit of measure**: a
unit with 0 decimals ("Each", "Piece") steps in whole units, and a unit that allows decimals —
kilograms at 3, litres, metres — sells fractions at exactly that precision.
Tapping a weight product's tile does **not** add one kilo. The line lands on the ticket reading
**Weight?**, already selected, with the keypad ready: put the goods on the scale and key what it
says — **.**, **2**, **5**, **0** for 250 grams. The line then reads as weight — `0.250 kg ×
1,200.00 DA/kg` — and so do the receipt the customer keeps and the refund screen if some of it
comes back. The keypad accepts the decimal point only on lines whose unit allows it, and no more
decimals than the unit itself carries.
A weight you forget to key stops the sale at **Pay**, naming the line — the till never charges for
a phantom kilo, and never silently drops the line either.
## Several customers at once
A counter is not a queue. Someone remembers the bread they forgot and walks back for it while the
next customer — two items, exact change — is already standing there. **The terminal holds up to six
tickets at a time**, shown as tabs along the top bar. Tap **+** (or press **Ctrl+Enter**, or **F2**)
to park what is on screen and start a fresh ticket for the next customer; tap a tab to come back to
it. Both keys do the same thing — F2 is the shorter reach, but many compact and gaming keyboards
leave their top row set to volume and brightness instead of F1–F12, and on those no function key
reaches the till at all, so Ctrl+Enter is the one to teach. **Ctrl+1** to
**Ctrl+6** jump straight to a ticket without taking your hand off the keyboard, and they are safe to
use mid-scan — a barcode scanner types plain digits, so only the Ctrl combinations are shortcuts.
The left and right arrow keys walk the tabs once one of them has focus.
The bar also holds the way back to the rest of Beelocity, the till's name, and — behind the **⋮**
button — the things you reach for less often: what this screen does, recalling a ticket (the menu
item points you at the search box, where the number is typed or scanned), switching
register, and closing the shift. Closing a shift throws away every basket still parked on it, which is why it is not
sitting beside the buttons you press all day. The browser tab names the till and the shift, so two
tills open on one machine are told apart from the taskbar.
Each tab shows what is waiting in it: how many items and what it comes to. Attach a customer and the
tab takes their name, which is usually the fastest way to find the right basket again. Paying for a
ticket closes its tab and hands the counter to the next one; there is always at least one ticket
open, ready for the next tap.
Only **one browser tab can run the till at a time**. Opening the terminal in a second tab moves the
till there — parked baskets and all — and the first tab steps aside with a message saying so, plus
a **Use the till here** button to take it back. Nothing is lost either way: the baskets always
follow whichever tab is live. (To serve two customers at once you never needed a second tab — that
is what the ticket tabs above are for.)
A parked ticket is **a basket on the counter, not a reservation**. Nothing is charged, nothing is
recorded in the ticket list, and no stock is held back — if the last unit is sold from another
ticket first, the parked one finds that out when it is paid for, exactly as a second cashier would.
Parked tickets belong to the till that rang them up and to the shift open on it:
- They **survive a refresh** of the terminal, so a reload costs nobody their basket.
- They do **not follow a change of register** — prices belong to the register that quoted them — and
the till asks before letting you walk away from them.
- They do **not survive the shift's close**. The closing screen says how many are still open so
they can be rung up or thrown away deliberately rather than by accident.
To throw one away, tap the **×** on its tab. A ticket with goods in it asks for confirmation first;
an empty one just goes. Nothing has been charged either way.
Every amount on the till — the tiles, the ticket, the total and the printed receipt — names its
currency: **125.00 DA**, not a bare 125.00. The rest of the app leaves the code off for your own
currency, which is right for a screen full of figures and wrong for one quoted across a counter.
Every line total is worked out to the centime and no further, so the amount on screen is always
an amount the customer can actually hand over — even when a price and a tax rate multiply out to
a longer number behind the scenes.
The prices on the tiles are the ones the till will charge, worked out on the server rather than
guessed at in the browser. The register sells from its own [price list](./registers.html) — or, if
it has none, from your organization's default list. Whichever list applies, a product it does not
price falls back to the product's own price. A product the register
has no price for is shown greyed out and reads "No price" — there is nothing to charge for it, and
finding that out at payment time with the cash already counted is nobody's idea of a good shift.
A tile can be greyed out for other reasons too, and it always says which:
- **No unit** — the product has no unit of measure yet. Every line on a ticket records what was
sold *and in what* — pieces, kilos, litres — so a product nobody has told the system how to
count cannot be sold. Open the product, go to its **Units** tab, add the unit you sell it in
(usually "Each" for anything sold by the piece), and the tile comes back priced and ready.
- **No variants** — the product comes in several variants (sizes, colours) and the till can price
none of them. Give the variants a price and a unit of measure and the tile comes back.
- **Bundle** — a bundle is a selling construct, not something on a shelf. Ring up its components,
or turn it into a simple product.
- **Not sellable** — a service or other non-physical product, which has no goods to hand across
the counter.
A product you have deactivated does not reach the shelf at all. The same is true of a single
variant: deactivate the XL shirt and the till refuses it while the other sizes keep selling, so
retiring one size is enough on its own — you do not have to unprice it as well.
A greyed-out tile is faded and outlined with a dashed border, so the goods actually on sale stand
out from the shelf at a glance rather than after a tap.
The shelf draws **up to 200 products at a time**. Past that it says how many more it is holding
back — type into the search box, and the tiles narrow to what the customer is buying. A shop with a
large catalogue is meant to work by scanning or searching anyway; nobody finds the right yoghurt by
scrolling through nine hundred tiles.
The tax line under the total reads "Tax included" or "Tax added" depending on how the register is
set up, so it always describes the amount you are about to collect.
On the payment screen the methods are keys at the top of the keypad, wearing the names you gave
them under Point of Sale settings, and the pressed ones are the split: one row per pressed key,
each filled in for you with what is still due at the moment you press it. Pressing a key selects
its row, and the keypad types over the selected row the way it types over a ticket line — the
first digit replaces the figure, so you only ever key what the till cannot know: what the
customer actually handed over, or how they want a split cut. Press a method's key again to take
it out of the split; its money moves back onto the cash row by itself. On a narrow till the keys
stack; either way they keep the digit keys' own size. The keys share the row between them, so a
name longer than the width its key gets is shortened with a … rather than pushing the row
sideways — hover the key to read the name in full. What is still due shows as a **Remaining**
row beside the total, and the change as a **Change** row — figures, not sentences.
The till also refuses a cash tender whose change would reach the largest note (2,000 DA).
Whatever bundle of notes a customer hands over, change that size means one of those notes could
simply go back to them — so a mistyped tender (52,222 keyed against a 2,936-DA ticket) stops at
the keypad with an explanation, instead of quoting a change figure that would empty the drawer.
When it really is the tender — 5,000 handed over in mixed notes for a 2,900 ticket — the message
carries a **Record it anyway** button that accepts the figure and stops asking for the rest of
that payment, so what physically happened can always be recorded.
The register takes payment that settles on the spot: cash, card, and the like. **Cheques, bills of exchange
and other paper you have to remit to the bank are not offered at the till** — they carry a number
and a maturity, and the money only arrives when the paper clears, none of which a counter sale can
record. If a customer wants to pay a large purchase by cheque, invoice them in Sales and receipt
the cheque in Treasury, where the whole remittance follows.
When a cash total lands on centimes — 99.99 DA, say — the payment screen offers to round it to the
nearest whole dinar, because the coin to settle the difference does not exist. The adjustment is
recorded on the ticket and reported on the shift's Z-report, so the drawer is not quietly over or
short at the end of the day. It is offered only when cash is being handed over: a card charges the
exact amount.
If a line is discounted all the way to nothing — a giveaway, a sample — the ticket can be worth
zero and takes no payment at all. The goods still leave stock and the ticket still records who
gave what away. (Registers only allow discounts up to the ceiling set on the register itself.)
## Returns at the till
A return works the way a sale does — same panel, same selectable lines, same keypad. Type or scan
the ticket's number (as printed, e.g. `POS-2026-000123`) into the **same search box the scanner
uses** and press Enter: the ticket opens on a **tab of its own**, tinted so a return is never
mistaken for a sale at a glance, and it parks there like any other ticket if the queue needs
serving first.
The refund tab lists what the ticket sold and how much of each line is **still returnable** —
already-returned units are simply not on offer. Tap a line, key the quantity coming back (a weight
line keys back at the gram, exactly as it sold), and the **Pay out** figure follows: it is worked
out on the server to the centime, never estimated at the till, so the figure on screen is always
the figure that will actually be paid. Keying more than is left simply stops at what is left, and
the till says so.
**Refund** opens the payout screen — the payment screen's twin, with two deliberate differences:
there is **no change** (nothing comes back across the counter on money going out) and every row is
an **exact amount**, so the split must cover the payout exactly before Confirm lights up. The
method keys offer **cash and the ways the original ticket was paid** and nothing else, because
those are the only routes the register accepts money back out by. Splitting a payout works like
splitting a payment: put part on the card, and cash follows with the rest.
**Void** lives on the same face, as its own clearly-marked button with a confirmation — offered
only for tickets sold on the *current* shift, because a void cancels the sale outright where a
refund works on any earlier day's ticket. Both actions carry their own permission, so a shop can
keep either for managers; an account without it is asked to call one over instead of being shown
controls that would fail.
## The receipt
Confirming the sale puts the receipt on screen, ready to hand over: the shop's name, the ticket
number, the till's name and when it was sold, then each line in its own unit. It is written in
the register's **receipt language** ([Registers](registers.html)) — the customer's slip, not the
cashier's screen — so switching the till to another language changes nothing the customer holds. A discounted line
says so underneath — the percentage and the money it took off — and a **Total discount** row above
the tax line adds up everything taken off the ticket, so a bargained price never reads as a
mischarge. Each payment prints what was handed over, with any change on its own line beneath the
tender it came out of. **Print** sends it to the printer, and **New sale** clears the screen for
the next customer.
## If the till loses the connection
If the network drops while a sale is being confirmed, the terminal says so plainly — it will not
claim the sale failed, because it cannot know. **Press Confirm again.** The till recognises the
retry and will not record the sale twice, so you can never charge a customer twice or take the
same goods out of stock twice by pressing again. If it keeps failing, check the ticket list before
starting the sale over.
That recognition is tied to the ticket it was rung into, not to the till, so you can leave a sale in
that state, serve the next customer from another ticket, and come back to it: the second customer is
charged for their own basket, and pressing Confirm again on the first still resolves to the one sale
it always was.
While payment is on screen, the rest of the till goes quiet: the shelf and the ticket tabs fade
and stop responding, and the keyboard shortcuts sleep. That matters most with a barcode scanner,
which types like a keyboard — a stray scan mid-payment lands nowhere instead of in the product
search or on another customer's basket. Only **Back** leaves the payment screen, and it keeps the
basket; a stray tap cannot throw away what you have entered. The closing dialog keeps
your typing inside it the same way, and the refund tab quiets the shelf exactly as payment does.
Every button that writes something — opening and closing a session, confirming a sale, refunding,
voiding — disables itself while it is working, so a nervous double-tap cannot send the same
instruction twice.
If your shift is closed from the back office while you are mid-sale, the till says so and tells you
nothing was charged, rather than leaving Confirm doing nothing with the customer waiting. And when
the till cannot reach the server at all, it says that too — it will not claim you have no registers
or no open session just because a request failed.
Switching to another register clears every ticket open on the till. Prices belong to the register
that quoted them, so a basket cannot simply walk to the next till — and because that throws real
baskets away, the terminal says how many are open and asks before doing it.
Source: https://docs.beelocity.com/en/pos/terminal/index.mdx