Qiiub

System Overview

How all the pieces of QIIUB connect together

☁️
QIIUB Cloud
Central API, databases,
device management (Azure)
internet
⚙️
Admin Portal
Partners, merchants,
devices, infrastructure
🌐
Merchant Portal
Products, inventory,
reports, settings
📱
Mobile App
Approve orders, receive
inventory, counts
auto sync
🛒
QIIUB POS
New POS terminals
work offline, always
📥 Legacy migration: Existing RMH/RMS stores import data once via the Import Tool (see RMH → QIIUB tab)
Key Points
Cloud-first: Build the cloud backend first. Import existing store data via the import tool. No need to wait for the new POS app.
Offline-first: POS terminals work without internet. Sales never stop. Data syncs when connectivity returns.
Zero-risk migration: Stores import one at a time. Existing POS software keeps running until cutover.
One platform, 3 verticals: Shop, Pharmacy (Rx), Hardware (Build) — same system, all 26 modules included.

Data Flow

How data moves from the store to the cloud and back

Sale Recorded at POS → Cloud
🛒
Cashier
Rings up sale on POS terminal
→
📦
Local DB
Saved instantly to SQLite on the terminal
→
🔄
Sync Service
Background service detects new data
→
☁️
Cloud API
Receives sale via REST API
→
🗄️
Merchant DB
Stored in merchant's cloud database
Price Change from Portal → POS
🌐
Admin
Changes price in Web Portal
→
☁️
Cloud API
Updates merchant database
→
📡
IoT Hub
Sends "sync now" signal to all terminals
→
🔄
Sync Service
Pulls updated price from API
→
🛒
POS Terminal
New price is active at next sale
What Happens When Internet Goes Down?
✅
Sales continue
POS reads/writes local database. No internet needed.
⏳
Data queues up
Sync service stores changes locally until connection returns.
🔄
Auto-resumes
When internet returns, everything syncs automatically. No manual steps.

Database Architecture

Where the data lives and how it stays isolated

Three Layers of Data Storage

🗄️ Central Database

One instance — shared by the platform
  • • Partner registry (channel partners, house partner)
  • • Merchant registry (who are our customers, PartnerId FK)
  • • Users & login credentials (merchant users + partner users)
  • • Module activation (all 26 modules included per merchant)
  • • Device registration (POS terminals)
  • • Group Loyalty (cross-company rewards)
  • • System audit log (MerchantId + PartnerId scoped)

🗄️ Merchant Database(s)

One or more — operational POS data
  • • Products & pricing
  • • Sales & transactions
  • • Customers
  • • Inventory & purchase orders
  • • Employees & shifts
  • • Gift cards, A/R, promotions

📦 Local SQLite

One per POS terminal — offline copy
  • • Full copy of products & prices
  • • Customers for lookup
  • • Pending sales (not yet synced)
  • • Sync queue & metadata
How 500 Pharmacies Are Organized

Multiple merchant databases by region

Large groups like a pharmacy cooperative can be split across multiple databases for performance. Each pharmacy's data stays isolated by MerchantId. The system routes to the correct database automatically.

Azure SQL Server (qiiub-sql.database.windows.net) ├── QIIUBCentral ← platform registry (all merchants) ├── QIIUB_PR_Pharmacy_Metro ← ~200 pharmacies (San Juan area) ├── QIIUB_PR_Pharmacy_North ← ~150 pharmacies (north/west) ├── QIIUB_PR_Pharmacy_South ← ~150 pharmacies (south/east) ├── QIIUB_US_Retail ← retail merchants (US mainland) └── QIIUB_Capri ← dedicated (large client)
How do you query across databases?
Individual merchant reports work normally (single DB). For cross-database analytics (e.g., "top OTC products across all 500 pharmacies"), data is aggregated into a dedicated Analytics Database. See below.
Analytics Database — Cross-Merchant Reporting
🗄️
Pharmacy Metro
🗄️
Pharmacy North
🗄️
Pharmacy South
↓ ↓ ↓
Scheduled ETL (hourly/nightly)
↓
📊
QIIUB_Analytics
Pre-aggregated data from all merchant DBs
Read-only — never used by POS operations
Why a separate database?
Azure SQL cannot JOIN across databases. Analytics queries are also heavy — running them on operational DBs would slow down POS terminals.
Who uses it?
Web Portal dashboards, cooperative admins, platform-level insights. Each user only sees data they're authorized for (merchant, group, or platform scope).

System Modules

One platform, 3 verticals — all 26 modules included for every merchant, no per-module licensing

Core Modules (20 — included for every merchant)
core
Product Catalog
Products, categories, barcodes, pricing
core
Sales & Transactions
POS sales, returns, receipts
core
Customer Management
Customer records, history
core
Employee Management
Staff, roles, PIN login, time tracking
core
Tax Configuration
Tax rates, rules by location
core
Payment Methods
Cash, card, check, account charge
core
Shift Reconciliation
Open/close shifts, cash counting
core
Orders & Quotes
Quotes, layaway, back orders, work orders
core
Reports & Analytics
Sales, inventory, employee reports
core
Stock Management
Levels, adjustments, counts
core
Purchase Orders
PO, receiving, distribution
core
Transfers
Inter-location transfers
core
Gift Cards
Issue, redeem, balance tracking
core
Multi-Currency
Exchange rates, dual display
core
Accounts Receivable
Charge accounts, statements
core
Loyalty Program
Points earn/redeem per merchant
core
Group Loyalty
Cross-company shared rewards
core
Promotions
%, fixed, BXGY, coupons
core
Label Printing
ZPL/TSPL, barcode labels
Vertical Modules (6 — activated by IndustryTemplate)
Pharmacy (Qiiub Rx)
pharmacy
Rx Dispensing
Prescription tracking
pharmacy
Controlled Substances
DEA compliance, tracking
pharmacy
Insurance / PBM
Claims, copay processing
Hardware (Qiiub Build)
hardware
Cut-to-Length
Lumber, wire, bulk cutting
hardware
Tool Rental
Rental tracking, returns
hardware
Job Accounts
Contractor job billing

Communication Channels

Who talks to whom and how

All Communication Paths
FromToChannelWhat For
Admin PortalCloud API HTTPS Partner management, merchant boarding, device registry, sync monitoring (/v1/platform/*, /v1/partner/*)
Merchant PortalCloud API HTTPS Products, sales, inventory, customers, employees, reports, settings (/v1/*)
Mobile AppCloud API HTTPS PO approval, receiving, stock counts
POS Sync ServiceAzure IoT Hub IoT Hub Receive "sync now" commands, report status, get config updates
POS Sync ServiceCloud API HTTPS Push sales data, pull product/price updates (bulk transfers)
POS ApplicationLocal SQLite Local All POS operations (sales, lookups). Never touches the network.
POS Sync ServiceLocal SQLite Local Read pending sales to push, write incoming updates from cloud
Cloud APICentral DB + Merchant DB(s) Internal All database operations. API is the only thing that touches the cloud databases.
Important Rules
POS never calls the cloud. It only reads/writes local SQLite. The Sync Service handles all network communication in the background.
Import tool for legacy data. Existing RMH/RMS stores migrate via a one-time import tool (ADR-0038). No active connector — data is imported once, then the store runs on QIIUB.
Two channels to the cloud. IoT Hub for quick signals ("sync now"). REST API for bulk data (products, sales). Both are always encrypted.
Every merchant's data is isolated. MerchantId on every row, Row-Level Security in the database, and filters in every query. No merchant can see another's data.

RMH → QIIUB Concept Mapping

Where familiar RMH concepts live in the new platform

Main Entities
RMH ConceptQIIUB EquivalentWhat Changed
Item (85 columns)→Product + ProductBarcode + ProductPriceOne monolith table split into focused entities. Prices support multiple tiers. Barcodes are a separate list (unlimited per product).
ItemClass + Dimension→ProductOption + ProductVariantMatrix items (Size/Color) are now proper option sets with variant combinations. No more Title1/Title2/Title3 columns.
Alias→ProductBarcodeAlternate barcodes stored in the same barcode table. Type auto-detected.
Department + Category→Category (hierarchical)Both merged into a single parent-child category tree. Unlimited depth.
Supplier→Supplier + ProductSupplierMostly the same. Products can now have multiple suppliers (junction table).
Customer (63 columns)→Customer + CustomerAddressAddress split out. PriceLevel (0-3) maps to a PriceTier. Lifetime stats tracked separately.
Transaction + TransactionEntry + TaxEntry→Sale + SaleLineItem + SaleTaxSame concept, cleaner structure. Tax captured per line. TransactionType determines SaleType.
TransactionHold→Sale (Status = Held)No separate hold table. A held transaction is a Sale with Status=Held. If cancelled, the Sale row is soft-deleted (IsDeleted=true) — the Sale number is consumed, same as RMH consuming a TransactionHold number on cancel.
TenderEntry→SalePaymentTenderType maps to a PaymentMethod lookup. Split-tender supported natively.
Batch (38 columns)→Shift + ShiftCountBatch = Shift. TenderDeclaration columns exploded into ShiftCount rows per payment method.
Cashier→Employee + EmployeeRoleCashiers and SalesReps merged into one Employee entity with role-based assignment.
SalesRep→Employee + EmployeeRoleSame person can have multiple roles (Cashier + SalesRep + Manager).
Register→TerminalSame concept. Register.ID = Terminal.Code.
Tax (74 columns!)→TaxGroup + TaxRateOne row with 8 embedded rate slots normalized into a TaxGroup with up to 8 TaxRate rows.
Store→LocationSame concept, new name. Supports multi-location natively.
PurchaseOrder→PurchaseOrder + PurchaseOrderLineSame flow but with full Receipt → Distribution pipeline. Mobile approval.
Quantity (on Item)→LocationProduct.QuantityOnHandStock tracked per location, not on the item. Movements create an audit trail.
RMH Central Manager + Store Manager→Admin Portal + Merchant PortalBoth desktop apps replaced by two browser-based portals. Admin Portal (qiiub-admin) for partner/merchant boarding and infrastructure. Merchant Portal (qiiub-portal) for products, sales, inventory. No VPN needed. Accessible from anywhere.
What's New in QIIUB (no RMH equivalent)
Offline-First Sync
Each terminal has a local database and syncs automatically. RMH required constant network to the store server.
Multi-Tenancy
One cloud platform serves all customers. Each merchant's data is fully isolated. RMH was one database per store.
Group Loyalty
Shared loyalty rewards across different companies owned by the same business. Phone-based identity.
Accounts Receivable
Charge accounts, ledger, statements, finance charges. RMH had limited A/R (basic charge account only).
Vertical Modules
Shop, Pharmacy (Rx), Hardware (Build) — all modules included. RMH was retail-only.
Mobile App
PO approval, receiving, stock counts from a phone. RMH required the desktop for everything.
Migration Path
🏪
RMH Store
Existing store data
→
📥
Import Tool
One-time data migration
→
☁️
Cloud + Portal
Manage from anywhere
→
🛒
QIIUB POS
When ready, per store
Each step is independent. Import runs once per store. No big-bang migration.