Loss control and cash risks
One manual discount means nothing. Twenty discounts under one PIN in a shift, when everyone else averages three, mean something.
Loss control has two layers. The first is the log of risky operations, which answers "what happened". The second is six rules, which answer the owner's question: "what should I look at".
Available on AWS brands (
cenaly.com,cenaly.ruand others), not oncenaly.ru. The platform's analytical database these figures come from is not deployed in the Russian contour: the till still writes events, but the risky-operations stream there is empty, the rules are not evaluated and no alerts appear. Everything else on this page — PIN approval and the server-side limit gate — works on every brand.
The log of risky operations#
The till writes an event stream of risky actions attributed to the current cashier (quick PIN switching counts, not just whoever is logged into the device):
| Event | When it is written |
|---|---|
| Manual discount / price override | the cashier lowered a price or granted a discount by hand |
| Order cancellation | the whole check was voided |
| Item voided after being sent to the kitchen | a dish already being cooked was removed |
| Refund against a receipt | a refund was issued |
| Cash drawer opened with no sale | the drawer was opened outside a sale |
| Reprint of an issued receipt | a reprint — the classic way to swap a guest's receipt |
| Cash discrepancy at shift close | the actual cash didn't match the expectation |
The stream itself, with filters by cashier and operation type, lives on the "Risky operations" tab of the Statistics section — see Site traffic and sales summary. It is not duplicated here.
The log is written by the till app as actions happen (best-effort) and reaches the server within a couple of minutes.
The log has a second, server-side leg. Risky operations are not only recorded by the till — the server also derives them on its own, from the way the order itself changed: voiding an item already sent to the kitchen, a manual discount, a price override, reopening a closed order, cancelling after payment, a refund, an edit after the pre-bill. The till cannot bypass this record: it is made on the side that accepts the order, not in the browser.
The two legs feed a rule of their own — “log mismatch”: when an operation appears in the till log but not in the server one (or the other way round), it is worth a closer look — the app was offline, the log never arrived, or the cashier tried to dodge the record. Such a mismatch shows up in “Till risks” on the “Under control” tab alongside the other alerts.
The six rules#
Rules are evaluated on the server against the log and your accounting data. The observation window is one week; a "shift" is approximated by the location's calendar day.
| Rule | When it fires |
|---|---|
| Void series | one cashier accumulated enough voids in a shift that it is no longer "just happens" (8 by default, roughly one an hour over a full shift) |
| Discount spree | the cashier's total manual discounts for a shift are three times (×3) the median across all cashiers of the account for the window |
| Cash discrepancy | the shortage/overage at shift close is above the owner's threshold, or three times (×3) the median discrepancy |
| Consumption above norm | for an inventory cycle, actual consumption exceeded the theoretical one (from recipes) by more than N % (5 % by default) — "where did the difference go" |
| Purchase price spike | a product was received above the median of its own price (15 %+ by default) |
| Log mismatch | an operation is in the till log but not in the server one (or the other way round) — see the section above |
Why money thresholds self-calibrate. A constant doesn't work here: accounts have different currencies and different check sizes. So the money rules compare a cashier with the median across all cashiers of the same account and only fire when it is exceeded threefold.
The median purchase price is computed over 30- and 90-day windows, with one invoice counting as one sample point (a supplier who splits a delivery into five lines does not shift the median five times harder). Fewer than three deliveries is not a sample and the rule stays silent. The same median powers the "+N % vs median" badge right on the receiving line — see Inventory.
Every alert carries a severity (high/medium), the amount at risk, the event count and the period. Re-running the calculation does not create duplicates: the same anomaly on the same day is the same alert.
Where to look and how to configure#
The "Cash risks" block sits in Work chat → Needs a decision → the “Under control” tab, together with the rest of the to-dos. There is no separate "Needs attention" section in the panel any more; the old address leads here. The "Review" button opens the event stream.
Thresholds open from the ⚙️ gear in the header of the "Statistics" section, the "Alert thresholds" item: it switches to the "Risky operations" tab and expands the collapsed thresholds block for you (the item is visible to the owner and the manager). You can also get there by hand — the "Risky operations" tab → the thresholds block. What you set:
- total manual discounts per shift — raises the bar: both conditions are required, the threshold and exceeding the median (what counts as a normal discount is relative and depends on promos);
- void series per shift — a count threshold;
- cash discrepancy — replaces the median: here the owner knows their tolerance in absolute money;
- losses above theoretical consumption, %;
- purchase price above median, %.
An empty threshold means "no threshold": the rule works from the median (money rules) or from a conservative default.
The owner's e-mail is opt-in. By default alerts are calculated and visible in the admin panel, but nobody gets letters. The e-mail switch lives in the same settings, and the design is one letter per run summarising new alerts, rather than one letter each: a void series usually arrives in a batch.
Video clips of risky operations#
If a camera is connected to the till device through Cenaly Hardware Bridge, a short video clip can be attached to an event: a few seconds before and after the operation.
It is configured per location (every till has its own room and its own camera angle) in the hardware section:
- on/off (off by default — video of the till area is personal data and cannot be switched on silently on the client's behalf);
- the till-area camera from the bridge device list;
- how many seconds before and after the event go into the clip — 30 and 30 by default, 5 to 120 seconds allowed;
- a daily clip quota per location — 40 by default, 1 to 200 allowed;
- how many days a clip is kept — 30 days by default, 1 to 365 allowed.
The log works fully without a camera — video is an addition, not a condition.
PIN approval#
Risky operations can be gated behind a supervisor's confirmation: the cashier requests the action, a manager enters their PIN, and the log records both the operation and who approved it.
Per-role limits on discounts, refunds and voids are set by the owner in Staff and shifts; the till uses them to decide whether an operation needs PIN approval.
Reprinting an issued receipt also goes through PIN and is written to the log.
Related sections#
- Site traffic and sales summary — the "Risky operations" stream itself and the "Pour" tab
- Attention — the work chat's "Under control" tab, home of the "Cash risks" block
- POS — PIN roles, pre-checks, refunds
- Cash shift — cash reconciliation and the Z-report the discrepancy comes from
- Inventory — stocktakes, variance and the "+N % vs median" badge on receiving
- Staff and shifts — per-role limits on discounts, refunds and voids
FAQ#
Is this surveillance of staff?#
It is a conversation tool, not a punishment tool. The rules do not accuse — they show that one person's numbers stand sharply out of the overall picture. What happens next is the manager's call.
Why didn't a rule fire even though the discount was huge?#
Money rules look at the shift total against the median across all cashiers, not at a single operation. If large discounts are the norm across the venue, the median is high too. Set an explicit threshold if you want to catch absolute amounts.
Do I get the same alert several times?#
No. An alert's identifier is built from the rule, location, cashier and period — recalculation produces the same alert, and the letter about it goes out once.
Can I enable e-mail without enabling video?#
Yes, they are independent settings: e-mail lives in the rule thresholds, video in the location's hardware settings.
What do I do when "Consumption above norm" fires?#
Compare theoretical consumption from recipes with the stocktake result: the usual causes are an inaccurate recipe, unrecorded waste write-offs, or portions served "by eye". The breakdown lives on the "Variance" tab of Inventory.