Skip to main content

Variations and SKUs

Where: the Variations section of the product editor


1. What a variation is​

The thing that is actually sold. A product is a concept — Bhetki Paturi. A variation is a buyable row — 6 Pieces, ₹900, SKU FISH-BHETKI-PATURI-6PCS.

ProductVariation
CarriesName, description, category, tax, imagesSKU, price, stock, unit
Customer picksThe product from a listingThe variation on the product page
Appears in ordersAs contextAs the line item
Has a BOM❌✅ — the recipe is per variation
A product with no variation cannot be sold

It renders in the catalogue, it can be published, and it has no purchasable row. This is the most common reason a product "is on the storefront but nobody can buy it".

Figure 1 — Three variations of one product. Each has its own SKU, price and stock.

2. How variations spread through the application​

Every ledger row that is not a raw-material movement points at a variation, not a product. So do storefront order lines, direct-sale lines and production output.


3. Step by step​

Step 1 · Choose the attributes​

The ATTRIBUTES selector at the top of the section picks which attributes this product varies by — Serving Size, Spice Level.

Step 2 · Add variations​

+ Variation appends a row. Fill:

FieldRequiredNotes
Image—Falls back to the product's hero image
Name✅The label a customer sees — 6 Pieces
SKU—Your stock-keeping code. Uppercase-hyphen by convention
Price✅In the org currency
Stock—current_stock — see the warning below
Unit✅From Units of measure

Step 3 · Bind attribute values​

Each variation binds to the attribute values that define it — Serving Size: Full. That binding is what the storefront selector renders.

Most variations on the reference tenant carry no attribute values

117 variations exist and only 3 attribute-value bindings do. A variation with no bindings still sells — its name carries the meaning — but the storefront cannot build an option selector from it, so customers see a flat list of variations rather than a Choose your size control.

If you want a real selector, bind values deliberately. It does not happen automatically.


4. The Stock field, and what it is not​

The Stock box writes current_stock on the variation.

Writes current_stockDoes not write it
This fieldGoods receipts
Product importProduction
Storefront order placement (decrement) and cancel/refund (restock)Direct sales
Adjustments and wastage
Typing a number here is not the same as recording a movement

Setting Stock to 40 changes the storefront's "Sold out" gate and leaves no ledger row. Nothing records who changed it or why.

Conversely, posting a goods receipt for 40 units writes a ledger row and leaves this field at 0. Read How stock is counted before you decide which one your process should use.

Stock is also exempt for two kinds of line: pre-order items and scheduled items are made-to-order for a future date and never move stock, in either system.


5. SKU conventions​

The SKU is yours; nothing in the module parses it. On the reference tenant the pattern is <CATEGORY>-<PRODUCT>-<SIZE> — FISH-BHETKI-PATURI-6PCS.

Two properties are worth preserving because other systems rely on them:

  • Stable. It is what a warehouse, an accountant and the external API match on.
  • Unique. Nothing enforces uniqueness, so duplicates are possible and confusing.

6. Downstream​

ChangeEffect
Rename a variationThe storefront label changes; historic orders keep their captured name
Change the priceNew orders only
Change the SKUThe ledger shows the new SKU on historic rows too
Delete a variationRemoved on save. Historic ledger and order rows survive, pointing at a deleted row

7. Troubleshooting​

SymptomCause
Product visible but not buyableIt has no variation
Storefront shows no size selectorThe variations carry no attribute values — see §3
Stock says 0 after a big goods receiptExpected. Receipts write the ledger, not this field
"Sold out" on a product with stockcurrent_stock is 0 even though the ledger balance is positive
Two variations share a SKUNothing prevents it; fix by hand