--- title: The three numbers of a built product summary: > A built product has three stock figures, not one. On hand is the finished units sitting on a shelf. Assemblable is how many more its components could produce right now. Available is on hand plus assemblable, minus whatever is already promised to orders. Assemblable is worked out separately at each location, because parts in two buildings cannot become one finished unit. type: concept group: make step: 4 permission: null prerequisites: [] related: - /help/make/product-types-and-stock-modes - /help/fulfil/when-stock-actually-moves - /help/sync/how-stock-reaches-your-channels last_updated: 2026-08-07 --- **A kitchen has three cakes on the counter and the ingredients for five more.** Both facts are true at once, and neither is the whole answer. "How many cakes do we have" is a bad question in a kitchen, and it is a bad question for anything you build from parts. A product assembled from components — a gift set, a bundle, a kit — is described by three numbers rather than one. Read all three together and the stock picture is honest. Read only the first and you will refuse orders you could easily fill. This page covers: - [The three numbers](#the-three-numbers) - [How assemblable is worked out](#how-assemblable-is-worked-out) - [Assemblable is counted one location at a time](#assemblable-is-counted-one-location-at-a-time) - [Kits inside kits](#kits-inside-kits) - [When there is no number to give](#when-there-is-no-number-to-give) - [How to say it out loud](#how-to-say-it-out-loud) ## The three numbers Only the first one exists on a shelf. The other two are worked out on the spot. - **On hand.** Finished units already built and physically present. If you walked the aisle and counted boxes, this is what you would get. It is the only one of the three that is stored. - **Assemblable.** How many more complete units the components in stock could produce right now. Nothing has been built; this is capacity, not inventory. - **Available.** On hand plus assemblable, minus whatever is already promised to orders. This is the number that should decide whether you can accept an order. So a set with 25 built, components for 50 more and 10 already promised is 25 on hand, 50 assemblable, 65 available. Assemblable is recalculated every time it is asked for. It has to be — it changes the instant any of its components moves, and no component knows which finished products depend on it. ## How assemblable is worked out Take each line of the parts list, ask how many finished units it alone could support, and keep the smallest answer. For one component line: 1. Start with that component's free stock: its own on hand, minus anything already promised to an order. 2. Divide by how many of it one finished unit needs, including any wastage allowance on the line. 3. Round **down**. Three quarters of a unit builds nothing. Do that for every line and take the lowest result. That component is the **limiting component** — the one you would have to buy or make more of to raise the number. The app names it, because "we can build 4" is far less useful than "we can build 4, and the ribbon is what stops us at 4". A worked example. A gift set needs 1 notebook, 1 pen and 2 cards. | Component | Free stock | Needed per set | Supports | | --- | --- | --- | --- | | Notebook | 90 | 1 | 90 | | Pen | 40 | 1 | 40 | | Card | 25 | 2 | 12 | The set is assemblable 12 times, and the card is the limit. Buying more pens changes nothing until the cards are dealt with. One kind of line is skipped entirely. A component that is itself made to order holds no stock by design, so it can never be the limit — counting its zero would drag every parent to zero and hide the real constraint. ## Assemblable is counted one location at a time **Parts in two buildings do not make a finished unit.** This is the rule that trips people up, and getting it wrong produces numbers that look plausible and are not. If you add up every component you own across every warehouse, retail counter and event stall, then divide, you get an answer nobody can act on: it pairs a box sitting in one city with a ribbon sitting in another and calls the pair a gift set. So the calculation is always run against the stock at **one** location. "How many can we build here, right now, out of what is physically here." A company-wide figure is then the **sum of those per-location answers**, not one big calculation over pooled stock. Those two are different numbers, and only the first one is true. This has cost real money elsewhere. A kit once advertised 13 assemblable when the warehouse that would actually build it could manage 3, because sub-kits parked at two shops were being counted into a build happening somewhere else. Every one of those 10 extra units was an order somebody would have had to apologise for. ## Kits inside kits A component can itself be something you build, and the capacity carries upward. If a gift set contains a smaller set, that smaller set contributes both its finished units *and* what it could itself be assembled into. Twenty pre-built inner sets plus components for sixty more supports eighty of the parent, not twenty. The calculation walks down the tree — up to six levels deep — and back up again, and it is safe against a parts list that accidentally refers back to itself. There is a switch that turns this off per product: **build from finished components only**. With it on, a parent counts only the finished sub-kits actually sitting on the shelf and ignores their build capacity. That is the right setting when packing a parent means picking up a sealed inner box, and nobody is going to stop mid-pack to build one from scratch. With it off, the capacity trickles all the way up. Turning it on always lowers the number. That is the point: it trades an optimistic figure for one the floor can honour today. ## When there is no number to give Some products have no stock-bound limit at all. If every component on the parts list is made to order, nothing anywhere constrains how many you could build. Rather than print a misleading finite figure, the app treats the product as unbounded and shows it as always available. This is common for printed or personalised items whose inputs are produced per order. The opposite case is a parts list with a component the app cannot resolve — a line pointing at something no longer in the catalogue. Assemblable drops to zero and that line is named as the blocker. Nothing is guessed. An unfixed parts list is not the same as an empty shelf, and the app refuses to blur them. ## How to say it out loud Never quote one number on its own. > "We have 25 in stock, and the components to assemble 50 more." That sentence is the house phrasing, and it is worth being disciplined about. "We have 25" makes a colleague turn down 40 units of business. "We have 75" makes them promise same-day dispatch on units that do not exist yet. The two halves answer different questions — what can ship this hour, and what can ship this week — and both are usually needed. The same split reaches your storefront. A built product advertises its derived availability, so it does not read as sold out while the parts are on the shelf. That figure is added at the location where assembly actually happens; other locations advertise finished units only, so the same capacity is never counted twice across stores. ## Explore **Product types and stock modes.** Whether a product has a parts list at all, and what its zero means, are the two settings this page assumes. [Learn more →](/help/make/product-types-and-stock-modes) **When stock actually moves.** Assemblable is capacity, not inventory — nothing is deducted until an order is fulfilled. [Learn more →](/help/fulfil/when-stock-actually-moves) **How stock reaches your channels.** What your storefront is told about a built product, and why it differs per location. [Learn more →](/help/sync/how-stock-reaches-your-channels)