The logic that you can apply on the Configurable Bundle is done by using Product Rules. Each Product Rule must be attached at a given level in the Configurable Bundle structure. They can be attached either at the Configurable Bundle level, or on a Selection Group, or on a Selection. The object on which the Product Rule is attached is called the Owner of the Product Rule. The Owner is used to determine the scope of application of a Product Rule. Only products belonging to the owner, or owner’s children can be affected by the Product Rule.

Product rules can be of distinct types:

• Association
• Incompatibility
• Implication
• Recommendation
• Validation
• Initialization

Each rule is described in a dedicated section.

If you want to Create a Product Rule:

How to:

• [In the Explore Structure explorer]
  • Click on the icon of the CB, SG or SE that should be the owner of the Product Rule.
• [In the menu toolbar]
  • Click on New Rule.
• [In the popup]
  1. The owner is automatically selected based on your position in the explorer.
  2. Select a Rule. Only Rules available at the selected level are available.
  3. Add a list of products in the Between/From section (if applicable).
  4. Add a list of products in the To/Recommended section (if applicable).
  5. Optionally add an Explanation.
  6. Click on Add in order to add the Product Rule.
  7. The Product Rule is created and added at the right level of the structure.
• [In the menu toolbar]
  • Click on Save.

    Information:

    Initialization rules have a very specific behavior and cannot be created as described above. Please see the dedicated chapter for more details.

This rule affects one group of products. When one of the products from the group is selected, then all the other products specified in the rule must be selected as well.

The following table specifies the attributes that can be defined on the Association Rule:

This rule affects one group of products. When one of the products from the group is selected, then all the other products specified in the rule cannot be selected anymore.

The following table specifies the attributes that can be defined on the Incompatibility Rule:

The rule affects two groups of products: One “From” group, and one “To” group. When all products from the “From” group are selected, then all the products from the “To” group must be selected as well. This rule is not bidirectional, meaning there is no impact by selecting products from the “To” group on the products of the "From" group.

The following table specifies the attributes that can be defined on the Implication Rule:

In addition to static recommendations that can be manually setup in the Designer, this rule allows dynamically recommending products. Recommended products are then available both in the dialog and in the optimization feature.

The rule affects two groups of products: One “From” group, and one “Recommended” group. When one products from the “From” group is selected, then all the products from the “Recommended” group are dynamically labelled as "Recommended". This rule is not bidirectional, meaning there is no impact by selecting products from the “Recommended” group on the products of the "From" group.

Optimize feature specifics

The Optimization feature can work:

• On static recommendations only, at any moment of the configuration process.
• On dynamic recommendations only. In that case, the optimization on recommended products is available as soon as all the recommended products for all mandatory selections are known.
• On a mix of static and dynamic recommendations. In that case, the optimization on recommended products is available as soon as all the recommended products for all mandatory selections are known.

  Once dynamic recommendations are populated, four use cases can occur for a given selection:

  1. Either the selection contains dynamic recommendations only and these are the ones to be considered.
  2. Or, the selection has no dynamic recommendations but has static ones. In that case, the static ones must be considered.
  3. Or the selection has both dynamic and static recommendations. Then both are valid and can be considered.
  4. The case where no static nor dynamic recommendation is made for a given selection is possible. It requires this selection to be optional in order for the optimization on recommended products to be available.

The following table specifies the attributes that can be defined on the Recommendation Rule:

The validation rule aims at checking if a given condition is met when selecting, deselecting or modifying the quantity of a given product. It assesses the impact of this selection / deselection / modification (quantity) and optionally raises a message giving you visibility on potential actions to take on selections.

Two different types of business explanations can be raised:

• Informative: the message gives you relevant information while navigating through the configuration process. E. g. "You are configuring a toaster T1000 with a titanium grill"
• Blocking: the message warns you about an anomaly in the configuration process requiring you to take action (e.g. modify selections) to fix the raised issue. E. g. "You must select as many computers (3) as screens (2). Please review your selections"

You can define several validation rules, even with an overlap in the list of products involved.

The rule affects two groups of products: One “From” group, and one “To” group. The two groups have the same role: listing products triggering the execution of the rule and that can be checked by this rule. Two groups are available in order to ease the modeling of the rule when a comparison between heterogeneous types of products must be done for instance. When any products from the “From” or "To" groups is selected / deselected / modified (quantity), then the rule is executed and, optionally, a message is raised if conditions are met.

The message raised can be built directly in the rule definition, or it can be set outside of the rule and dynamically given as input.

The following table specifies the attributes that can be defined on the Validation Rule:

VALIDATION MACRO BRC

The Validation rule logic is driven by a Macro BRC with a specific modeling and behavior.

How to define a Validation Macro

• [In the Product Rules Main Frame]
  • Click on the cell in the Validation Rule column.
• [In the popup]
  1. Set a Name for the Macro.
  2. Set a Description for the Macro.
  3. The type of BRC is restricted to Macro only.
  4. Click on Save.
• [In the Product Rules Main Frame]
  1. Click on the cell in the Validation Rule column.
  2. Click on Open BRC and OK.
  3. You are redirected to the BRC Dictionary
• [In Parameters > System Properties]
  1. Notice that the box Validation Macro is checked and greyed.
  2. Notice that no alias can be defined for this type of macro. Aliases for the products of the "From" and "To" groups, and for the optional message, are automatically computed by the system.
  3. All aliases are associated with Must Exist and Must Be Answered flags set to false.
• [In Parameters > Business Logic]
  1. That's where you can build the logic of the Validation Macro (see below)
  2. Click on Save.

Whenever the Validation rule is triggered, the Validation Macro should:

1. Browse the input list(s) of aliases for the products of the "From" - and optionally "To" - group and their quantities. It should also browse the alias for the optional validation message.
2. Depending on the rule:
   • Check for specific but acceptable behaviors and raise an informative message.
   • OR Check for specific and non acceptable behaviors and raise a blocking message.
3. Raise maximum one message.
4. Give the ability to redirect you to a given selection.

To build that logic, specific elements have been added to the Macro Language.

The input aliases deduced from the list(s) in the associated Validation rule can be accessed using the following elements:

• Products of the "From" list: fromProducts.
• Quantities of the products of the "From" list: fromProductQuantities.
• Products of the "From" list: toProducts.
• Quantities of the products of the "From" list: toProductQuantities.

You can also access the product descriptions to use it in the raised message by using the following syntax: ** fromProducts[i]**, where i is the index of a given product in the list.

Two new methods are available to raise either Informative or Blocking messages:

• Informative messages: raiseBlockingBusinessExplanation.
• Blocking messages: raiseInformativeBusinessExplanation.

Those methods take the following parameters as input:

• A message string.
• A label string to name the rule.
• A redirection CPE pointing at a given Selection.

Redirection can be done to a Selection Group or a Selection. For that, you can either:

• hard-code the reference of the Selection Group / Selection in the Validation Macro code directly.
• or dynamically reference the Selection Group / Selection of one of the products given as input of the Validation Macro.

For the latter, you can use the following expression:

• confML.getSelection("to",2) to get the Selection CPE corresponding to the product in the To table at index 2.
• confML.getSelectionGroup("from",1) to get the Selection Group CPE corresponding to the product in the From table at index 1.

Example of a macro raising an informative message when a given item is selected with a quantity of 1:

DEFINE brcValidationInformative()

LET msg ""

LET lbl "myRule"

LET redirection "CPE.wksA/SE/se1"

LET i 1

WHILE IsDefined(fromProducts[i])

IF (fromProducts[i] = "wksA/SI/siA")

IF IsDefined(fromProductQuantities[i])

IF (fromProductQuantities[i] = 1)

LET msg msg + "You are currently configuring a great product."

END_IF

END_IF

END_IF

LET i i+1 END_WHILE

confML.raiseInformativeBusinessExplanation(msg, lbl, redirection)

END_DEFINE

Example of a macro raising a blocking message if two specific items do not have the same quantity:

DEFINE brcValidationCompare()

LET msg ""

LET lbl "myRule"

LET redirection "wksA/SE/se1"

LET i 1

LET qtyFrom 0

LET qtyTo 0

WHILE IsDefined(fromProducts[i])

IF(fromProducts[i] = "wksA/SI/siA")

IF IsDefined(fromProductQuantities[i])

LET qtyFrom fromProductQuantities[i]

END_IF

END_IF

LET i i+1 END_WHILE

LET j 1

WHILE IsDefined(toProducts[j])

IF(toProducts[j] = "wksA/SI/siB")

IF IsDefined(toProductQuantities[j])

LET qtyTo toProductQuantities[j]

END_IF

END_IF

LET j j+1 END_WHILE

IF(qtyFrom != qtyTo)

LET msg "You have the same number of A and B - " + STR qtyFrom + " - Which is good!"

confML.raiseInformativeBusinessExplanation(msg, lbl, redirection) ELSE

LET msg "You don't have the same number of A - " + STR qtyFrom + " - and B - " + STR qtyTo + " - Which is bad!"

confML.raiseBlockingBusinessExplanation(msg, lbl, redirection) END_IF

END_DEFINE

Example of a macro raising an informative message given as input as a validation message:

DEFINE brcValidationRaiseValidationMessage()

LET lbl "myRule"

LET redirection "CPE.wksA/SE/se1"

IF IsDefined(explanation)

confML.raiseInformativeBusinessExplanation(explanation, lbl, redirection) END_IF

END_DEFINE

OVERVIEW

Initialization rules have a very specific behavior and are not exactly defined like the other rules presented above. Their goal is to contextualize the set of entities part of a Configurable Bundle dialog (Selection Groups and their Selections) at opening, based on tags statically associated with SG entities during the modeling.

Let's take a business example. Let's imagine a company building machines sold to end customers by two different resellers. Each reseller has the capability to add different exclusive sets of options for a given machine. In terms of modeling, you would design a single Configurable Bundle with all possible options accessible to all resellers. You would then define a tag for each reseller and associate each tag only with the options (at a Selection Group level) the reseller can propose to customers. At runtime, whenever a given Sales Rep for a given reseller would start configuring a Bundle, the tag of the corresponding reseller would be given as input, thus filtering the dialog to the Selection Groups tagged accordingly.

To detail a bit more that example, let's consider the following Configurable Bundle structure with tags corresponding to reseller A and reseller B:

CB

• SG1 (tags A, B)
  • SE1.1
  • SE1.2
• SG2 (tag B)
  • SE2.1
  • SE2.2
  • SE2.3

If reseller A runs the CB process, the tag A is given as input at opening, thus filtering the dialog as follows:

CB

• SG1
  • SE1.1
  • SE1.2

If reseller B runs the CB process, the tag B is given as input at opening, thus filtering the dialog as follows: CB

• SG1
  • SE1.1
  • SE1.2
• SG2
  • SE2.1
  • SE2.2
  • SE2.3

    Important Information:

    • The purpose of the tags in the initialization rule is to reduce maintenance by allowing addressing several scenarios in a single Configurable Bundle process. However, the tags are not a way to manage the access to a Configurable Bundle based on user profiles.
    • The definition of tags to drive the configuration of Bundles must be thought at the quote level. It means that all Bundles added to a given quote must use the same list of tags as input. If not the case, you may face issues when refreshing a quote containing Bundles initialized with different tag lists.

HOW-TO DEFINE TAGS

Tags are objects that can be created and managed in the Designer.

How to:

• [In the Designer home page]
  • Select your Workspace and click on Edit this workspace.
• [In the Parameter tab]
  1. Scroll down to the Define Tags section.
  2. Click on Add Tag.
  3. Select the Tag class.
  4. Give the tag a Name and Description and click on Create.

TAGGING SELECTION GROUPS

In Configurable Bundles, tags can be associated with Selection Groups only. When a SG is tagged, then its sub-tree (SEs part of it and their products) inherits from its tags. If a SE is part of different SGs, then it inherits from all tags of all the SGs it is part of (knowing that only one of those SG may be displayed at a given time).

The tagging action - meaning associating tags to a SG - is static.

How to:

• [In the Bundle section of the Designer]
  • Click on your CB and navigate to the Structure tab.
• [In the Structure tab]
  1. Select the SG to tag in the explorer.
  2. In the System Properties section of the SG, click on Add Tags to the Tag List.
     
     
  3. In the Add Tags window, the tags in the left part are the ones available in the workspace. Move the tags in the left part you want to associate to the selected SG to the right part. If you move a tag from right to left, then it removes the association with the selected SG for this tag.
     
     
  4. Click on OK.

TAGGING PRODUCT RULES

Similarly to the SG tagging explained above, you can tag all types of product rules (Validation, Recommendation, Association, Incompatibility, Implication) to execute only those matching the tags given as input of the CB when opening it.

How to:

• [In the Product Rules tab]
  1. Identify the rule to tag and click in the cell of the Tags column for this rule.
     
     
  2. In the Add Tags window, the tags in the left part are the ones available in the workspace. Move the tags in the left part you want to associate to the selected rule to the right part. If you move a tag from right to left, then it removes the association with the selected rule for this tag.
     
     
  3. Click on OK.

INITIALIZATION RULE EXECUTION

The initialization rule is executed only once per Configuration session, meaning at the opening of the CB and prior to any other rule defined in the Designer (Recommendation, Validation, Association,

Implication, etc.).

The initialization rule is based on a list of tags given as input. This list of tags is given as a context CPE. This CPE references a session variable (aka. CPE.Settings.Session.InitializationTags). It can thus be filled in several ways, including via the mapping mechanism from a CRM for instance.

As explained above, the initialization rule does not require any modeling in the Designer, except for the tagging. It also implies that the session variable has to be filled prior to the opening of a given CB.

When opening a CB process, the Configurator checks the tag list in the session variable described above:

• If the tag list is empty, then all non-tagged entities of the CB are displayed as part of the dialog.
• If the tag list contains one or several tags, then the corresponding tagged SGs (and sub-trees) and / or tagged rules are used in the CB process.
• The elements (SG or Rule) that are not tagged are always displayed.

  Warning:

  All CB have their initialization rule based on the same session variable. If the list of tags has to be different from one CB to the other, then the session variable must be updated dynamically by CPQ.

Defining the Sales Breakdown

Once a Configurable Bundle structure has been set up, and once product rules have been added, you need to define a Sales Breakdown to the Configurable Bundle.

The Sales Breakdown purpose is to produce some tangible outputs and to determine which criteria can be used for the optimization feature.

In the Sales Breakdown step, you can define how you want to influence the system when it completes/optimizes the Configurable Bundle. For each Price and Business Property that is used as an output of the Configurable Bundle, you can define if you expect the system to try to make this value as small or as big as possible.

When asked for an optimization, the system then selects missing products by making the result the smallest or the biggest for the selected criteria.

The Sales Method step focuses on the setup of a Sales Method. In order to setup a Sales Method, make sure that at least one Sales Method has been defined in the workspace parameters.

Definition: A Sales Method is a generic representation of a quote, that is made of a set of sales breakdown lines and that indicates the information to be applied (meaning: be generated) on each Sales Breakdown line.

Reference: In order to create new parameters, please refer to Define Methods.

For each Sales Method added in the workspace, an additional sub-tab is created.

Once the sales method has been setup, its sales breakdown lines should be defined. To do that, proceed as follows:

How to:

• [In the Sales Breakdown sub-tabs]
  • Select the appropriate Sales Method in which you want to add a Sales Breakdown line.
• [Using the Filter Objects explorer]
  1. Select a workspace for the object to retrieve.
  2. Select the type of object you want to add in the Sales breakdown. It can be either a Pricing Method, or a Business Property.
  3. (Optionally) Choose a user type.
  4. Enter part of the object name or description.
  5. Click on Search.
  6. In the result list, select and drag&drop the expected element to the grid on the right side of the screen.
• [In the Pricing Lines or Business Properties Lines grid]
  • Complete the Sales Breakdown line settings.
  • Click on Save.
    Warning: For Business Properties on Sales breakdown lines, only numeric or integer Business Properties can be used.

The list below shows the Sales Breakdown lines attributes for Pricing Lines:

The list below shows the Sales Breakdown line attributes for Business Property Lines

To remove a specific line in your Sales method, you must check the box associated to the Sales Breakdown line you want to delete (in the grid) and then click on "Delete" in the menu toolbar.