Barcode Scanning for Inventory

Paid pluginsize Mplanned, not built

Indicative price, not an offer: €24/mo; barcode label printing, mobile scanning, cycle-count workflows

Generated from docs/plan/paid/barcode-scanning-for-inventory/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

A paid module for inventory-heavy retailers that adds barcode/QR scanning workflows to count and reconcile stock. Provides barcode label printing, mobile-friendly scan UI, cycle-count workflows, and scan audit logs. Turns manual inventory counts from error-prone to verifiable and quick.

The problem

I count inventory manually with pen and paper; errors are frequent and hard to trace. I need QR or barcode scanning to make counts faster and auditable. I also need to generate barcode labels for every bin and product.

What it does

• Barcode label generation: UPC, EAN, or QR code from product SKU, printable as PDF or receipt-printer format
• Barcode config: per-shop settings for standard (UPC/EAN/QR), checksum type, label size
• Scan UI: mobile-friendly form that reads barcode input, logs product_id + qty scanned, timestamp, scanner_id
• Cycle-count workflow: create count session, scan products, finalize count, reconcile to system inventory
• Scan audit log: every scan recorded with product, qty, timestamp, scanner identity, session_id for traceability
• Count reconciliation report: expected qty vs. scanned qty, variance percentage, adjustments needed
• Batch label printing: select multiple products, generate label sheet for bin labels or shipping
• Mobile app or responsive web form for barcode scanning (no native app; web-based)
• Undo scan: remove incorrect scan from count session before finalization
• Count session history: view past counts, compare trends, identify chronic variances

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Barcode hardware drivers or scanner device firmware — clients integrate their barcode scanner; the app reads keyboard input as barcode data
• Shipping label integration with courier APIs — label generation is internal only; no FedEx/UPS API calls
• Advanced inventory analytics or variance trend prediction — history is logged; merchants do manual trend review
• Barcode standards certification — app generates standard-compliant barcodes; compliance is merchant’s responsibility with their barcode provider

Data model

New tables: barcode_configs (id, shop_id, standard enum(upc, ean, qr), label_width_mm, label_height_mm, print_format enum(pdf, receipt)), cycle_counts (id, session_id, created_by, created_at, finalized_at, finalized_by), scans (id, cycle_count_id, product_id, qty, scanned_at, scanner_id, barcode_text), count_reconciliation (id, cycle_count_id, product_id, expected_qty, scanned_qty, variance_qty, status enum(pending_adjustment, approved)).

API

• GET /api/barcode-config
• PATCH /api/barcode-config
• POST /api/barcode-labels/generate
• GET /api/barcode-labels/:productId
• POST /api/cycle-counts
• GET /api/cycle-counts/:id
• POST /api/cycle-counts/:id/scans
• DELETE /api/cycle-counts/:id/scans/:scanId
• POST /api/cycle-counts/:id/finalize
• GET /api/cycle-counts/:id/reconciliation
• POST /api/cycle-counts/:id/reconciliation/:productId/approve

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Barcode label printer UI with template chooser, cycle-count starter with session name, mobile scan form (fullscreen barcode input), reconciliation table comparing expected vs. scanned, variance flag highlighting (red for >10%), print history, undo-scan controls.

The seam — why this is paid

Core owns the barcode interface and scan logging. Paid owns cycle-count workflows, mobile app support, label printing orchestration, and the SLA for scan accuracy audits.

Support commitment: barcode standard compliance, mobile app SLA, count audits

Dependencies

• product module (SKU lookup)
• inventory module (qty reconciliation)
• audit log system (scan traceability)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• Barcode label generates valid UPC/EAN/QR readable by standard scanner apps
• POST scan increments scanned_qty in count session
• DELETE scan removes scan from reconciliation before finalize
• Finalize fails if any product has qty=0 scans but exists in system (incomplete count)
• Reconciliation report shows variance_qty = expected_qty - scanned_qty
• Scan audit log includes scanner_id and timestamp for every entry
• Mobile form accepts barcode input from hardware scanner or manual entry
• Duplicate scan on same count session within 5 sec is flagged (possible scanner double-read)

Risks

Invalid barcode format crashes label printer; concurrent scans to same session cause lost updates (optimistic lock needed); count session deletion loses audit trail if not archived; barcode standards library vulnerability; duplicate detection false-positives block legitimate re-scans.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.