QIIUB — Floating Shifts

Explained simply · sales-floating-shifts-cash-management · April 2026 · BCPOS

1. How it works today in RMH

In RMH the shift is called a Batch and it is tied to the register (terminal). When you open a batch on Register 1, everything that happens there belongs to Batch #47 — no matter who is operating it.

Key concept: In RMH, the batch belongs to the terminal, not the employee.

The problem: Maria works 8am–4pm and gets moved between terminals

Time	Register	Batch	Action on switch
8:00 – 10:30	Register 1	Batch #47	Close + count cash drawer
10:30 – 2:00	Register 5	Batch #48	Close + count cash drawer
2:00 – 4:00	Register 9	Batch #49	Close + count cash drawer

Result:

Maria has to close and count the cash drawer 3 times during her workday.
Reports show 3 separate over/short lines.
There is no way to see "how much did Maria sell today?" in a single place.
Cash responsibility is fragmented across 3 pieces.

The overnight-batch pain

RMH auto-creates the next batch when you close the previous one. If you close on Monday at 10pm, the new batch opens with Monday's date. But that batch is used all day Tuesday. When SAP/accounting reads the open date, it thinks the batch is Monday's. A familiar accounting headache.

2. How it works in QIIUB (Floating Shifts)

  Key concept: In QIIUB, the shift belongs to the employee, not the terminal. The terminal is just infrastructure — it's where things happen, not who is responsible.

Shift + ShiftSegment

Two new concepts:

Shift = Maria's full shift (8am–4pm). One shift for the whole day.
ShiftSegment = each chunk of time on a specific terminal. Records when she was on each terminal.

Same scenario, different outcome

RMH 3 separate batches

Batch #47 → Register 1 (8:00–10:30)

Batch #48 → Register 5 (10:30–2:00)

Batch #49 → Register 9 (2:00–4:00)

3 counts, 3 reports, 0 unified view

QIIUB 1 shift, 3 segments

Segment 1 → Terminal 1 (8:00–10:30)

Segment 2 → Terminal 5 (10:30–2:00)

Segment 3 → Terminal 9 (2:00–4:00)

1 count, 1 report, 1 owner

At the end of the day Maria counts once: "$347.50". The system expected $345.00. Over/short: +$2.50. One line in the report. One productivity view.

The overnight-batch fix

QIIUB has a BusinessDate field that is computed from the first sale of the shift (adjusted by the Location's BusinessDayEndTime). SAP/accounting reads BusinessDate, not OpenedAtUtc. Problem solved — the wall-clock time the shift opened no longer matters.

3. Cash drawer policies

Not every business handles the cash drawer the same way. QIIUB supports 3 policies per terminal:

Policy	How it works	Cash tracking	Typical industry
CarryDrawer	The cashier carries the cash drawer tray with them when they switch terminals. A single pool of cash.	At Shift level only	Supermarkets, retail, pharmacies, gas stations
FixedDrawer	The cash drawer stays fixed on the terminal. When the employee arrives or leaves, a handoff count is performed.	Per-segment snapshot (StartingCash / EndingCash)	High-volume chains, hardware stores, bars
NoDrawer	No physical cash drawer. The server carries their own cash, or the terminal is card-only.	None at terminal level. Server bank reconciled at close.	Restaurants (servers), kiosks, card-only terminals

The policy is configured per terminal (TerminalSetting.CashDrawerPolicy) with a default per location. Same schema, different behavior depending on the business.

4. What happens when they're offline?

This is the most interesting part of the design. QIIUB's POS is offline-first: each terminal has its own local database and can operate without internet.

Scenario: Maria moves to a terminal that is offline

Maria is on Terminal 1 (Shift open, Segment 1 active).
The manager tells her: "go to Terminal 5".
Terminal 5 is offline — it cannot see Maria's open shift.
Maria authenticates on Terminal 5 with her PIN.
Terminal 5 finds no open local shift → creates a new local shift.
Maria works normally. Sales are written to the local database.
When connectivity returns → sync uploads everything to the cloud.
The cloud detects: "there are 2 shifts for Maria, same location, overlapping times".
Automatic merge:
- The older shift (Terminal 1) is the canonical one.
- The Terminal 5 shift is marked as Merged (tombstone).
- Its sales, segments and cash movements are re-assigned to the canonical shift.
Final result: Maria has 1 shift with 2 segments, as if the disconnect never happened.

  Merge properties: idempotent (running twice yields the same result), auditable (recorded in AuditEntry), reversible (the merged shift is a tombstone, never deleted), and excludes Connector data (RMH/RMS don't float).

5. Existing customers on RMH/RMS — the Connector

  Important: Floating shifts only applies to customers on the new native QIIUB POS. Customers still on RMH or RMS connect through the Connector, and their data looks different in QIIUB.

How RMH data looks in QIIUB

The Connector translates each RMH batch into a QIIUB shift, but in a simple, 1:1 way:

RMH		QIIUB (via Connector)
1 Batch	→	1 Shift + 1 ShiftSegment
BatchStatus (bitmask)	→	ShiftStatus enum + IsBlindClose + IsExported
OpeningTime	→	OpenedAtUtc
CashierID	→	EmployeeId
RegisterID	→	CurrentTerminalId + ShiftSegment.TerminalId
(does not exist)	→	BusinessDate (computed from first sale)
(does not exist)	→	SourceSystem = ConnectorRMH, SourceId = "Batch#48"

Connector rules

What does NOT change for RMH/RMS customers

Their shifts are read-only in QIIUB — they cannot be edited from the portal.
No floating — each batch is still 1 shift = 1 terminal = 1 segment.
No offline merge — the Connector excludes these shifts from merge logic (SourceSystem != NativeQIIUB).
The segment's cash-drawer fields stay empty (RMH has no handoff concept).
If Maria works on 3 registers in RMH, they will remain 3 separate shifts in QIIUB.

What RMH/RMS customers DO gain in QIIUB

Corrected BusinessDate — the overnight-batch / SAP problem is gone.
Explicit fields instead of the bitmask — readable IsBlindClose, IsExported, Status.
Unified reports — their data lives alongside native-QIIUB customers in the same reports.
Traceability — SourceSystem and SourceId always identify where the data came from.
Migration path — when the customer migrates to the native POS, new shifts become floating automatically. Historical data is preserved as-is.

6. Closeout types

QIIUB supports 3 closeout patterns, configurable per location and terminal:

Type	What happens	Who counts	Final status
Full Close	The cashier sees the expected amount, counts the cash drawer, enters the actual amount.	The cashier	Closed
Blind Close	The POS hides the expected amount. The cashier counts blind and enters their count.	The cashier (without seeing expected)	Closed + IsBlindClose
Deferred Count (Bargain City pattern)	The cashier does NOT count at the terminal. The cash drawer goes straight to the safe. The manager counts later.	The manager (from the safe)	PendingCount → Closed

If a shift stays in PendingCount longer than MaxPendingCountHours (default: 24h), the system raises an alert.

7. Shift lifecycle

A shift can move through these states:

State	Meaning	Allowed transitions
Open	Employee actively working, can ring sales	Suspended, PendingCount, Closed, Voided
Suspended	On break or lunch. Can resume on the same or a different terminal.	Open (resume)
PendingCount	Blind closeout — cash drawer in the safe, awaiting manager count	Closed (manager counts)
Closed	Fully reconciled, close amount entered	Final state — does not change
Merged	Absorbed by another shift during offline reconciliation (tombstone)	Final state — does not change
Voided	Cancelled by manager — only allowed if it has zero transactions	Final state — does not change

Summary

RMH: the batch belongs to the terminal. 3 terminals = 3 batches = 3 counts.

Native QIIUB: the shift belongs to the employee. 3 terminals = 1 shift, 3 segments, 1 count.

RMH via Connector: each batch becomes 1 simple shift (read-only, no floating).
But they gain corrected BusinessDate, explicit fields, and unified reports.

Floating = once they migrate to the native QIIUB POS.

Companion: Technical diagrams (sales-floating-shifts-cash-management)