The system has around 50 granular rights — there is no such thing as "full access" or "no access". Every right can be limited to a specific store (per-POS scoping). The cashier in Râșcani sells and issues fiscal receipts exclusively at Râșcani; they do not see the stock of other locations, they do not initiate transfers, they cannot touch operations of any other store. We configure the role for you at onboarding after talking with you.
Three pieces work together: the employee's personal account, the role (a list of rights) and the scoping (which store each right applies to).
Every employee gets their own account (username + password of at least 8 characters, or a 4-6 digit PIN for quick authentication at the POS). One account per person — not shared between people who might be working at the same time, so that the audit of actions carries individual weight.
A role is simply a list of rights out of the ~50 available ones. You name it whatever you want (cashier, B2B cashier, warehouse keeper, location manager, accountant, auditor). There is no rigid predefined list — at onboarding we configure the roles to fit how you like to structure them.
Every right in a role can be tied to a specific store. The "issue fiscal receipt" right granted with scoping to the Râșcani store means exactly that — yes at Râșcani, no anywhere else. You can also combine several stores (a regional manager with two locations, for instance).
On every sensitive operation (sale, receipt issuance, stock change, transfer) the system checks whether the user has the right in question — in under 10 ms per check. If they don't, the operation is refused and the attempt remains in the audit log as a failed try.
A real scenario from our documentation: a chain with stores in Centru, Botanica, Râșcani and Buiucani, where every employee only sees what belongs to their job.
Oxana · cashier Râșcani ✔ sells at Râșcani ✔ issues fiscal receipts at Râșcani ✔ sees the stock of the Râșcani store ✖ does not see the stock of the other stores ✖ does not sell at Centru / Botanica / Buiucani ✖ does not issue B2B e-Factura (separate right, not granted) Vlad · manager Râșcani ✔ everything Oxana does ✔ approves goods receipts at Râșcani ✔ approves transfers to / from Râșcani ✔ sees the reports for the Râșcani location ✖ does not see the sales of the other stores Andrei · regional director (south) ✔ sees consolidated reports for 2 stores ✔ approves inter-store transfers in the south area ✖ does not sell anywhere General director ✔ everything, everywhere
Adapted excerpt from the live documentation — see also Multi-POS for the full scenario, including inter-store transfers with a mobile POS running from a vehicle.
The pre-configured "cashier" role applies the least privilege principle — the exact rights required to work at the till, nothing extra.
The system refuses the operation and leaves a trace in the log — not just a silent "access denied". The audit is designed to be useful for real investigations.
If a cashier restricted to Râșcani accidentally (or intentionally) opens an operation on another store, the system refuses it. No partial data shows up, nothing incomplete is saved.
Every important action (receipt issuance, approval, transfer, price change) is written with username, second-precision timestamp, context and outcome. The normal interface does not allow deleting or modifying the history — not even for the admin.
Failed logins are logged with reason (wrong password, blocked account). Repeated attempts trigger a server-side lockout and notify the administrator. Unlocking is done manually, by the admin.
Every employee responsible for a POS can be restricted to accessing only the transfers to / from their POS. That way a Botanica manager CANNOT initiate or accept a transfer to a store other than the one they are responsible for. Every transfer keeps a full history (who, when, what status) for later audit.
Case-insensitive username, up to 32 characters. Password of at least 8 characters. 4-6 digit PIN for quick authentication at the POS (handy when the cashier logs in and out every time a customer arrives). Login time: typically under a second.
Staff rotation on the same functional account (morning and evening shifts using the "cashier1" account for their role) is accepted and does not count separately for licensing. What we recommend avoiding is an account shared between people who might be working at the same time — that is where the audit loses its value.
How long the cashier stays logged in without activity — we set it to the value that fits your flow (stores with dense foot traffic tend to pick a longer timeout, warehouses with rare shifts a shorter one).
Two-factor authentication (TOTP) and Single Sign-On (Active Directory, Google Workspace, Microsoft 365) are not accessible by default. They can be activated as a custom Enterprise integration on request — priced in support hours after evaluation.
Composing and activating roles is an assisted configuration service — a conversation with us at onboarding, not a settings page you figure out on your own.
Initial role configuration (5-10 distinct roles with per-store scoping) typically takes 1-3 business days after the conversation in which we clarify who does what. Later adjustments (new role, new store, extra right) — quoted individually depending on complexity.
The list of positions from your org chart + a short description of what each one does + the map of stores. From there we propose the roles, the scoping and the layout. A best practice we apply from day one: per-store scoping from the very first day (not added later) and a quarterly review of the user list.
Yes. A "regional director" role receives the reporting and transfer-operation rights limited to their stores — two, three, five, as many as you assign. The third store (with no scoping toward it) does not appear in their UI and operations on it are refused.
The administrator can reset the password or unblock the account. All actions related to user management are a separate right ("user management"), granted only to the admin account. Unlock + reset are recorded in the audit log.
Scoping is done at the POS (point of sale) level, not by arbitrary geographic zones outside the POS hierarchy. If you want "sell only at register number 2 in the store", then that register has to be a distinct POS in the system. We clarify unusual cases at discovery.
No. The admin has no hidden "super-power" — the logs are immutable by design and their actions stay in the audit log exactly like any other user. Our recommendation: use the admin account only for real configuration, and handle daily operations on a manager account (with a smaller blast radius).
Chains with 2-10 stores that have already had incidents like "the cashier changed prices without me knowing" or "I have no idea who initiated that transfer". A granular setup prevents the incident, and the audit log solves it when one still shows up. See Large retail for the full profile.
The structures above reflect our standard offering, but every client is discussed individually. We adjust scope (how many roles, how many stores, which additional integrations), onboarding timelines and specific configurations to match your business. The final binding offer is the one in the written quote + the signed contract.
The multi-POS setup with granular RBAC and per-store scoping is part of the Standard package (up to 4 POS) or the Extra package (up to 10 POS). Role configuration at onboarding is included — we do the work, you just tell us who does what. Full comparison on the pricing page.
20 minutes on the phone — you tell us how many stores you have, how many employees, which operational roles you need. We propose the role structure + scoping + onboarding calendar. The initial consultation is free.
SGAPPS LABS SRL · Chișinău, Moldova · Continuously in production since 2018 · POS · ERP · MEV fiscal register · Android fleet