Skip to main content

​
Overview

The BOMs page defines what your products are made of. It is the structure production planning uses to translate finished-good demand into upstream production and raw-material procurement. A BOM is the production recipe for one item you make or buy. BOMs are organized as a directed acyclic graph: a BOM with no components is a raw material, and a BOM with components is an assembly. One entity can have several BOMs, either because the recipe varies by configuration or because there is more than one way to make the same thing. This page covers BOMs themselves. Configuration templates, which describe what a configurable product can be, live in the Configurator. The BOMs & Configuration overview explains how the two fit together.

​
The BOMs Page

The page drills down in three levels:
  1. Entity list. Every entity in the factory, with its Unit, Level, Attributes, number of BOMs, and Used In count. Level is the entity’s depth in the structure: L0 is a top-level product that nothing else consumes, and higher levels sit further down. Search, filter by level or attribute, and use Create entity to add one.
  2. Entity. Click an entity to see its BOMs, each with the conditions it covers. The side panel holds the entity’s description, Unit, and Attributes. Create BOM adds a recipe for this entity.
  3. BOM. Click a BOM to open it. The side panel holds its description, its Conditions, and the Used in list. The main area has three views:
    • Tree: the component tree, expandable level by level, with the quantity per unit of the parent on each line. Add components with Add component, or remove one from its row.
    • Table: the BOM’s direct components with Component, Qty, Unit, and Conditions columns.
    • Graph: the BOM as a node diagram. Select a component and click Explode to expand everything beneath it, or Go to BOM to open that component’s own BOM.
The Used in list shows the direct parents of the open BOM: the BOMs that list it as an immediate component. Click a parent to open it. Exploring the graph in either direction is covered in BOM Explosion & Where-Used.

​
Entities

Every BOM produces an entity. An entity has a name, an optional description, a unit, and a set of attributes that define the dimensions along which members of that product family can differ. A canned-seafood entity might carry species, sourcing, and can_size attributes; a bracket entity might carry material_grade. Add attributes with Add Attribute in the entity’s side panel. Attributes come in five types: Entities live at the factory level and are shared across every model, BOM, and planning input. Deleting an entity also deletes every BOM for it, so make the change deliberately.

​
How BOMs Work

A BOM links a parent entity to zero or more child components. Each component points to another BOM, not to a bare entity. That distinction is what lets the graph carry different recipes for the same entity: the parent chooses which specific child BOM it wants, not just which entity. BOMs form a directed acyclic graph:
  • Every node is a BOM; edges are defined by a BOM’s components.
  • A material can’t be part of its own BOM. Changes that would create a cycle are rejected when you save.
  • The same child BOM can be used by many parents. It’s a graph, not a strict tree.
  • Each component quantity is the amount consumed per unit of the parent. It must be greater than 0, and fractional quantities such as 0.25 are allowed.
The Add component quantity field in the Tree view takes whole numbers. To set a fractional quantity, ask Dexter to update the BOM.

​
Material Classification

When a BOM is used in planning, its type comes from its position in the graph and is never set by hand: Every material in a plan needs a BOM, including raw materials; an entity with no BOM can’t be planned or supplied. Classification decides what each planning input accepts: demand orders accept only SKUs, supply orders accept only RAW materials, and on-hand inventory and inventory goals accept any classification. See Demand & Supply.
Classification is evaluated against the BOMs in the planning model, not the whole factory. A finished good whose BOM has no components yet is classified RAW, and a finished good that another BOM in the model consumes becomes an INTERMEDIATE. Either one produces “Only SKU entities are allowed in demand orders” when you add it as a demand line.

​
Variant Conditions

One entity can have multiple BOMs, each covering a different region of the entity’s attribute space. Each BOM carries conditions on the entity’s attributes that narrow which configurations this recipe serves. All conditions on a BOM must match, and attributes the BOM does not mention are wildcards. A BOM with no conditions (shown as Universal (no conditions)) is the default recipe for the entity. Add a condition from the Conditions section of the BOM’s side panel: click Condition, pick the Attribute, and set the value. The value you can set depends on the attribute’s type: When several BOMs for the same entity condition on the same attribute, they must all use the same kind of condition for it. One BOM can’t match can_size against a list of values while another matches it against a range.

​
Matching Orders to BOMs

Variants on demand orders, supply orders, on-hand inventory, and inventory goals are matched against BOM conditions by subset, not exact match: for every attribute the BOM mentions, the input must carry the same attribute with a value that falls inside the BOM’s condition. Attributes the input carries that the BOM doesn’t mention are ignored; attributes the BOM mentions that the input omits cause the match to fail. This lets each BOM condition only on the recipe-relevant attributes while the order carries the full product spec. An entity with five attributes may need only two BOMs if the recipe varies along one dimension. A BOM with no conditions mentions no attributes at all, so it matches any input.

​
Identical or Mutually Exclusive

When an entity has several BOMs, each pair must be either identical or mutually exclusive:
  • Identical conditions (including two BOMs with no conditions) make the BOMs alternative recipes for the same material. The planning optimizer chooses between them and can split production across them. Alternative recipes must all be assemblies or all be raw materials; a material can’t be both bought and made.
  • Mutually exclusive conditions each own a distinct region of the attribute space. Two BOMs are mutually exclusive when at least one shared attribute has conditions with no value in common.
Anything in between is ambiguous and fails validation when you validate a planning scenario:
  • A default recipe can’t sit next to a conditioned BOM for the same entity. A BOM with no conditions overlaps every other variant, so it can only coexist with other unconditioned BOMs. Once one BOM for an entity has conditions, give every BOM for that entity conditions.
  • Two BOMs that condition on completely different attributes are not mutually exclusive. Both can apply to the same input. Make sure the BOMs for one entity share at least one attribute with non-overlapping conditions.

​
Creating a BOM

  1. Create the entity first, if it does not exist (Create entity on the BOMs page). Name it, set its unit, and add the attributes the recipe or the demand side needs to distinguish variants.
  2. Open the entity and click Create BOM. Give the BOM a name and optional description.
  3. In the Tree view, use Add component to add each component BOM with its quantity.
  4. If more than one recipe applies to this entity, add Conditions that narrow this recipe to the region of the attribute space it serves.
Build bottom-up: raw materials before the assemblies that consume them, layer by layer up to the finished good. A component must already exist before a parent can use it.
When a BOM’s structure or quantities come from source data, such as an ERP export, a parts list, or a customer document, upload the file and ask Dexter to build the entities and BOMs from it.

​
BOMs and Planning

A planning model lists the BOMs the optimizer plans with. You select the top-level BOMs; every component BOM they use is pulled in automatically, all the way down. A BOM that is neither selected nor a component of a selected one is invisible to that model. Given those BOMs, the optimizer uses them to:
  • Derive intermediate production from downstream SKU demand
  • Resolve each demand line to the matching BOM
  • Choose between alternative recipes for the same material
  • Respect precedence: a parent cannot be produced before its components are available
Resource usage is not part of the BOM. It lives on the planning model’s bill of resources, so the same BOM can load resources differently under different models. Each scenario then supplies the demand orders, supply orders, on-hand inventory, inventory goals, and resource capacity to plan against. Changes to a BOM take effect the next time a scenario runs; existing results are historical.

​
Best Practices

  • Build bottom-up. Author leaf BOMs first, then the layers above.
  • Prefer one entity with variant BOMs to many entities. Products that share production structure but differ along specific dimensions are the same entity with attributes, not separate entities.
  • Condition variants on the fewest attributes that actually drive the recipe. Every extra attribute in a condition is a place the demand match can fail.
  • Share an attribute across variant BOMs of the same entity. BOMs that condition on unrelated attributes are rejected as ambiguous.
  • Check the Used in list before changing a shared component. Every parent that consumes it moves with the change.
  • Name entities descriptively. Human-readable names survive reorganization and read cleanly in errors; opaque part numbers do not.
  • Use descriptions as operational context. They are the durable notes the next person reads.