A register is one till. Before anyone can sell, an administrator creates the register under Point of Sale → Registers and binds three things to it:
- Warehouse (and optionally a location inside it) — where sold stock is taken from. Every completed ticket immediately decreases on-hand there; every refund puts it back.
- Cash account — the Treasury account that represents the physical drawer. When a session closes, the takings post as ordinary treasury receipts — one per payment method, for each invoice the shift settles into (the day’s walk-in invoice, plus one per named customer) — and each method’s share goes into the treasury account that payment method names: card money into the card method’s account, mobile money into its own. Only methods that name no account of their own — cash, typically — post here, into the drawer. That split is what lets this account reconcile against the physical cash count while the card account reconciles against the bank statement.
- Price list — where the register looks prices up. A register with no list of its own sells from the organization’s default list instead; whichever list applies, a product that list does not price falls back to the product’s own base price. (The organization default is the alternative to the register’s list, not a second place to look after it.) Tip: dedicate a retail price list to your registers so shelf prices stay independent of your B2B pricing.
Two switches shape how the register behaves:
- Tax-inclusive prices (on by default). The Algerian retail norm: the price on the shelf is what the customer pays — 119.00 DA means 119.00 DA. Beelocity works out the tax share inside that price for your reporting; nothing is added at the counter.
- Sell without stock (off by default). When off, a sale that asks for more than the system has on hand is refused with a clear message. When on, the sale always goes through — useful when the shelf sometimes holds stock the system hasn’t caught up with — and the difference is found later during cycle counting.
Maximum discount (0% by default) is the largest discount a cashier may key into a line at this register. Leaving it at 0 means no discounting at the till at all, which is the safe setting for most shops: a discount is money out of the drawer with nothing to show for it, and a till that can give 100% off can give the goods away. Raise it only for registers you want to trust with give-aways — and note that every discounted ticket is recorded in the audit trail with the discount named, whatever the ceiling.
Some products are simply not sellable at a register and are refused with a clear message: a product that comes in variants must be sold as a specific variant, and bundles and service/virtual products have no goods to hand over.
The Registers list narrows on its filter button by Warehouse, Price List, Cash Account, Tax-inclusive prices, Sell without stock or Active (Working with lists).
You can also give each register a receipt footer — a line or two printed at the bottom of every customer receipt (opening hours, return policy, a thank-you) — and a receipt language: the language customer receipts print in at this register, whatever language the cashier reads the till in. Left unset, it follows your organization’s document language. A till whose cashier works in Arabic can still hand every customer a French slip, or the other way round — the receipt belongs to the shop, not to the shift.
A register that still has an open session cannot be deactivated or deleted — close the session at the terminal first. For the same reason, while a session is running you cannot change what the register is bound to: its warehouse, location, price list, cash account or tax-inclusive setting. Changing any of those halfway through a shift would settle the session against something other than what the cashier was actually selling. Everything else — the name, the receipt footer, the receipt language, the discount limit — can be edited at any time.
The price list and the cash account must be in the same currency. Beelocity refuses the combination when you save the register, rather than letting the till sell all day and then fail at closing time.
That currency — the cash account’s — is also how the back office reads the register’s money: every float, expected, counted and over/short figure on the sessions and tickets pages is shown in the register’s own currency, even when the organization’s default is a different one. The dashboard cards that add several registers together use the one currency all registers share; with registers in mixed currencies those totals fall back to the organization default.