---
title: "Tickets"
description: "A ticket is one counter transaction — a sale or a refund."
---

> 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.

# Tickets

A ticket is one counter transaction — a sale or a refund. Tickets are created at the terminal
and are final the moment they print: the price, discount and tax on each line are frozen at sale
time, and no ticket is ever edited or deleted afterwards. Corrections happen through voids and
refunds, so the ticket list is a complete, trustworthy history of everything the registers did.

Tickets are rung up on the terminal — see [Selling at the till](./terminal.html) for the screen
itself. This page is the ticket as a record: what it holds, and what can still happen to it.

## Finding a ticket

The **Tickets** list narrows on its **filter button** by **Status**, **Customer**, **Shift**, **Sold by**, an amount range or a **Sold** date window — and by the two questions the list exists for: **Type** (Sale or Refund) and **Register**, neither of which is a column of the ticket; the list answers them from the ticket's refund link and its shift's register ([Working with lists](../getting-started/working-with-lists.html#narrowing-the-list)).

Opening a ticket puts everything it holds on one screen: the customer, the shift and the money
down one side, the goods it sold in a table beside them, and the payments that settled it on a tab
of its own.

## Refunds

A customer returning goods gets a **refund ticket**: type or scan the original ticket's number in
full into the till's search box (from any earlier day — a partial number is refused rather than
guessed at, so you never refund the wrong ticket), key the quantities coming back on the refund
tab that opens, and pay the money out. The refund
carries the **original prices** — nothing is re-priced — and the returned goods go straight back
into stock, into the very batch they were sold from when the product is tracked by batch, valued at
what they cost when they left. Stock reports and expiry lists therefore stay correct after a return
instead of slowly drifting. The refund tab counts what is **left** to return, not what was originally sold, so a second
visit for the same ticket cannot offer you units that have already come back. The **Pay out**
figure is the one the till will actually pay, worked out on the server to the
centime. You can refund a ticket in several steps until every unit is returned; asking for
more than was sold is refused — including asking for the same line twice in one go, which counts
as one request for the total. However you split it, the total given back is exactly what was
charged, down to the centime: the last return of a line pays whatever is left rather than another
rounded share. If the sale was rounded to a whole dinar at the counter, returning the whole ticket
gives back the rounded figure the customer actually handed over.

Money goes back the way it came: **in cash, or by a method the original ticket was paid with**.
Paying a card refund out of a till that took cash would leave the drawer count looking right while
the money had gone somewhere else entirely. The one exception is the paper the till never took in
either: a refund is never paid out as a cheque or a bill of exchange. Pay it in cash, or raise a credit note
for the customer in Sales.

Refunding carries its **own permission**, separate from selling. Every cashier has it out of the
box, but a shop that wants returns handled by a manager can take it off the cashier role alone —
the till keeps selling exactly as before, and the refund screen asks the cashier to call a manager
over instead of showing controls that would be refused.

<a id="voids"></a>

## Voids

A void cancels a whole ticket **from the same, still-open shift** — the "I rang it up wrong,
customer is still standing here" case. Stock returns, the money never counts, and the ticket
stays on record marked as voided. Once the session has closed, voiding is no longer possible —
use a refund instead.

Two tickets can never be voided, and the till says which:

- **A refund ticket.** Voiding it would take back goods the customer left with and un-pay money
  they were handed. If a refund was a mistake, sell the items again — that is the transaction that
  actually happened.
- **A sale that has already been refunded**, in part or in whole. Some of it has been reversed
  already, so voiding the rest would count the reversal twice. Void is for a sale that should never
  have existed; a sale that came partly back is one that did.

Like refunding, voiding carries its **own permission** — granted to cashiers by default, and
removable on its own so cancelling a sale can be made a manager's call without touching anything
else the till does.

## Receipts

Every completed sale shows a printable receipt: your organization's name, the till it was sold on,
the ticket number and the time of sale, then the lines, the tax, the payments and any change, and
finally the register's own footer text — put your returns policy or a thank-you there. Use the
Print button for a paper copy; a long basket runs onto a second page rather than being cut off, and
prints in black on white whatever theme the till is running.

The time on the receipt is the one recorded against the ticket, not the till's own clock, so a
machine with the wrong time set cannot print a receipt that contradicts your records.

Source: https://docs.beelocity.com/en/pos/tickets/index.mdx