Generate SKUs in bulk for a Shopify catalog

What a SKU is for, and what it is not

A SKU is your internal name for a variant. It never leaves your business, it is not regulated, and — unlike a GTIN — nobody has to issue it to you. Its whole job is to be unique, stable and legible to a human reading a picking list.

A barcode is the opposite: it is the machine's name for the same thing, and if it is an EAN or UPC that will cross a retailer's till, it belongs to a numbering space you have to own. Markio keeps the two separate for that reason. You can generate as many SKUs as you like; barcodes it will generate freely as internal codes, and from your GS1 company prefix where you have one.

A pattern, not a spreadsheet formula

A numbering rule in Markio is a pattern plus a counter. The pattern is built from tokens that are filled in per variant:

So {vendor:3}-{option1}-{seq:5} on a grey medium T-shirt from Acme produces ACM-M-00042.

Text tokens are folded to characters the target symbology can actually encode, so a title with an ampersand or an accent in it does not produce a code that will not print. As you type the pattern, the form shows what it produces from a sample product — you never save a rule that only fails on the thousandth variant.

The part that quietly matters: the counter

Every rule owns its own counter, and the counter is handed out inside a database transaction. Two people pressing Issue at the same moment get different ranges rather than the same numbers.

That sounds like an implementation detail until you consider what the alternative produces: two variants with the same SKU, which is exactly the damage the catalog audit exists to clean up. Generating identifiers is not a place to leave anything to luck.

A rule can also carry a ceiling — the point where a numbering space runs out. For a GS1 company prefix that ceiling is real, and Markio refuses to issue past it rather than minting a code you do not own.

Filling in an existing catalog

The common case is not a fresh start. It is a shop where most variants have a SKU, some never got one, and a few got one twice.

1. Run the catalog audit first. It reports "No SKU" and "Same SKU on different variants" separately, so you know what you are filling in and what you are repairing.
2. Issue to the variants that have none. Select by vendor, product type, tag or collection; Markio only writes to variants where the field is empty, so an existing code is never quietly replaced.
3. Repair the duplicates deliberately. Which of the colliding variants keeps the code is a decision about physical stock, so it is offered as a preview with an undo, never applied silently.

Bulk issue runs 500 variants at a time — run it again to continue. Every write is recorded in the activity log with the staff account behind it, so a catalog rewrite always has an author.

Automatically, for products created from now on

A scheme applied once decays. Markio can watch for products created or edited without a code and issue one from a rule you pick — off by default, because writing to a merchant's catalog without being asked is not a feature.

It applies to products created after you switch it on. Variants that were already sitting there empty stay empty until you run a bulk issue over them, which is the honest behaviour: a background job silently rewriting an old catalog is not something you would want to discover afterwards.