⚠️ garment

Broken Size Sets

Broken Size Sets is a read-only report — not a data-entry screen — that automatically detects products where some sizes are sold out while other sizes of the same product are still in stock, so you know exactly which size to reorder before you lose more sales.

📍 Menu path: /garment/broken-size-sets

👤 Who uses it: Owner,Manager,Staff

Overview

The report scans every active product that has two or more size variants and flags any product where at least one size is completely out of stock (quantity ≤ 0) while at least one other size of the same product still has stock — a classic "broken size run" (e.g. Small and Large in stock, Medium sold out).

Each flagged product shows its name, SKU, brand and season tags, a green "✓ In Stock" group of size chips with their remaining quantity, and a red "✗ Out of Stock" group of size chips with no quantity shown (there is none to show).

Every flagged product is scored HIGH or MEDIUM severity: HIGH means the out-of-stock sizes are equal to or outnumber the in-stock sizes (the set is more broken than whole); MEDIUM means still-in-stock sizes outnumber the missing ones.

There is no create, edit or delete action anywhere on this page — it exists purely to surface a computed insight from your existing product/variant stock data, refreshed on demand.

Before You Start

Only products with two or more size variants are considered at all — single-size or non-sized products never appear here regardless of stock level.
Size is read from each product variant's attributes.size / attributes.Size JSON field, falling back to the variant's name if no size attribute is present — products whose variants do not carry a recognisable size value will not be grouped correctly by this report.
This page requires the inventory plan feature, unlike Tailoring Orders/Measurements (billing) or Wishlist (customers).

Step-by-Step Guide

1 Review today's broken size sets

Open Broken Size Sets — it loads automatically on page open.
Check the three summary chips at the top: Total Broken Sets, High Severity and Medium Severity counts.
Scroll the list, ordered with the most severely broken products (most out-of-stock sizes) first.
For each flagged product, compare the green In Stock sizes (with quantity) against the red Out of Stock sizes to decide what to reorder and in what size.

2 Search and refresh

Use the search box to filter the list by product name, SKU or brand.
Click ↻ Refresh after receiving new stock or making a sale, to re-run the detection against current numbers.

Every Field & Button, Explained

Field / Button	What it does
`Total Broken Sets`	Count of distinct products currently flagged as having an incomplete size run.
`High Severity`	Count of flagged products where out-of-stock sizes are equal to or more numerous than in-stock sizes.
`Medium Severity`	Count of flagged products where in-stock sizes still outnumber the out-of-stock ones.
`↻ Refresh`	Re-runs the broken-size-set scan against current product/variant stock levels.
`Search box`	Filters the list by product name, SKU or brand.
`✓ In Stock chips`	Each size still available for that product, with its current stock quantity in parentheses.
`✗ Out of Stock chips`	Each size for that product that has zero or negative stock.
`Severity badge`	HIGH (red) or MEDIUM (amber), computed from the ratio of out-of-stock to in-stock sizes for that product.
`"N size variants · N out of stock" line`	Total size variants detected for the product and how many of those are currently out of stock.

Tips & Best Practices

Sort your reordering priority by the HIGH severity chip first — those products have already lost more size coverage than they have left, so they are actively turning away sales right now.
Use this report right after a sales rush or a stocktake, when size-level stock counts are freshest, rather than relying on a stale morning check.
If a product you know is missing a size never appears here, check that its variants actually carry a size attribute (or a variant name that reads as a size) — the detection depends on that field being set consistently at the product/variant level.

Troubleshooting & FAQ

A product I know is missing a size isn't showing up in this report.

The report only flags products with 2+ size variants where the size can be read from the variant's attributes.size/Size JSON field or its variant name — if that product's variants were set up without a recognisable size value, or it currently has only one size variant on file, it will not be detected.

I want to reorder stock or edit a product directly from this page.

This page is read-only by design — there is no create, edit, delete or reorder action here. Use the Products or Purchase Orders pages to place a reorder for the sizes this report flags.

The numbers look out of date after I just received new stock.

Click ↻ Refresh — the report is computed once when the page loads and does not poll automatically; a fresh stock receipt or sale is not reflected until you manually refresh it.

A product shows as Medium severity but I think it should be High (or vice versa).

Severity is purely a count comparison: HIGH means out-of-stock sizes are ≥ in-stock sizes, MEDIUM means in-stock sizes are still greater — it does not weigh which specific sizes are missing (e.g. a missing best-selling Medium is scored the same as a missing slow-selling XXL).

🧑‍💻 Developer Notes

Source component(s):

frontend-app/pos-app-garment/src/pages/garment/BrokenSizeSetsPage.jsx

Backend endpoints used:

GET /garment/broken-size-sets

Related tables (db-core repositories):

Product
ProductVariant

Redux slices:

None — local component state only

Feature flag key: inventory

This is a computed/detection report, not CRUD — garment.routes.js registers only a single GET /garment/broken-size-sets route (ctrl.getBrokenSizeSets), with no POST/PUT/DELETE counterpart, confirming there is no underlying "BrokenSizeSet" table; the pos-core getBrokenSizeSets() function (packages/pos-core/src/garment.js) reads directly from the shared Product and ProductVariant tables at request time. Size is parsed defensively from each variant's attributes JSON with a try/catch falling back to the raw variant name, so malformed attributes JSON degrades gracefully rather than throwing. Severity is a simple count comparison (outOfStock.length >= withStock.length ? HIGH : MEDIUM) with no weighting for sales velocity or specific size popularity. The scan variant lookup filters by tenantId when present but the product lookup filters by storeId — worth noting if a future multi-store/multi-tenant edge case surfaces mismatched scoping between the two queries.