Skip to main content

​
Overview

Product structure in ProDex is captured across two related surfaces:
  • BOMs — the production recipes for every item you make or buy: a directed acyclic graph of parents and components that the planning optimizer relies on to translate finished-good demand into upstream production and raw-material procurement. (Resource requirements aren’t carried on the BOM itself — they’re declared per-BOM on the planning model.) BOMs live on the BOMs & Supply page.
  • The Configurator — how you handle configure-to-order products: walk an option tree, make selections, pin per-material attribute values, and land a concrete parts list for one specific order. Templates and their configurations live side by side on the Configurator page.

​
The Four Artifacts

​
When to Use Which

  • Flat recipe, no per-order decisions — author it as a BOM. If the product varies along a small number of attributes with a fixed recipe per combination, use one entity with variant BOMs.
  • Per-order choices with cascading structure (roof type, engine option, accessories, cross-class rules) — author a Configuration Template and run the Configurator per order. The template captures the space; each order writes a configuration under it.
  • A configurable product line that also feeds planning — do both. Author the template for the customer-facing decision walk, and author BOMs for the material flow the optimizer needs. The two are not automatically linked — see the handoff notes below.
If you find yourself wanting to use a template directly in a planning model, that’s the signal you actually need a BOM. Templates describe what a product can be; BOMs describe how it is made.

​
Exploring the Structure

From the BOMs page you can drill down through any assembly to its raw-material leaves, or run where-used up from any BOM to see every parent that consumes it. Both directions — including running them through Dexter — are covered in BOM Explosion & Where-Used.

​
Planning and Simulation Handoff

  • Planning reads BOMs directly. Every planning model carries an explicit BOM list — BOMs outside that list are invisible to the model.
  • Simulation references entities through model nodes. Neither BOMs nor templates flow into a simulation model automatically.
  • Configurations do not auto-create demand orders. A completed revision’s resolved parts list is available for you (or a pipeline) to hand off into planning demand as a distinct step.
Dexter gives you natural-language access to all of the above: ask it to explode a BOM, run where-used, walk a Configurator turn, or reconfigure a completed configuration.