#Point of sale

POS is Tamra for a counter: a cashier opens a session on a terminal, rings sales and refunds, takes payment by cash, card or anything else you accept, and closes the session with a drawer count. Each sale reaches the books as it is paid, and closing squares the drawer with the books, so the accountant sees a day's takings and any difference in the drawer, tied to the session.

#Setting up

POS → Configuration.

• Terminals — one per till: a code, a name, the stock location it sells from (sales reduce stock there), and a default walk-in customer for sales with no named customer.
• Payment methods — each with a name, a kind (cash, card, bank transfer, voucher, other), the ledger account the money lands in, and a sort order for the payment screen. Cash needs a drawer account; card methods usually point at a clearing account that the acquirer's payout later clears.
• Settings — receipt header and footer, whether prices include tax, rounding.

Products sell at the active price list's price, with the product's sale tax; the terminal shows the tax breakdown on the receipt.

#Sessions

A session is one cashier's shift on a terminal — open it at the start, ring sales through it, close it at the end. Only one session can be open per terminal.

Open POS session: choose the terminal and enter the opening cash float — the change put in the drawer. Every sale, refund and payment then rings against the open session.

Close POS session: count the drawer and enter the cash counted. Tamra compares it with the expected closing — float + cash kept from sales (the cash handed over, less the change given back) − cash refunds — and shows the variance, over or short. The figure is worked out on the server from the session's own sales and refunds, so it is the same in the close dialog and on the Z-report. The closing summary is your Z-report: sales by payment method, refunds, tax breakdown, gross and net, expected and counted cash. The (i) on the page walks the arithmetic with an example: open with 200, take 1,500 cash, refund 50 → expected 1,650; count 1,645 → 5 short.

Over or short reaches the books (since 1.73). When the count differs, closing posts the difference to Cash Over/Short, so the books match the drawer:

The cash account is the one your Cash payment method lands in. Cash Over/Short is your chart's own account of that name (Cash over & short, Over/Short and the like are found); if there is none, Tamra adds Cash Over/Short under expenses (code 6995, or the next free code after it, in order) the first time it is needed. An opening float below zero is refused. The entry is dated the company's today, names the session (its reference is the session's name) and is kept on the session. A count that matches posts nothing.

Cash taken out of the drawer or put in by hand during a shift isn't recorded on the session, so it shows as over or short at closing — leave the drawer alone until the count.

Earlier sessions. Below today's sessions, Earlier sessions lists the ones opened before today, newest first (Show more brings the next page) — or pick one day with the date box. Each has its Z-report, so yesterday's close is there to see again. The Z-report's tax breakdown names each rate as a percentage (5%), and a sale refunded in full still counts in the session's gross sales, with its refund taken off.

#The terminal

Search or scan products; tap to add; change quantities; apply a discount on a line or the sale. Pick a customer for a named sale (their price list and TRN apply) or leave it as walk-in. Take payment: one method or split across several — 300 card, the rest cash — until the balance is zero. When the customer hands over more cash than is due — 120 for a 105 sale — the change to give back (15.00) shows on the screen and prints on the receipt and in the order's details. Change only ever comes out of the drawer, so a card, or any method but cash, pays no more than is still due plus the cash this sale has already taken; typed above that, the window says what it can take (Card can't take more than AED 105.00 here: change comes out of the cash drawer, and this sale has no cash to give it from.). A product with serial numbers sells in whole pieces.

To the fils. Each line is worked out to the fils (cent): quantity × price, less the line's discount, then its tax, each rounded — and the total is the sum of the lines, the same figure the books post. So a 20.05 item with 5% VAT is 21.05, and paying 21.05 completes the sale (before 1.73 the screen could hold an unrounded 21.0525 and never reach paid). The order posts, the receipt prints or emails, stock moves from the terminal's location.

A draft that the customer walked away from is voided, not posted. Void is for drafts only: a sale that posted is undone by a refund, and a refunded sale and its refund stay on the books. Orders lists every order of the session and before, with details and receipt reprint.

#Refunds

Open the original order → Refund → select the quantities coming back → the refund method (it starts on the way the sale was paid: the method that paid the most of it). Stock returns to the location (into the lots it came from), tax is reversed, the refund counts against the session. A sale whose session is closed is refunded from an open one — the same till's, or else your own open session — and the refund window says which; that session's Z-report and expected cash count it. A refund made while a session is closing goes to an open session too. A cash refund comes out of the paying session's drawer and can't take it below zero: Only AED 20.00 is in the cash drawer of … — refund that much in cash and the rest by card, or refund from the session that holds the cash. A sale already refunded in full says so. An item sold at 100% off posts like any other; a sale with nothing to book (free goods that cost nothing) posts without a journal entry. Refunds without an original order aren't possible — that's the control. A posted sale changes only through Refund and Void, whoever asks and however: its lines and payments can't be edited afterwards.

Line by line (since 1.73). Each line of the sale can be refunded up to what that line sold, less what was refunded from it before — also when the same product is on two lines (two prices, or a free one). A refund is rung in the sale's own session while it is still open, and a cash refund comes off that session's expected cash. A line refunded in parts gives back what was paid for it and no more: each part takes its share, and the last part takes what is left, VAT included (three parts of a line paid 10.51 gave back 10.53).

#What the books see

Each sale posts its own journal entry when it is paid: revenue and tax, each payment method's account for what it took, and the stock's cost of goods sold. A sale records the cashier who was signed in, and ringing, changing or refunding sales needs POS Terminal — use, on the terminal or any other way. A refund posts the reverse of what it brings back. Closing the session posts only the drawer difference, to Cash Over/Short (above). Reports show sales by terminal, by payment method, by hour, and tax breakdown for the VAT return.

#Common questions

Can two cashiers share a terminal? One session at a time; the second cashier closes the first session and opens their own, or uses another terminal.

A card payment was declined after we posted. Refund the order to the card method and re-ring; the session stays right.

Do POS sales appear in Sales → Invoices? They're POS orders, not invoices; a customer who needs a tax invoice gets one printed from the order, or you create an invoice for the named customer instead of ringing it.

Offline? The terminal needs the connection to post a sale. If it drops, wait until it is back before taking payment, and don't close the session until it is.

#If something goes wrong

• Open session is refused → a session is already open on that terminal; close it.
• Products don't show → Can be sold is off, or no price on the active list.
• Variance is large → check refunds paid in cash were refunded through the terminal, not from the drawer by hand, and that no cash was taken out or put in by hand during the shift.
• A cash refund is refused: "Only … is in the cash drawer" → the session paying it holds less cash than the refund. Refund up to that in cash and the rest by card, or refund from the session that holds the cash.
• The payment window says a card can't take more → change comes out of the drawer, and the sale hasn't that much cash. Put no more than is due on the card; cash pays the rest.
• Close is refused: The till has no cash account → set the Cash payment method's account under POS → Configuration, then close again (only needed when the count differs).
• A sale won't complete at the exact total → since 1.73 the total is to the fils; if it still happens, reload the terminal so it runs the new version.
• Payment method missing on the screen → it has no ledger account or is inactive.