Material planning & costs

This page covers the planning and costing layer beneath the work order’s plan — what gets stored when an item is added, how operator overrides are tracked, where the cost figures come from, and which actions get you back to a clean state.

The spread, in plain language

When you add an item to a work order, Assemblified walks the item’s bill of materials and any assembly BOMs nested inside it. For every leaf material the walk encounters, it adds (or finds and merges into) a row on the work order’s materials list. For every assembly BOM, it adds a row and recurses into that bill’s own components — but everything still ends up on one flat materials list, so when you build, you’re picking from a single pile.

That walk is the spread. The result has two side-effects:

A flat list on the Materials tab, deduped per material.
A contribution tree recording “item X needs Y units of material Z, sourced via path P.” This is what lets each material row expand to show which item(s) actually require it.

The spread runs automatically when an item is added, and on a quantity change unless you answer Keep current materials (which decouples the item). You can also run Refresh from bills at any time to reconcile the materials list with the current bill definitions — see editing the plan → refresh from bills.

Original vs. planned quantity

Each material row carries two quantities:

Original quantity — what the spread (or a manual add) wrote. The BOM’s truth, frozen at spread time. It isn’t a column on the table; it is what Reset quantities puts back.
The Planned quantity column — the planned material quantity that will actually be consumed when you build. It starts equal to the original, and you can edit it in place.

The planned quantity is what every downstream system reads — pick lists, cost calculations, build-run plans. The original is preserved so a refresh or a reset can tell where operator overrides have moved away from the BOM.

When a row’s planned quantity has been manually edited, it is flagged as manually overridden. Refresh from bills respects the flag and leaves the quantity alone. Reset quantities (see below) is the way to wipe overrides en masse.

The three cost totals

The Overview tab’s summary card has a Cost band of six money cells: Material cost · Labour cost · Additional cost · Original planned cost · Current planned cost · Actual cost. The first three are the buckets of the current plan; the last three are totals over all of them. Every cell opens a breakdown when you press it.

Original planned cost

The cost the bills of materials give the plan as it stands now: the quantities the items’ bills call for, at master unit costs, with the pre-assembled splits as they were when the materials were spread. It follows the latest plan, so adding an item, changing a planned quantity or refreshing from the bills moves it. Your own overrides do not: a quantity or unit cost you edited by hand shows up under Adjusted, not here.

This is the figure to look at when answering “what does the recipe say this plan should cost, before my adjustments?”

Its breakdown splits into Material, Subassembly, Labour and Additional.

Current planned cost

The current target after your edits to material quantities, unit costs, substitutions and splits. The cell prints its difference against Original planned cost underneath, so the impact of every override is on screen without arithmetic.

This is the figure to look at when answering “if I build this exactly as planned today, what will it cost?”

Actual cost

What the build runs really cost. Each consumption stamps the unit cost at the moment of consumption, and Actual cost is the sum. It too prints a difference against original planned cost — but only once there is one: until the work order has actually run, the cell is blank and so is its difference, because a difference against nothing is not zero.

Because the cost is stamped at consumption time, a later edit to a master cost does not retroactively rewrite Actual cost on already-built runs.

Every build run consumes its items’ full share of each material, also when several items share a component and are built in separate runs. So once everything is built and nothing in the plan or the costs was changed, Actual matches the plan.

Per-item material cost (Shopify cost push)

Update Shopify cost, in the work order’s More actions menu, computes the cost attributable to a single bill item — separated out from the rest of the work order’s items — and pushes it to Shopify as that product’s per-unit cost. This lets a built finished good carry the cost it actually took to produce, rather than a static BOM estimate.

The math walks the contribution tree from the item down through its assembly BOMs, scaling each one’s contribution by its own to-build ratio so an assembly BOM drawn 100% from pre-assembled stock contributes nothing fresh. Raw cost adds up, pre-assembled cost adds up, the divisor is the item’s built quantity (or its planned quantity if nothing’s built yet — the table’s Divided by column says which), and the per-unit figure goes to Shopify.

Assembly BOM items and bare-variant items are excluded — only bill-of-materials items are eligible. A row with no Shopify link wears a No Shopify link badge and can’t be selected.

Choosing what to push

Before you confirm, the dialog lets you pick what each per-unit figure is built from. Both choices apply to the whole push and are recorded on the work order’s history, so you can later see which basis a past push used.

Cost basis — Current planned cost or Actual cost:

Current planned cost uses the cost from the current plan: planned quantities and any unit-cost overrides you’ve entered. It’s always available.
Actual cost uses what the completed build runs really consumed. It only becomes selectable once at least one build run has consumed material — until then it is greyed out with the hint “Actual cost is available once material has been consumed.” On a single-item work order the item carries the whole actual cost; on a multi-item work order the actual cost is split across items in proportion to each item’s current planned cost, so the per-item figures always add back up to the work order’s actual total.

Include labour adds each item’s share of the work order’s labour cost on top of the material cost, spread evenly across every unit built. It pairs with the basis — Current planned cost basis adds current planned labour cost, Actual cost basis adds actual labour. It’s off by default, so the unchanged push stays material-only.

Include additional costs is a second, independent checkbox, also off by default. It adds each item’s overhead cost rates. Labour-kind cost rates are excluded here — they reach Shopify through Include labour instead — so ticking both boxes can never charge labour twice. Additional costs have no actual figure, so the planned value is used on both bases; on the Actual cost basis the checkbox is labelled Include additional costs (current plan) to say so.

The table shows Variant · Shopify cost · Per unit · Change · Divided by. Flipping any control recomputes every row’s per-unit figure and its Change against Shopify’s current cost, and re-ticks the rows where the cost actually differs. A row whose chosen basis isn’t available shows a dash and can’t be selected.

Labour cost

Labour has its own small dialog. Open the Labour cost cell’s breakdown on the summary card and press Edit labour cost; the dialog has two fields, Current planned cost and Actual cost.

Current planned labour cost flows into the Current planned cost total.
Actual labour cost flows into the Actual cost total.
A baseline labour line is captured the first time you write a planned labour cost, then frozen, so editing the planned labour later doesn’t move the Original planned cost total.

An empty field and a zero mean different things, and the dialog says so: “Leave a field empty to say nothing about it. Zero means this work order costs no labour.”

Labour is operator-entered — Assemblified doesn’t track time spent — unless the work order’s bills carry labour cost rates. In that case the app derives the labour for you and includes it in the cost figures; the breakdown then shows a From bills line, and adds an Operator override line beside it only when you have typed your own number. Clear the field to hand it back. See Additional costs on work orders.

Overhead cost rates are folded into the Original planned cost, Current planned cost and Actual cost figures too, with the same value in all three — so they never distort the differences between them.

For per-unit labour that scales with order quantity (rather than per-batch), attach a labour cost rate to the bill, or model labour as a virtual material inside it. See Track building cost for all three patterns and when each fits — and Check BOM margin and cost breakdown for reading the rolled-up cost.

Retail prices on the Materials tab

Some shops fill each box to a retail budget instead of a fixed bill. A gift hamper sold at £69.99, for example, is filled with whichever products add up to that value at selling price. For that, the Materials tab can show each material’s Shopify selling price beside its unit cost, with a running Retail total at the foot of the table.

Turn it on under Settings → Catalogues → Work orders → Materials → Show retail prices on work-order materials. It is off by default.

With it on:

A Retail price column follows Unit cost. It shows the product’s current price in Shopify, so a price change in Shopify shows up on the next page load.
The Retail total row multiplies each line’s planned quantity by its retail price and adds them up, over every material on the work order, whatever page or search you are on. It updates as you add, remove or change materials.
In the By component view, each component’s subtotal row also shows its retail value.
Virtual materials and subassemblies have no selling price. They show an empty cell, count as nothing in the total, and the total row says how many lines it could not price.

Pre-assembled vs. to-build splits

When the spread encounters an assembly BOM material, it splits the required quantity into:

Quantity from pre-assembled — drawn from existing pre-assembled stock at the work order’s production location.
Quantity to build — built fresh from that bill’s own materials, which the spread’s recursion also added to the materials list.

The split is computed at spread time using current pre-assembled stock. If inventory at the production location changes after you’ve planned the work order — somebody else built or consumed pre-assembled stock — the split goes stale. Two things then happen, and they are different actions:

A page-level banner, “The pre-assembled split is out of date”, with a Reset materials button. That is the work-order-wide fix: it replans every material. While the banner is up, no new build run can be started.
A per-row action, Reconcile pre-assembled, in the ⋯ menu of any assembly BOM line on the Materials tab. That rebalances one line against current shelf stock and leaves everything else alone.

The constraint quantity from pre-assembled + quantity to build = planned quantity is enforced; you can’t break it through the UI.

Reset paths

When the plan diverges too far from the BOM and you want a clean slate, these actions get you back:

Action	Where it lives	Scope	What it clears
Reset quantities	The Materials tab toolbar	All materials	Every manual override; re-runs the spread for every item.
Reset materials	The page’s More actions menu, and the stale-split banner	All materials	The same action under the name the page uses for it.
Reset decoupling	An item row’s ⋯ menu on the Items card	One item	The decoupled flag on that item; re-runs the spread for its materials. Offered only on a decoupled row.
Reconcile pre-assembled	A material row’s ⋯ menu, assembly BOM lines only	One material line	Rebalances that line’s pre-assembled / to-build split against current shelf stock. Leaves manual quantity overrides on materials alone.

All of them respect the lifecycle: they’re only available in non-terminal statuses, because the plan is frozen in completed and cancelled.

Items with units already built or being picked. Reset quantities, Reset materials and Reset decoupling re-plan such an item only while its bill is unchanged since its materials were spread. If the bill has changed, the item is skipped — or stays decoupled — because its built units were made to the old recipe and re-planning them would misstate what they consumed. When that happens the page says so: instead of the usual confirmation, a notice names each item that kept its materials and why. None of the resets may take a material below what a build run has already used, or below what an open build run is picking; such a reset is refused as a whole.

Editing the plan — where the overrides are actually edited.
Build runs — how planned quantities turn into picks.
Shopify sync — what happens when you push cost back to Shopify.
Glossary.