--- title: A kit will not build even though the app says it can summary: > Buildable is counted per location, so the usual cause is components sitting somewhere else: the headline figure on a product list is org-wide and can pair a part in one warehouse with a part in another. Next most likely, the kit contains sub-kits nobody has built yet, or component stock is already allocated to orders. An unapproved order blocks it too. type: troubleshooting group: make step: 4 permission: assembly.execute prerequisites: [] related: - /help/make/run-an-assembly-order - /help/make/the-three-numbers-of-a-built-product - /help/make/build-a-bill-of-materials last_updated: 2026-08-07 --- **Nothing can be assembled out of parts that are in another building.** That sentence is the whole article. A kit is buildable at a place, not in general, and the number you were reading may not have been about the place you are standing in. When a build refuses, Mossery names the component that stopped it and what it found — something of the shape "need 40, have 12". Read that line first; it usually points straight at one of the checks below. - [Check 1: are the components at this location](#check-1-are-the-components-at-this-location) - [Check 2: does the kit contain sub-kits nobody has built](#check-2-does-the-kit-contain-sub-kits-nobody-has-built) - [Check 3: is the component stock already spoken for](#check-3-is-the-component-stock-already-spoken-for) - [Check 4: has the assembly order been approved](#check-4-has-the-assembly-order-been-approved) - [Check 5: does every line of the recipe point at a real product](#check-5-does-every-line-of-the-recipe-point-at-a-real-product) Work through them in that order. The first two explain most cases. ## Check 1: are the components at this location The buildable figure on a product list is an org-wide estimate. The one an assembly order obeys is per location. They are different numbers, and the org-wide one is always the larger. Here is why. A product list adds up every component everywhere and then works out how many kits that would make. That arithmetic will happily pair a lid held at one warehouse with a base held at another, and count a kit that can be assembled at neither. | Component | Warehouse A | Retail 1 | Total | | --- | --- | --- | --- | | Base | 3 | 10 | 13 | | Lid | 10 | 3 | 13 | | Kits buildable | 3 | 3 | 6, not 13 | The org-wide sum says 13. Warehouse A can build 3. Retail 1 can build 3. Nobody can build 13, and an assembly order at Warehouse A will stop at 3. ### Fix it 1. Open the product and find the **Stock by location** card. It gives the real per-location answer. 2. Build the quantity that location can actually make. 3. If you need more there, transfer the short component in first, then build. Treat the org-wide figure as a planning hint, never as a promise for today. ## Check 2: does the kit contain sub-kits nobody has built A build consumes the recipe's direct components, from stock. It does not build their parts for you on the way down. The buildable figure is more generous than that. When a kit is made of other kits, it counts each sub-kit's own build capacity as well as the finished sub-kits on the shelf — the assumption being that you *could* build the sub-kits first. That is genuinely useful for planning, and it is exactly the gap you fall into when you try to build today. So a kit can honestly read "8 buildable" while the shelf holds 2 finished sub-kits and enough loose parts for 6 more. An assembly order for the parent will build 2 and stop, because the other 6 do not exist yet. The fix is an order of operations, not a setting: 1. Run an assembly order for the sub-kit first, at that location. 2. Then run the assembly order for the parent kit. > If you had previously set a kit to build "from finished components only", > that switch is gone. Sub-kit capacity now always counts towards the buildable > figure, for every kit, because the old behaviour meant two kits could report > different numbers for reasons nobody on the floor could see. ## Check 3: is the component stock already spoken for A component's availability is what is on hand *minus* what is already allocated to orders. Assembly only gets what is left. Sixty units on the shelf with fifty allocated to open orders leaves ten for building. The shelf looks full and the build still refuses at ten, which is correct — those fifty belong to customers who have already bought them. Read the failure message. It names the component and reports what it found, and that figure is the availability, not the shelf. If it says "have 10" while you can see 60, allocation is the difference. If the build genuinely matters more than the open orders, someone has to resolve those orders first. Assembly will not quietly take stock out from under them, and that is the point. ## Check 4: has the assembly order been approved An assembly order has to be approved before it can be executed. A draft one cannot run, no matter how much stock is available. If the message you got was about approval rather than about a component, this is the whole problem — and the fix is not yours. Approving assembly orders is a separate permission from executing them, on purpose: one person decides what gets built, another does the building. Send the order reference to whoever approves assembly work and ask for it to be approved. Nothing about the stock needs to change. ## Check 5: does every line of the recipe point at a real product A recipe line that does not resolve to a product forces the buildable figure to zero. This happens when a component was entered as a code that no product matches — a typo, a product code changed later, or a product removed while a recipe still referred to it. The app does not guess. It marks the line unresolved, reports the kit as buildable zero, and names that unresolved line as the thing holding it back. Open the kit's bill of materials and look for a line flagged as unresolved. Fixing it means pointing that line at the right product, which needs whoever owns product data and their bill-of-materials permission — not the person doing the build. ## Still refusing after all five? Two quieter causes are worth ruling out before you escalate. **Wastage.** A recipe line can carry a wastage allowance, which raises what each kit actually consumes. A line needing 10 with 5% wastage draws 10.5, so 100 on hand builds 9 kits, not 10. Small percentages produce exactly this kind of off-by-one argument. **"Always available".** If every component in a recipe is made to order rather than stocked, the kit is reported as always available instead of as a number. That is not a bug and it is not a promise that a build will run — it means nothing in the recipe is being counted, so nothing is constraining it. If none of that fits, capture four things and pass them on: the kit's product code, the location you were building at, the quantity you asked for, and the exact message including the component it named. Those four identify the problem without anyone having to reproduce it. ## Explore **Running an assembly order.** The normal path, from picking a quantity to recording what was actually consumed. [Learn more →](/help/make/run-an-assembly-order) **The three numbers of a built product.** Built, buildable, and available — why a kit needs three figures instead of one. [Learn more →](/help/make/the-three-numbers-of-a-built-product) **Building a bill of materials.** How a recipe is put together, including wastage and unresolved lines. [Learn more →](/help/make/build-a-bill-of-materials)