Chapter 03: Systems Being Replaced
Overview
This chapter provides detailed analysis of the systems currently in use that the new POS will replace. Understanding these systems - their capabilities, limitations, and failure modes - informs the design of the replacement system.
3.1 QuickBooks Point of Sale V19
Product Overview
QuickBooks Point of Sale (QB POS) was Intuit’s retail point-of-sale solution designed for small to medium businesses. Version 19 was the final release before Intuit discontinued the product line.
+------------------------------------------------------------------+
| QUICKBOOKS POS V19 PROFILE |
+------------------------------------------------------------------+
| |
| Vendor: Intuit |
| Product: QuickBooks Point of Sale Pro V19 |
| Release Date: 2019 |
| End of Sale: 2023 |
| End of Support: 2024 |
| Architecture: Desktop application (Windows only) |
| Database: Proprietary (Pervasive SQL) |
| Multi-Store: Via Store Exchange (nightly sync) |
| Deployment: On-premises per store |
| |
+------------------------------------------------------------------+
System Architecture
+------------------------------------------------------------------+
| QB POS V19 ARCHITECTURE |
+------------------------------------------------------------------+
| |
| STORE 1 (HQ) STORE 2 (GM) STORE 3 (HM) |
| +---------------+ +---------------+ +------------+ |
| | Windows PC | | Windows PC | | Windows PC | |
| +---------------+ +---------------+ +------------+ |
| | QB POS V19 | | QB POS V19 | | QB POS V19 | |
| | (Server Mode) | | (Client Mode) | | (Client) | |
| +-------+-------+ +-------+-------+ +------+-----+ |
| | | | |
| v v v |
| +---------------+ +---------------+ +------------+ |
| | Local DB | | Local DB | | Local DB | |
| | (Pervasive) | | (Pervasive) | | (Pervasive)| |
| +-------+-------+ +-------+-------+ +------+-----+ |
| | | | |
| | STORE EXCHANGE | | |
| | (Nightly Batch) | | |
| +----------->-------------+---------------------+ |
| SYNC DIRECTION: HQ <-> ALL STORES |
| |
+------------------------------------------------------------------+
Features and Capabilities
What QB POS V19 Does Well
| Feature | Capability | Rating |
|---|---|---|
| Transaction Processing | Reliable sales, returns, exchanges | Good |
| Cash Drawer Management | Drawer counts, Z-outs, blind counts | Good |
| Basic Inventory | Item tracking, quantities, costs | Good |
| Receipt Printing | Standard receipts with customization | Good |
| QuickBooks Integration | Syncs with QuickBooks Desktop | Good |
| Reports | Canned reports for sales, inventory | Adequate |
| Hardware Support | Receipt printers, barcode scanners | Good |
What QB POS V19 Does Poorly
| Limitation | Impact | Severity |
|---|---|---|
| No real-time multi-store | Stale data, overselling | Critical |
| Desktop-only | No remote management | High |
| Windows-only | Hardware constraints | Medium |
| No cloud backup | Data loss risk | High |
| No mobile support | Tied to register | High |
| Limited API | Cannot integrate easily | Critical |
| No Shopify integration | Manual e-commerce process | Critical |
| Outdated UI | Training challenges | Medium |
| No updates | Security concerns | High |
Data Model
QB POS V19 uses a proprietary database structure. Key entities learned from the Stanly project:
+------------------------------------------------------------------+
| QB POS DATA ENTITIES |
+------------------------------------------------------------------+
| |
| ITEMS SALES |
| +----------------------+ +----------------------+ |
| | ItemNumber (SKU/UPC) | | SalesReceiptNumber | |
| | ItemName | | TransactionDate | |
| | Department | | Customer | |
| | QuantityOnHand | | Total | |
| | OnHandStore01 | | TaxAmount | |
| | OnHandStore02 | | PaymentMethod | |
| | ... (up to 10) | | Associate | |
| | Cost | +----------------------+ |
| | Price | | |
| | Vendor | v |
| | LastReceived | +----------------------+ |
| | LastSold | | SalesReceiptItems | |
| +----------------------+ | - ItemNumber | |
| | - Quantity | |
| | - Price | |
| | - Discount | |
| +----------------------+ |
| |
+------------------------------------------------------------------+
Query Interface (QBXML)
QB POS uses QBXML for programmatic access. This is the interface Stanly’s Bridge uses.
Sample Item Query:
<?xml version="1.0"?>
<?qbposxml version="3.0"?>
<QBPOSXML>
<QBPOSXMLMsgsRq onError="continueOnError">
<ItemInventoryQueryRq requestID="1">
<MaxReturned>1000</MaxReturned>
<OwnerID>0</OwnerID>
</ItemInventoryQueryRq>
</QBPOSXMLMsgsRq>
</QBPOSXML>
Lessons Learned from QBXML Integration:
| Lesson | Detail | Design Implication |
|---|---|---|
| Pagination Required | Must use MaxReturned + iterators | API must support cursor pagination |
| No Store Filter | Returns aggregate quantities | Per-store data needs store prefix fields |
| Connection Timeouts | Long queries disconnect | Implement chunked queries |
| Version Sensitivity | Different QBXML versions | Abstract API layer |
Known Issues and Workarounds
Issue 1: Store Number Mapping
Problem: QuantityOnHand returns total across all stores, not per-store.
Current Data:
ItemNumber: NXP0323
QuantityOnHand: 58 (TOTAL - misleading)
OnHandStore01: 12 (HQ)
OnHandStore02: 8 (HM - Store 2)
OnHandStore04: 15 (LM - Store 4)
OnHandStore06: 10 (NM - Store 6)
OnHandStore07: 13 (GM - Store 7)
Workaround in Stanly: Parse OnHandStoreXX fields, map to store codes.
Design Implication: New system will have explicit per-location quantities.
Issue 2: SKU vs UPC Confusion
Problem: ItemNumber field contains UPC barcode, not SKU.
Example:
Returns: ItemNumber = "0657381512532" (UPC)
Expected: SKU = "NXP0323", UPC = "0657381512532"
Root Cause: Original data entry used barcode scanner into ItemNumber field.
Design Implication: New system will have separate, enforced SKU and UPC fields.
Issue 3: Company File Connection
Problem: Connection string format is inconsistent.
Formats Found:
- "Company Data=NEXUS"
- "Computer Name=HQ-PC;Company Data=NEXUS;Version=19"
- "" (empty - uses currently open file)
Workaround in Stanly: Detect format and normalize.
Design Implication: New system uses standard connection configuration.
3.2 Store Exchange
Product Overview
Store Exchange is Intuit’s multi-store synchronization component for QB POS. It runs nightly to replicate data between locations.
+------------------------------------------------------------------+
| STORE EXCHANGE PROFILE |
+------------------------------------------------------------------+
| |
| Function: Nightly data synchronization |
| Schedule: Typically 11:00 PM - 1:00 AM |
| Direction: Bi-directional (HQ as hub) |
| Method: Full data comparison and delta sync |
| Failure Mode: Silent - no notifications on failure |
| Recovery: Manual intervention required |
| Documentation: Minimal (Intuit discontinued) |
| |
+------------------------------------------------------------------+
Synchronization Model
+------------------------------------------------------------------+
| STORE EXCHANGE DATA FLOW |
+------------------------------------------------------------------+
| |
| 11:00 PM |
| +-------+ +-------+ +-------+ +-------+ |
| | HQ | | GM | | HM | | LM | |
| +---+---+ +---+---+ +---+---+ +---+---+ |
| | | | | |
| v v v v |
| [Collect Changes from Each Store] |
| | | | | |
| +------+------+------+------+ |
| | |
| v |
| +--------------------+ |
| | HQ AGGREGATION | |
| | - Merge changes | |
| | - Resolve dupes | |
| | - Update totals | |
| +--------------------+ |
| | |
| v |
| [Push Merged Data to All Stores] |
| | | | | |
| v v v v |
| +-------+ +-------+ +-------+ +-------+ |
| | HQ | | GM | | HM | | LM | |
| +-------+ +-------+ +-------+ +-------+ |
| |
| 1:00 AM - Sync Complete (if successful) |
| |
+------------------------------------------------------------------+
Known Problems
Problem 1: Silent Failures
Issue: Store Exchange fails without notification.
| Failure Mode | Frequency | Detection |
|---|---|---|
| Network timeout | 2x/week | Next day when data is stale |
| Database lock conflict | 1x/week | Morning sync mismatch |
| Partial sync | 2x/month | Some stores updated, others not |
| Corruption | 1x/month | Data integrity errors |
Impact: Staff do not know data is stale. Decisions made on wrong information.
Design Implication: New system will have:
- Real-time sync status dashboard
- Alert notifications on failure
- Automatic retry with exponential backoff
- Manual sync trigger available
Problem 2: Batch Window Constraints
Issue: Sync only runs once per day.
+------------------------------------------------------------------+
| DATA STALENESS TIMELINE |
+------------------------------------------------------------------+
| |
| 10AM 12PM 2PM 4PM 6PM 8PM 10PM |
| |--------|--------|--------|--------|--------|--------| |
| |
| STORE A SELLS ITEM X |
| | |
| v |
| [10:30 AM - Sale recorded locally] |
| |
| STORE B CHECKS INVENTORY |
| | |
| v |
| [2:00 PM - Still shows item X as available at Store A] |
| |
| ONLINE ORDER PLACED |
| | |
| v |
| [5:00 PM - Order placed for item X, shows Store A has stock] |
| |
| RESULT: Oversold - item was sold at 10:30 AM |
| |
| SYNC RUNS |
| | |
| v |
| [11:00 PM - Finally updates inventory across stores] |
| |
| DISCOVERY: Order cannot be fulfilled |
| |
+------------------------------------------------------------------+
Business Impact:
- 12-14 hours of potential data staleness
- Overselling on high-velocity items
- Customer disappointment on online orders
Design Implication: Real-time sync with < 30 second latency.
Problem 3: No Conflict Resolution
Issue: Same item edited at multiple stores creates conflicts.
| Scenario | Store Exchange Behavior | Correct Behavior |
|---|---|---|
| Both stores change price | Last sync wins (random) | Flag for review |
| Both stores adjust qty | Merge adjustments | Sum the deltas |
| Item deleted at one store | Sometimes cascades delete | Protect with confirmation |
Design Implication: Implement proper conflict detection and resolution rules.
3.3 Manual Inventory Counting
Current Process
Without reliable real-time inventory, stores perform frequent manual counts.
+------------------------------------------------------------------+
| MANUAL COUNT PROCESS |
+------------------------------------------------------------------+
| |
| WEEKLY CYCLE COUNT |
| Duration: 2-3 hours per store |
| Staff Required: 2 people minimum |
| |
| Step 1: Print count sheets from QB POS |
| (30 minutes) |
| |
| Step 2: Physically count sections |
| (60-90 minutes) |
| - One person counts |
| - One person records on paper |
| |
| Step 3: Enter counts into QB POS |
| (30-45 minutes) |
| - Manual data entry |
| - High error rate |
| |
| Step 4: Review variances |
| (15-30 minutes) |
| - Manager reviews discrepancies |
| - Often just "approved" without investigation |
| |
| Total Cost per Store per Week: ~3 hours x 2 staff = 6 hours |
| Total Cost per Month (5 stores): ~120 labor hours |
| |
+------------------------------------------------------------------+
Problems with Current Approach
| Problem | Detail | Impact |
|---|---|---|
| Labor Intensive | 6 hours per store per week | $2,400/month in labor |
| Error Prone | Manual transcription errors | Creates new discrepancies |
| Disruptive | Counts done during business hours | Customer service impact |
| Incomplete | Never counts entire store | Partial accuracy at best |
| No Audit Trail | Paper records discarded | Cannot investigate losses |
| Delayed Entry | Counts entered hours later | Data already stale |
Comparison to Target State
| Aspect | Current Manual | Target with RFID |
|---|---|---|
| Time per count | 2-3 hours | 15-30 minutes |
| Staff required | 2 people | 1 person |
| Accuracy | ~95% | ~99.5% |
| Audit trail | Paper (discarded) | Digital (permanent) |
| Frequency | Weekly | Daily or continuous |
| Coverage | Sections | Entire store |
Design Implication: System must support both:
- Traditional barcode scanning (immediate)
- RFID bulk scanning (future phase)
3.4 Paper-Based Transfers
Current Transfer Process
Inter-store transfers use paper forms with manual data entry.
+------------------------------------------------------------------+
| PAPER TRANSFER PROCESS |
+------------------------------------------------------------------+
| |
| SENDING STORE (GM) |
| +----------------------------------------------------------+ |
| | 1. Manager identifies excess inventory | |
| | (Manual review of shelves and QB POS reports) | |
| | | |
| | 2. Calls other stores to find need | |
| | (Phone calls, often voicemail tag) | |
| | | |
| | 3. Creates handwritten transfer slip | |
| | (Paper form, carbon copy) | |
| | - Date | |
| | - From/To stores | |
| | - List of items (SKU, description, qty) | |
| | - Manager signature | |
| | | |
| | 4. Boxes items, attaches slip | |
| | (Physical packaging) | |
| | | |
| | 5. Enters transfer in QB POS (decrease qty) | |
| | (Manual data entry after items leave) | |
| +----------------------------------------------------------+ |
| | |
| | DELIVERY |
| | (Next day usually) |
| v |
| RECEIVING STORE (LM) |
| +----------------------------------------------------------+ |
| | 1. Receives box, finds transfer slip | |
| | | |
| | 2. Counts items, compares to slip | |
| | (Discrepancies are common) | |
| | | |
| | 3. Notes variances on slip | |
| | (Handwritten corrections) | |
| | | |
| | 4. Enters transfer in QB POS (increase qty) | |
| | (Manual data entry - may not match sending store) | |
| | | |
| | 5. Calls sending store about discrepancies | |
| | (Resolution often never happens) | |
| | | |
| | 6. Files paper slip | |
| | (Stored in filing cabinet, rarely referenced) | |
| +----------------------------------------------------------+ |
| |
+------------------------------------------------------------------+
Transfer Problems
| Problem | Frequency | Impact |
|---|---|---|
| Quantity Mismatch | 10% of transfers | Inventory discrepancy |
| Lost Paperwork | 5% of transfers | No audit trail |
| Entry Errors | 15% of entries | Data corruption |
| Delayed Entry | Most transfers | Stale data during transit |
| No Confirmation | All transfers | Sender does not know receipt |
| No Optimization | All transfers | Sub-optimal stock allocation |
Cost Analysis
+------------------------------------------------------------------+
| TRANSFER COST BREAKDOWN |
+------------------------------------------------------------------+
| |
| Per Transfer (Average) |
| +----------------------------------------------------------+ |
| | Sending Store | |
| | - Manager time to identify need: 15 min | |
| | - Phone calls to find destination: 10 min | |
| | - Create transfer slip: 10 min | |
| | - Box and label items: 10 min | |
| | - Enter in QB POS: 10 min | |
| | Subtotal: 55 minutes | |
| +----------------------------------------------------------+ |
| | Receiving Store | |
| | - Receive and unbox: 10 min | |
| | - Count and verify: 15 min | |
| | - Note discrepancies: 5 min | |
| | - Enter in QB POS: 10 min | |
| | - Resolve issues (calls): 10 min | |
| | Subtotal: 50 minutes | |
| +----------------------------------------------------------+ |
| | Total Labor: 105 minutes per transfer | |
| | At $15/hour average: ~$26 labor cost per transfer | |
| | | |
| | Average transfers per week: 15 | |
| | Monthly transfer labor cost: ~$1,560 | |
| +----------------------------------------------------------+ |
| |
+------------------------------------------------------------------+
Target Transfer Process
| Step | Current | Target |
|---|---|---|
| Identify Need | Manual review | System recommendation |
| Find Destination | Phone calls | Real-time availability |
| Create Transfer | Paper form | Digital request |
| Approve Transfer | Manager signature | Digital approval |
| Track Transit | None | Status tracking |
| Receive Transfer | Manual count | Scan to confirm |
| Resolve Discrepancies | Phone calls | In-app workflow |
| Total Time | 105 minutes | 20 minutes |
3.5 Separate Shopify Administration
Current State
Shopify and QB POS operate as completely separate systems with no integration.
+------------------------------------------------------------------+
| CURRENT SHOPIFY WORKFLOW |
+------------------------------------------------------------------+
| |
| SHOPIFY ECOSYSTEM QB POS ECOSYSTEM |
| +------------------------+ +----------------------+ |
| | Shopify Admin | | QuickBooks POS V19 | |
| | | | | |
| | - Products | X X | - Items | |
| | - Inventory | X X X | - Inventory | |
| | - Orders | X X | - Sales | |
| | - Customers | X X X | - Customers | |
| | - Analytics | X X | - Reports | |
| +------------------------+ +----------------------+ |
| | | |
| | NO INTEGRATION | |
| | (Manual Bridge Only) | |
| v v |
| +------------------------+ +----------------------+ |
| | E-commerce Website | | 5 Physical Stores | |
| | - Customer orders | | - Walk-in sales | |
| | - Online payments | | - Cash/card payments | |
| +------------------------+ +----------------------+ |
| |
+------------------------------------------------------------------+
Manual Synchronization Tasks
| Task | Frequency | Time Required | Error Rate |
|---|---|---|---|
| Update Shopify inventory from QB | Daily | 2 hours | 5-10% |
| Process online orders in QB | Per order | 15 min each | 3-5% |
| Add new products to both systems | Per product | 20 min each | 5% |
| Sync price changes | Weekly | 1 hour | 10% |
| Reconcile discrepancies | Weekly | 2 hours | N/A |
Problems
Problem 1: Inventory Mismatch
+------------------------------------------------------------------+
| INVENTORY DIVERGENCE EXAMPLE |
+------------------------------------------------------------------+
| |
| Item: Nike Air Max 90 - Size 10 (SKU: NAM90-10) |
| |
| Reality: |
| GM: 2 units |
| LM: 1 unit |
| NM: 0 units |
| HQ: 5 units |
| ------------------ |
| Total Available: 8 units |
| |
| What Shopify Shows: 15 units |
| (Not updated since last manual sync 3 days ago) |
| |
| Result: Customer orders 10 units for wholesale order |
| Only 8 units available |
| Manual scramble to cancel/partial fill |
| |
+------------------------------------------------------------------+
Problem 2: Order Fulfillment Chaos
| Issue | Description | Frequency |
|---|---|---|
| Duplicate Orders | Same order entered in QB twice | 2-3/week |
| Missed Orders | Order not entered, never fulfilled | 1-2/week |
| Wrong Store | Order fulfilled from wrong location | 3-4/week |
| Late Fulfillment | Order sits in queue for days | Daily |
Problem 3: Customer Data Silos
+------------------------------------------------------------------+
| CUSTOMER DATA FRAGMENTATION |
+------------------------------------------------------------------+
| |
| Customer: John Smith |
| |
| SHOPIFY RECORD QB POS RECORD |
| +------------------------+ +----------------------+ |
| | Email: john@email.com | | Name: John Smith | |
| | Phone: 555-123-4567 | | Phone: 555-123-4567 | |
| | Orders: 15 online | | Transactions: 8 | |
| | Total Spent: $2,340 | | Total: $1,200 | |
| | Address: Current | | Address: Old (2022) | |
| | Loyalty Points: N/A | | Loyalty: N/A | |
| +------------------------+ +----------------------+ |
| |
| REALITY: |
| - Same customer, two different profiles |
| - Total relationship: $3,540 (unknown to either system) |
| - Cannot offer unified loyalty program |
| - Cannot track true customer value |
| |
+------------------------------------------------------------------+
Stanly Project Learnings
The Stanly project was built specifically to address Shopify integration. Key learnings:
| Learning | Detail | Design Implication |
|---|---|---|
| Webhooks vs Polling | Webhooks for orders, polling for inventory | Support both patterns |
| Rate Limits | Shopify limits API calls per minute | Implement rate limiter |
| Order States | Multiple states (pending, paid, fulfilled) | State machine design |
| Inventory Locations | Shopify supports multi-location | Map locations correctly |
| Fulfillment Flow | Separate from order creation | Two-step process |
3.6 What We Keep vs Replace
Decision Matrix
+------------------------------------------------------------------+
| KEEP vs REPLACE DECISION |
+------------------------------------------------------------------+
| |
| KEEP (Re-use) REPLACE (New System) |
| +-----------------------+ +-----------------------+ |
| | Receipt Printers | | QuickBooks POS V19 | |
| | Barcode Scanners | | Store Exchange | |
| | Cash Drawers | | Manual Counting | |
| | Shopify Store | | Paper Transfers | |
| | PostgreSQL Database | | Dual Admin Systems | |
| | Tailscale VPN | | Offline = No Work | |
| +-----------------------+ +-----------------------+ |
| |
| MIGRATE (Transform) INTEGRATE (Connect) |
| +-----------------------+ +-----------------------+ |
| | Historical Sales Data | | Payment Processor | |
| | Customer Records | | Shopify API | |
| | Inventory Baselines | | RFID Hardware | |
| | Product Catalog | | Accounting System | |
| +-----------------------+ +-----------------------+ |
| |
+------------------------------------------------------------------+
Migration Requirements
| Data Type | Source | Volume | Complexity |
|---|---|---|---|
| Products | QB POS + Shopify | ~30,000 SKUs | Medium |
| Customers | QB POS + Shopify | ~15,000 records | High (dedup) |
| Inventory | QB POS | 5 locations x 30K SKUs | Medium |
| Sales History | QB POS | 3 years | Low (import only) |
| Vendors | QB POS | ~200 vendors | Low |
Hardware Compatibility
| Hardware | Current Model | Compatible | Notes |
|---|---|---|---|
| Receipt Printer | Epson TM-T88V | Yes | ESC/POS standard |
| Barcode Scanner | Symbol LS2208 | Yes | HID keyboard mode |
| Cash Drawer | APG Vasario | Yes | Printer-driven |
| POS Terminal | Dell OptiPlex | Yes | Will run new software |
| Touch Screen | ELO 15“ | Yes | Standard USB |
| Card Reader | Verifone MX915 | Maybe | Depends on processor choice |
3.7 Summary
Systems Being Replaced
| System | Primary Issues | Replacement Strategy |
|---|---|---|
| QuickBooks POS V19 | End of life, no real-time, no API | Custom POS application |
| Store Exchange | Batch sync, silent failures | Real-time sync engine |
| Manual Counting | Labor intensive, error prone | Barcode/RFID scanning |
| Paper Transfers | Slow, no tracking | Digital transfer workflow |
| Separate Shopify | Manual sync, errors | Native integration |
Key Learnings Applied
- From QB POS: Need proper SKU/UPC separation, per-location quantities
- From Store Exchange: Real-time sync with failure alerts
- From Manual Counting: Mobile-first scanning workflow
- From Paper Transfers: End-to-end digital tracking
- From Shopify Split: Single source of truth for inventory
Next Steps
- Chapter 04: Define measurable success criteria to validate replacement
Document Information
| Attribute | Value |
|---|---|
| Version | 1.0.0 |
| Created | 2025-12-29 |
| Author | Claude-NAS |
| Status | Draft |
| Part | I - Foundation |
| Chapter | 03 of 04 |
This document is part of the POS Blueprint Book. All content is self-contained and requires no external file references.