Skip to content

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
  • Original vs. planned quantity
  • The three cost totals
  • Per-item material cost (Shopify cost push)
  • Labour cost
  • Pre-assembled vs. to-build splits
  • Reset paths

When you add an item to a work order, Assemblified walks the item’s bill of materialsBill of MaterialsA bill of materials tells Assemblified how to build one unit of a finished good. When a customer orders the finished-good variant, Assemblified deducts the right component quantities from inventory automatically. Read more → and any assembly billsSub-assemblyA reusable assembly block that composes into bigger bills: define it once, include it in any bill of materials, and Assemblified expands it into its own components at execution time. The app now calls it an assembly bill. Read more → nested inside it. For every leaf raw material the walk encounters, it adds (or finds and merges into) a row on the work order’s materials list. For every assembly bill, 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 spreadSpreadThe step that walks each work-order item's bill, assembly bills included, and turns the result into the flat list of materials the work order needs. It runs immediately when you add an item and cannot be skipped; a later quantity edit offers to re-spread. Read more → . 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 decouplesDecoupleDetaching one work-order item's material list from that item's planned quantity, so the list stops resizing when the quantity changes. You decouple by answering "Keep current materials" at the re-spread prompt; a decoupled item wears a badge until you reset it. Read more → 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.

Each material row carries two quantities:

  • Original quantity — what the spread (or a manual add) wrote. The recipe’s truth, frozen at spread time. It isn’t a column on the table; it is what Reset quantities puts back.
  • The Planned column — the effective quantityPlanned quantityHow much of a material a work order intends to consume: the bill's quantity, editable per material in the Planned column but never below what has already been consumed. Pick lists and Adjusted cost read it. "Effective quantity" is the older name. Read more → that will actually be consumed when you build. It starts equal to the original, and you can edit it in place.

The Planned figure 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 recipe.

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 Overview tab’s summary card has a Cost band of six money cells: Material cost · Labour cost · Additional cost · Planned · Adjusted · Actual. 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.

The original cost target from the bill of materials, locked when the work order was created. It uses the original quantities, master unit costs, and the original pre-assembled splits frozen at spread time. It does not move when you edit the plan.

This is the figure to look at when answering “what was the recipe’s expected cost before I made any adjustments?”

Its breakdown splits into Material, Sub-assembly, Labour and Additional.

The current target after your edits to material quantities, unit costs, substitutions and splits. The cell prints its difference against Planned 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?”

ActualActual CostWhat the work order really cost, derived from materials that have been consumed by completed build runs. Stamped into the audit ledger at the moment of consumption, so it doesn't drift if prices change later. Read more →

Section titled “Actual”

What the build runs really cost. Each consumption stamps the unit cost at the moment of consumption, and Actual is the sum. It too prints a difference against Planned — 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 on already-built runs.

Per-item material cost (Shopify cost push)

Section titled “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 recipe estimate.

The math walks the contribution tree from the item down through its assembly bills, scaling each one’s contribution by its own to-build ratio so an assembly bill 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-bill 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.

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 — Planned or Actual:

  • Planned uses the cost from the current plan: planned quantities and any unit-cost overrides you’ve entered. It’s always available.
  • Actual 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 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 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 — Planned basis adds planned labour, Actual 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 factors. Labour-kind factors 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 basis the checkbox is labelled (planned) 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 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, Planned and Actual.

  • Planned labour flows into the Adjusted cost total.
  • Actual labour 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 Planned 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 factors. 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 factors are folded into the Planned, Adjusted and Actual 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 factor 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.

When the spread encounters an assembly-bill 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 raw materials, which the spread’s recursion also added to the materials list.

The split is computed at spread time using current pre-assembled inventory. 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-bill 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.

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

ActionWhere it livesScopeWhat it clears
Reset quantitiesThe Materials tab toolbarAll materialsEvery manual override; re-runs the spread for every item.
Reset materialsThe page’s More actions menu, and the stale-split bannerAll materialsThe same action under the name the page uses for it.
Reset decouplingAn item row’s ⋯ menu on the Items cardOne itemThe decoupled flag on that item; re-runs the spread for its materials. Offered only on a decoupled row.
Reconcile pre-assembledA material row’s ⋯ menu, assembly-bill lines onlyOne material lineRebalances that line’s pre-assembled / to-build split against current shelf stock. Leaves manual quantity overrides on raw 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.