Handling sizes and colours without a variant system

If you sell clothing, the first thing anyone tells you to look for in a POS is variant support. A single product called “Oxford shirt” with a grid behind it: four sizes across, three colours down, twelve stock figures in the boxes.

It is a genuinely good feature and it is the right answer for some shops. But it is also the feature most likely to be the reason a small shop rules out software that would otherwise have suited it perfectly, and that is usually a mistake. So it is worth understanding what a variant grid actually buys you, because the answer is smaller than it looks, and what it costs, because that is bigger than it looks.

What a variant grid is actually for

Underneath, a variant system stores twelve separate stock figures with twelve separate codes. Twelve rows in a table. That is unavoidable, because a medium blue shirt and a large blue shirt are physically different objects sitting in different places on your shelf, and there is no clever data model that changes that.

So the grid is not saving you from having twelve things. You have twelve things either way. What it gives you is three conveniences:

1. One row in the product list instead of twelve, so browsing your catalogue is less cluttered.
2. A grid to type stock into, which is genuinely faster when a delivery arrives with all twelve.
3. Reporting that rolls up, so you can ask how the Oxford shirt did without adding twelve numbers together.

Those are real. Number three is the one that matters most and the one shops notice missing.

What it does not give you is fewer things to count, fewer labels to print, or fewer decisions about what to reorder. Those are the same either way.

The workaround, done properly

Every system that lacks variants can model them as separate products. The trick is doing it with discipline, because done carelessly it is genuinely awful and done well it is barely worse than a grid.

Put the structure in the code, not in the name. This is the whole thing. Build codes with a pattern, so:

OXF-BLU-S
OXF-BLU-M
OXF-BLU-L
OXF-WHT-S
OXF-WHT-M

Now search behaves like a grid. Type OXF and you get all twelve. Type OXF-BLU and you get one colour in every size. Type OXF-BLU-M and you get the exact garment. A cashier finds the item as fast as they would in a grid, arguably faster, because typing five characters beats tapping through a two-dimensional picker.

Keep the name human and consistent. “Oxford shirt, blue, M”. Same word order every time, colour before size, no abbreviations in some and not others. The moment one is “Oxford Shirt Blue Medium” and another is “oxford blue, sz M”, search stops working and no amount of good code structure saves you.

Use categories as the roll-up. If your system has product categories, a category per style, or per range, gives you back most of item three above. Sales by category is your sales by style. It is not as neat as a variant grid, and it works.

Decide your dimensions once and never deviate. Colour then size. Or size then colour. Pick one, write it on a card, stick it inside the stockroom door. Two people inventing conventions independently is how a catalogue becomes unsearchable in about six weeks.

Set up this way, a 12-variant style takes about four minutes to enter, mostly copy and adjust. The honest cost is roughly two extra minutes per style compared to a grid, plus a slightly longer product list.

When you genuinely need real variants

I am not going to pretend the workaround scales forever. Three situations where you should insist on a proper variant system and not compromise:

Serious breadth. Somewhere around thirty styles with ten or more variants each, so three hundred-plus lines that are all near-duplicates of each other, the manual approach stops being tedious and becomes unmanageable. Deliveries take too long to enter and the product list becomes unnavigable.

Selling online from the same stock. Web stores are built around the variant model, and if your shop and your website share one stock pool, you want the POS to speak the same language. Reconciling a grid on the website against 200 flat products in the till is a job you will hate.

Size-curve buying. If you order by curve, two smalls, four mediums, four larges, two extra-larges, and you want the system to help you see that mediums sell out in three weeks while extra-larges sit for a season, a grid makes that visible at a glance and flat products make you work for it. Boutiques that buy well really do use this.

If none of those three describe you, and for a shop with, say, forty styles at a time it often will not, the workaround is fine and you should not eliminate a system over it.

The part that matters more than variants

Something worth saying, because it gets lost in the feature comparison.

The expensive problem in a clothing shop is not how your catalogue is structured. It is that you are holding capital in the shape of garments, some of which will not sell at full price, and every week you do not notice that is a week closer to marking them down. What you need from a system is to be told which lines have not moved in six weeks, which sizes always sell out first, and what your actual margin is after the end-of-season reductions.

A variant grid helps with the second of those. It does nothing for the first or the third. I have seen shops choose software on the strength of a beautiful grid and then never once look at a slow-moving report, which is the wrong way round. Get the reorder and slow-mover discipline working first, on whatever structure you have.

Also, and this is not a small thing in clothing: returns are a much larger part of your week than in most trades, and a system that handles an exchange for a different size cleanly, as a real document rather than a manual fudge, will save you more time per month than the grid will.

Where StoreWave sits

Plainly: StoreWave has no variant grid. A product is one row with one code, and sizes and colours are modelled as separate products using the naming and code discipline above. That is a real limitation and it is the right thing for a clothing shop to know in the first paragraph rather than the fifth screen.

What is there to make the workaround work properly: codes are unique per shop, and search matches anywhere inside a name, a code or a barcode, so OXF finds the whole style and BLU finds every blue thing in the shop, which is what makes a structured code scheme behave like a grid at the counter; product categories give you the roll-up reporting by style or range; each product has its own barcode, so you can label and scan by size; and each has its own reorder level, which is arguably better than a grid for size-curve work, since a size that always sells out can be given a higher trigger than one that lingers.

Exchanges are handled properly rather than fudged, which matters here. A size swap is recorded as a real return plus a real sale, so the stock moves both ways correctly and the revenue nets out, instead of somebody editing yesterday’s receipt.

If you are running forty styles and you are disciplined about codes, this works and shops do run it this way. If you are running three hundred lines, buying by curve, or sharing stock with a web store, buy something with a variant grid. That is the honest answer and it is not the one that sells you a subscription.