| POS-CASH-001 | Cash dropA cash drop is the withdrawal of cash from the register drawer to a safe or deposit during the shift, to reduce the amount of cash on hand. It reduces the expected cash in the drawer for the batch. It is one of three cash-movement features (with Paid in, POS-CASH-002, and Paid out, POS-CASH-003) that share a common permission and reason model. | CASH | v1 | should | proposed | JF | JF-F_07 |
| POS-CASH-002 | Paid inPaid in is the entry of cash into the register drawer that is not a sale (e.g. adding change, returning a float). It increases the expected cash in the drawer for the batch. It is one of three cash-movement features (with Cash drop, POS-CASH-001, and Paid out, POS-CASH-003) that share a common permission and reason model. | CASH | v1 | should | proposed | JF | JF-F_08 |
| POS-CASH-003 | Paid outPaid out is the removal of cash from the register drawer that is not a sale (e.g. paying a small expense or vendor in cash). It reduces the expected cash in the drawer for the batch. It is one of three cash-movement features (with Cash drop, POS-CASH-001, and Paid in, POS-CASH-002) that share a common permission and reason model. | CASH | v1 | should | proposed | JF | JF-F_09 |
| POS-CASH-007 | Mid-shift countThe mid-shift count is a cash count performed during the shift without closing the batch, used to verify the drawer (a control check). It compares the counted amount against the expected cash and shows the difference, but it does not affect the batch or its totals — the batch continues unchanged. | CASH | v2 | could | proposed | JF | JF-F_11 |
| POS-CASH-009 | Automated cash drop alertThe automated cash drop alert notifies staff when the cash in the drawer exceeds a configured threshold, prompting (or requiring) a cash drop (POS-CASH-001) to reduce cash on hand. The amount evaluated against the threshold is the shift's accumulated cash excluding the starting float — i.e. cash sales + paid in − paid out − cash drops, not counting the opening float (POS-SHIFT-019), since the opening float is not money to be safeguarded. | CASH | v1 | could | proposed | JF | JF-F_10 |
| POS-CASH-010 | Integrated card reconciliationIntegrated card reconciliation auto-fills the counted card amounts at reconciliation using the settlement from the payment processor, based on what was recorded in the batch summary, instead of the cashier entering them manually. A key consideration: not all stores close a batch per cashier — some close the settlement at the end of day rather than per cashier/shift — so the settlement level is configurable. When the settlement is done per batch, the system compares settlement vs recorded and shows the difference. | CASH | v2 | should | proposed | JF | JF-F_15 |
| POS-CASH-011 | Cash drawer securityCash drawer security controls and monitors every interaction with the physical cash drawer at each POS register. The cash drawer is a lockable tray that holds physical cash; it can be opened automatically by the system (e.g. when a cash sale completes) or manually by a user with no associated transaction. Every opening is tracked. This spec owns the security-policy layer for the drawer: drawer-open tracking, No Sale monitoring and thresholds, and cash over/short discrepancy tracking and alerts. | CASH | v1 | must | proposed | JF | JF-J_05 |
| POS-CFG-013 | Training modeTraining mode is a Settings feature that puts one or more POS terminals into a practice mode. In training mode the entire POS works exactly the same — sales, layaways, returns, quotes, work orders, holds, discounts, voids — but nothing affects real inventory, real transaction records, real reports, or any live business data. New cashiers are routed to training before they get live access, and a Qiiub Certificate is issued on completion. Training mode is configured per terminal and persists across restarts. Receipts printed in training mode carry a visible watermark so they cannot be confused with real receipts. | CFG | v2 | must | proposed | AF | AF-F_18, AF-A_05 |
| POS-CFG-014 | Emergency Mode (offline, cash-only)Emergency Mode is the state the Qiiub POS automatically enters when a terminal (the physical register running the POS) loses its connection to the Qiiub cloud. The goal is to let the store keep selling even with no connectivity, while clearly limiting the POS to what can be done safely offline. | CFG | v1 | must | proposed | GFD | GFD-F_08 |
| POS-CFG-015 | Sequential numbering per terminal with unique prefix (conflict-free)This is the numbering scheme that gives every sale/transaction (and its receipt) a globally unique ID, so that records never collide — even when multiple terminals are selling offline at the same time and cannot coordinate through the cloud. | CFG | v1 | must | proposed | GFD | GFD-F_09 |
| POS-CFG-016 | Configurable tenders by businessEach business (tenant) can independently configure which payment tenders are active and visible at its POS. This configuration is done by the tenant admin or business owner in the backoffice admin panel — not at the POS, and not by a manager or cashier. Configuration applies at the business level, not per register or per cashier. Disabled tenders are completely hidden from the cashier's payment modal — they do not appear as grayed-out or locked options. Changes take effect immediately across all active registers. In-progress transactions are not interrupted when a configuration change is made. | CFG | v1 | must | proposed | AB | AB-B_13 |
| POS-CFG-017 | Par level controlPar level control monitors inventory quantities for items designated as "controlled" — items that require a minimum stock level to be maintained at all times (e.g. controlled substances in a pharmacy, high-value items, or critical operational supplies). The tenant admin sets a par level (minimum threshold) per item per location. When an item's available stock drops to or below its par level, the system generates an automatic alert to the store manager and/or backoffice, prompting a replenishment order. | CFG | v2 | must | proposed | AB | AB-B_39 |
| POS-CFG-018 | Tenders per userTenders per user is a back-office Settings feature that controls which payment methods ("tenders") each cashier can see and use at the POS terminal. The configuration is attached to the user account — not to a specific terminal — so it follows the cashier regardless of which register they operate. | CFG | v1 | must | proposed | AF | AF-A_01 |
| POS-CFG-019 | Tax holidaysTax Holidays is a back-office Settings feature that lets the administrator or manager configure periods during which the IVU (Puerto Rico sales and use tax) is waived for selected product categories or individual items. The system activates and deactivates the exemption automatically based on the configured date range, and the administrator or manager can manually force it on or off at any time, overriding the schedule. When a Tax Holiday is active, the cashier takes no action — the POS automatically applies 0% IVU to qualifying items during the sale. | CFG | v1 | must | proposed | AF | AF-A_03 |
| POS-CFG-020 | Remote supportRemote support integrates a remote support access tool directly into the POS interface. A partner logo is displayed at all times in the lower-left corner of the POS screen, next to the "Built by BCPOS" label. When a user taps the logo, the POS automatically creates a remote support session in the background — no code copying, no browser required. The support technician sees the session appear in their panel and connects. Each partner (reseller or support provider) configures their own logo, name, and support URL from the back office. | CFG | v2 | must | proposed | AF | AF-A_07 |
| POS-CFG-021 | Kiosk modeKiosk mode is a Settings feature that restricts a cashier's ability to exit the POS application and access the underlying operating system. When kiosk mode is active, the POS runs full-screen and the cashier cannot switch to other applications or access system settings without the administrator. Kiosk mode is configured at two independent levels: per terminal (all non-admin cashiers on that terminal are restricted) and per cashier (that cashier is restricted on any terminal). The administrator is never subject to kiosk-mode restrictions. | CFG | v2 | must | proposed | AF | AF-A_08 |
| POS-CUST-002 | Customer lookupCustomer lookup lets a cashier identify a customer and attach them to the current sale directly from the POS. It is the gateway to sale, AR, loyalty, and work-order flows: one screen finds a customer (or deliberately proceeds without one) and immediately launches an action against that customer. Identification runs through a single universal search bar that searches several customer fields at once, plus dedicated fast paths for scanning a QR code from the customer's mobile app and scanning a Real ID. The selected result expands inline with its actions, so the cashier never navigates away to a separate screen. | CUST | v1 | must | proposed | GFD | GFD-D_01, GFD-F_01, GFD-D_05, GFD-D_11 |
| POS-CUST-007 | Customer 360 drawerThe Customer 360 drawer is a side panel that opens over the POS — without taking the cashier out of the active sale — to show the full customer context in one place: loyalty points, store credit, AR (accounts receivable), layaways, holds, overdue invoices, recent transactions, and favorites. It is a read + action view: the cashier both reviews the customer's information and takes actions on it (register an AR payment, create a layaway or installment, resume a hold, add a favorite to the cart). It unifies in a single panel what the reference POS spreads across several screens. A partial shell of this drawer already exists (this spec expands POS-CUST-007 from "Abrir drawer de cliente" to the full Customer 360 drawer). Consolidates Phase 2 GFD-F_02 + GFD-D_08 (merged per audit CONFLICT 1). | CUST | v1 | must | proposed | GFD | GFD-D_08, GFD-F_02 |
| POS-CUST-008 | Create customer from the POSCreate customer from the POS lets a cashier register a brand-new customer directly at the register, normally in the middle of a transaction, without leaving the sales flow. It is triggered automatically when a customer lookup (POS-CUST-002) finds no match, and is also available at any time through a dedicated "New customer" / "+ Crear cliente nuevo" button. The form is designed not to slow the cashier: only the required fields are visible, with optional data collapsed. The email is the central field — it is the channel that brings the customer into the Qiiub app and validates QIIUB Rewards. On creation, the new customer is automatically attached to the current sale. | CUST | v1 | must | proposed | GFD | GFD-D_02, GFD-F_03 |
| POS-CUST-009 | Edit customer (role-restricted)Edit customer lets an authorized user modify an existing customer's details from their customer card, opened from the lookup (POS-CUST-002). The action is permission-restricted: contact data versus money/price-affecting fields are governed by role, and every successful edit is recorded in the POS audit log. Consolidates Phase 2 GFD-F_04 + GFD-D_03 (merged per audit CONFLICT 1). | CUST | v1 | must | proposed | GFD | GFD-D_03, GFD-F_04 |
| POS-CUST-010 | Customer purchase historyCustomer purchase history shows an authorized user a list of a customer's past transactions, opened from the customer card in the lookup (POS-CUST-002). It opens with a summary header (total spent, number of purchases, average ticket, last purchase), a search/filter bar, and collapsible per-transaction rows. Its standout action is "Devolver" (Recall for Return), which pulls an exact past transaction — items and original prices — so a return can be started without manual typing. Consolidates Phase 2 GFD-F_05 + GFD-D_04 (merged per audit CONFLICT 1). | CUST | v1 | must | proposed | GFD | GFD-D_04, GFD-F_05 |
| POS-CUST-013 | Customer credit limit enforcementCustomer credit limit enforcement governs paying with store credit — an in-house "buy now, pay later" account (a receivable owed to the store, the same account the in-session set calls AR; charge-to-account is POS-PAY-011), not a bank card or external loan. Store credit appears as a payment method in the checkout payment modal alongside cash and card. Each customer has a credit limit, and the POS enforces it in real time: available credit = credit limit − outstanding balance. When a charge would cross the limit, an enforcement modal opens at tender, shows all the math, and offers a way forward instead of a dead block. Consolidates Phase 2 GFD-F_06 + GFD-D_06 (merged per audit CONFLICT 1). | CUST | v1 | must | proposed | GFD | GFD-D_06, GFD-F_06 |
| POS-CUST-014 | Sales rep lookupSales rep lookup is a picker that opens from a transaction to assign a salesperson (sales rep / "vendedor") to the sale, so the sale can be credited for commissions and performance reporting. The assignment happens at the start of the sale and feeds commissions and the Cashier Performance Summary. Whether the rep is a separate employee or simply the cashier depends on the store's configuration, and whether assigning a rep is required is likewise store-configurable. A single transaction can carry more than one rep for commission splits. Consolidates Phase 2 GFD-F_07 + GFD-D_07 (merged per audit CONFLICT 1). | CUST | v1 | must | proposed | GFD | GFD-D_07, GFD-F_07 |
| POS-CUST-015 | Dual notification at AR limitWhen the current purchase would cause the customer to exceed their AR (store-credit) limit, the POS blocks charging to AR and notifies both parties at once: the cashier in the POS and the customer in their app. "Dual" means the two notifications fire together. This is the notification/alert layer over the credit-limit enforcement defined for credit limit (POS-CUST-013); "AR" here equals "store credit" there. | CUST | v2 | must | proposed | GFD | GFD-D_09 |
| POS-CUST-016 | Quick action buttons (Sale + WO)Quick action buttons that appear in the Customer 360 header (POS-CUST-007) once a customer is selected, letting the cashier start a flow with that customer in one tap. The buttons are "Sale" and "WO" (Work Order). A "Quote" button was considered but is not part of this functionality. | CUST | v1 | must | proposed | GFD | GFD-D_12 |
| POS-CUST-017 | Customer receipt journalA journal showing the history of all the customer's receipts / transactions. It is reached via its own button in the Customer 360 header (POS-CUST-007), which opens a separate view — it is not one of the five Customer 360 tabs (those remain Points, AR, Layaways, Holds, Favorites). From a receipt, the cashier can view detail, resend by email / SMS, and initiate a return. It is conceptually related to customer purchase history (POS-CUST-010), but that one is role-restricted and read-only, whereas this receipt journal is cashier-accessible and action-capable (resend, return). | CUST | v1 | must | proposed | GFD | GFD-D_13 |
| POS-CUST-018 | Subscribe & SaveSubscribe & Save is a recurring purchase subscription — a standing subscription that repeats a purchase on a schedule. The end-to-end behavior (what is subscribed, discount or not, billing, payment method, cancellation) is not yet defined. | CUST | v3 | could | proposed | GFD | GFD-D_14 |
| POS-CUST-019 | Virtual queueA virtual queue ("turno digital") that customers join remotely instead of standing in line. In the captured design, the customer joins by WhatsApp (messaging the business number) (WhatsApp when enabled per ADR-0094; email/SMS/app otherwise) and receives a turn number plus a notification when their turn is getting close. The queue is fully automatic — no manual calling by staff. | CUST | v3 | could | proposed | GFD | GFD-D_15 |
| POS-CUST-020 | Product arrival notificationA waitlist with automatic arrival notification: a customer signs up for an out-of-stock product's waitlist from the app, and when the product's inventory goes from 0 to greater than 0 (stock arrives), the system automatically notifies the customer via WhatsApp (WhatsApp when enabled per ADR-0094; email/SMS/app otherwise). | CUST | v2 | could | proposed | GFD | GFD-D_16 |
| POS-DISC-009 | Price overrideThis spec expands the existing ceiling row for role-gated price editing of a cart line — a price override that relates directly to the manager override workflow (POS-SESS-006). Qiiub makes the price editable inline by tapping it, always shows the allowed range ("entre $X y $Y"), gates the action by role with managerial override and remote approval, warns (via AI) if the price drops below cost, marks the line with an icon when changed, and saves the reason for audit. | DISC | v1 | must | proposed | AF | AF-F_05 |
| POS-DISC-011 | Real-time upsellReal-time upsell encourages a larger basket by showing, in real time, how close the customer is to a discount threshold. A progress bar shows "te faltan $X para Y% dto" (you need $X more for a Y% discount), and the AI suggests a specific item that would reach the threshold. The discount applies automatically once the threshold is reached. A supervisor analytic identifies cashiers who never upsell. | DISC | v2 | must | proposed | AF | AF-F_20 |
| POS-DISC-012 | Discount controls and approval workflowThe discount controls and approval workflow govern how discounts are applied in the Qiiub POS. It defines who is authorized to apply discounts of various sizes, what limits exist per transaction and per day, how price overrides are constrained, and how the system monitors and alerts on excessive discounting. The goal is to prevent unauthorized discounting, protect margins, and give managers real-time visibility into discount patterns. | DISC | v1 | must | proposed | JF | JF-J_03 |
| POS-DISC-013 | Accumulated discount limit per shift or dayThe accumulated discount limit caps the total dollar value of discounts a cashier may apply across all transactions during a single shift or business day. The limit is a fixed dollar amount; the POS keeps a running total of every discount the cashier applies and blocks any further discount once the accumulated total would reach or exceed the limit. A blocked discount can only proceed via a manager override, performed from the manager's own device/session — the manager does not come to the cashier's register. Approved overrides count toward the running total (they do not reset the counter). The counter resets automatically at the start of each new shift or day. All blocks and overrides are logged in a full audit trail. | DISC | v1 | must | proposed | AB | AB-B_15 |
| POS-HOLD-001 | Hold — paused salesHold — Ventas en Pausa (Hold — Paused Sales) lets a cashier pause an active sale, save it with a name, and retrieve it later from any POS terminal to complete the transaction. This handles interruptions — a customer who needs to take a phone call, or a second customer ready to pay — without abandoning the in-progress sale. The Z Report (end-of-day report) automatically cancels all holds that were not completed, releasing the reserved inventory. | HOLD | v1 | must | proposed | AF | AF-A_04 |
| POS-HW-010 | Customer identification on the CFDCustomer identification on the CFD lets a customer identify themselves at the POS terminal using the Customer-Facing Display (the customer-side screen, POS-HW-011) without any intervention from the cashier. The system supports three identification methods: phone-number entry, QR-code scan, and NFC tap. Upon successful identification, the customer's profile, loyalty points balance, and loyalty tier are loaded automatically. Points are credited to the customer's account when the sale is completed (loyalty enrollment, POS-LOY-003). | HW | v2 | must | proposed | AF | AF-A_09 |
| POS-HW-011 | Customer-facing displayThe Customer-Facing Display (CFD) is a secondary screen oriented toward the customer during a POS transaction. It can be the customer-facing screen on a PAX payment terminal or a separate standalone touch display. The CFD shows the sale in real time as items are added, displays a summary at sale completion (including loyalty points earned), shows a customizable idle screen when no sale is active, and supports customer interaction (identification, digital signature, tip selection, age verification) when a touch screen is available. | HW | v2 | must | proposed | AF | AF-A_10 |
| POS-HW-012 | Real IDReal ID is a POS feature that lets the cashier scan the back of a customer's driver's license or government-issued ID using the POS barcode scanner. The scanner reads the PDF417 two-dimensional barcode present on all U.S. and Puerto Rico driver's licenses. The system parses the barcode data (following the AAMVA standard) and uses it to: (1) automatically create or update a customer profile with no manual typing required, (2) verify the customer's age for restricted-item sales (alcohol, tobacco, and other age-restricted products), (3) detect expired licenses, and (4) maintain a verification log for audit purposes. The customer's date of birth, once verified, is stored in their profile so that repeat visitors do not need to present their license again unless required by re-verification rules. | HW | v2 | must | proposed | AF | AF-A_11 |
| POS-HW-013 | Employee tabletThe Employee Tablet gives store staff a mobile interface (on a tablet) to look up real-time inventory across all of the tenant's locations — from the sales floor or stockroom, without returning to the POS register. Beyond viewing stock, staff can initiate inventory transfer requests and item reservations directly from the tablet, enabling faster service without tying up a register. | HW | v2 | must | proposed | AB | AB-B_47 |
| POS-HW-014 | AI produce recognition — camera detects fruits and vegetablesAI produce recognition uses a camera integrated with the POS to automatically identify fresh fruits and vegetables placed on the checkout scale or counter, without the cashier manually looking up a PLU code. When a produce item is placed under the camera, the AI model identifies it (e.g., "Green apple," "Roma tomato," "Plantain"), and the POS looks up the correct PLU, fetches the price per unit or per pound, and adds it to the cart. This speeds up produce-heavy checkout and reduces PLU entry errors. | HW | v3 | must | proposed | AB | AB-B_53 |
| POS-LOY-003 | Automatic loyalty enrollmentCustomers are automatically enrolled in the loyalty program on their first purchase, with SMS validation the first time. The SMS confirms the customer's phone via a verification code. If the customer does not validate, they remain enrolled but do not accumulate points until they validate. | LOY | v1 | should | proposed | GFD | GFD-D_17 |
| POS-LOY-007 | Birthday / Anniversary discountA discount applied on the customer's birthday or anniversary, where "anniversary" means the anniversary of the customer's signup (registration) date. The POS detects the qualifying date automatically when the customer is on the sale, but the cashier confirms the discount before it applies. It is a percentage discount on the purchase and stacks with other active promotions. | LOY | v2 | must | proposed | GFD | GFD-D_10 |
| POS-LOY-008 | Loyalty points policyThe loyalty points program. Points never expire by default — unless an offer says otherwise. "Dates = offers" means that only points earned within an offer/promotion carry an expiration date; regular points do not expire. Points are earned at X points per $ spent (configurable) and redeemed as X points = $ of discount (configurable). | LOY | v1 | should | proposed | GFD | GFD-D_18 |
| POS-LOY-009 | Loyalty / Rewards in offline mode (points deferred)This functionality defines how the Qiiub Loyalty / Rewards program behaves while the POS is in Emergency / Offline mode (see POS-CFG-014). The loyalty program covers points accumulation and tier discounts (discounts tied to a customer's loyalty tier). | LOY | v1 | could | proposed | GFD | GFD-F_10 |
| POS-PAY-007 | Credit / debit card paymentCredit and debit card payment handles transactions where the customer pays using a physical card or a contactless device. The POS communicates with a payment processor to authorize and capture the charge. The business owner chooses their own payment processor; Dynamics Payments is one of the available options but is not the default or mandatory choice. The functionality supports all three card-reading methods: tap (NFC contactless), insert (EMV chip), and swipe (magnetic stripe). Tip is configurable per business type. | PAY | v1 | must | proposed | AB | AB-B_02 |
| POS-PAY-008 | Multi-tender / split paymentMulti-tender (also called split payment) allows a single transaction to be paid using more than one payment method. The cashier selects a tender, enters the amount to apply, and the POS tracks the running balance. This continues until the full total is covered. Any combination of active tenders is allowed, with no limit on the number of tenders in a single transaction. The customer receives one consolidated receipt listing all tenders used. | PAY | v1 | must | proposed | AB | AB-B_03 |
| POS-PAY-009 | Loyalty / rewards as tenderLoyalty points earned by a customer through the Qiiub rewards program can be redeemed as a payment method at the POS. Points are converted to a dollar value at a rate configured by the tenant (e.g., 100 points = $1.00). The customer is identified via the Qiiub mobile app. Partial redemption is supported — the customer can apply a portion of their points balance and cover the rest with another tender (multi-tender, POS-PAY-008). Points are only accrued on the portion of the transaction NOT paid with loyalty points. | PAY | v1 | should | proposed | AB | AB-B_04 |
| POS-PAY-010 | Gift cardGift cards are a prepaid tender available in both physical (barcode/QR code) and digital (email or app code) formats. They can be purchased and reloaded in-store at the POS or through the Qiiub online platform. The value is open — the buyer sets the amount at the time of purchase. Gift cards never expire, support partial use (the remaining balance stays on the card), and can be checked at the POS (scan) or via the Qiiub app (see the LOY-005 ceiling row — gift card balance). Lost cards can be transferred to a new card by a manager only. Gift cards cannot be converted to cash. | PAY | v1 | must | proposed | AB | AB-B_07 |
| POS-PAY-011 | Charge to AR accountCharge to AR (Accounts Receivable) lets eligible customers with a pre-approved credit account complete a purchase without paying at the point of sale. The amount is posted to the customer's AR account and invoiced. Only customers who have been pre-approved and assigned a credit line by the business are eligible — the cashier cannot create an AR account at the POS. The customer is identified by the cashier searching by name, phone, or account number, or by the customer presenting their Qiiub app. AR can also be applied to Layaway deposit payments and can be combined with other tenders in a split payment. | PAY | v1 | must | proposed | AB | AB-B_06 |
| POS-PAY-013 | Remove tender from payment stackDuring a multi-tender / split payment transaction (POS-PAY-008), the cashier may need to remove a tender already added to the payment stack — either before or after that tender has been processed. Removing an unprocessed tender simply restores the running balance. Removing a processed tender triggers an automatic void or reversal for that tender. In both cases the cashier must manually assign the restored balance to a new tender; the system does not auto-redistribute. If a void or reversal fails, the cashier is alerted and the case is flagged for manager reconciliation. | PAY | v1 | must | proposed | AB | AB-B_11 |
| POS-PAY-016 | Manual auth code (manual CC)Manual auth code (manual CC) is an emergency payment method used when the card terminal is non-functional or the payment processor is unreachable. The cashier calls the payment processor's voice authorization line, obtains an approval code verbally, and enters that code manually into the POS. The customer always physically presents their card — the cashier taps or swipes the card on the terminal if possible, but NEVER types card numbers into the POS. This method requires a justification entry and generates a full audit trail. It is the emergency fallback for normal credit/debit card payments (POS-PAY-007). | PAY | v1 | should | proposed | AB | AB-B_10 |
| POS-PAY-019 | Cash payment with visual change calculatorCash payment handles transactions where the customer pays with physical cash at the register. The cashier enters the amount of cash received; the POS calculates the exact change due and displays it prominently on screen. The cash drawer opens automatically upon confirmation, and a receipt is generated. The flow includes a visual change calculator that shows the total change due in large, easily readable text so the cashier does not make errors when returning change. This is one of the two core payment methods (alongside credit/debit card) and is required at launch. | PAY | v1 | must | proposed | AB | AB-B_01 |
| POS-PAY-020 | Store credit as tenderStore credit is a dollar-denominated balance held on a customer's Qiiub account that can be used as a payment method at the POS. Store credit is generated in three ways: as the result of a refund or return, by manual creation by a manager, or as a credit adjustment on a customer's AR account (credit limit / AR, POS-CUST-013). Store credit never expires, can be used partially (combined with another tender via multi-tender, POS-PAY-008), and can be applied to Layaway deposits with manager approval. | PAY | v1 | must | proposed | AB | AB-B_05 |
| POS-PAY-021 | BNPL / financing as tender (Klarna / Synchrony)Financing through a third-party provider (such as Klarna or Synchrony, specific provider TBD) lets customers pay for purchases in installments rather than in full at the point of sale. There are two flows: one for customers who already have an approved account with the provider, and one for customers applying for new financing on the spot. Approved financing finalizes the sale immediately; a denied application leaves the sale in a hold state while the cashier offers an alternative tender. Financing can also be combined with other tenders in a split payment (POS-PAY-008). | PAY | v1 | could | proposed | AB | AB-B_08 |
| POS-PAY-022 | PayPal as tenderPayPal as a tender lets customers who have linked their PayPal account to their Qiiub wallet pay at the POS using PayPal. The cashier selects PayPal as the tender, and the customer approves the payment within the Qiiub app. This functionality is intentionally post-launch — it will only be activated after the Qiiub wallet has sufficient adoption. | PAY | v1 | could | proposed | AB | AB-B_09 |
| POS-PAY-023 | Foreign tender (foreign currency cash)Foreign tender lets customers pay with physical cash in a currency other than USD. The exchange rate is fetched in real time from an external exchange-rate service at the moment of the transaction. Change is always returned to the customer in USD. The receipt displays the full currency conversion breakdown. This functionality is marked Could Have because Puerto Rico's retail market is not yet widely prepared for foreign currency acceptance. Each business can configure which foreign currencies it accepts. | PAY | v2 | could | proposed | AB | AB-B_12 |
| POS-PRINT-011 | Custom text and receiptsCustom Text & Recibos (Custom Text & Receipts) is a back-office Settings feature that lets the administrator personalize the text printed on every document type generated by the POS. Each receipt type has its own configurable title, subtitle, and footer note, plus a shared set of editable line-item labels. A real-time preview renders the result in 40-column format (matching an 80mm thermal receipt printer) as the administrator types. | PRINT | v1 | must | proposed | AF | AF-A_02 |
| POS-RET-001 | Return with receiptReturn with receipt lets a cashier refund one or more items from a previously completed sale, using the original receipt or transaction reference to retrieve that sale. The cashier retrieves the original transaction (by scanning the receipt barcode/QR, typing the transaction number, or accepting a transaction the customer submits through the Qiiub customer app), confirms it is a return (not an exchange), selects the items and quantities to return, the system validates the request, determines the refund method according to tenant configuration, processes the refund, updates inventory, and prints/sends a return receipt. The system records the returned quantities against the original transaction so the same items cannot be returned twice (including quantities already returned through an exchange). | RET | v1 | must | proposed | GFD | GFD-G_01 |
| POS-RET-005 | Return without receiptReturn without receipt lets a cashier refund items when the customer has no receipt or transaction reference. It branches by customer type: a registered customer is looked up and their purchase history is used to select returnable items; a walk-in customer has items scanned in return mode and registered as negative quantities. No-receipt returns require the cashier to have the "Allow returns" permission (returns with and without receipt); otherwise a manager override (POS-SESS-006) is required. A separate tenant toggle controls whether walk-in no-receipt returns are allowed at all. | RET | v1 | must | proposed | GFD | GFD-G_03 |
| POS-RET-008 | Exchange with receiptExchange with receipt combines a return-with-receipt with a new sale. The cashier retrieves the original transaction, confirms it is an exchange, and the system runs the complete return process (POS-RET-001) for the items being given back. Instead of refunding the customer directly, the refunded amount is held by the system and automatically applied as payment toward a new transaction — with its own transaction number — for the items the customer takes in exchange. The returned items are tied back to the original transaction and their quantities tracked there to prevent future double returns. | RET | v1 | must | proposed | GFD | GFD-G_02 |
| POS-RET-010 | Refunds and returns controlRefunds and returns control governs how the Qiiub POS handles the reversal of completed sales. It defines who can process a refund, under what conditions a refund without a receipt is permitted, how the system validates that refunds go back to the original payment method, what limits exist on refund and void actions per role, what return reasons are captured, and how the system detects potentially fraudulent refund patterns. | RET | v1 | must | proposed | JF | JF-J_04 |
| POS-RET-011 | Exchange without receiptExchange without receipt combines the return-without-receipt flow (POS-RET-005) with the exchange process (POS-RET-008). The cashier processes a no-receipt return — a registered customer via purchase history, or a walk-in via scanned negative quantities — and instead of paying the refund out, the system holds the refunded amount and automatically applies it as payment toward a new transaction — with its own transaction number — for the items the customer takes in exchange. | RET | v1 | must | proposed | GFD | GFD-G_04 |
| POS-RPT-001 | X report (without closing the batch)The X Report is an intermediate reading of the batch totals that does not close the batch — the batch stays open and continues operating after the X is viewed or printed. It is modeled as a "Z without closing": it shows the same totals as the Z report but, because no cash is physically counted, it shows the expected cash without over/short. | RPT | v1 | should | proposed | JF | JF-F_06 |
| POS-RPT-005 | Cashier performance summary (Z report)POS-RPT-005 already exists in the 21c ceiling as the cashier's end-of-shift "Lo que hiciste hoy" view. This spec expands that ceiling with the Phase 2 performance metrics described below — the on-screen and printable cashier performance summary tied to the Z close. | RPT | v1 | could | proposed | JF | JF-F_02 |
| POS-RPT-007 | Flash reportThe Flash Report is an on-demand, mid-day sales summary screen that lets a manager see how the store is performing so far today, at any moment, without waiting for the end-of-day close. The manager opens it whenever they want and the report shows the sales accumulated from store opening up to the current moment, computed live from the day's transactions. It exists to give management a quick pulse on the business during the day — how much has sold, through which payment methods, by which cashiers, and which products are driving revenue — so they can react (restock, adjust staffing, etc.) before the day ends. | RPT | v1 | should | proposed | JF | JF-F_01 |
| POS-RPT-008 | Real-time security monitoring and alertsReal-time security monitoring and alerts gives managers and administrators a live dashboard that consolidates the most security-relevant events happening across all POS registers during the business day. It also provides automated detection of suspicious activity patterns and a notification system that delivers alerts to configured recipients via Email and/or SMS when defined thresholds are crossed or critical configuration changes are made. | RPT | v1 | must | proposed | JF | JF-J_06 |
| POS-SALE-001 | Create new saleThis spec expands the existing ceiling row for starting a new sale and returning the register to a clean state. It governs how a sale begins and how the register returns to a ready-to-scan state after a sale ends. In Qiiub, the moment the receipt is printed or sent, the screen clears instantly and returns to a ready state — no button, no confirmation. Newly scanned items appear at the top of the cart (configurable), and a Pole Display shows the running total to the customer while the cashier scans. | SALE | v1 | must | proposed | AF | AF-F_01 |
| POS-SALE-002 | Scan itemThis spec expands the existing ceiling row for adding items to the cart by scanning a barcode. Qiiub adds a green flash on success and a red flash on failure, briefly highlights the newly added line, and auto-increments the quantity when the same item is scanned twice. Scanning also works through the tablet camera when no physical scanner is available. | SALE | v1 | must | proposed | AF | AF-F_02 |
| POS-SALE-003 | Search item by name or codeThis spec expands the existing ceiling rows for item search. The ceiling splits sale-side and palette-side search; this spec owns both (it covers POS-SEARCH-002). It governs finding an item when it cannot be scanned. Qiiub shows results inline as you type (never as a separate window over the cart), each result with photo, price, and stock. It accepts free-text descriptions, auto-corrects typos, lets the cashier take a photo so Qiiub identifies the item, and filters by department. | SALE | v1 | must | proposed | AF | AF-F_03 |
| POS-SALE-005 | Edit line quantityThis spec expands the existing ceiling row for changing the quantity of an item already in the cart. Qiiub adds +/- buttons on the same line, removes the line when quantity reaches 0, allows swipe-left to delete and double-tap to edit, and — when the cashier lacks permission — lets a manager approve remotely from their phone so the register is never blocked. | SALE | v1 | must | proposed | AF | AF-F_04 |
| POS-SALE-010 | Apply variant, size, or colorThis spec expands the existing ceiling row for selecting the correct variant (size, color, and other attributes) of a product. Qiiub shows a visual selector when the product is scanned; each button shows remaining units. Out-of-stock variants are still selectable but warn and allow a special order or an out-of-stock notification depending on the store configuration. | SALE | v1 | must | proposed | AF | AF-F_06 |
| POS-SALE-024 | Item-not-found sound and failure feedbackAudible feedback so the cashier knows the result of a scan without looking up. A beep plays on a successful scan and a buzzer plays on a not-found scan; both tone and volume are configurable per store from Settings. Qiiub also keeps a daily scan-failure log and shows a shift failure counter to the supervisor. | SALE | v1 | must | proposed | AF | AF-F_07 |
| POS-SALE-025 | Create a new item during a saleWhen a scanned product is not in the system, instead of blocking the sale Qiiub opens a mini form to create it in seconds. The item sells as a provisional item and the sale continues; a manager completes the cataloging later. | SALE | v1 | must | proposed | AF | AF-F_08 |
| POS-SALE-026 | Create an item from a supplier catalog by scanningWhen a staff member scans an item barcode that is not in the tenant's catalog (unknown-item handling — see AB-B_34, Inventory module) but the barcode matches a product in a connected supplier's catalog, the system automatically pulls the item's data from the supplier catalog (name, description, category, unit of measure, supplier SKU, and any available pricing) and pre-fills an item-creation form. The staff member reviews and supplements the pre-filled data (sets the retail price, assigns a category if needed, etc.) and saves the item to the tenant's catalog. This eliminates manual data entry for items that already exist in a supplier's catalog. | SALE | v1 | must | proposed | AB | AF-F_09, AB-B_42 |
| POS-SALE-027 | Inter-store sale with pickup at another locationInter-store sale lets a customer buy an item that is out of stock at the current location and commit to collecting it at a different location of the same tenant that has the item in stock. The cashier sees stock across all locations, requests the inter-store sale with one tap, and the other location is notified automatically. The customer pays in full at the originating location and chooses: pick up at the other location, or wait for a transfer to the current location. Stock at the pickup location is committed immediately so it cannot be sold to another customer. | SALE | v2 | must | proposed | AB | AF-F_10, AB-B_30 |
| POS-SALE-028 | Detailed availability (stock, committed, dispatch, on order)Detailed availability gives the cashier a real-time, multi-dimensional view of an item's inventory position directly from the sale, without leaving the screen. Each cart line carries a color dot reflecting free stock, and the cashier can expand an item to see the tracked quantities, a natural-language ETA for incoming stock, and a forward-looking expected-available figure — plus availability at the tenant's other locations. | SALE | v1 | must | proposed | AB | AF-F_11, AB-B_38 |
| POS-SALE-029 | Item relation recommendationsItem relation surfaces the most relevant add-on at the moment an item is added to the cart. Relations come from both manual back-office configuration and AI learning from sales history. When the cashier adds a product, Qiiub shows a suggested-accessory button; one tap adds it. If the full bundle ends up in the cart, a bundle discount applies automatically. For a known customer, Qiiub may show a personalized suggestion based on history. | SALE | v2 | must | proposed | AF | AF-F_12 |
| POS-SALE-030 | Shopper appA customer-facing way to build a cart while shopping. A QR at the store entrance opens the app in the phone browser (no download). At checkout, the cashier scans the customer's QR and the cart appears ready in the POS. | SALE | v3 | could | proposed | AF | AF-F_13 |
| POS-SALE-031 | Scan & GoThe customer scans items with their phone, pays in the app, and leaves without passing through a register. Inventory updates in real time and the POS receives confirmation. On exit, a guard scans the QR of the digital receipt. | SALE | v3 | could | proposed | AF | AF-F_14 |
| POS-SALE-032 | Smart fitting roomA fitting-room experience where the customer can request another size or color without leaving the room. Access is via QR (phone) and a fixed fitting-room screen. | SALE | v3 | could | proposed | AF | AF-F_15 |
| POS-SALE-033 | Smart cursor (the search field is always ready)The smart cursor keeps the scan/search field always ready so the cashier never has to hunt for where to type. After every action, the cursor returns by itself to the search field immediately. A continuous scan mode keeps the field from ever losing focus during the whole sale, so a scanner shot or a typed search always lands in the right place. | SALE | v1 | must | proposed | AF | AF-F_16 |
| POS-SALE-034 | Copy transaction (repeat purchase)Copy transaction loads a cart from a prior transaction so frequent customers do not have to re-scan. From the customer profile, a "Repetir compra" (repeat purchase) button loads items without scanning. The cart can be sourced from the customer's last purchase, their top 3 most-frequent combinations, any past transaction looked up by number, or a prior quote copied into a sale. The loaded cart is fully editable before charging. | SALE | v1 | must | proposed | AF | AF-F_17 |
| POS-SALE-035 | Out-of-stock alert and cashier optionsWhen a cashier scans or adds an item that has zero available stock at the current location, the POS immediately alerts the cashier and surfaces the resolution paths inline at the point of the alert — the cashier does not have to guess or leave the sales screen. The alert presents: real-time availability across the tenant's other locations, an inter-store sale where the customer pays now and picks up where stock exists (POS-SALE-027), an inventory transfer request to bring units to the current location, automatically suggested substitute items (POS-SALE-036), and — if the tenant allows negative selling — a backorder option (POS-SALE-041). The cashier picks the path that matches the customer's preference. | SALE | v1 | must | proposed | AB | AB-B_29 |
| POS-SALE-036 | Item substitution with automatic similarity suggestionsWhen an item is out of stock or unavailable at the current location, the POS automatically suggests similar in-stock items as substitutes. Suggestions are generated by the system from item similarity (same category, similar attributes, comparable price range) rather than requiring the tenant admin to configure substitutes manually. The cashier reviews the suggestions with the customer; if the customer agrees, the substitute replaces the original in the cart. If no suitable substitute exists or the customer declines, the cashier dismisses the suggestion and proceeds with the standard out-of-stock options (POS-SALE-035). | SALE | v1 | must | proposed | AB | AB-B_31 |
| POS-SALE-037 | Kit / assembly sellingKit / assembly selling lets a cashier sell a predefined bundle of items (a "kit") as a single line item in the cart. The kit has its own SKU and price. When a kit is scanned or added, the POS adds it as one item — the cashier and customer see the kit name and price, not the individual components. The receipt, however, shows a breakdown of all components included in the kit. When the kit is sold, inventory is decremented for each individual component (not for a "kit" as a unit), since kits are assembled from existing component stock. | SALE | v1 | must | proposed | AB | AB-B_32 |
| POS-SALE-038 | Age verification prompt for restricted itemsWhen a cashier adds an age-restricted item (such as alcohol or tobacco) to the cart, the POS immediately interrupts the checkout flow and requires the cashier to verify the customer's age before the item can remain in the cart. The cashier scans the customer's government-issued ID (driver's license or equivalent) or reads it from the customer's Qiiub app. The POS calculates the customer's age from the ID's date of birth and determines whether they meet the minimum age requirement. If the customer is underage or refuses to present ID, the item is removed from the cart and the sale is blocked for that item. Because this flow is compliance-critical, every verification attempt is recorded for audit regardless of outcome. | SALE | v1 | must | proposed | AB | AB-B_33 |
| POS-SALE-039 | Unknown item handlingWhen a cashier scans a barcode that does not match any item in the tenant's item catalog, the POS presents two options in the same prompt: (1) sell the item immediately as a one-time "open item" with a manually entered price and description, or (2) register the barcode as an unknown item for later classification by the manager without completing the sale of that item now. The cashier chooses based on the situation. Regardless of the path chosen, the unrecognized barcode is always logged for manager review. | SALE | v1 | must | proposed | AB | AB-B_34 |
| POS-SALE-040 | Prevent sale of inactive itemsWhen a cashier scans or adds an item that has been marked as "Inactive" in the item catalog, the POS blocks the item from being added to the cart and displays a clear alert. The cashier cannot override this block without manager intervention. An item is marked inactive by the tenant admin (e.g., discontinued products, items pending re-pricing, recalled products, seasonal items not yet active). This prevents accidental sales of items the business has intentionally taken out of the active product lineup. | SALE | v1 | must | proposed | AB | AB-B_35 |
| POS-SALE-041 | BackordersBackorders allow a customer to purchase an item that is currently out of stock, with the understanding that the item will be fulfilled when new stock arrives. When an out-of-stock (OOS) item is scanned and the cashier selects the backorder option, the POS presents a confirmation prompt and — upon the cashier's confirmation — creates a backorder record linked to the customer. The customer pays a deposit (or the full amount, configurable per tenant) at the time of the backorder. When the item arrives in stock, the system notifies the store and the customer is contacted to complete the transaction. | SALE | v1 | must | proposed | AB | AB-B_36 |
| POS-SALE-042 | Fast part — unavailable item linked to customer with notificationFast Part is a lightweight "request and notify" flow designed for specialty or parts-based businesses (e.g., hardware stores, auto parts, pharmacies) where a customer asks for a specific item that the store does not currently carry or have in stock. The cashier logs the request against the customer's account, and the system automatically sends the customer a WhatsApp message (WhatsApp when enabled per ADR-0094; email/SMS/app otherwise) confirming the request and committing to follow up. When the item becomes available, store staff notifies the customer through the same channel. No sale is created; this is purely a demand capture and communication tool. | SALE | v2 | must | proposed | AB | AB-B_37 |
| POS-SALE-043 | Serial number managementSerial number management enables the tenant to track inventory at the individual unit level for items that require serial number tracking (e.g. electronics, appliances, medical devices, firearms). Each unit of a serialized item has a unique serial number. When serialized items are received into inventory, their serial numbers are recorded. When a serialized item is sold, the specific serial number of the unit sold is captured at the POS and linked to the sale transaction and the customer. This creates a complete chain of custody for every serialized unit: from receiving to sale to customer. | SALE | v1 | must | proposed | AB | AB-B_40 |
| POS-SALE-044 | Expiration date on perishable itemsExpiration date tracking enables the system to monitor the expiration dates of perishable items in inventory. When a perishable item approaches or reaches its expiration date, the system generates alerts to the manager. Items that have expired are automatically flagged and blocked from being sold at the POS. The tenant admin configures which items are perishable and how many days in advance to trigger the "approaching expiration" alert. | SALE | v1 | must | proposed | AB | AB-B_41 |
| POS-SALE-045 | Box content verifierBox Content Verifier is used when a customer's purchase is packed into a box or bag for delivery or complex pickup — a multi-item order, a prepared food order, or a large purchase. Before the box is sealed, the cashier (or fulfillment staff) works through a checklist of every item on the POS screen, checking each off. Once all items are confirmed, the customer signs digitally on the POS touchscreen to acknowledge they reviewed and accepted the contents. This creates a record of what was packed and that the customer confirmed it, preventing disputes about missing items. | SALE | v3 | must | proposed | AB | AB-B_48 |
| POS-SALE-046 | Transaction template — AI-generated from customer historyTransaction template learns from a customer's purchase history and, when that customer is identified at the POS, suggests a pre-built cart ("template") based on the items they most frequently buy together. The cashier identifies the customer, the system immediately suggests a personalized template, and the cashier applies it with one tap — saving time for repeat customers with predictable orders (a coffee-shop regular, a weekly grocery customer, a business reordering supplies). The customer can modify the suggested cart before checkout. | SALE | v2 | must | proposed | AB | AB-B_50 |
| POS-SEARCH-008 | Quick-action assistantThe quick-action assistant is an always-available panel of the most-used actions, reachable without leaving the POS. The panel surfaces the top-10 actions, changes by role, adapts via AI to how the cashier works, and includes a search. If a cashier is idle for more than 30 seconds, the AI suggests the next step. It keeps common actions one tap away so the cashier does not have to navigate menus mid-sale. | SEARCH | v2 | should | proposed | AF | AF-F_19 |
| POS-SEARCH-009 | Process guideThe process guide ("Guía de Procesos") is an in-POS reference tool that gives cashiers instant, step-by-step guidance for any workflow they need to perform. The cashier opens the menu, selects a process, and the system displays the exact numbered steps to complete it — clear, short, and precise. This eliminates the need for cashiers to memorize infrequently-used procedures and reduces errors during complex workflows. The content is static and read-only: it explains how to perform a process but never executes it. | SEARCH | v1 | must | proposed | AF | AF-A_06 |
| POS-SESS-006 | Manager override / approval workflowThe Manager Override / Approval Workflow is a permission-gating mechanism in the Qiiub POS. Certain sensitive actions are blocked for a cashier and cannot be completed until a manager (or a higher role) approves them. When a cashier attempts a blocked action, the POS interrupts the action and requires a manager to authorize it; once authorized, the originally blocked action is completed automatically. | SESS | v1 | must | proposed | JF | JF-F_03 |
| POS-SESS-011 | POS audit log and immutable audit trailThe POS audit log is a comprehensive, tamper-proof record of every significant event that occurs within the Qiiub POS system. Every action taken by any user — from sales and refunds to overrides, logins, logouts, configuration changes, and customer record modifications — is captured in real time as a structured log entry. The log is designed so that an administrator, supervisor, or manager can reconstruct exactly what happened at any register, at any time, by any user. | SESS | v1 | must | proposed | JF | JF-J_01 |
| POS-SESS-012 | User access control and permissionsUser access control and permissions defines exactly which actions each role in the Qiiub POS system is allowed to perform, and what happens when a user attempts an action outside their permission level. This functionality covers four areas: | SESS | v1 | must | proposed | JF | JF-J_02 |
| POS-SESS-013 | Cashier message — internal real-time chatCashier message is a real-time internal chat tool embedded in the POS that lets employees at the same location send text messages to each other without leaving the POS screen or using personal phones. It enables instant communication between registers — request a price check, ask a colleague to cover a line, notify the manager of an issue, or coordinate a break. Messages are visible only to employees of the same location (same tenant + same branch). | SESS | v2 | must | proposed | AB | AB-B_51 |
| POS-SESS-014 | Modern time clock — breaks, overtime, payroll exportModern time clock is a built-in employee time-tracking system in the POS. Employees clock in and out directly from the POS at shift start and end. The system tracks paid and unpaid breaks separately, monitors overtime thresholds, and alerts the manager when an employee approaches or exceeds configured overtime limits. At the end of the pay period, the manager exports a payroll report for all employees at the location. This expands the ceiling's punch-in / punch-out rows (POS-SESS-008, POS-SESS-009) with breaks, overtime, and payroll export. | SESS | v2 | must | proposed | AB | AB-B_52 |
| POS-SHIFT-009 | Blind closeoutBlind closeout is a two-stage closing flow. The batch is closed at the register without counting the cash there; the cash count is then performed later in the back office with a manager present. The cashier removes all the cash from the drawer and takes it to the back office, where the cashier counts it in front of the manager and the counted amount is entered (the system computes over/short at that point). Between the register close and the back-office count, the batch is in a "closed pending count" state. | SHIFT | v1 | should | proposed | JF | JF-F_13 |
| POS-SHIFT-019 | Batch opening with denominationsBatch opening with denominations is the operation that opens a cash batch (a shift's cash session) by registering the starting cash float, optionally broken down by individual denominations (how many $20 bills, $10 bills, quarters, etc.) rather than just a single total amount. The system can sum the denominations and compute the starting float automatically. It establishes the opening cash baseline against which the batch will later be reconciled at close. | SHIFT | v1 | must | proposed | JF | JF-F_04 |
| POS-SHIFT-020 | Batch close / Z reportBatch close / Z report is the full batch-closing operation. It covers both the cash reconciliation of the close (counting the final money and computing over/short) and the Z report document with the batch totals. It is broader than the Cashier Performance Summary (POS-RPT-005), which is the performance summary that appears at the moment of the Z close; this spec is the act of closing and reconciling the batch itself. The two are complementary. | SHIFT | v1 | must | proposed | JF | JF-F_05 |
| POS-SHIFT-021 | Floating reconciliation per userFloating reconciliation per user defines the floating mode: the batch/reconciliation follows the individual cashier rather than being tied to a physical register, so a cashier can operate at different registers and their batch travels with them. This is the conceptual counterpart of "register mode" (where the batch belongs to the physical register). Floating vs register is a global store mode (consistent with the Cashier Performance Summary, POS-RPT-005). | SHIFT | v1 | should | proposed | JF | JF-F_12 |
| POS-SHIFT-022 | Closing tools — adjustmentThe Adjustment tool reclassifies the tender of a transaction (e.g. Visa → Mastercard) when the settlement does not match how the payment was originally recorded. It does not change the sale total — it only redistributes the amount between tenders. It can be used during the batch close and after the close (post-settlement), and every adjustment is audited. | SHIFT | v2 | could | proposed | JF | JF-F_14 |
| POS-SHIFT-023 | Custom shift recordsCustom shift records are store-configurable records the store defines for business-specific concepts such as lottery (lotería) sales or gaming machines. They are not POS sales (they do not count as POS revenue), but they represent real money that enters the drawer — so they are recorded as a cash entry (or whatever tender is configured) so that the reconciliation (cuadre) balances, and then that amount is automatically removed from the drawer (because it belongs to the lottery/machine business, not the store). They appear in the Z/close report as a separate section. | SHIFT | v2 | could | proposed | JF | JF-F_16 |
| POS-SHIFT-024 | Smart handoff — note to next employeeSmart handoff lets a cashier or employee attach a structured note to a transaction, customer account, or open order so the next employee who opens that record has full context without a verbal briefing. The note combines structured fields (category tag, priority level) with a required free-text body and is shown prominently the next time any employee opens the associated record. This reduces customer frustration from re-explaining their situation and reduces errors from poor shift handoffs. | SHIFT | v2 | must | proposed | AB | AB-B_49 |
| POS-VERT-014 | Create quote with items and customer dataCreate quote builds a price quote ("cotización") with items and customer data, with no charge taken. Qiiub places a visible "Nueva Cotización" (new quote) button on the main screen, shows a clear "MODO COTIZACIÓN — Sin cobro" (quote mode — no charge) banner so a quote is never confused with a sale, sets an expiration (default 30 days, configurable per store), shows the quote number from the start, and exposes quote history in the customer profile. This spec promotes the prior POS-VERT-014 "Estimado / quote" placeholder in the ceiling into the full create-quote flow. | VERT | v1 | must | proposed | AF | AF-F_21 |
| POS-VERT-015 | Create work orderCreate work order lets a cashier create a work order (WO) at the POS for a specific customer, reserving existing inventory and collecting a mandatory, configurable deposit. The WO captures the items the customer will pay for over time (deposit + abonos) and pick up later, fully or partially. It is the entry point of the entire Work Orders module. Typical uses: layaway, special orders, services, and contractors retrieving materials in phases. | VERT | v1 | must | proposed | AB | AB-A_01 |
| POS-VERT-016 | Sales rep visibility on quotesSales rep visibility makes the assigned salesperson (sales rep) visible and easy to manage on a quote or transaction. The assigned rep is shown in the transaction header, a red warning appears before charging or converting if no rep is assigned, and the rep can be changed or cleared with one tap. A rep can be assigned per transaction, per line, and shared across more than one rep for a commission split. | VERT | v1 | must | proposed | AF | AF-F_22 |
| POS-VERT-017 | Print, email, or SMS a quoteQuote delivery delivers a quote professionally and tracks it. Qiiub generates a branded PDF and delivers it as a printed PDF, by email, or by SMS — each digital channel carrying a clickable link. The quote auto-sends on save when contact info exists, a reminder is sent 3 days before expiration, the salesperson is notified when the customer opens the link, and if the customer accepts from the link the quote converts to a sale automatically. | VERT | v1 | must | proposed | AF | AF-F_23 |
| POS-VERT-018 | Convert quote to saleConvert quote to sale turns an accepted quote into a sale with minimal friction. The active quote appears immediately on customer search, a "Convertir a Venta" (convert to sale) button converts it without an extra confirmation screen, and partial conversion is available via per-item checkboxes. If the customer accepts the quote from the link, it converts automatically with a cashier alert. | VERT | v1 | must | proposed | AF | AF-F_24 |
| POS-VERT-019 | Convert quote to work orderConvert quote to work order turns a quote into a work order (WO). A "Convertir a Work Order" (convert to work order) button on the quote copies items, prices, customer, and delivery date; the quote's notes become the WO instructions. A deposit can be charged at conversion, configurable per store. From Venta (the sales side), the cashier handles everything related to the POS transaction; the WO can then convert to any sale type the business has configured. WO type configuration and payment rules are owned by the Work Orders module (Arnaldo & Brito) — Venta only consumes that configuration. | VERT | v1 | must | proposed | AF | AF-F_25 |
| POS-VERT-020 | Convert quote to layawayConvert quote to layaway turns a quote into a layaway (apartado). A "Convertir a Layaway" (convert to layaway) button copies items, prices, and customer; an initial deposit is charged at conversion and stock is reserved automatically. The journey is traced end to end: Quote → Layaway → Sale. A mixed conversion — part to layaway, part charged now — is configurable per store. The quote's price is respected, with no renegotiation. Customer app-initiated conversion ships in v1, configurable per store (each owner or manager decides whether to enable it). | VERT | v1 | must | proposed | AF | AF-F_26 |
| POS-VERT-021 | Remove a quote item before convertingRemove a quote item cleanly removes an item from a quote before converting it, fixing the legacy qty-zero ghost-line bug. The cashier swipes left to delete the line or sets the quantity to 0; the item disappears and the total recalculates instantly. Full version history of the quote is retained, the original is auto-saved before changes, and undo is available. | VERT | v1 | must | proposed | AF | AF-F_27 |
| POS-VERT-022 | Quote with customer signatureQuote with customer signature captures the customer's signature on a quote for legal backup, without paper. It captures printed name, signature, and date. The customer signs on the tablet with their finger; if they are not in the store, they sign remotely via a link. On signing, the quote converts automatically — to a sale, work order, or layaway. The signed PDF is delivered instantly and legal validity/date is auto-generated. Multiple signatures are supported (one link per signer). AI signature verification is permanently deferred — there is no comparison against stored signatures, keeping the sales process as simple as possible. | VERT | v2 | must | proposed | AF | AF-F_28 |
| POS-VERT-023 | Customer pays a quote from their phoneCustomer pays a quote from their phone is a customer portal to view and pay quotes from the phone. The customer sees active quotes and the pending balance, taps "Pagar" (pay), and pays with "ATH Móvil", credit/debit card, "Qiiub Card", "Rewards", or gift card. Partial payments (abonos) are supported. A full payment auto-converts the quote to a sale and alerts the cashier. | VERT | v2 | could | proposed | AF | AF-F_29 |
| POS-VERT-024 | Work order partial paymentsWork order partial payments is the general mechanism at the POS for taking partial payments (abonos) against a WO's pending balance after the deposit. Abono amount rules come from the WO's snapshotted type; overpayment is blocked; a receipt is issued for each abono; and reaching a $0 balance makes the WO ready for pickup and marks it paid. The customer-app counterpart of this flow (abonos from the customer app) is documented separately under POS-VERT-027. | VERT | v1 | must | proposed | AB | AB-A_02 |
| POS-VERT-025 | Work order pickup and checkoutWork order pickup and checkout handles the pickup/checkout of WO items. It covers three behaviors consolidated from the Phase 2 source: full pickup (retrieve everything at once), partial pickup (retrieve only selected items, subject to the per-type abono threshold), and a simplified checkbox UI for selecting items. On confirming any pickup, items are marked as delivered, the reserved inventory is decremented, a pickup receipt is generated, and the WO status is updated (partial or closed). | VERT | v1 | must | proposed | AB | AB-A_03 |
| POS-VERT-026 | Work order typesWork order types are categories of work order (e.g. Layaway, Special Order, Service), each with its own independent configuration. This is the central configuration object that drives the deposit, abono amounts, partial-pickup threshold, HOLD time, restocking fee, and close-by period for every WO created under that type. The rules are snapshotted onto each WO at creation, so editing a type never changes existing WOs. | VERT | v2 | must | proposed | AB | AB-A_04 |
| POS-VERT-027 | Work order payments from the customer appWork order payments from the customer app is the app-side flow that lets a customer make abonos against their work order (WO) balance and view WO details from the end-user app. It is the customer-app counterpart to POS-VERT-024, which is the in-POS abono mechanism. The customer sees their open WOs and pending balance, pays an abono with a saved card / online payment and QIIUB Rewards, and the balance updates in real time in the POS. | VERT | v2 | must | proposed | AB | AB-A_05 |
| POS-VERT-028 | Work order restocking fee on late closeWork order restocking fee on late close is a charge retained when a work order (WO) is not closed within its deadline, or is cancelled, requiring items to be returned to inventory. The deadline is a close-by date set at WO creation and auto-calculated as the creation date plus the number of days configured in the type, per tenant policy. The restocking-fee terms are disclosed to the customer at creation. When the deadline passes the fee triggers automatically: items are returned to inventory, the WO is cancelled, the remainder is refunded minus the fee, the customer is notified, and an internal audit record is retained. | VERT | v2 | should | proposed | AB | AB-A_06 |
| POS-VERT-029 | Work order dispatch managementWork order dispatch management handles the preparation and handover of work order (WO) items by scanning each item at its Bin Location, and assigns and tracks who dispatches each WO. It is performed preferably on the mobile app and is also available at the POS. Dispatch happens either as staging/preparation before pickup or as the actual handover. The dispatcher opens the WO, sees the items and their Bin Location, and scans each item to confirm it; the system records who dispatched and when. | VERT | v2 | must | proposed | AB | AB-A_07 |
| POS-VERT-030 | Remote payments on work orders and quotes via the appRemote payments on work orders and quotes via the app is the shared remote-payment mechanism that lets a customer pay toward a Work Order (WO) or a Quote (cotización) from the Qiiub mobile app without being physically at the store. The customer can pay any amount from $0.01 up to the full remaining balance — partial payments are supported, and the app blocks overpayment. When a remote payment is received, the WO/Quote record updates in real time and the cashier is notified immediately. If the remaining balance reaches $0.00, the record is marked Fully Paid. | VERT | v2 | must | proposed | AB | AB-B_16 |
| POS-VERT-031 | Create layaway with minimum depositCreate layaway with minimum deposit is the entry point of the layaway (apartado) workflow. The cashier builds a cart, initiates a layaway instead of a standard sale, and the customer pays a deposit that meets or exceeds the configured minimum. The items are immediately reserved in inventory under the customer's account, and a layaway record is created with the full item list, the deposit paid, the outstanding balance, and the payment deadline. The minimum deposit is configurable per tenant as either a percentage of the total (e.g. 20%) or a fixed dollar amount (e.g. $50.00); only one format is active per tenant at a time. | VERT | v1 | must | proposed | AB | AB-B_17 |
| POS-VERT-032 | Layaway abono payment at any locationLayaway abono payment at any location lets a customer make a payment (abono) toward an active layaway at any active location of the same tenant — not only the location where the layaway was created. The cashier at the receiving location looks up the layaway, processes the payment with any active tender, and the layaway's outstanding balance is updated in the central record. The originating location sees the new balance the next time its cashier opens or refreshes the layaway. Every abono is recorded against the layaway with the location that processed it, regardless of where it was paid. | VERT | v1 | must | proposed | AB | AB-B_18 |
| POS-VERT-033 | Layaway full pickupLayaway full pickup is the completion step of a layaway. The customer arrives at any location of the tenant (not necessarily the originating location), pays any remaining outstanding balance in full, and physically receives all items. The cashier processes the final payment (if a balance remains), marks all items as picked up, closes the layaway record, and triggers label printing. Inventory is released from "On Layaway" status and the sale is finalized. | VERT | v1 | must | proposed | AB | AB-B_19 |
| POS-VERT-034 | Layaway partial pickup with item selectionLayaway partial pickup lets a customer take possession of one or more specific items from their layaway without picking up all of them. The cashier selects which items are being picked up, the POS calculates the proportional payment due for those items (if a balance remains), processes the payment, and marks the selected items as delivered. The remaining items stay on layaway and the record stays "Active" until all items are picked up. Partial pickup can happen at any location of the tenant. | VERT | v1 | must | proposed | AB | AB-B_20 |
| POS-VERT-035 | Cancel layaway with mandatory commentCancel layaway closes an active layaway before the customer completes payment and pickup. The cashier must provide a cancellation reason — selected from a predefined list, with an optional free-text supplement — before the cancellation is confirmed. On confirmation, the tenant's configured refund policy is applied (full refund, store credit, or forfeiture), reserved items are released back to available inventory, and the layaway record is closed. The mandatory comment ensures every cancellation has a documented reason for audit and reporting. | VERT | v1 | must | proposed | AB | AB-B_21 |
| POS-VERT-036 | Layaway restocking fee on overdue cancellationLayaway restocking fee on overdue cancellation is a charge applied when a layaway is cancelled after its payment deadline has passed. When a cashier initiates a cancellation on an overdue layaway, the system detects that the deadline has been exceeded and proposes a restocking fee. The cashier reviews the proposed fee with the customer and confirms it before the cancellation is applied. The restocking fee is deducted from any refund owed to the customer. The fee amount is configurable per tenant — either a percentage of the total or a fixed dollar amount. This is the layaway counterpart of the work order restocking fee (POS-VERT-028) — the same pattern applied to a different document type: the WO fee triggers automatically on a late close, whereas the layaway fee is proposed to the cashier for confirmation during an overdue cancellation. | VERT | v2 | should | proposed | AB | AB-B_22 |
| POS-VERT-037 | Convert layaway to quoteConvert layaway to quote lets a cashier transform an active layaway into a quote (cotización) when the customer has not yet paid any deposit — total payments = $0.00. The conversion is only available when no payment has ever been made. Items and pricing carry over from the layaway into a new quote record, and the original layaway is closed without applying a refund policy (since nothing was paid). The new quote then follows the standard quote flow and can be sent to the customer, paid, or converted to a sale. This is the inverse of convert quote to layaway (POS-VERT-020): that flow turns a quote into a layaway and charges a deposit; this one turns a zero-deposit layaway back into a quote and releases the reserved inventory. | VERT | v1 | should | proposed | AB | AB-B_23 |
| POS-VERT-038 | Layaway quick task panelThe layaway quick task panel is a floating drawer that opens over the layaway list when a cashier selects a layaway record. It provides one-tap access to the three most common actions — make a payment (abono), process a pickup, and edit the layaway — without navigating away from the list. The goal is to reduce the number of taps required for high-frequency layaway tasks during busy periods. The panel overlays the list rather than replacing it, and after an action completes the list auto-refreshes to show the updated status and balance. | VERT | v2 | should | proposed | AB | AB-B_24 |
| POS-VERT-039 | Layaway bulk cancellationLayaway bulk cancellation lets a cashier holding the bulk-cancellation permission cancel multiple layaways in a single operation. The operator opens a dedicated window, applies filters to narrow the layaways (location, expiration date, status, outstanding balance), reviews the filtered list, selects which layaways to cancel, chooses the refund policy to apply to the whole batch, and confirms. The system processes every cancellation in batch — applying the selected policy, releasing all reserved inventory, and logging each cancellation. Per the gap audit this is most likely an admin/portal surface (a management-screen operation gated by a special permission and granted in the backoffice) rather than a primary POS register flow. | VERT | v2 | should | proposed | AB | AB-B_25 |
| POS-VERT-040 | Pay or complete layaway from the customer appPaying or completing a layaway from the customer app lets a customer make an abono (partial payment) or pay the full remaining balance on their active layaway from the Qiiub mobile app, from anywhere, without visiting a store. The POS updates in real time when a remote payment arrives, and the cashier or manager at the originating location is notified immediately. This extends the remote-payments mechanism (POS-VERT-030) specifically to the layaway context, where partial payments are a core part of the workflow. As a customer-app feature it is online-only — it has no offline behavior on the register. | VERT | v2 | must | proposed | AB | AB-B_26 |
| POS-VERT-041 | Layaway simplified checkout with item checkboxesLayaway simplified checkout is a streamlined screen used when the customer is ready to complete their layaway and pick up their items. It displays all the items in the layaway as checkboxes so the cashier can confirm which reserved items are being taken, and it also lets the cashier add extra items to the same transaction through the same checkout. The full outstanding balance — plus the value of any extra items added — is collected in one payment before the layaway is closed and items are released. | VERT | v1 | should | proposed | AB | AB-B_27 |
| POS-VERT-042 | Print layaway item label at closingWhen a layaway is completed (all items picked up and the balance fully paid), the POS automatically prints a single summary label for the layaway. The label is a physical record of the completed transaction, used on the customer's bag or folder when they leave the store. It is printed on a label printer connected to the POS and is triggered automatically at completion — the cashier does not initiate it manually. A reprint option is always available from the completed layaway record. | VERT | v2 | should | proposed | AB | AB-B_28 |
| POS-VERT-043 | Native ecommerceNative ecommerce is the backbone that unifies the tenant's in-store POS operations with their online sales channel. The same inventory sells through both the physical store and a Qiiub-built online storefront from a single product catalog. Online orders flow into the same operations pipeline as in-store sales — they appear in the backoffice, reduce inventory in real time, and are fulfilled via Click & Collect (POS-VERT-044), Ship-from-Store (POS-VERT-045), or delivery integration (POS-VERT-046). This functionality lives in the Backoffice / Operations context; the POS-facing pieces are the three fulfillment specs. | VERT | v3 | must | proposed | AB | AB-B_43 |
| POS-VERT-044 | Click and collectClick & Collect lets a customer who placed an online order (POS-VERT-043) and selected in-store pickup collect their items at the physical store. The cashier searches for the order in the POS by name, order ID, or Qiiub account, verifies identity, prepares the items, and completes the handoff. No payment is required at pickup — the customer already paid online. The order is marked completed and inventory moves from committed to sold. | VERT | v2 | must | proposed | AB | AB-B_44 |
| POS-VERT-045 | Ship from storeShip-from-Store lets a physical store act as a fulfillment center for online orders that ship to the customer's address. When a customer places an online order with "Ship to Address," the Qiiub backoffice assigns it to the most appropriate store (based on stock and proximity). Store staff receive the packing assignment, pick the items, print a packing slip, pack, and hand the package to the carrier. Inventory is decremented when the shipment is confirmed. | VERT | v3 | must | proposed | AB | AB-B_45 |
| POS-VERT-046 | Delivery integrationDelivery integration connects the Qiiub POS and backoffice to third-party delivery platforms — DoorDash, Uber Eats, and UVA (a local Puerto Rico delivery service) — so orders placed on those platforms are automatically received, processed, and tracked in Qiiub without manual re-entry. Incoming orders appear in the backoffice order management screen and optionally on a dedicated fulfillment display (KDS). Inventory is committed on receipt and decremented on driver pickup. Driver pickup and order completion are tracked end-to-end. | VERT | v3 | must | proposed | AB | AB-B_46 |