How the expected amount is built
Every transaction a till records is sent to the Transaction Repository, which passes it on to Reconciliation. For each transaction Reconciliation finds the till audit of the drawer it belongs to and adds the transaction's tender lines to that drawer's expected amount, tender by tender. When the drawer is counted, the count is compared with that amount.
In the example, till 1's expected cash at closing is 2 000 + 350 + 120 − 80 − 1 000 + 240 = 1 630. The cashier counts 1 620, which is 10 short. The allowed deviation for cash is 20, so the till audit is approved.
What changes the expected amount
| At the till | Effect on the expected amount |
|---|---|
| A sale paid in cash | + the amount the customer handed over |
| Change given back | − the change. A 400 note for a 350 purchase adds 400 and takes 50 away: +350. |
| A return paid back in cash | − the amount paid back |
| A payment with card, gift card or voucher | + on that tender's own total. It never changes the cash total. |
| A paid-in or paid-out, for example cash for a delivery | + for paid-in, − for paid-out |
| Cash brought from the safe into the drawer (tender loan) | + the amount |
| Cash taken from the drawer to the safe (tender deposit or pickup) | − the amount |
| The opening float | sets the opening amount of a new till audit. See Drawers and floats. |
| A transaction voided after it was finished | reverses the original transaction's amounts |
Each tender also gets an expected quantity: the number of tender lines. That is what lets a store count, for example, the number of gift vouchers in the drawer rather than their value.
A payment in a foreign currency is added to its own tender in that currency, so euro notes in a Norwegian store are expected and counted as euros.
What is ignored
- Lines cancelled before the receipt was finished.
- Suspended transactions. They count when they are resumed and finished.
- Training-mode transactions.
- A transaction received twice. Each transaction is counted once, by its transaction ID.
Counted items: bottle-deposit receipts and similar
Some things in the drawer are not tenders, for example the bottle-deposit receipts a store pays out against. The POS marks such lines in the PosLog with reconciliation attributes, and Reconciliation then expects them to be counted too:
| PosLog attribute | Meaning |
|---|---|
ReconciliationMethod | MANUAL means the item must be counted. Any other value means it is shown but not counted. A line without this attribute is not an item to reconcile. |
ReconciliationTypeCode | groups the lines, for example one code per kind of receipt |
ReconciliationCountMethod | AMOUNT or QUANTITY: whether staff count the value or the number of receipts |
ReconciliationMaxAllowedDeviation | how far the count may be off |
These are Visma extension attributes on the PosLog Return line. Items are counted alongside the tenders, as
described in Counting the till.
Which till audit a transaction lands in
A transaction always lands in an open till audit for its drawer: the cashier's under operator accountability, the till's under workstation accountability. See Drawers and floats.
⚠ A transaction that arrives after the till audit is finished does not change it. Once a till audit is
COMPLETED or LOCKED, it takes no more transactions: the next one for the same drawer starts a new till audit,
which has to be counted as well. This is how a till that keeps trading after its count, or a transaction that reaches
Hii Retail late, is still accounted for.
A count that was rejected with attempts left is different. The till audit stays OPEN, so a sale rung up before the
next attempt changes the amount that attempt is compared with. Hii InStore shows whether the cashier is still signed
in at the till, so that a drawer is not counted while it is still in use.
The business date
Every till audit belongs to a business date: the store's local date, shifted by the business-day offset set on the business unit in Business Unit Management. A store whose business day ends at 03:00 records a sale at 01:30 on the previous business date. End of day is closed per business date, and the reports use it.
Warnings for too much or too little cash
For each tender you can set a highest and a lowest expected amount (maxAllowedAmount and minAllowedAmount in the
tender settings). When a transaction takes a drawer's expected amount above the
highest, or below the lowest, Reconciliation sends a warning. It is sent each time the limit is crossed: once when the
amount goes over, and again if it drops back and goes over a second time. A limit of 0 switches the warning off.
A store uses it to know that a drawer holds so much cash that some should go to the safe. The warning goes to Hii Retail's own store applications. It is not offered through External Events.