Variant management
Product & Catalog Management Critical in apparel. Includes Variant management Variant management is the core feature for apparel retail. If this is done well, FlowPOS feels “built for clothing” immediately. A “product” is not what you sell in apparel. 👉 You sell variants: size + color (+ style/fit sometimes) Here’s exactly what you need to add for Product & Catalog → Variant management. What “Variant management” means (business meaning) A single product (e.g., “Slim Fit Jeans”) can have: sizes: 28, 30, 32, 34… colors: Black, Blue… sometimes: length, fit, wash, material Each unique combination is a sellable SKU with its own: barcode price (sometimes) cost stock per location reorder rules So you must treat the variant as the real “unit of sale”. Core concept (very important) Product = marketing container Variant (SKU) = operational entity Everything operational should reference variant_id, not product_id: inventory ledger sale_line purchase_order_line replenishment settings barcode labels Product remains for browsing and grouping. What you must track (minimum) Product-level fields name, description category, brand, style active images (optional) attributes that are shared across variants Variant-level fields (critical) variant code / SKU option values (size, color, etc.) barcode (EAN/UPC or internal) price snapshots (or price-list linkage) cost snapshots (last/avg) tax category (optional) status (active/discontinued) Recommended option model (future-proof) You need a generic option system: Option type: Size, Color, Length, Fit Option value: “M”, “Black”, “32”, “Slim” This makes your system reusable across retail types. Database structure (recommended)
- product id business_id name category_id, brand_id, style_id description is_active created_at
- product_option_type Examples: Size, Color, Length id business_id name code (size/color) sort_order
- product_option_value Examples: M, L, Black, Blue id option_type_id value sort_order
- product_variant (SKU table) This is the star. id product_id sku (unique per business) barcode (unique per business, nullable) is_active last_cost (optional snapshot) avg_cost (optional snapshot) created_at
- product_variant_option Join table linking variant to its option values: variant_id option_type_id option_value_id This supports 2D matrix (size x color) and 3D (size x color x length). Inventory integration (must) Inventory must be tracked at variant level: inventory_balance (optional cache) location_id variant_id on_hand_qty reserved_qty damaged_qty Or ledger-only with bucket logic (slower but pure). MVP: hybrid works great. Purchasing integration (must) Purchase orders must buy variants: purchase_order_line.variant_id qty, cost, supplier SKU optional Sales integration (must) Sale lines must sell variants: sale_line.variant_id qty, price snapshot, discount snapshot, tax snapshot Frontend screens (PWA) Variant matrix editor (flagship screen) For apparel, you need: grid: Size (rows) × Color (columns) create variants in bulk show: SKU barcode price (if editable) active toggle bulk actions: generate barcodes apply price to selected cells disable variants This screen is one of your strongest differentiators. Barcode generation (apparel must-have) You need support for: external barcodes (UPC/EAN) internal barcodes (FlowPOS generated) Recommended: allow barcode per variant enforce uniqueness per business label printing uses variant barcode Reports unlocked (Metabase) Once you have variants correctly: sales by size sales by color size curve report (apparel gold) stock by variant sell-through by variant slow movers by size/color replenishment suggestions by variant This is the apparel advantage. MVP vs Phase 2 ✅ MVP variant management product + variant tables size + color option model matrix editor UI barcode per variant inventory + sales + purchasing all use variant_id 🚀 Phase 2 3rd dimension options (length/fit) variant-specific pricing per location variant images discontinued variants lifecycle supplier SKUs per variant automatic size curve replenishment assortment planning Biggest edge cases (important) Some products only have one size or one color (still variant exists) Duplicate barcodes (must prevent) Merging option values (renaming “XL” to “Extra Large”) Discontinue variant with stock remaining Returns must match variant exactly Matrix performance with large catalogs Key recommendation (very important) If FlowPOS is “apparel-first”, then: ✅ Variant management + size curve reports + replenishment by variant should be your flagship trilogy. Most POS systems are weak here. If you share your current product / inventory tables (or your Drizzle/Kysely definitions), I can tell you exactly: what to keep, what to add, what to migrate, and how to avoid breaking your existing data.