Bitta Retail POS guide
Security, PINs, and lock screen
Cashier PINs for shared-terminal login and lock-screen unlock, auto-relock, switching users mid-shift, supervisor PIN approvals, and the permission-set and licensing layers underneath.
status: verified applies-to: 1.0.0.121rev: 1
Who is allowed to do what at the till, and how the register proves it: cashier PINs for shared-terminal login and lock-screen unlock, automatic relocking, switching users mid-shift, supervisor PIN approvals, and the permission and licensing layers underneath. The goal is that every sale, discount, and drawer-open names a real person.
Cashier PINs
Every POS User can carry a PIN, set through the Set PIN action on the POS User card. PINs are stored salted and hashed (SHA-256), never in plaintext, and every PIN check is validated server-side - the register screen is never the only gate.
The PIN serves two purposes:
- Shared-terminal login - identifying who is ringing when several cashiers share one till.
- Lock-screen unlock - resuming work after the register locks, or handing the till to the next person.
See Stores, terminals, and users for the full POS User field reference, including the per-user discount cap and Can Override Price flag that feed the pricing rules on Pricing and discounts setup.
Shared-terminal login
PIN login at the register is controlled by two switches working together:
- Require Terminal Password on POS Setup - the company-wide master switch.
- Shared Terminal on the POS Terminal - marks that specific till as shared by multiple POS users.
Only when both are on does the till require a PIN at login. The POS User's Is Shared User field is a read-only derived indicator; it does not control login. Once signed in, the active cashier's identity is stamped on new sales, so reports and shift records attribute work to the right person via the user's BC salesperson mapping.
Lock screen and switching users
The register has a lock screen so a cashier can step away or hand over the till without closing the register:
- Lock the register from the register surface (or let it auto-lock, below).
- Any authorized POS User can unlock with their own PIN.
- If a different user unlocks, the active cashier switches - new sales carry the new user's attribution.
This is the intended handover flow on a shared till: lock, walk away, next cashier unlocks as themselves. No sale data is lost across a lock; if you need to set a basket aside for later instead, see Parking and resuming sales.
Auto-relock
Each terminal can relock itself after idle time via the Auto-Lock (min) field on the POS Terminal:
| Value | Behavior |
|---|---|
| -1 | Inherit the POS Setup value. |
| 0 | Never auto-lock this till. |
| 1 or more | Lock after that many idle minutes. |
TIP
On a shared till in an open area, set a short auto-lock (a few minutes) so an unattended register cannot be used under the previous cashier's identity.
Supervisor PINs and approvals
A POS User with the Supervisor flag can authorize actions that exceed another cashier's authority. When a change needs approval - an over-cap discount, a price override by a user without Can Override Price - the POS Supervisor Auth dialog asks a supervisor to enter their PIN. The approving supervisor is recorded on the sale or line (Approved By), so every over-limit change names who authorized it. A cashier who is themselves a supervisor is never prompted for their own actions.
Two rules to remember:
- Supervisor approval is an escape hatch above a cashier's cap, not a bypass of a hard floor: a below-cost or below-minimum-margin price can never be authorized past, by anyone.
- Whether an over-cap change can be approved at all is a policy choice - if the relevant "Supervisor For..." toggle on POS Setup is off, the over-cap action is simply refused with no approval path.
The policy toggles and caps live on Pricing and discounts setup; day-to-day approval scenarios are walked through in Supervisor operations.
NOTE
Drawer-opens outside a sale are also audited: a No-Sale records a zero-amount cash movement naming the user, so the drawer never opens anonymously. See Cash movements.
Permission sets and licensing
Underneath the register-level controls sit the standard Business Central layers:
- Permission sets - the app ships its own permission sets covering its objects. Assign them to your users alongside standard BC permissions; register capabilities can be visible only where the underlying permission allows the operation, and company policy and permissions always win over any register-level profile setting (see Role profiles playbook).
- Licensing entitlement - the license is a signed entitlement enforced at register open and at sale insert, with a terminal cap and a bounded trial/grace period. An unlicensed or expired state degrades gracefully rather than corrupting data. Details on Licensing and trials.