Product Variants: Size and Color

Product variants in a store script are size, color, or configuration with separate stock and often their own price. They are not decorative buttons on a product card. If stock is shared as "100 pieces for all sizes", you will sell the tenth XL when warehouse has zero and then apologize manually.

Catalog: product catalog, order: store.

How it usually works in the admin panel

• Attributes: Size, Color, and similar.
• Values: S/M/L, black/white, and so on.
• Combinations create SKU, the variant article.
• Each SKU has stock, price, and sometimes its own photo.
• A flag showing whether it is available for purchase.

Do not create an attribute for every marketing word. Start with two or three dimensions. Put the rest in the description.

Storefront product card

1. Buyer selects size and color.
2. Price and availability update for the SKU.
3. The "add to cart" button stays inactive until a required variant is selected.
4. The cart receives variant id, not only product id.

If photos depend on color, change the main preview. Otherwise people order black while looking at white. Image handling overlaps with photo upload, but without moderation of external authors.

Stock rules that save you

• Purchase writes off SKU stock.
• Canceling an unpaid order returns the reserve according to your policy.
• A zero-stock SKU cannot be placed in cart, while another size may remain available.
• The admin order shows "T-shirt / M / black", not only the parent name.
• Stock import uses the variant article.

Online payment and double write-off are webhook pain: YooKassa. Idempotency is mandatory.

Variant prices

Sometimes XL costs more, or a "with belt" kit costs more than the base. Store price on SKU. Percentage promo codes calculate from the selected variant price: promo codes. A crossed old price should also be variant-specific if the sale applies only to one color.

Typical breakages

1. Cart contains a product without size, so the packer guesses.
2. Two identical SKU codes with different ids after import; stock diverges.
3. Catalog filter color=black does not find the product because color is only on variants and the index is built by parent.
4. Changing the attribute set after sales without migration makes old orders display incorrectly.
5. Mobile UI: the second dropdown goes off screen.

Acceptance: create a 2x2 matrix (two sizes by two colors), set different stock, buy one SKU, then check admin and neighboring stock.

When variants are not needed

Unique goods, services, and digital items without modifications need one card. Do not enable the SKU module just because it is on a checklist. Complexity must pay for itself through assortment.

Checkout must carry the variant to the end: checkout. Delivery usually does not depend on clothing size, but weight/dimensions sometimes do; add fields if the courier calculation uses them: delivery.

Variants are separate stock and an honest cart. Create SKU, test the stock matrix, and lock the variant into the order. Then size M ends by itself, not together with the whole warehouse by guesswork.

Naming and article codes

Agree on an article scheme before import: BASE-COLOR-SIZE or supplier internal codes one-to-one. Changing schemes after a thousand orders hurts. Human order line: "Runner sneakers / 42 / black"; accounting language: SKU. If barcode is needed, attach it to the variant, not the parent.

• Forbid two variants with the same article at database level.
• Disable a variant without deletion so order history stays intact.
• Mass action "set all XL stock to 0" should require confirmation.

Storefront and attribute filters

Filter color=blue should find the parent if at least one available SKU is blue. Listing card shows "from {min_price}" when variant prices differ. The "out of stock" badge appears only when all SKUs are zero; if M is out and S exists, the card is alive. These details create the feeling that someone manages the store.

External marketplace exports also need stable SKU. Even if exports are not planned, avoid chaos; in six months someone will want a feed for Yandex or another marketplace, and broken ids surface. Checkout must already write variant_id into the order; verify it in checkout before advertising the size grid.

Manager training: five minutes at the screen creating a 2x2 matrix is more useful than a long PDF. Until the person creates variants by hand, they will keep editing "common stock" and breaking accounting.

Returns and size exchanges

When a buyer changes M to L, admin should record two stock movements or a special exchange status. Do not pretend it is just editing text in the order; warehouse will diverge. Product variants exist so these operations are explicit. In the PHP store script, store variant_id in history; otherwise you cannot later collect statistics about which size sells.

Create matrices before the season, not on the day of an ad photo shoot. Check that mobile cards cannot add to cart without size. This two-minute test saves many returns. SKU, stock, cart, order: one language. When storefront and warehouse share it, variants stop causing chaos and become a normal assortment tool.

SKU report

Once a week, check which variants are zero, which have no sales, and where a variant price is odd because of a typo. Product variants without reports become a dump. A PHP store script usually has an availability filter; use it. Before a supply arrival, compare the matrix with the supplier invoice by article codes, not by color names "as it seemed".

For a 5x5 matrix on the storefront, do not show all combinations as a huge table. Let the user choose size, then available colors. Fewer user errors. Repeat the selected variant text in the cart. During order picking, this saves minutes and prevents "wrong item arrived" returns. SKU is the warehouse language; teach it to the site and people.