Custom SKU

Enough to identify the variant unambiguously, and nothing that changes. Style, colour and size are stable for the life of the product. Season, price tier and supplier are not, and encoding them means the SKU becomes wrong rather than merely dated when they change.

The most useful property is that a human reading a SKU on a shelf label can tell what it is without a lookup. That is worth more than compactness, and it is worth more than any scheme that packs extra meaning into fewer characters.

A reasonable shape is style root, then colour, then size, separated consistently. Everything else belongs in a field of its own, where it can be filtered and reported on properly rather than parsed back out of a string.

Many catalogs let the POS generate a sequential SKU. That is fine for uniqueness and useless for everything else: it cannot be matched against a vendor document, it cannot be read, and two records for the same product will happily receive different numbers. If you rely on generated SKUs, the matching burden shifts entirely onto the manufacturer SKU and the product name.

Whatever separator and ordering you choose, apply it everywhere. A catalog where some SKUs use hyphens and others use nothing, or where colour sometimes precedes size, cannot be searched or reconciled reliably. The specific format matters far less than the fact that there is only one of them.

The test is whether someone who has never seen your catalog could predict the SKU of a product they are holding. If they can, the convention is doing its job. If they have to look it up, the SKU is an opaque key and every process that depends on reading it will need a lookup you did not budget for.