Seven Sizes, One Item: Retail Without Variants
There is no variant model here. A shirt in four colours and five sizes is twenty items, not one item with options. That is a real constraint, it has one correct answer, and the answer has to be chosen before you name your first five hundred items rather than after.
A clothing shop sells one shirt. To the buyer it is one shirt. To the supplier it is one style code. To the customer it is the blue one in medium. And to a stock system it is twenty different things, each of which can be in stock or out of stock independently, and nineteen of which are useless to the customer standing in front of you.
Systems built for apparel handle this with variants: one product, a set of attributes, a stock figure per combination. This system has no variant model of any kind. Knowing that before you build your item list saves a rebuild; discovering it afterwards costs you a weekend and your stock history.
What an item actually is here
Precision first, because the shape of the constraint decides the workaround. An item carries a name, a category, a description, a single barcode, a buying price, a selling price, a weighted average cost and a whole-number stock figure, with a quantity held per warehouse and location.
What it does not carry: any attribute list, any option set, any parent-child relationship to another item, any second barcode, and any concept of a variant. There is no size field, no colour field, and no generic attribute mechanism that a size or colour could live in as structured data.
The rule
One item per independently scannable, sellable, countable thing. If it has its own barcode, its own shelf space and its own reorder decision, it is its own item. That is not a workaround for a missing feature; it is the only structure the system can hold correctly, and fighting it produces stock figures that lie.
The temptation is the opposite: one item called "Oxford Shirt" with a stock of 137, and the colour and size worked out at the counter. It is one line in the item list instead of twenty. It is also a system that will cheerfully sell you a medium when you have only extra-large left, will never tell you that blue is finished, and will compute a reorder point across four colours as if they were interchangeable.
A stock figure that spans things a customer cannot substitute for each other is not a stock figure. It is a total.
Naming, which is now load-bearing
With no attribute fields, the variant lives in the item name — which means your naming convention is doing structural work, and an inconsistent one will cost you every search you ever run. Decide the format once, write it down, and hold everybody to it.
What the shop calls it What the item should be named
Blue Oxford shirt, medium Oxford Shirt — Blue — M
Style, then colour, then size, separated consistently. Searching "Oxford" gets the family; searching "Oxford Blue" narrows it; the size sorts last so the list reads in a predictable order.
Bata school shoe, size 34, black School Shoe Bata — Black — 34
Numeric sizes want padding if you have more than nine of them: 04, 34, 40. Otherwise size 4 sorts between 39 and 40 and your shelf list stops matching your shelf.
500ml Coke Coca-Cola — 500ml
Pack size is a variant like any other. The same discipline applies, and it is why the size belongs in the name rather than in the description.
Cement Cement Bamburi — 50kg bag
Brand and unit both belong in the name, because both change the price and neither has a field.
Assorted socks Not an item
If the price and the reorder decision genuinely do not depend on which pair, then it is one item and "assorted" is honest. If they do, this is where a shop starts lying to itself.
The separator matters more than which convention you pick. Use one delimiter, always, in the same order, and never mix "Blue M" with "M Blue" — the second one makes every prefix search useless.
What to do with size and colour as data
The name makes an item findable by a person. It does not make it filterable or groupable by the system. For that there are two mechanisms, and they do different jobs.
The first is category. Categories are a real field on an item, used for filtering, for scoping stock counts and for scoping variance rules. That last one is the reason to take categories seriously: a variance rule can auto-approve small differences in one category and demand review in another, so your category structure is also your control structure.
The second is custom fields on items. These give you your own structured fields — a size, a colour, a supplier style code, a season — captured per item, consistently, and available on the item record. That is the closest thing here to an attribute model, and for a shop that wants to answer "how much extra-large do we hold across all styles" it is the mechanism to use.
You need to find the item at the counter
The name carries it
A consistent "Style — Colour — Size" name is searched, printed on documents and read by the storekeeper. This is the primary job and the name does it well.
You need to group or filter by style family
Use the category
Categories are a real field with real consequences downstream in counting and variance rules. Structure them at the level you actually manage — "Shirts", not "Blue shirts".
You need to report on a dimension across styles
Use a custom field on items
A size or colour custom field, populated consistently, is what lets you answer questions the name cannot. It has to be populated on every item to be worth anything, so do it at creation rather than as a retrofit.
You want a size-curve or matrix purchase order
This is not available
Buying goes line by line. A purchase order for twelve of each of five sizes is five lines, typed. There is no grid entry and no size-curve template, and no amount of naming discipline creates one.
You are tempted by one item for the whole style
Do not
It saves nineteen lines in a list and costs you every availability answer, every reorder point and every count. This is the one option in the list that is actually wrong rather than merely limited.
What the constraint actually costs, priced honestly
Four losses, in descending order of how much they will annoy you.
| What you lose | How much it hurts | What you do instead |
|---|---|---|
| Matrix or grid entry when buying and receiving | Daily, if you buy apparel | One purchase order line per size. Tedious and correct. A spreadsheet import is the practical relief if you buy in large curves |
| A size-curve or sell-through report by size across styles | Monthly, and it is real | A size custom field on every item, then export and pivot. The data exists; the report does not |
| Roll-up availability for a style family | Weekly | Category, or a naming prefix search. Both work; neither is a single stock figure |
| One item page showing every variant | Cosmetic | Nothing. This is the part that is genuinely just absent, and it costs you screen convenience rather than information |
Notice what is not on that list: correctness. A twenty-item structure gives you accurate stock, accurate cost, accurate reorder points per size and accurate counts. It is more typing and no less true. The single-item shortcut is less typing and false.
How this lands on the rest of the system
Two consequences reach outside the item list, and both are arguments for getting the structure right on day one.
Reorder points are per item, which under this structure is exactly what you want: extra-large runs out at a different rate from medium, and a per-size reorder point says so. Had you modelled the style as one item, the reorder point would fire on a total that stays comfortable while the sizes people actually buy are finished. The constraint and the correct answer point the same way here.
Counting is per item-location row, so a count of twenty items is twenty lines rather than one. That sounds like a cost until you have run a count on a shop that used the single-item shortcut, discovered a variance of eleven units, and had no way to know which colour was missing. Twenty lines is the price of an actionable count.
Score this before you load your item list, not after. Renaming five hundred items is possible; restating their stock history and their reorder points is a different kind of afternoon.
Every sellable thing is its own item
Make them prove it: Pick a style you stock in several sizes. Is there one item or several?
Names follow one convention
Make them prove it: Read ten item names in the same family. Is the order and the separator identical in all ten?
Numeric sizes are padded
Make them prove it: Sort your shoe items by name. Does size 4 appear near size 40?
Categories match how you manage, not how you display
Make them prove it: Could a variance rule be usefully written against each category?
The reporting dimension is a custom field
Make them prove it: Can you list all extra-large stock across every style, without reading names?
Reorder points are set per size
Make them prove it: Is the reorder point on the size people actually buy different from the rest?
What we do and do not do
What AWRA OpsHub does today
- One barcode per item, scannable at the till, which is what makes per-variant items work at the counter.
- Item categories as a real field, used for filtering and for scoping stock counts and variance rules.
- Custom fields on items, giving you structured size, colour, style-code or season data of your own.
- Stock per warehouse and location per item, so per-variant availability is genuinely accurate.
- Reorder points per item, which under a one-item-per-variant structure means per size — the right granularity.
- Weighted average cost per item, so a colour that was bought at a different price carries its own cost.
What it does not do
- No variant, option or attribute model. No parent product, no child SKUs, no combination grid. This is absent, not partially built.
- One barcode per item. A second supplier barcode for the same physical thing has nowhere to live.
- No matrix or grid entry on purchase orders, receipts or counts. Every size is its own typed line.
- No size-curve or sell-through-by-size report. With a size custom field the data exists; the report is an export and a pivot.
- No roll-up availability for a style family as a single figure — category filters and name searches are the substitutes.
- Whole-number stock only, as everywhere else in the system.
If you buy apparel in deep size curves every month, the missing matrix entry is a real recurring cost and worth pricing before you commit. A spreadsheet import of purchase order lines is the practical answer, and it is worth setting up properly rather than typing five lines at a time forever.
Related reading
- A bag is not a kilo: why stock is counted in whole numbers — the same naming-carries-the-structure problem, applied to units of measure.
- Counting the shop without closing it — why your category structure is also your control structure.
- Best POS and inventory system for Kenyan retail — where to put this on an evaluation checklist.
- SKUs and bin locations: naming stock so it runs itself — the other half of item-list discipline.
See the item master and custom fields
Items with barcodes, categories, per-location stock, per-item reorder points and your own structured fields for the dimensions the system does not name.
Explore inventory managementFrequently asked questions
Can one item hold several sizes or colours?
No. There is no variant, option or attribute model — no parent product with child SKUs, and no combination grid. Each independently scannable, sellable, countable thing is its own item. A shirt in four colours and five sizes is twenty items, each with its own barcode, its own stock figure, its own cost and its own reorder point.
Could we not just use one item for the whole style and sort it out at the counter?
You can, and it is the one genuinely wrong answer in this article. A single stock figure spanning things a customer cannot substitute will let you sell a medium when only extra-large remains, will never report that blue has finished, and will compute a reorder point on a total that stays comfortable while the sizes people actually buy run out. It saves nineteen lines in a list and costs you every availability answer.
Where do size and colour live if there are no fields for them?
In two places, doing two jobs. The item name carries them for humans — searching, printing, picking — which is why a single consistent naming convention matters so much. Custom fields on items carry them as structured data, which is what lets you answer questions the name cannot, such as total extra-large holdings across every style. Populate custom fields at item creation; retrofitting them across hundreds of items is the expensive path.
Can we raise a purchase order as a size grid?
No. There is no matrix or grid entry anywhere — purchase orders, receipts and counts are all line by line, so twelve of each of five sizes is five typed lines. If you buy in deep curves regularly this is a real recurring cost, and the practical relief is a spreadsheet import of order lines rather than typing. Worth setting up properly if apparel buying is central to your business.
Can we report sell-through by size across all styles?
Not as a report. If you populate a size custom field consistently on every item then the data exists and the answer is an export and a pivot table. Without that field, size lives only inside item names and the question becomes text parsing. This is the strongest practical argument for using custom fields from the first item you create.
How should we name items so searching works?
Pick one order and one delimiter and never vary them — "Style — Colour — Size" is a sound default, because searching the style gets the family, adding the colour narrows it, and the size sorting last keeps the list readable. Pad numeric sizes with a leading zero if you have more than nine, or size 4 sorts between 39 and 40 and your shelf list stops matching your shelf.
Does one item per variant make stock counting harder?
It makes it longer and much more useful. Twenty items is twenty count lines instead of one, which is the price of a count you can act on: a variance of eleven units on a single style item tells you nothing about which colour walked out. Counts are per item-location row here, and scoping a session by category keeps the count small enough to do before opening.
