---
title: Assemblies
description: "**Audience:** bookkeeper, admin · **Last updated:** 2026-06-07 · [Edit on GitHub](https://github.com/phreesoft/bizuno/edit/main/docs/04-modules-in-depth/03-inventory/03-assemblies.md) # Assemblies An **assembly** is an inventory item built from other items. You define what it's made of (the bill of materials), and when you build it Bizuno consumes…"
url: "https://www.bizuno.com/docs/assemblies/"
updated: "2026-06-18"
category: Inventory
---

# Assemblies

**Audience:** bookkeeper, admin · **Last updated:** 2026-06-07 · [Edit on GitHub](https://github.com/phreesoft/bizuno/edit/main/docs/04-modules-in-depth/03-inventory/03-assemblies.md)

# Assemblies

An **assembly** is an inventory item built from other items. You define what it's
 made of (the bill of materials), and when you build it Bizuno consumes the
 components and produces the finished good — moving cost from the component SKUs
 into the assembled SKU. This page covers the data model and the costing; the
 build workflow itself is in [Work orders / production](/docs/work-orders-production/).

> **Scope check.** Bizuno's assembly model is solid for kitting and light
>  manufacturing, but it is **not** a full MRP — no work centers, routings, or
>  capacity planning. You *can* itemize **labor and overhead** on the bill of
>  materials to factor them into the assembly's *estimated* cost (for pricing) —
>  with one deliberate rule about how they hit the GL (see
>  [Costing labor and overhead](#costing-labor-and-overhead)).

---

## Which types are assemblies

Only two types carry a bill of materials:

- **`ma` — Assembly**: the normal built item.
- **`sa` — Serialized Assembly**: the same, with serial numbers on finished units.

(Don't confuse these with **`ms` Master Stock**, which generates *variants* from
 options and is not an assembly — see [Inventory types](/docs/inventory-types/).)

---

## The bill of materials

The BOM is stored as item metadata (`bill_of_materials`) on the assembly SKU — a
 list of component rows, each with:

| Field | Meaning |
| --- | --- |
| `sku` | The component item |
| `description` | Component description |
| `qty` | How many per one assembled unit |

Edit it on the assembly item's **Assembly** tab (visible only for `ma`/`sa`). As
 you build the list, Bizuno shows the rolled-up component quantity and cost in the
 footer (`managerBOMList`).

> **The BOM locks once you transact.** After the assembly SKU has any posted
>  journal activity, its bill of materials is locked from editing — changing it
>  would make past builds inconsistent with the recipe. To change a recipe in
>  flight, version it as a new SKU.

### Multi-level BOMs

A component can itself be an assembly, and Bizuno **does** handle that for
 **availability** — the "how many can I build" calculation recurses through
 sub-assemblies to find the limiting component.

**Cost rollup, however, does not recurse.** An assembly's build cost is computed
 from the **direct** components' costs (one level). If you nest assemblies, build
 the sub-assemblies first so their finished cost is current before you build the
 parent — otherwise the parent rolls up a stale sub-assembly cost.

---

## Costing labor and overhead

Labor and overhead don't need a separate cost field — model them as **inventory
 items** and drop them into the bill of materials like any other line:

1. Create a labor- or charge-type item — e.g. a Labor (`lb`) item *"Assembly
    labor"* with an `item_cost` of `$3.00` representing 0.1 hours of work (or
    however you prefer to unitize it). Do the same for overhead/burden if you
    track it.
2. Add that item to the assembly's BOM with the **quantity** you need — e.g. 5 ×
    *"Assembly labor"* for 0.5 hours of build time.

The assembly's **estimated/standing cost** picks these lines up: `dbGetInvAssyCost`
 sums `qty × item_cost` across **every** BOM line regardless of type, so the figure
 you see for pricing and margin reflects materials **plus** the labor and overhead
 you've itemized.

> **Important — labor is not capitalized into inventory value, by design.** At
>  *build-post* (jID 14), Bizuno deliberately rolls **only the stocked, COGS-tracked
>  components** into the finished item's GL inventory value; labor/charge lines are
>  intentionally **excluded** from that capitalized cost. This is correct, not a
>  gap: labor is expensed through its **own GL → COGS path**, so capitalizing it
>  into the assembly's inventory value as well would **double-count** it. The net
>  effect is what you want — labor shows in the *estimate* for pricing, while the
>  capitalized inventory cost (and therefore the COGS posted when the assembly
>  later sells) stays materials-only.

---

## Building: what posts

A build is recorded by the **Assembly journal (jID 14)**. Its `Post()`:

1. Reads the BOM, and for each component creates a consumption leg
    (`gl_type='asi'`) — drawing the component's cost via its
    [costing method](/docs/history-and-costing/) (FIFO/LIFO/average) and
    **decrementing** its `qty_stock`.
2. Creates the assembled-item leg (`gl_type='asy'`) — **incrementing** the
    assembly's `qty_stock` and adding a cost layer.
3. Rolls the cost: **assembled cost = sum of the components' COGS**, and the
    finished unit cost = that total ÷ quantity built.
4. Marks the build closed.

The GL effect nets within your inventory/COGS accounts — value simply moves from
 the component SKUs to the finished SKU. Reversing a build (un-post) puts the
 components back and removes the finished units.

> You don't usually post a jID 14 by hand — it's created for you when a
>  [work order](/docs/work-orders-production/) step completes. The jID 14 is the
>  accounting record; the work order is the shop-floor workflow that drives it.

---

## Honest limits

What the assembly model **does**:

- Component bills of materials on `ma`/`sa` items
- Build / un-build with correct stock movement and component-cost rollup
- **Labor and overhead** in the *estimated* cost, via labor/charge items on the
   BOM — deliberately not capitalized into inventory GL value (above)
- Multi-level **availability** (recursive "can I build N?")
- "How many can I build per store" capability view

What it **does not** do (so you don't design around features that aren't there):

- **No work centers, routings, or capacity planning** — the build is a recipe,
   not a routed operation.
- **No recursive cost rollup** — parent cost reflects direct components only;
   build sub-assemblies first so their cost is current.
- **No phantom assemblies** — there's no "don't stock the assembly level" flag;
   every build moves real stock for both components and the finished item.

For kitting and light builds — including itemized labor and overhead — this is
 plenty. For routed operations through work centers with capacity scheduling,
 you've crossed into territory a dedicated MRP handles better.

---

## Related

- [Work orders / production](/docs/work-orders-production/) — the build workflow that drives jID 14
- [History and costing](/docs/history-and-costing/) — how component costs are drawn
- [Inventory types](/docs/inventory-types/) — `ma`/`sa` vs. `ms`
- [Journals (the journal_id reference)](/docs/journals/#jid-14--assembly-j14php)