Skip to content

Sessions

A session is the time that one register is open. It starts with a float, records each ticket, and ends when someone counts the drawer.

Updated View as Markdown

A session is the time that one register is open. It starts when the cashier opens the register with a float. It records each ticket sold in between, and it ends when someone counts the drawer. A register can have only one open or closing session at a time.

The status line at the top of a session’s page shows where the session stands:

  • Open means that the cashier can sell, refund and void.
  • Closing means that the drawer is counted and Beelocity is writing the paperwork. A normal close passes through this step in a moment. If the paperwork stops, the session stays here, as When a close does not finish explains below.
  • Closed means that the session is finished, and its figures no longer change. A normal close ends here with its paperwork done. A forced close also ends here, and its paperwork can be unfinished.

Opening

At the terminal, the cashier presses Open session and enters the Opening float. This is the cash placed in the drawer to give change, such as 5,000 DA. To count it note by note, tick Count notes and coins instead and enter how many of each face value. The terminal then adds up the float for you.

During the session

Each sale, refund and void is recorded on the open session. You can read the takings at any time on the X-report tab of the session’s page. It is the same summary as the closing Z-report, taken early. While the session is open, Expected cash on that page shows the running figure, followed by the words so far.

Closing and counting

Closing a session also ends whatever is still on its counter. Beelocity discards any ticket that is still open and unpaid. The closing screen says how many there are, so the cashier can take payment for them or discard them on purpose.

To close, the cashier presses Close session on the ⋮ menu. They count everything in the drawer, float included. They enter the total, or tick Count notes and coins instead. Beelocity then works out the Expected cash from the recorded tickets and cash movements:

expected cash = opening float + cash taken on sales − change given − cash paid out on refunds + cash movements paid in − cash movements paid out

A voided ticket counts for nothing in this figure. Only cash affects it, because card takings never sit in the drawer.

The terminal does not offer a cheque or a bill of exchange, because the register has nowhere to record the number on the paper. A customer who pays that way needs an invoice in Sales.

Cash can move during a session, without waiting for the close. Examples are taking cash to the safe, topping up the float, or paying a courier from the drawer. The cashier records each one at the terminal with Move cash on the ⋮ menu, with the amount and a reason. The expected cash follows the movement at once, so a safe drop never reads as a shortage at close. You cannot edit a movement. To correct a wrong amount, record a movement the other way, so that the session’s story stays complete. The register refuses a payout larger than what the drawer should hold.

Before the cashier confirms, the terminal shows Expected in the drawer and the difference that the count makes. The difference updates as they type. If the two figures disagree, the button reads Review the shortage or Review the overage. The cashier has to press it before the button reads Close & settle. A recount costs nothing, but nobody can change the recorded figure afterwards. A drawer that balances closes in one press.

The difference between the count and the expected cash is the Over / short. A positive figure means more cash than expected, and a negative figure means that cash is missing. Beelocity stamps it once at close and keeps it for good. The session’s page shows it in the Drawer section. If a drawer is often short, review how the register is run. The cashier can explain a difference in the Closing note.

Settlement — automatic

Closing also settles the session, so you post nothing by hand:

  • One sales invoice covers the session’s walk-in sales, with refunds already netted in. Each ticket sold to a named customer gets its own invoice on that customer’s account. The invoices match the tickets to the centime. A discount given at the terminal appears on them as a discount, and not as a lower price. Cash rounding stays off the invoices and settles on the receipts.
  • One treasury receipt for each payment method, on each invoice. The money of each method posts into its own treasury account. Cash goes into the register’s cash account, and card money goes into the account that the card method names. The receipts pay the invoices in full.
  • A return can outweigh the session’s sales of that product. For example, someone brings back an earlier purchase, and nobody buys the same thing in this session. The difference cannot sit on an invoice, so Beelocity writes a credit note for it against that invoice.
  • A named customer who returns a purchase from an earlier session gets their own credit note, on their own account, whatever else the shop sold. Their statement then shows what really happened. It shows the purchase invoiced and the return credited back.
  • The cashier has already handed back the part of a return that the session’s sales could not absorb. So Beelocity records that part as money paid out against the credit note, from the account that it really left by. A cash refund leaves the register’s cash account, and a refund on a card leaves the card method’s account. Each account keeps matching what really crossed the counter.
  • A sale paid by card and refunded in cash in the same session cancels out on paper, but not in money. The card payment is still on its way from the bank, and the cash has left the drawer. So the close writes both sides. It invoices the sale and banks the share of each payment method in its own account. It credits the return and records its payout.
  • This also holds for a split sale. If a customer pays 60 by card and 40 in cash and gets a cash refund, Beelocity banks each amount where it belongs. It then pays the refund out of the drawer.
  • A refund can go back the same way that the money came in, such as a card sale refunded on the card. If the sale and all of its refund fall in one session, there is nothing to record, and Beelocity writes nothing for that sale.
  • A session with no tickets writes no invoice. A session that only refunded earlier sales writes an invoice at zero, to hold its credit note.

The session’s page links to its Settlement invoice, which is the invoice for the walk-in sales. A named customer’s invoice is linked from their ticket. Each of these invoices links back to the session. A credit note that the close wrote shows its Register session and links back in the same way. A credit note that you write yourself in Sales never has one. So no close takes it for its own and pays it out of the drawer.

The close writes no note of its own on these documents. The printed invoice and credit note name the session in their references, in the language of the document. A French invoice shows Session de caisse beside SES-2026-000001, and an Arabic one shows جلسة الصندوق. The receipts and the money paid back carry the bare session number as their reference. So a search for SES-2026-000001 in Receipts & Payments finds each of them.

After a session closes, it is closed everywhere. The terminal goes back to offering Open session at once. This holds whichever way the cashier leaves the closing summary, with the Closed button or with the View Z-report link beside it.

When a close does not finish

A close has two halves: the drawer count, which is instant, and the settlement above. If the settlement stops, the session stays at Closing. The cause is usually a setting in Sales or Treasury. Nothing is lost. Fix the cause and press Finish settling, and the settlement continues from where it stopped.

The terminal says so itself. A register whose session is stuck at Closing does not offer to open a new session. It explains that the session was counted but that its paperwork did not finish, and it offers Finish settling. This asks for no new count, because the first count records what really happened, so it stands. Only the paperwork runs again. If it stops again, read the reason that it gives. Then ask the owner of your organization to fix that setting.

One cause cannot be fixed that way. Someone in Sales can cancel a credit note that the close wrote, before its refunds are paid out. Finish settling then stops and names that note each time. So leave the credit notes of a closing session alone until its status line reads Closed. If this happens to a session that already has its Settlement invoice, neither Finish settling nor a forced close can free the register today.

A session left at Closing keeps its register busy, so no new session can start on it. If Finish settling keeps failing and you need the register back, the owner of your organization can force the session closed. No other built-in role can, and a custom role needs the force-close permission.

To force a close, the owner opens the session’s page and presses Closed on the status line. This is the row across the top of the page that reads Open · Closing · Closed. A forced close does these things:

  • It asks for a reason and keeps it on the session for good. The session’s page shows the reason as Force-close reason, under the status and apart from the cashier’s closing note.
  • It gives up on the rest of the settlement and frees the register. What the settlement already wrote stays.
  • It leaves the rest to you. You enter anything missing by hand in Sales and Treasury. If tickets still have no invoice, the session appears on Force-closed, not settled.
  • It puts the name of the person who forced the close in Counted by.

A forced close is a last resort, and you cannot undo it. Closed is not a button for a session that already has its Settlement invoice, because Finish settling is the way to finish that session. It is also not a button for anyone without the permission, who sees the same status line.

When another screen got there first

You can work on a session from more than one place: the terminal at the counter and the session’s page in the office. One of them can change the session while the other still shows it as it was. Beelocity then refuses the second screen. A sentence in the reader’s own language says what happened and what to do:

  • Opening a register that already has a session names that session. If it is open, reload the page and carry on with it or close it. If it is closing, reload the page and press Finish settling.
  • Closing a session that another screen has just closed says that the session is already closed and that nothing is left to close. If both screens close it at the same moment, the second one sends you to the Sessions page to see how it ended.
  • Finish settling, pressed while another screen finishes the same settlement, says that the drawer count is recorded. It asks you to wait a moment and look at the session again.
  • A Z-report asked for on a session that is still open says that the report is written at close. It adds that the X-report shows the session so far.
  • Closed on the status line of a session that is no longer stuck at Closing says so. If the session is still open, it tells you to close it at the terminal.
  • Closed on a session that has since got its Settlement invoice says that you cannot abandon its settlement. It tells you to press Finish settling at the terminal.

The Z-report

The Z-report is the session’s closing summary. Beelocity works it out from the recorded tickets each time you open it. It shows how many tickets, sales, refunds and voids the session had, and its net takings. It also shows the totals by payment method, by tax rate and by product category.

You read it on the Z-report tab of the session’s page. The tab appears after the drawer is counted, so a session at Closing has one too. The tab has no print button. It does not show the over / short, which is in the Drawer section of the same page.

The tables by tax rate and by product category price what was sold, which means the goods on the tickets. Cash rounding is not part of either one. It is the few centimes added to or taken off a cash ticket, so that the customer can really pay it. So the bottom of the tax rate table reads in three steps: Gross takings, plus Cash rounding, gives Net takings. Net takings is the figure that matches what the payment methods collected. In a session with no rounding, the middle line is zero and the two others agree.

Finding a session

The Sessions list narrows on its filter button by Status, Register, Cashier, Counted by or With a difference. It also takes a date window on Opened at or Closed at, and a range on Opening float, Expected cash, Counted cash or Over / short. For example, to find the sessions that were short last week, set Over / short below zero and Closed at to that week (Working with lists).

A register’s own page lists its sessions on the Sessions tab, with filters on the columns that it shows. On a session’s page, Tickets narrows by Type and Status, Cash counts by Count, and Cash movements by Direction.

What is kept on record

Beelocity records everything that a register does for later review, and also what people read from it. That covers opening and closing a session, and each sale, refund and void. It also covers each X-report or Z-report that someone opened, and the daily takings that someone looked up.

The settlement’s own paperwork is recorded in the same way, and names the session that it came from. That means the invoice, any credit note and any money paid back to a customer. The owner of your organization reads all of it in the Audit log, and so can anyone whose role the owner gives that permission.

Navigation

Type to search…

↑↓ navigate↵ selectEsc close