Configured Component Definition and Multi-Level Processing

Since we also have a configured component for the desk, we must also define the drawers as a configured part on the Part Master File.  Our drawers will not be configuration costed and therefore will not have configuration codes associated with them.  The procedure for defining the drawers is the same as that of the desk.

In essence, when using the configurator in a multi-level environment, you will define two or more configured parts.  In our example, we define two configured parts (desk and drawer).  Since both are defined as configured parts, we could actually order and manufacture or purchase each as separate configured products (for example, the drawer could be requested by itself as a service part).  However, in our example, we want our configured desk product to contain the configured drawer part.  To accomplish this with the configurator, we define a Configured Component Rule for the desk (Configured Component rules are discussed in more detail later, also see Configured Component Rule).  This rule specifies that the desk requires a component part that is also configured.  Functionally, this rule serves as a bridge between the two configured parts. 

When the Configured Component Rule is encountered within the desk's bill-of-rules, desk configuration processing ends and drawer configuration processing begins.  After drawer configuration is complete, processing of the desk begins again at the point immediately following the configured component rule.  In essence, multi-level configuration is a modular process.  Each configured component is processed when its configured component rule is encountered.  This process may be nested as many times as necessary to create a configured product.  In our example, we could define the drawer part to have a configured component such as handles or sliding tracks, and the desk could also contain further configured components.  The Expert Configurator makes this easy by processing each component separately.