Production Costing

Production costing answers two questions for every work order Beelocity closes:

1. What was this run supposed to cost (the standard, frozen at release)?
2. What did it actually cost (the running totals from issues and operation reports)?

The difference between those two numbers is the variance, broken out by category — material, labor, overhead, subcontract — and recorded on the work order when it closes. The pattern Beelocity follows is standard costing: the variance is the gap between what the run actually consumed and the standard frozen at release, computed at completion and finalized at close. This keeps a stable baseline for every comparison and gives you a permanent, per-category record of how each run performed against plan.

The cost snapshot

When a work order is released (Approved → Released), Beelocity rolls the standard unit cost of the parent product against the WO’s BOM, routing, and the work-center cost rates. The result is the cost snapshot — a JSON record on the WO header that carries:

• Material cost — sum of (component standard cost × quantity per parent × (1 + scrap factor)) over every consumable BOM line, divided by the BOM’s produces_quantity.
• Labor cost — the in-house labor portion of the routing’s operation cost (setup time amortized over the batch + run time at the work-center rate × parallelism).
• Overhead cost — the overhead portion of the same operation cost. For organizations that bundle overhead into the work-center rate, this is part of the labor figure.
• Subcontract cost — the supplier’s per-unit fee on subcontract operations.
• By-product credit — for BOMs with by-products: the by-products’ standard cost reduces the parent’s effective material cost.
• Total cost = material − by-product credit + labor + overhead + subcontract.

The snapshot is frozen for the life of the WO — every variance comparison happens against this baseline, never against drifting product master data. If the standard cost was wrong at release, the right move is to correct the underlying cost master data so future runs are accurate, not to edit this WO’s snapshot.

Reading the cost card

The Cost tab on a Work Order’s detail page lays out the picture in four columns: Snapshot (what we expected), Actual (running totals updated on every issue and operation report), Variance (actual − snapshot), and the per-category split:

• Material — accumulates as components are issued. Each issue’s unit_cost is the lot/serial-specific cost when the component is lot-tracked, otherwise the product’s standard cost.
• Labor — accumulates as operations report time. Hours × work-center rate × labor share.
• Overhead — same shape as labor for the overhead share.
• Subcontract — service-product cost on the subcontract PO line(s). Currently not tracked as an actual on the WO header — the variance column reads zero until a future iteration adds the column.

Variance numbers are colour-coded: red for unfavourable (positive — we spent more), green for favourable (negative — we spent less). The card surfaces snapshot warnings inline: if the rollup couldn’t complete at release (cycle, missing data), a yellow banner explains, and any rollup flags (e.g., a missing leaf cost) are listed below.

How variances get computed

When you click Complete on a Released or In-Progress WO, Beelocity:

1. Reads the snapshot off the header.
2. Reads the running actuals (actual_material_cost, actual_labor_cost, actual_overhead_cost).
3. Computes actual − snapshot for each category and stamps material_variance, labor_variance, overhead_variance on the header.
4. Stamps actual_end_date.

These variance numbers stay on the header as informational data until Close.

How variances get finalized

When you click Close on a Completed WO, Beelocity:

1. Releases any remaining reservations on unconsumed BOM lines back to free stock.
2. Stamps closed_by and flips status to Closed.
3. Finalizes the per-category variance breakdown on the work order.

From this point the WO is sealed and read-only. Its variance figures — material, labor, overhead, and subcontract — stay permanently on the record, so you can always revisit how the run performed against the standard frozen at release.

Cancelling a WO

Cancellation reverses everything that’s been done:

1. Outstanding component issues are reversed with Cancellation Reversal rows, returning the consumed quantities to stock.
2. Reservations on unconsumed BOM lines are released back to free stock.
3. Any labor already reported remains attributed to the run as a sunk cost.

A cancelled WO is sealed and read-only.

On-demand cost rollup

Sometimes you want to know the rolled cost of a product without running a work order — to validate a new BOM, to check pricing margin, to refresh standard cost master data quarterly. Two surfaces let you do that:

• Cost Rollup button on the Bill of Materials detail page — rolls the cost of the BOM’s parent product using that BOM. Useful when you’re iterating on a draft BOM and want to preview the cost it produces.
• Cost Rollup button on the Product detail page — rolls the cost of the product using its currently active default BOM. Useful as the day-to-day “what does this part cost?” view.

Both buttons prompt for a batch size (used to amortize setup time) and show the breakdown — material, labor, overhead, subcontract, by-product credit, total — plus any flags (e.g., WARN_MISSING_LEAF_COST on a component with neither a standard cost nor a recent supplier price).

For the org-wide quarterly refresh, the API exposes POST /products/cost-bulk-reroll which rolls every active product with an active default BOM and returns a summary. Most teams wire this into a cron job tied to month-end / quarter-end close.

Common pitfalls

• Editing the cost snapshot. Don’t. The snapshot is frozen at release for a reason — variances need a stable baseline. If the standard was wrong, fix the underlying cost master data so future runs are accurate.
• Closing before all operations have reported. Closing finalizes the variance. If you close before the last op reports its time, the labor figure will look favourable for the wrong reason — not because you saved time, but because you forgot to capture it.
• Letting WARN_MISSING_LEAF_COST flags slide. A leaf component with no standard cost and no last-purchase price rolls at zero. The flag tells you the rollup is incomplete; fix the master data before you trust the snapshot.
• Quarterly bulk re-roll on day-one of a new period. The bulk re-roll updates standard costs based on whatever supplier prices are recorded at run time. Run it at the start of a period (after period-close has finalized the prior period’s data) so the new standard is set before any work orders for the new period release.
• Treating variance as universally bad. A favourable variance can mean “we got lucky” — but it can also mean “we under-counted scrap” or “we forgot to issue some components”. Investigate large favourable variances the same way you investigate large unfavourable ones.