A session is one cash-drawer shift on one register: it starts when the cashier opens the drawer with a float, records every ticket sold in between, and ends with a counted drawer. Each register can have only one open session at a time.
Opening
At the terminal, the cashier opens a session by entering the opening float — the cash placed in the drawer to give change (for example 5,000 DA). They can itemize it by denomination (how many 2,000-DA, 1,000-DA, 500-DA notes and so on); the breakdown must add up to the float.
During the shift
Every sale, refund and void is recorded against the open session. You can peek at the takings at any time with the X-report on the session page — the same summary as the closing Z-report, taken mid-shift.
Closing and counting
Closing ends the till’s day, so it also ends whatever is still sitting on its counter: any tickets still open and unpaid are thrown away with the shift. The closing screen says how many there are, so they can be rung up or discarded on purpose rather than by surprise.
To close, the cashier counts everything in the drawer (float included) and enters the total — again with an optional note-and-coin breakdown. Beelocity then computes the expected cash from the recorded tickets:
expected cash = opening float + cash taken on sales − change given − cash paid out on refunds + cash paid in mid-shift − cash paid out mid-shift
Only cash affects this figure — card takings never sit in the drawer. (A cheque cannot be taken at the till at all: the register has nowhere to record the instrument number, so it asks you to invoice the customer instead.)
Cash can move mid-shift without waiting for the close. Banking takings to the safe, topping up the float, paying a courier from the till — record it at the terminal under Move cash on the ⋯ menu, with the amount and a reason. The expected figure follows the movement immediately, so a safe drop never reads as a shortage at close. A movement is never edited afterwards: correct a mis-keyed one with a movement in the other direction, and the shift’s story stays complete. The register refuses a payout larger than what the drawer holds.
Before you commit, the till shows what the tickets expect the drawer to hold and the difference your count makes, updating as you type. If the two do not agree, the button asks you to review the shortage or overage before it will close the shift — recounting costs nothing, and the figure that gets recorded cannot be revised afterwards. A drawer that balances closes in one click.
The difference between the count and the expectation is the over/short: positive means more cash than the tickets explain, negative means missing cash. It is stamped once at close, kept forever, and shown prominently on the session page — a drawer that is repeatedly short is the classic signal to review till procedures. A closing note lets the cashier explain a discrepancy.
Settlement — automatic
Closing also settles the session, with no manual posting:
- One sales invoice covers the day’s anonymous (walk-in) sales, with refunds already netted in. Tickets sold to a named customer get their own invoice on that customer’s account. The invoice matches the tickets to the centime — what the drawer collected is what the document says — and a discount given at the till appears on it as a discount, not as a quietly lowered price.
- One treasury receipt per payment method, for each invoice the shift settles into. Each method’s share posts into its own treasury account — cash into the register’s drawer account, card into the account the card method names — and pays those invoices off, so they land fully paid.
- When a return outweighs the day’s sales of that product — someone brings back yesterday’s purchase and buys nothing similar — the difference cannot sit on an invoice, so Beelocity writes a credit note for it against the same invoice.
- A named customer returning an earlier day’s purchase gets their own credit note, on their own account, whatever else the shop sold that day. Their statement then reads the way the shift actually went: the purchase invoiced, the return credited back.
- Whatever a return is too big for the day’s sales to absorb, the cashier still physically handed back — so that part is recorded as money paid out against the credit note, from the account it actually left by: a cash refund out of the register’s cash account, a refund put back on a card out of the card method’s account. Each account keeps matching what really crossed the counter.
- A sale paid by card and refunded in cash the same shift cancels out on paper but not in money: the card payment is still on its way from the bank while the cash left the drawer. The close writes both sides anyway — the sale invoiced and each payment method’s share banked into its own account, the return credited and its payout recorded — so every account keeps matching what actually happened. That holds even when the sale was split across methods: a purchase paid 60 by card and 40 in cash then refunded in cash banks the 60 and the 40 where each belongs and pays the refund out of the drawer, rather than lumping everything onto one method. Only when the refund went back the same way the money came in (card sale, card refund) is there truly nothing to record, and then nothing is.
The session page links to its invoice, and the invoice links back to the session.
Once a shift is closed, it is closed everywhere. The till goes back to offering Open session straight away, whichever way the cashier leaves the closing summary — the Closed button or the View Z-report link beside it.
When a close does not finish
Closing has two halves: the drawer count (instant) and the settlement above. If the settlement half fails — usually because something in Sales or Treasury is misconfigured — the session stops at Closing. Nothing is lost: fix the cause and close again, and it picks up exactly where it stopped.
The till says so itself. A register whose shift is stuck at Closing does not offer to open a new one — it explains that the shift was counted but its paperwork did not finish, and offers Finish settling. That asks for no recount: the count already taken is the record of a count that really happened, so it stands, and only the paperwork is retried. If it stops again, the reason it gives is the thing to fix.
A session left in Closing keeps its register busy, so no new shift can start on it. If closing again keeps failing and you need the register back, a manager with the force-close permission can open the session page and click Closed on the shift’s status line — the row across the top of the page that reads Open · Closing · Closed and shows where the shift has got to. It asks for a reason, keeps that reason on the session forever, gives up on the rest of the settlement, and frees the register — so anything the settlement had not written yet has to be entered by hand in Sales and Treasury. It is a last resort, and it cannot be undone. Without that permission the status line still shows the whole shift, and Closed is simply not a button.
The Z-report
The Z-report is the shift’s closing summary, computed live from the recorded tickets: totals by payment method, by tax rate and by product category, plus ticket counts and the over/short. Print it, file it, or read it straight from the session page.
The breakdowns by tax rate and by product category price what was sold — the goods on the tickets. Cash rounding is not part of any of them: it is the few centimes a cash ticket is nudged by so the customer can actually pay it. The bottom of the by-tax-rate table therefore reads down in three steps — Gross takings, plus Cash rounding, equals Net takings — and net takings is the figure that matches what the payment methods collected. On a shift with no rounding the middle line is simply zero and the two ends agree.
Finding a shift
The Sessions list narrows on its filter button: Status, Register, Opened by, Closed by, an Opened / Closed date window, or a range on the float, the expected and counted cash or the Over / Short figure — “which shifts were short last week” is Over / Short below zero with Closed in the window (Working with lists). A register’s own page lists its shifts on the Sessions tab with the same filters, and a session’s tabs narrow their tickets by Type and Status, the cash counts by Count, the cash movements by Direction.
What is kept on record
Everything the till does is recorded for later review, and so is everything anyone reads from it: opening and closing a shift, each sale, refund and void, the Z-report someone printed, the daily takings someone looked up. Settlement’s own paperwork — the invoice, any credit note, and money paid back to a customer — is recorded the same way, naming the shift it came from. Managers with permission read all of it from the audit trail.