Bills of Materials

​

Overview

The BOM section defines product structure for your factory — what each product is made of, what components are required, in what quantities, and under which variant conditions. BOMs are the foundation for production planning: the optimizer uses them to determine what needs to be produced upstream to fulfill downstream demand. ProDex carries two related-but-distinct objects in this section:

• Standard BOMs — production recipes used by the planning optimizer. Each BOM represents one assembly or material: a parent item, its child components, and the quantity of each component needed to produce one unit of the parent. Optionally, a variant condition narrows the recipe to specific configurations.
• Configuration Templates — configurable product structures used by the Configurator. Instead of a fixed recipe, templates define which options and substitutions are valid for a product family. A template contains materials (always-included components) and option classes (decision points with choices that can nest further option classes, forming a tree of decisions). Templates produce Configurations — saved, per-order records of the selections made and their resolved parts lists. Each Configuration owns a chain of immutable Revisions, so reconfiguring creates a new revision rather than overwriting the previous one — preserving a full audit trail.

Both live in the BOM section of the UI. They serve different questions: Standard BOMs answer “how do we make this?”; Configuration Templates answer “what variants are valid for this configurable product?”.

​

Entities

BOMs reference entities — the products and materials your factory works with. Before you can create a BOM, the entity it produces must exist in your factory’s entity library. Each entity has a name, a description, a unit of measure (default “EA”), and a set of attributes that describe its dimensions of variation — things like size, color, grade, or material class. These attributes are what variant conditions use to distinguish between recipes for the same product. For example, a “Pipe” entity might have attributes for diameter, material, and schedule — and different BOMs for that entity can specify different component lists depending on those values. Entities are factory-scoped: they’re shared across all models, BOMs, and planning configurations in the same factory. Renaming or deleting an entity affects every BOM that references it.

​

How BOMs Work

A BOM links a parent entity to its components — other BOMs that must be produced or sourced to create one unit of the parent. Each component reference points to a specific BOM (not just an entity), which matters when the same entity has multiple variant recipes. The parent-child relationships form a structure from finished goods at the top down to raw materials at the bottom. Because the same component can appear in many parents — a fastener used in three different assemblies is defined once and referenced by all three — the BOM structure is a graph, not a strict tree. That shared structure is also why where-used exists: given any component, you can trace upward to see every assembly that depends on it.

​

Material Classification

ProDex automatically classifies every material based on where it sits in the BOM structure:

• SKU — a finished good. Has components (it’s built from something) and is not itself consumed by any other BOM. These are the items you fulfill demand for.
• INTERMEDIATE — a sub-assembly or work-in-progress. Has components AND is consumed by at least one other BOM. Produced internally and fed into downstream assemblies.
• RAW — a purchased material. Has no components — it’s sourced externally. Any entity without child components is classified as RAW.

You don’t set classifications manually — they are derived automatically as you build the structure. Classification determines what kinds of planning inputs an entity can appear in: demand orders only accept SKU-classified entities, and supply orders only accept RAW-classified entities.

​

Browsing BOMs

The BOM page opens to the All Entities view — a list of every entity in your factory with color-coded level badges (L0, L1, L2, L3, L4+) showing each entity’s depth in the BOM structure. Use the search input and filters (by level, by attribute) to narrow the list. Click into any entity to see its expanded tree view — the full assembly structure from that entity down to its leaf-level raw materials, with quantities at each level. This is how you inspect multi-level product structures and verify your BOM data before running a plan.

​

Creating a Standard BOM

1. Navigate to BOMs & Supply in the sidebar
2. Create an entity first if one doesn’t exist yet — click Create entity and define its name, attributes, and unit of measure
3. Create a BOM for that entity — the BOM is the recipe, the entity is the product
4. Add components to the BOM: for each child, select the component and specify the quantity needed per unit of output (quantities are whole numbers, minimum 1)
5. Optionally add a variant condition to narrow the recipe to specific configurations
6. Save

Each BOM is scoped to a factory and shared across all models and planning configurations — any change to a BOM is visible everywhere it’s referenced. Creation order matters. Define your raw materials and leaf-level components first, then build upward through sub-assemblies to finished goods. The system rejects circular references — every component you add must already exist.

​

Variant Conditions

A single entity can have multiple BOMs — for example, the same product produced under different configurations. Variant conditions tell the planner which recipe applies to which order. Variant conditions work by referencing attributes on the entity. If your “Pipe” entity has attributes for diameter and material, you can create one BOM for 12-inch carbon steel pipe and another for 8-inch stainless — each with different component lists and quantities. When a demand order specifies diameter: 12 and material: "carbon steel", the planner matches it to the BOM whose conditions are satisfied. There are four condition types:

• Boolean — an attribute is true or false (e.g., requires_coating)
• Discrete text — an attribute matches one of a list of allowed values (e.g., material is one of “carbon steel”, “stainless”, “alloy”)
• Discrete number — an attribute matches one of a list of allowed numbers (e.g., diameter is one of 8, 12, 16)
• Range — a numeric attribute falls within a bound (e.g., length between 10 and 20). Range bounds are inclusive on the lower end and exclusive on the upper end by default; both can be configured. Either bound can be left open for one-sided ranges.

A BOM with no variant condition is the default recipe — it matches any order for that entity. A BOM with conditions matches an order only when the order’s values satisfy every condition. Orders can carry more attributes than a BOM conditions on — extra attributes are ignored during matching. But if the BOM conditions on an attribute that the order doesn’t specify, the match fails.

​

Configuration Templates

Configuration Templates are a separate object type that lives alongside standard BOMs in this section. They define the option space for a configurable product family and feed into the Configurator, where the agent walks the option tree and proposes selections for user review, resolving to a concrete parts list for a specific order.

​

Where-Used

Where-used is the reverse of the tree view: given any component, find every parent assembly that depends on it — tracing upward through the structure toward finished goods, with the quantity consumed at each level. This is the right tool for impact analysis. If a component’s lead time changes, its specification is updated, or it’s being discontinued, where-used shows you every finished good affected and how many units of the component each one needs.

​

BOMs and Planning

Once your BOMs are defined, they feed into the Planning module. A planning model includes an explicit list of which BOMs participate — BOMs not included in that list are invisible to the optimizer, even if they exist in the factory. The planning optimizer uses the included BOMs to:

• Determine which intermediate materials need to be produced to meet finished-good demand
• Enforce resource capacity constraints — total consumption of each resource per interval cannot exceed available capacity
• Match each demand line to the correct variant of the BOM
• Respect precedence — sub-assemblies must be produced before the finished goods that consume them

​

Planning Runs

Each planning run is a scenario with its own inputs:

• Demand orders — what you need to produce: which finished goods, in what quantities, by when, and optionally for which variant. Each order carries a tag that controls its priority and penalty behavior (hard deadline vs. soft, penalty weight).
• Supply orders — raw materials you expect to receive: which materials, how much, and when they arrive
• On-hand inventory — current stock levels at the start of the planning horizon
• Inventory goals — target inventory levels you want to maintain, with acceptable bands above and below the target. Each goal carries a tag that controls its penalty behavior (rolling vs. non-rolling, weight).
• Resource capacity — how much of each resource is available in each planning interval

A planning model can have multiple runs, each representing a different scenario — different demand forecasts, different capacity assumptions, different inventory positions. Results from multiple runs are stored and can be compared side by side. Changes to BOMs take effect on the next planning run; existing planning results are not retroactively recalculated.

​

Best Practices

• One entity, many recipes — not many entities. When products share the same structure but differ in specific characteristics (material grade, size, color), model them as one entity with attributes and multiple BOMs with variant conditions — not as separate entities. The number of BOMs should reflect the number of recipe-relevant attribute combinations, not the total product catalog.
• Keep variant conditions minimal. Only condition on attributes that actually affect the recipe. If your pipe BOM has the same components regardless of length, don’t add a length condition — leave it as a wildcard. Fewer conditions mean fewer BOMs to maintain and less surface area for overlap errors.
• Verify your BOM list in the planning model. The most common planning issue: a BOM exists in the factory but isn’t included in the planning model’s BOM list. After creating or modifying BOMs, confirm they appear in the planning model before running the optimizer.
• Use where-used before making changes. Before modifying a component’s specification, quantity, or lead time, run a where-used check to understand the full impact. A change to a shared component ripples through every assembly that depends on it.
• Name entities descriptively. Use human-readable names (“Carbon Steel Plate, 12mm”) rather than part numbers or codes (“CS-PLT-012”). Part numbers can go in entity attributes if needed for cross-referencing, but the name should be immediately understandable to anyone reading the BOM.
• Use descriptions as operational context. BOM and entity descriptions aren’t just labels — they’re where you document sourcing decisions, business rules, and the reasoning behind structural choices. When someone asks “why is this BOM set up this way?” six months from now, the description is the first place they’ll look.
• Set resource capacity for every interval. Resource capacity defaults to zero for intervals without an explicit entry. If you define capacity for weeks 1–3 but not week 4, the optimizer will schedule zero production requiring that resource in week 4. Ensure every resource has capacity defined for every interval in the planning horizon.
• Test with a single planning run before building scenarios. Before creating multiple what-if scenarios, get one baseline run working: demand orders, supply orders, initial inventory, resource capacity, and a successful optimization. Validate that the results match your intuition before branching into alternatives.
• Keep BOMs and planning models in sync. When you add, remove, or restructure BOMs, review every planning model that references them. A structural change to a BOM (adding or removing a component) can shift material classifications, which in turn affects which entities are valid in demand orders vs. supply orders.