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 — 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. 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, 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). 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 — 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) — 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.