The key is simple: in SGApps you encode attributes directly into the SKU
using a common-prefix convention
(SHIRT-COTV.M.WHT.COT, SHIRT-COTV.L.WHT.COT),
not through a parent-child relationship. Each combination is an independent SKU
with its own stock, its own barcode label, and its own price. The common prefix
(SHIRT-COTV.*) groups them in searches and reports.
A design choice. The 'parent with variants' model looks elegant on paper, but in practice it generates ambiguous aggregated stock, prices that don't align with the correct variant, and 'where did that L, white, cotton T-shirt go?' with no clear answer. The prefix convention takes the hierarchy out of the model and puts it into the code.
Each size x color x material = an independent SKU
with its own stock, price, and barcode. SHIRT-COTV.M.WHT.COT and
SHIRT-COTV.L.WHT.COT are two equal entities, not 'variants of
something'.
SHIRT-COTV.* automatically aggregates all combinations of the
same model in searches and reports. You immediately see how much sold per
model, per size, per color — without maintaining a separate 'parent product'
entity.
Stock stays the computed result of recorded movements (goods receipt, sale, return, inventory) — on the exact SKU. There's no 'parent stock' to reconcile. Every sale decrements exactly what it should.
We define the structure together at onboarding, tailored to your habits. A few examples from real catalogs (you can adopt any of them or propose your own).
SHIRT-COTV.M.WHT.COT
SHIRT-COTV.L.WHT.COT
SHIRT-COTV.M.BLK.MIX
Model (SHIRT-COTV) · size (M/L) ·
color (WHT/BLK) · material
(COT/MIX). The SHIRT-COTV.* prefix
aggregates the whole model.
SHOE-XX.42.BLK · SHOE-XX.43.BLK
BAG-XX.RED.LTH · BAG-XX.BLK.CNV
WATCH-XX.STL.WHT
Same logic — a model prefix, attributes following with a consistent separator. The convention is not limited to textiles.
A technical detail that matters in practice:
✅ Allowed: letters (A-Z, a-z),
digits (0-9), dashes (-), dots (.),
underscores (_).
❌ Not allowed in the code: space (" ") and
forward slash (/). They cause issues with URLs, CSV exports,
barcodes, and integrations.
The display name doesn't have these restrictions — you can write "T-shirt COTV / 100% cotton, white, size M" as descriptively as you like. The rule applies only to the internal SKU code.
Three recurring flows in a clothing store — how they work on SGApps once the SKU convention is defined.
The customer brings a T-shirt to the checkout. You scan the barcode label —
SGApps sees the exact SKU
(SHIRT-COTV.M.WHT.COT), the price, the seasonal discount
(if active), the remaining stock. Everything decremented from the specific
SKU, not from an aggregated pool.
The collection arrives. You prepare the SKU list following the prefix convention (one line per size x color x material combination) with quantity plus price. We run the import at onboarding; for later collections, bulk import is delivered as paid support effort, priced in hours after evaluation. The average cost recalculates, barcode labels are prepared for printing.
The customer wants to exchange M for L. You issue a void receipt for the M SKU (stock is recovered automatically) and a new sale receipt for the L SKU. Both operations meet MEV requirements for return / reissue. The cashier follows a guided flow, without manually re-entering data.
Each SKU generates a unique barcode (EAN-13 or Code-128). Label templates include name + size / color from the SKU + price + barcode, for Zebra / Godex / Argox printers. You reprint when labels get damaged or when the seasonal price changes.
The same data, two perspectives: the per-SKU detail (for the operator at the shelf) and grouping by prefix (for the manager placing orders).
╔═══════════════════════════════════════════════════════╗ ║ Sales this month — prefix filter: SHIRT-COTV.* ║ ╠═══════════════════════════════════════════════════════╣ ║ SHIRT-COTV.M.WHT.COT 18 pcs 5 400 MDL ║ ║ SHIRT-COTV.M.BLK.MIX 12 pcs 3 600 MDL ║ ║ SHIRT-COTV.L.WHT.COT 9 pcs 2 700 MDL ║ ║ SHIRT-COTV.L.BLK.MIX 5 pcs 1 500 MDL ║ ║ SHIRT-COTV.S.WHT.COT 3 pcs 900 MDL ║ ║ ║ ║ TOTAL model SHIRT-COTV.* 47 pcs 14 100 MDL ║ ╚═══════════════════════════════════════════════════════╝
That's how you order from your supplier only the sizes / colors that move (M.WHT and M.BLK here) and liquidate the slow combinations (S.WHT). Reduced overstock on dead combinations, less capital tied up on the shelf.
Yes. You can associate multiple barcodes with the same SKU (useful for different packaging: single unit vs. pack of 3). At scan time, any code leads to the same SKU with its stock.
You extend the prefix. If additional variants appear
(e.g. sleeve length on T-shirts), you add a segment to the convention for
new collections (SHIRT-COTV.M.WHT.COT.LONG). Old SKUs remain
valid. You consult with us before the change — we verify catalog coherence
and make the transition together.
At onboarding we clean them together — mapping from the old code to the new one, using the chosen convention. Physical barcodes already printed remain valid (we keep them associated with the new SKU). Label reprinting happens as you sell / restock the products.
Our recommendation: consistency — you either choose
uppercase throughout (SHIRT-COTV.M.WHT.COT) or lowercase
throughout and stick with it. At onboarding we set the policy and apply it
uniformly across the catalog. A catalog with half UPPERCASE and half
lowercase = a search trap later on.
SHIRT-COTV.*)?
Yes. The catalog's search field filters in real time by
any text in the SKU or name. You type SHIRT-COTV
→ you see all combinations of the model with their stock. The filter works
on the current result, without a server roundtrip.
The Micro package covers up to ~1500 distinct SKUs (typical profile of a fashion shop with 1-2 checkouts). Above ~500 receipts/day or ~2500 distinct SKUs you upgrade to Start, with no migration — only the plan changes, the database and settings stay in place.
The structures above reflect our standard offering, but each client is discussed individually. We define the SKU convention based on your real catalog, and the onboarding scope (cleaning up old codes, initial import, integrated label printers) is adjusted after evaluation. The binding final offer is the one in the written quote plus the signed contract.
For a clothing store with 1-2 checkouts, the catalog with prefix-based SKUs (size x color x material), separate stock per SKU, and barcode label printing is covered by the Micro Package (150 MDL/month). We configure the SKU convention at onboarding based on the discovery discussion. For custom requirements (massive cleanup of old codes, non-standard label printer integration, migration from another system) — priced as support hours after evaluating the source data. Package comparison plus current pricing → see the Decision-maker page.
20 minutes on the phone and we'll tell you exactly which SKU convention is realistic for your catalog, how we estimate cleaning up old codes, and what hardware you need for label printing. Initial consultation is free.
SGAPPS LABS SRL · Chișinău, Moldova · Continuously in production since 2018 · POS · ERP · MEV fiscal register · Android fleet