QIIUB — Floating Shifts

Explicado sencillo · sales-floating-shifts-cash-management · Abril 2026 · BCPOS

1. Cómo funciona hoy en RMH

En RMH el turno se llama Batch y está amarrado al registro (terminal). Cuando abres un batch en Register 1, todo lo que pase ahí es del Batch #47 — no importa quién esté operando.

Concepto clave: En RMH, el batch pertenece a la terminal, no al empleado.

El problema: María trabaja 8am–4pm y la mueven de terminal

Hora	Register	Batch	Acción al cambiar
8:00 – 10:30	Register 1	Batch #47	Cerrar + contar cash drawer
10:30 – 2:00	Register 5	Batch #48	Cerrar + contar cash drawer
2:00 – 4:00	Register 9	Batch #49	Cerrar + contar cash drawer

Resultado:

María tiene que cerrar y contar el cash drawer 3 veces durante su jornada.
En los reportes aparecen 3 líneas separadas de over/short.
No hay forma de ver "¿cuánto vendió María hoy?" en un solo lugar.
La responsabilidad del efectivo está fragmentada en 3 pedazos.

El dolor del batch nocturno

RMH auto-crea el batch cuando cierras el anterior. Si cierras el lunes a las 10pm, el nuevo batch abre con fecha del lunes. Pero ese batch se usa todo el martes. Cuando SAP/contabilidad lee la fecha de apertura, piensa que es del lunes. Dolor de cabeza contable que ya conocemos bien.

2. Cómo funciona en QIIUB (Floating Shifts)

  Concepto clave: En QIIUB, el turno (Shift) pertenece al empleado, no a la terminal. La terminal es solo infraestructura — es dónde pasan las cosas, no quién es responsable.

Shift + ShiftSegment

Dos conceptos nuevos:

Shift = el turno completo de María (8am–4pm). Uno solo para todo el día.
ShiftSegment = cada pedazo de tiempo en una terminal específica. Registra cuándo estuvo en cada terminal.

Mismo escenario, resultado diferente

RMH 3 batches separados

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 conteos, 3 reportes, 0 visión unificada

QIIUB 1 shift, 3 segmentos

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 conteo, 1 reporte, 1 responsable

Al final del día, María cuenta una sola vez: "$347.50". El sistema esperaba $345.00. Over/short: +$2.50. Una línea en el reporte. Una vista de productividad.

El fix del batch nocturno

QIIUB tiene un campo BusinessDate que se calcula a partir de la primera venta del turno (ajustado por BusinessDayEndTime del Location). SAP/contabilidad lee BusinessDate, no OpenedAtUtc. Problema resuelto — ya no importa a qué hora se abrió el turno.

3. Políticas de cash drawer

No todos los negocios manejan el cash drawer igual. QIIUB soporta 3 políticas por terminal:

Política	Cómo funciona	Tracking de efectivo	Industria típica
CarryDrawer	El cajero se lleva la bandeja del cash drawer cuando cambia de terminal. Un solo pool de efectivo.	A nivel de Shift únicamente	Supermercados, retail, farmacias, gasolineras
FixedDrawer	El cash drawer se queda fijo en la terminal. Cuando el empleado llega o se va, se hace un conteo de traspaso (handoff).	Snapshot por segmento (StartingCash / EndingCash)	Cadenas alto volumen, ferreterias, bares
NoDrawer	No hay cash drawer físico. El mesero carga su propio efectivo, o es terminal de tarjeta solamente.	Ninguno en terminal. Fondo del mesero al cierre.	Restaurantes (meseros), kioscos, terminales solo tarjeta

La política se configura por terminal (TerminalSetting.CashDrawerPolicy) con un default por location. El mismo schema, diferente comportamiento según el negocio.

4. ¿Qué pasa cuando están offline?

Esto es lo más interesante del diseño. El POS de QIIUB funciona offline-first: cada terminal tiene su base de datos local y puede operar sin internet.

Escenario: María se mueve a una terminal que está offline

María está en Terminal 1 (Shift abierto, Segment 1 activo).
El manager le dice: "andá a Terminal 5".
Terminal 5 está sin conexión — no puede ver el shift abierto de María.
María se autentica en Terminal 5 con su PIN.
Terminal 5 no encuentra shift abierto local → crea un shift local nuevo.
María trabaja normalmente. Las ventas se graban en la base local.
Cuando se restablece la conexión → sync sube todo al cloud.
El cloud detecta: "hay 2 shifts de María, misma location, tiempos traslapados".
Merge automático:
- El shift más viejo (Terminal 1) es el canónico.
- El shift de Terminal 5 se marca como Merged (tombstone).
- Sus ventas, segmentos y movimientos de efectivo se re-asignan al shift canónico.
El resultado final: María tiene 1 shift con 2 segmentos, como si nunca hubiera habido desconexión.

  Propiedades del merge: Idempotente (ejecutar 2 veces = mismo resultado), auditable (queda en AuditEntry), reversible (el shift merged es un tombstone, nunca se borra), y excluye datos del Connector (RMH/RMS no flotan).

5. Clientes existentes con RMH/RMS — el Connector

  Importante: Floating shifts solo aplica para clientes con el nuevo POS nativo de QIIUB. Los clientes que siguen usando RMH o RMS se conectan vía Connector, y sus datos se ven diferente en QIIUB.

Cómo se ven los datos de RMH en QIIUB

El Connector traduce cada batch de RMH a un shift de QIIUB, pero de forma simple y 1:1:

RMH		QIIUB (via Connector)
1 Batch	→	1 Shift + 1 ShiftSegment
BatchStatus (bitmask)	→	ShiftStatus enum + IsBlindClose + IsExported
OpeningTime	→	OpenedAtUtc
CashierID	→	EmployeeId
RegisterID	→	CurrentTerminalId + ShiftSegment.TerminalId
(no existe)	→	BusinessDate (calculado de primera venta)
(no existe)	→	SourceSystem = ConnectorRMH, SourceId = "Batch#48"

Reglas del Connector

Lo que NO cambia para clientes RMH/RMS

Sus shifts son read-only en QIIUB — no se pueden editar desde el portal.
No hay floating — cada batch sigue siendo 1 shift = 1 terminal = 1 segmento.
No hay merge offline — el Connector excluye estos shifts de la lógica de merge (SourceSystem != NativeQIIUB).
Los campos de cash drawer del segmento quedan vacíos (RMH no tiene concepto de handoff).
Si María trabaja en 3 registros en RMH, seguirán siendo 3 shifts separados en QIIUB.

Lo que SI ganan los clientes RMH/RMS en QIIUB

BusinessDate corregido — se acabó el problema del batch nocturno con SAP.
Campos explícitos en vez del bitmask — IsBlindClose, IsExported, Status legibles.
Reportes unificados — sus datos conviven con los de clientes nativos QIIUB en los mismos reportes.
Trazabilidad — SourceSystem y SourceId siempre identifican de dónde vino el dato.
Camino de migración — cuando el cliente migre al POS nativo, sus shifts nuevos serán floating automáticamente. Los históricos se conservan como están.

6. Tipos de cierre

QIIUB soporta 3 patrones de cierre, configurables por location y terminal:

Tipo	Qué pasa	Quién cuenta	Status final
Full Close	El cajero ve el monto esperado, cuenta el cash drawer, ingresa el monto real.	El cajero	Closed
Blind Close	El POS oculta el monto esperado. El cajero cuenta a ciegas e ingresa su conteo.	El cajero (sin ver esperado)	Closed + IsBlindClose
Deferred Count (patrón Bargain City)	El cajero NO cuenta en la terminal. El cash drawer va directo a la caja fuerte. El manager cuenta después.	El manager (desde la caja fuerte)	PendingCount → Closed

Si un shift queda en PendingCount más de MaxPendingCountHours (default: 24h), el sistema genera una alerta.

7. Ciclo de vida del shift

Un shift puede pasar por estos estados:

Estado	Significado	Transición posible
Open	Empleado trabajando activamente, puede hacer ventas	Suspended, PendingCount, Closed, Voided
Suspended	En break o almuerzo. Puede resumir en la misma o diferente terminal.	Open (resume)
PendingCount	Blind closeout — cash drawer en la caja fuerte, pendiente que el manager cuente	Closed (manager cuenta)
Closed	Totalmente reconciliado, monto de cierre ingresado	Estado final — no cambia
Merged	Absorbido por otro shift durante reconciliación offline (tombstone)	Estado final — no cambia
Voided	Cancelado por manager — solo si tiene cero transacciones	Estado final — no cambia

Resumen

RMH: el batch pertenece a la terminal. 3 terminales = 3 batches = 3 conteos.

QIIUB nativo: el shift pertenece al empleado. 3 terminales = 1 shift, 3 segmentos, 1 conteo.

RMH vía Connector: cada batch se traduce a 1 shift simple (read-only, sin floating).
Pero ganan BusinessDate corregido, campos explícitos, y reportes unificados.

Floating = cuando migran al POS nativo de QIIUB.

Companion: Diagramas técnicos (sales-floating-shifts-cash-management)