Bitta Retail POS guide

Supervisor operations

Supervisor PIN approvals for over-limit discounts and price overrides, drawer and over/short oversight, lock screen user switching, return permissions, and the attention queues for card, refund, print, and posting follow-up.

status: verified applies-to: 1.0.0.121rev: 3

Supervisors resolve the exceptions a cashier cannot: over-limit discounts, price overrides, returns, drawer variances, and stuck card or print jobs - while keeping the approval, money, and audit records linked. This page collects the supervisor-facing controls in one place.

Supervisor PIN approvals

When a change exceeds a cashier's authority, the supervisor authorization 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. PINs are validated server-side and stored salted and hashed, never in plain text.

Typical triggers:

  • A line or invoice discount above the cashier's cap, when supervisor over-limit approval is enabled in the discount policy.
  • A price override, for users without their own override permission.
  • A pricing profile switch on a profile configured to require approval.

Supervisor gating is a soft escape hatch, not a hard gate: hard floors (never below cost, minimum margin) can never be authorized past, by anyone. Thresholds, caps, floors, and reason-code requirements are configured in the pricing policy - see Discounts and price overrides and Pricing and discounts setup. PIN policy and permission sets are covered on Security, PINs, and lock screen.

NOTE

When reason codes are required, the reason and the approving supervisor are stamped together on the sale, giving a complete "who changed what price and why" trail.

Drawer oversight

Day-to-day cash discipline runs through shifts:

  1. Scan the POS Shifts list's Over/Short column for red values; drill into the Cash Movements count when a shift looks off. See Shifts.
  2. Review cash movements: Pay Out and Safe Drop always carry a reason code, No Sale rows attribute every drawer opening to a shift, terminal, and user, and all movement rows are immutable.
  3. Print an X report mid-shift for a live drawer health check; review the Z report and its differences after the close.
  4. Use Blind Close in POS Setup if counting users should not see expected amounts while counting, and the Over/Short Warning Threshold to surface large variances at close.

Lock screen and switching users

The register's Lock button (and idle auto-relock) covers the register with a full-screen PIN lock. Entering a different user's number and PIN is the switch-user path: the register changes hands without leaving the page, and the new cashier's identity drives sale attribution and discount permissions from that moment. On shared terminals, have cashiers switch via the lock screen so per-cashier stamping is correct from the first sale. Configuration is on Security, PINs, and lock screen.

Returns

Returns are gated to the BAA POS - Admin permission set. A plain cashier who taps Return gets a friendly "ask a manager" toast before anything opens. The whole flow - receipt-anchored entry, refund tenders, and refund recovery - is on Returns and refunds.

Attention queues

A few durable queues collect items that need a supervisor's follow-up:

  • Card transactions needing attention: the register reconciles in-flight card payments automatically at open; anything unresolvable is flagged on the POS card-transactions list for a supervisor to resolve. Reconcile pending card work first, before retrying anything else. See Card payments.
  • Refund recovery: a return whose card refund legs did not all capture stays open in Refund Recovery until each leg is retried, replaced, or confirmed - see Returns and refunds.
  • Print queue: failed receipts and kitchen output sit in the durable print queue for retry or cancel. A print retry never changes sale money - see Printers and hardware setup.
  • End of Day failures: failed consolidation groups are listed in the run summary; fix the named mapping and rerun - already-posted groups never post again. See End of day.

The POS admin role center's dashboard surfaces these as attention cues (including loyalty items such as refund recovery and reconciliation), so a morning glance at the role center catches anything left over from yesterday.

TIP

When correcting posted accounting, use reversal and credit processes - never record edits. The original sale, approval, reason, tender, refund, shift, and output records should stay linked as evidence.

// next step

Ready to try Bitta Retail POS?