Bill of materials from the architecture

The problem this solves

A BOM pulled out of a system model is either too credulous or useless. Too credulous, and logical blocks and software functions end up in the parts list, a typical mass gets substituted for a missing one, and a manufacturer is guessed from a part name. Useless, and it is a flat dump with no quantities and no way to tell which numbers are real.

How it works

An engineering BOM out of the part hierarchy, with every empty field counted rather than filled. Quantities derived from multiplicity and rolled up with the arithmetic shown, logical elements kept out of the parts list, and a findings sheet for everything the model could not populate.

You are producing a bill of materials from the Dalus model
[model name] as a spreadsheet deliverable.

BEFORE ANYTHING ELSE, LOAD THE XLSX SKILL and follow it for
construction and formatting.

WHAT THIS IS. A Dalus model is a system model, not a CAD assembly or
a PLM part master. What you can produce is an engineering or system
BOM: the parts the architecture defines, their hierarchy, quantities
and whatever procurement data the model actually carries. It is not
a manufacturing BOM and must never present itself as one. State this
on the cover sheet. Where the team's authoritative part data lives
in PLM or a component database, say that this BOM reflects the
system model and should be reconciled against that source.

CONFIRM FIRST, in one message: which Dalus model and branch; the
scope (whole system, one subsystem, one configuration or variant);
how deep to indent the structure; whether an existing BOM format or
template should be matched; and what the BOM is for, since a costing
BOM, a long-lead procurement list and a design review appendix want
different columns. Ask anything else in the same message. Then
begin. If the user attaches an existing BOM or template, match its
columns, ordering and terminology rather than imposing your own.

READ THE MODEL: the part hierarchy in full; part attributes
including any part number, manufacturer, supplier, description,
material, mass, cost, lead time, lifecycle status and provenance;
multiplicities on part usages; variants or configurations where the
model records them; and any component-library provenance such as an
imported source ID or URL.

DERIVE QUANTITIES FROM MULTIPLICITY, not by counting occurrences,
and say which you used where the model is ambiguous. Roll quantities
up through the hierarchy so an indented BOM shows both the quantity
per parent assembly and the total quantity in the system. Show your
arithmetic on the reconciliation sheet: extended quantities must
multiply out from the tree, and if they do not, stop and report it
rather than publishing numbers that do not add up.

NEVER INVENT A FIELD. This is the rule the deliverable stands on.
Where the model has no part number, no supplier, no cost, the cell
is empty and the gap is counted on the findings sheet. Do not infer
a manufacturer from a part name, do not estimate a cost, do not
substitute a typical mass. Someone will procure from this document.

CLASSIFY EVERY LINE so the reader knows what they are looking at:
- Procurable item: a discrete part the model treats as bought or
  made.
- Assembly: a structural grouping whose children are the real
  items. Rolled up, not double-counted.
- Logical or functional element: something in the architecture that
  is not a physical item at all. Excluded from the BOM by default
  and listed separately, since including software functions or
  logical blocks in a parts list is how a BOM loses credibility.
Report the counts per class and let the user change the exclusion
rule before you build the workbook.

UNITS AND VALUES: carry masses, costs and lead times with their
units, normalised to one unit per column, and say which unit you
chose. Where a value is marked estimated, provisional or
vendor-claimed in the model, carry that qualification into its own
column rather than dropping it. A mass roll-up built from unmarked
estimates is a number nobody can defend.

THE WORKBOOK:
- Cover: model, branch, revision, date, scope, configuration, what
  this BOM is and is not, and the totals.
- BOM: indented structure with level, part number, name,
  description, quantity per assembly, total quantity, unit of
  measure, manufacturer, supplier, unit cost, extended cost, mass,
  extended mass, lead time, lifecycle status, model element ID, and
  any linked requirement. Drop columns the model cannot populate at
  all rather than shipping a sheet of empty fields, and say on the
  cover which you dropped.
- Flat view: the same items deduplicated by part, with total
  quantities, which is what procurement actually uses.
- Findings: items missing a part number, missing a supplier,
  missing cost or mass, duplicate part numbers across different
  parts, the same part under two part numbers, parts with no
  requirement traced to them, and items with obsolete or
  end-of-life status where the model records it.
- Excluded: everything left out, with the reason, so the exclusion
  is auditable.
- Reconciliation: item counts, the quantity arithmetic, and total
  mass and cost with how much of each is covered by real data. If
  forty per cent of items have no mass, the roll-up says so next to
  the number.
Every model element ID stays on the row, so a line can be traced
back and the BOM can be regenerated.

LONG-LEAD AND RISK, if the model carries lead time or status: a
short sheet listing the longest-lead items and anything flagged
obsolete or single-source. This is usually the part of a BOM anyone
reads twice.

BEFORE DELIVERY, render and check the workbook: formulas resolve,
totals match the reconciliation sheet, the indented structure reads
correctly, no column is entirely empty, and the numbers on the cover
match the sheets. Fix anything that does not, then check again.

DELIVER the .xlsx and report: item counts by class, the coverage
figures for the key fields, the findings, and one plain paragraph on
how complete this BOM is and what a human should verify first. Offer,
do not execute: pulling missing procurement data from a component
database, opening tasks for the items with no part number, and
regenerating this against a different configuration.

THIS WORKFLOW IS READ-ONLY on the model.

Replace the [bracketed] placeholders with your model and project names.

What you get

Common questions