In this article: what happens when you close out a production run, and why the finished item's cost is what it is.

Pre-conditions

To complete an order it must be In Progress, and — if the order had any allocations — you need at least one consumption record on it. Otherwise, log actuals first (see Recording consumption and waste).

What happens on complete

Clicking Complete runs all of the following in a single atomic operation, so either everything succeeds or nothing changes:

1. For each allocated component:

   • Reads the actual quantity you consumed (falls back to the reserved quantity if you didn't log any).

   • Calculates the cost of that consumption from the component's batch/cost data while the reservation is still in place (so concurrent activity can't steal the underlying batches).

   • Releases the reservation.

   • Deducts the actual quantity from on-hand stock. The movement is recorded with reason manufacturing_consumed.

2. Rolls up the total input cost and divides by the quantity to build to get a unit cost for the finished item.

3. Adds the finished stock to on-hand at the order's location with that unit cost. The movement is recorded with reason manufacturing_produced.

4. Clears the allocation records on the order.

5. Moves the order to Completed.

Why the cost looks like that

The finished item's cost is "what it actually cost to make this batch, divided by how many you made." That is more accurate than using the BOM cost estimate — because it uses real consumed quantities and real batch costs at the time you built.

After completion

• The order is terminal — you can't transition it any further.

• You can still view its history, notes, scope, and actuals tabs for audit.

• The stock movements are in the normal item history and show up in reports.