Skip to main content
ION splits a bill of materials into a plan and a record. The manufacturing BOM (mBOM) hangs off a part and holds engineering’s planned structure. The as-built BOM (aBOM) hangs off a part inventory and holds the serial-and-lot record of what actually went into one unit. A build requirement is the shared line item: on the mBOM it states what should be installed, and on the aBOM it accumulates the installations that satisfy it. When a run starts against a part inventory, ION snapshots the parent part’s released mBOM into that run’s aBOM, one build requirement per line, and locks the run to that mBOM version. Operators install against the aBOM during execution. The aBOM can diverge from the mBOM through substitutes, quantity deviations, redlines, and made-on-assembly installs, and that divergence is the traceability signal ION preserves. For the steps to edit requirements mid-run, see Edit build requirements.

​
Manufacturing BOM

The mBOM is the parent part’s planned parts list. Each line is a build requirement carrying a child part and revision, a per-assembly quantity, approved substitutes, reference designators, and a made-on-assembly flag. ION multiplies the line quantity by the parent run quantity to compute demand. You maintain the mBOM on the mBOM card on the part page while its version is in Draft, and edits save inline. For the build and consumption flow, see Manufacturing BOM (mBOM). If your engineering team keeps an eBOM in a PLM system such as Solidworks PDM, Arena, or Teamcenter, the ION mBOM is the manufacturing counterpart of it. Keeping the two in sync is a separate export/import or integration workflow.

​
As-built BOM

The aBOM is a parent/child tree of part inventories that compose one finished unit. Sub-assemblies are part inventories with their own aBOMs, so traversal recurses through each installedPartInventory. Each install writes an Installation record linking the consumed inventory to the build requirement it satisfied. The tree answers traceability queries in both directions: what went into a delivered unit (top-down) and every parent a given lot reached (reverse traversal on parentPartInventory). For UI navigation and query patterns, see As-built BOM (aBOM). For batch traversal, see Get an aBOM with full hierarchy. The aBOM is a work-in-progress until the run completes, at which point every required build requirement has an installation or an explicit issue-based exception, and the tree locks. Reopening the run is the only way to edit it afterward.

​
Build requirement fields

FieldNotes
Part Number / RevThe required child part, shown with its revision.
QuantityCount per one parent assembly. Multiplied by parent run quantity at execution.
SubstitutesApproved interchangeable parts for the line. See Alternates and substitutes.
Reference DesignatorsPositional identifiers such as R12 and U7. See Reference designators.
Made on AssemblyWhether ION builds the child inside the parent’s run instead of as its own run. See Made on assembly.
Substitutes and reference designators are line metadata: you can edit substitutes without revising the whole mBOM, while adding or changing designators is a structural change. A reference designator is unique within its build requirement, and an approved substitute applies to every designator on the line.

​
Divergence and versioning

The mBOM and aBOM carry independent version histories. A structural mBOM change (add or remove a line, change a part, change a designator, toggle MOA, or a significant quantity change) needs a new mBOM version; metadata changes such as notes and substitute edits are in-place. Releasing a new version archives the prior one, and only one version is Released at a time. In-flight runs keep the version they started against: to apply a structural change to a running build, use a redline rather than a new version. For version states and the release flow, see Manage BOM versions. An mBOM version is distinct from a part revision. The revision tracks what the part is; the mBOM version tracks how to build a given revision. A new part revision usually implies a new mBOM, but an mBOM can also change on its own for routing or substitute updates.