A configurable product can be modelled to have the product specific rules. In the Digital Sales Platform, rules are represented in a technical term called, KBTrigger and the same type of rules are grouped together inside an object having a technical type called, KBTriggerGroup ( In excel, we will call RULE_ sheet to represent the KBTriggerGroup ). The technical representation of the relationships of rules to product is as follow.
Depending on the complexity and requirements of product model, product rules can be defined within the knowledge base or using the IMCScript. However, the rules to define the range restriction and BOM explosion can only be done inside the knowledge base as of 1902 release. Generally, the rules are defined in order to do the following tasks.
- to restrict some attribute’s range value based on the configuration data
- to perform the BOM Explosion
- to assign some values based on certain condition
- to assign the property of an attribute such as read Only, mandatory, costing Relevant, hidden
- to calculate some attribute value
Range Restriction Rule
Defining Range Restriction Rule via GUI
The range restriction will limit the values of the certain attributes based on some other attributes value assigned in the configuration page or some data point inside the Quote or SalesItem using the Quote Attribute/KBTriggerRelation ( See how to define Quote Attribute/KBTriggerRelation in Product Characteristics Definition ) in rule.
- Create Range Name
- Add the attributes and click the Triggers tab
- Create new trigger and add range restriction condition
- BOM Entries are not needed to define for the type having type, Range ( White List ). They are only needed to define when the type of rule is BOM or BOM_AND_RANGE.
Example of a Rule
Viewing All Rules
In above example, there are three triggers, if the user selected DA1 value to be DA1_1, user will only see the DA2 value as DA2_1 and DA3 value as DA3_1.
To see the data more clearly as shown below, a product modeler can download the data into excel sheet by downloading the existing knowledge base.
Select the sheet starting with name RULE_
Example Rule Sheet Showing All Rules inside A Group
Note: A product modeler can add the more than one KBTriggerRelation/Quote Attribute as part of controlling value for range restriction.
Example of Defining Range Restriction by Attribute and Quote Attribute
Creating Range Restriction Via Excel
In order to create range restriction rule, it is recommended that product already had the Knowledge Base and all the attributes to be considered for that product have been added to the Knowledge Base. By doing so, user can see the range value as a drop-down list in Rule sheet.
- Select the knowledge base to define the new range restriction rule or update the existing one rule if there is an existing knowledge base
- Select the Range (White List) and specify the number of range restriction group
- Click download to obtain the knowledge base excel template with/without existing data
Downloading an Existing Knowledge Base with Additional Range Rule Sheet
The following template with the new sheet called, RULE_2 will be obtained. The new sheet will also list all the DA having enumerable property automatically together with drop list for each column.
- Define the header of the RULE
- Enter the name of the rule
- Define the Sequence ID of the rule (Defining the sequence ID will make sure that the order of sheets inside the workbook will be maintained when user downloaded it from KnowledgeBase again)
- The new rule sheet will list all the DA with enumerable property inside a knowledge base and user can add new DA which is not enumerable or remove it if it is not necessary.
- User can also add the new column using the QUOTE_ATTRIBUTE by following the naming convention such as QUOTE_ATTRIBUTE.[Name of KBTriggerRelation] and use the value based on definition of KBTriggerRelation’s onType and onAttribute property.
- Define the details of the RULE
- In this example, we will use DA1 (which is a shared DA used in RULE_1, DA4, and DA5)
- Remove other attributes column that are not part of the range restriction rule
- Define the range restriction rule and upload
Define the range restriction rule as above and uploading will show as follow
Note: A product modeler can manually add the Quote Attribute in range restriction/BOM explosion Rule sheet if the requirement is to restrict range value not only be attribute value but also by Quote Attribute value such as Sales Organization of Quote or Product Status of Sales Item which is being inserted.
Understanding the concept of Range Restriction
Currently range restriction algorithm is using the OR operator between the attributes within a same sheet and UNION concept is used to combine all range values obtained from different rule sheets if there is no intersected range values or INTERSECTION concept is used if there are intersected range values from all groups having the shared attribute. If there is a shared attribute among the different group and the attribute that user wanted to see the range value is on that attribute, the following concept will be applied.
Concept One: All Group Having Common Range Value
For example, we had three rule groups/sheets and each rule group/sheet can return the common attribute as shown below, user will only see the value(s) which are in common in all three groups. According to below example, you will see the value 2.
All Groups with Shared Attribute Having Common Range Value ( Three Groups - above)
All Groups with Shared Attribute Having Common Range Value ( Two Groups - above)
Concept Two: All Groups with Shared Attribute Not Having Common Range Value
In case, all groups having shared attribute does not return the common attribute in all groups or one of the groups, it will return the UNION values obtained in all groups.
All Groups with Shared Attribute Not Having Common Value in One of Groups (above)
All Groups with Shared Attribute Not Having Common Value (above)
If the requirement is to provide range restriction based on some logical condition ( For example, if DA1 > 10 and DA1<= 20then range value of DA2 must be 1,2,3 and if DA1>20 then the range value of DA2 must be 4,5,6), the product modeler can make use of Simplified Conditional Rule and Dummy Attribute to assign unique value ( See also Case 5 How to get range value based on some logical condition for more information about how to implement such use case ).
Use Case 1: Ignoring the rule
For example, Let’s say, we had defined the following two groups/rules as shown below and user has selected the DA4 value as DA4_4.
When the user clicks on the DA1 to see the range value of it based on above rule, he/she will see the DA1_4 as shown below. That is because, the RULE 1 is not applying as none of the conditions are met. Only Rule 2 was applied by filtering the DA4 value to be DA4_4.
Use Case 2: Applying both rules for shared attribute’s range values
Let’s say user selected DA2 to be DA2_1 and DA4 to be DA4_4. When the user selected the DA1 which is used both RULES, he/she will see the values for DA1 as DA1_1 from RULE 1 sheet and DA1_4 from RULE_2. This case shows that it is using OR between the Attributes inside a sheet and the UNION concept to gather all the results obtained from different rule group ( RULE_ sheet ) as there is no common value returned from two different rule group/sheet.
No Common Values in Both Group (above)
Example Range Restriction Showing OR and UNION Concept (above)
Use Case 3: Combining Rule which had shared attribute into one to restrict more
Let’s say the requirement is to show DA1 as DA1_1 if DA2 is selected as DA2_1 or DA1 as DA1_4 if DA4_4 is selected. In order to solve this requirement, it is needed to combine all sheet having the common attribute, in this case DA1 as follow.
After combining two sheets into one as above, the DA1 value will still be shown as DA1_1 and DA1_4. That is because of the following
- In row with DA1 having value DA1_1, DA2 and DA3 will be used to check the condition using [OR]. Since DA2 is having DA2_1, that row is valid as it is using [OR] condition between the condition attributes for Range Restriction.
- In row with DA1 having value DA1_4, DA4 and DA5 will be used to check if row is valid for getting range value. Since DA1_4 is having DA4_4, the row is valid and thus DA1_4 will become part of the range value for DA1.
In order to satisfy the requirement to show only DA1_1 once DA2_1 was selected in DA2, it is needed to put default value in DA2, DA3, DA4 and DA5 for those rows which has value assigned for DA1.
In this way, user can only select DA4 as DA4_NONE when DA2 was selected first with value DA2_1 which lead to have value for DA1 as DA1_1 if the user started from DA2.
If user started with the DA4 with value DA4_4, he/she will see None in DA2 and DA1 value as DA1_4 as shown below.
Use Case 4: Concept About Intersected Range Value in Different Group
Let’s say we had the following range rule defined and user expected to show DA1 value as DA1_1 once DA2 was selected as DA2_1 and DA4 as selected as DA4_4. It means, he/she wanted to show the range values which are in common (ie. DA1_1). In term of set theory’s intersection rule, Range Value from Rule 1 (DA1_1) ∩ Range Value from Rule 2(DA1_1, DA1_4) = DA1_1.
Since both RULE groups are having the common range value DA1_1 from RULE_1 and DA1_1,DA1_4 from RULE_2 due to interception concept, the final range value becomes DA1_1.
Intersection Concept Used In This Case(above)
Use Case 5: How to get range value based on some logical condition
Let’s say the requirement is to obtain the range restriction based on some attribute value which is greater than or equal to certain value. Firstly, the attribute to use as condition must be DDA and having the data type, Numeric. Below is an example rule definition to restrict the range value of DA1 based on DDA_NUMBER1. Example, if DDA_NUMBER_1’s value is greater than 10 and less than or equal to 20, the range value for DA1 should be DA1_1.
Since range restriction algorithm only apply the EQUALTO operator for the value in each attribute column, it is needed to create some DUMMY attribute to maintain some value based on DDA_NUMBER_1 by writing the conditional rule or IMCScript to assign some unique value which will be used to restrict the value of DA1.
Step 1: Define the dummy attribute as follow
Step 2: Add that Dummy Attribute to Knowledge Base and Group
Step 3: Download an existing Knowledge Base with Simplified Conditional Rule and Range Rule
Step 4: Define the conditional rules to assign to Dummy Attribute
Above is an example definition for Dummy attribute assignment using the Simplified Conditional sheet. Next step is to define the range rule in Rule 2.
Uploading the above RULE_1 and RULE_2 and configuring the DDA_Numeric_1 value will trigger the Conditional Rule to assign the value to Dummy Attribute (example, Logical_Condition_Result). At the time of getting range values for DA1, it will apply the RULE_2 sheet based on the Dummy Attribute as shown below. Based that Dummy attribute’s value, the range values for DA1 will be restricted as shown below.
Use Case 6: How to define range restriction based on single Quote Attribute
In some case, a product modeler wants to define the simple range restriction based on some Quote Attribute. In order to define range restriction by Quote Attribute via UI,
- KBTriggerRelation/Quote Attribute must have been defined (See also Product Characteristics Definition - Quote Attributes (KBTriggerRelation))
- Create new knowledge base if it has not been defined.
- Create new rule with Range (White List) and add an existing quote attribute (See also Product Characteristics Definition - Quote Attributes (KBTriggerRelation))
- which is a controlling data point and a Knowledge base attribute where the range value of that will be restricted by Quote Attribute.
- Add triggers to restrict Knowledge base attribute’s range values ( in this case, DA5 ) by the Quote Attribute’s value. In below case, the value of DA5 will be DA5_1 if the quote’s sales organization is selected as 0006.
- Due to the definition of Quote Attribute’s onType and onAttribute property, a modeler can select the Sales Org ERP ID from the list as shown above.
Note: The Quote attribute value will not be restricted by Knowledge base attribute. Generally, if the product model contains such attribute usage in Rule, user must be informed to assign the Quote Attribute (Example Sales Org) value before doing any configuration.
In order to define range restriction by Quote Attribute via Excel
- Click the knowledge base and download
- Click the advanced tab and choose one Quote Attribute and specify the number of values to be used
- Select the ATTRIBUTES_RANGE sheet
- The two new columns were added
- 1: QUOTE_ATTRIBUTE.Sales Org ERP ID
- 1 represent the index,
- QUOTE_ATTRIBUTE represent the QUOTE_ATTRIBUTE sheet name
- Sales Org ERP ID is the object name of KBTriggerRelation
- 2: QUOTE_ATTRIBUTE.Sales Org ERP ID
- 1: QUOTE_ATTRIBUTE.Sales Org ERP ID
- The two new columns were added
In above example, the DA2 value will be restricted to have DA2_1 if Quote sales organization is 0006.
Note: If the requirement is to restrict the range value not only be Quote Attribute but also by another attribute’s value, then this feature is not suitable for it. It needs to use the standard rule definition with Quote Attribute (See Also Defining Range Restriction Rule via GUI and Creating Range Restriction Via Excel)
BOM Explosion Rule
After defining the product BOM (See also Product Characteristics Definition - Quote Attributes (KBTriggerRelation)) and the KB has linked with the respective BOM, the product modeler can specify the BOM explosion rules. There are three categories that the product modeler can specify the BOM Explosion rules.
- Default BOM Explosion Rules
- Attributes value based BOM Explosion
- Attributes value and Quote Attribute values (Example: Sales Org) based explosion
Same as range restriction, it needs to define the conditions by the value of one or more than one attributes and actions to insert the product into the parent product.
Default BOM Explosion
The BOM Explosion could be configured to execute once the main configurable product is added to the sales document ( Quote ). In order to do that, user needs to define KBTriggerRelation or Quote Attributes ( Product Characteristics Definition - Quote Attributes (KBTriggerRelation)) which will fetch the value from Product status. After that it needs to create rule with type BOM to define the rules to trigger the BOM Explosion based on main product’s status.
Defining the default BOM rule via UI
To define the default BOM rule via UI, so here is the step below for user to create.
Step 1: There should be Product BOM defined for those products that are to be inserted as sub line items together with main product (See also Product BOM Definition). The knowledge base should also link with preferred BOM.
Step 2: There should be QuoteAttribute or KBTriggerRelation with search expression, SalesItem().isProduct.hasProductStatus.objectName[0]. See also Product Characteristics Definition - Quote Attributes (KBTriggerRelation).
Step 3: Define the new trigger group with type BOM and add the KBTriggerRelation attribute created above.
Step 4: Define the new triggers and assign the attribute value as Active and add the BOM Entry created in Step 1.
Defining the default BOM rule via excel
In order to define default BOM explosion rule, a product modeler can download the knowledge base with option as shown below.
In Quote attribute sheet, new row with name Product Status can be found as it was created via UI in Product Characteristics Definition - Quote Attributes (KBTriggerRelation). If it is not inside the list, it can be entered in QUOTE_ATTRIBUTE sheet as follow.
- Define the product BOM
- Go to the new rule sheet and add column called, QUOTE_ATTRIBUTE.ProductStatus where QUOTE_ATTRIBUTE is the sheet name and ProductStatus is the one that was defined in QUOTE_ATTRIBUTE sheet
By that RULE_3, adding the main product will do the BOM explosion for those products listed in PRODUCT BOM sheet.
Attributes value based BOM Explosion
Below are the steps to define the attributes based BOM Explosion using the UI.
- Create new KBTriggerGroup
- Add Attributes which will be used to determine the BOM Explosion
- Create Trigger and assign the attributes value and select the BOM Entries
To create the attributes based BOM explosion via Excel,
- Download the knowledge base template with option BOM
- Define the Product BOM if it has not been defined ( See Also Product BOM Definition )
- Define the BOM explosion rule in newly created sheet as shown below
Attributes value and Quote Attribute values based BOM Explosion
This is for the case where user wanted to do the BOM explosion based on some data point inside the Quote such as Sales Organization. Depending on Sales Org, product modeler can define the rule to explode certain product that is only available for the sales organization of the Quote. The steps to define this kind of BOM explosion rule is the mixture of steps mentioned in Default BOM Explosion and Attributes value based BOM Explosion
In order to define the BOM Explosion rule based on Product Attributes and Quote Attributes,
- Define new Trigger Group with type BOM
- Add attributes (Knowledge Base Attributes and Quote Attribute/KBTriggerRelation that are to be used to perform the BOM Explosion based on that attribute value)
- Define triggers and assign the attributes value and attach the BOM Entries
In order to define the BOM Explosion rule via the knowledge base excel,
- Download the knowledge base excel template with option to include the new rule with type BOM
- Select the new rule sheet and add or remove the knowledge base Attributes (Example, DA1, DA2, DA3 as shown below)
- Add the QUOTE_ATTRIBUTE.[xxx] column (example QUOTE_ATTRIBUTE.Sales Org ERPID where [Sales Org ERPID] must be found in QUOTE_ATTRIBUTE sheet, see also Default BOM Explosion for creating new QUOTE_ATTRIBUTE via UI and Excel if the quote attribute was not found inside the QUOTE_ATTRIBUTE sheet. )
- Add the condition values for knowledge base Attributes and Quote Attributes
- Assign the BOM Entry ID
Understanding the concept of BOM Explosion Rule
The BOM Explosion rule is using the AND between the ATTRIBUTES inside a sheet and using UNION concept between different sheets if the BOM Entry ID is not same and INTERSECTION concept if BOM ENTRY ID is same. If the cell value is empty, it will be ignored and will not be used as part of a condition to explode the BOM Item. For example, let’s say we had the following definition for BOM.
- Product A1 will be exploded when DA1 is DA1_1 and DA2 is DA2_1 and DA3 is DA3_1 and Quote’s Sales Org ERP ID is 0006.
- Product A5 will be exploded when DA2 value is DA2_5 and DA2 value is DA3_5 and Sales Org of Quote is having 0007.
- Product A6 will be exploded when DA2 value is DA2_5.
- Product A5 and Product A6 will be exploded when DA2 is DA2_5 and DA3 is DA3_5 and Quote’s Sales Org is 0007. It is because, row 13 is a valid condition and row 14 is also a valid condition as in row 14, the empty cells are ignored and will not be part of condition thus in row 14, only DA2 will be considered to decide if product should be added or not.
Note: In BOM Explosion, AND operator is used between the attributes having value and empty value will be ignored and will not be part of condition to decide to inject product or not. If there are same products returned from different rule group and each having the same position and quantity, it will be exploded once due to INTERSECTION concept. If there are same products returned from different rule group and each having the different position or quantity, it will be exploded twice due to UNION concept.
Conditional Rule (Conditional Triggers)
Conditional Triggers are rules that are fired once the condition is found to be true. The conditional triggers are defined per Product-Knowledgebase. The different types of the conditional triggers are:
- Trigger Assign DA Value
- Trigger Assign DA Default Value
- Trigger Copy Attribute Values
- Triger Change Dynamic Attribute (DA) Meta Attribute
- Trigger Assign Business Type
- Trigger Product Recommendation
- Validation Trigger
The triggers are part of the Configuration engine and hence mostly work on/in the configuration of a line item.
A common use case is to set one DA (Dynamic Attribute) value based on the value of another or change the readability, visibility of an attribute based on the value of another DA. This can be achieved by trigger assign DA Value and default value or change DA meta attribute value. Where meta attributes control the visibility, editability or mandatory of an attribute. Another use case is in recommendation where recommendation trigger come to use to suggest to user additional products that can be sold as up/cross selling potential.
The sequence of execution of triggers is controlled by the group and next by the order of trigger within the trigger group.
Calculations:
Calculations are used to calculate new information during the configuration process flow. Defined as arithmetic equations/ formulas these calculations make the bulk of costing estimates based on user entered data and calculation of other dependent parameters.
For example: Based on the metal length and width a simple calculation can find its area. This calculated information can next be used in price engine to get the metal cost* (*Note that in such a case getting cost value is responsibility of price engine, whereas getting area calculated is responsibility of Calculation engine).
Calculations are defined on the Product Knowledgebase and calculate the values of a dynamic attribute. One can make use simple BODMAS principle and combine it with various arithmetic functions to achieve simple to complex estimation work.
Conditional Triggers Definition via GUI
Conditional triggers are part of a product knowledgebase and are defined under the triggers.
Pre-requisite prior to creation of conditional trigger
Step 1: Create the required dynamic attributes if required. You may do so by accessing the attributes management view via Model – Attributes Management ( See Also Product Characteristics Definition- Attributes Introduction )
Step 2: Create the required dynamic attributes if required. You may do so by accessing the attributes management view via Model – Attributes Management ( See Also Product Characteristics Definition- Attributes Introduction )
Step 3: Create a new product if required or select an existing one. You may do so by accessing products view via Products – Products (See Also Product Creation)
Step 4: Create a new knowledge base if required or select an existing knowledgebase for the product.
Step 5: Select the knowledgebase that you want to configure and add all required dynamic attributes to the knowledgebase.
Step 6: Create all the groups and subgroups that are required for the product and assigned the dynamic attributes to the individual subgroup that it belongs to. This is to model how the attributes will be displayed to the end-user during product configuration.
Step 7: Create a new trigger group of type conditional or use existing trigger group which is of type conditional.
Step 8: Create a new trigger or use an existing trigger
Trigger Assign DA (Dynamic Attribute) Value
Use this trigger if you want to assign a value to a DA that cannot be changed by the user. The value assigned is also shown as read only.
- Ensure that pre-requisite prior to creating conditional trigger are met. (please refer to Pre-requisite prior to creation of conditional trigger)
- Create condition(s) and save. One can create more than one condition, the trigger executes the action when all the conditions are met (that is true):
- Name – A name represent the condition.
- Search Expression – The search expression can be used to find the value of a Dynamic Attribute (DA) / value of attribute (URI).
- SalesItem().getDAValue('DDA')[0]-> To get the value of a DA.
- SalesItem().getDAUri(‘DDA’)[0] -> to get the URI of a DA.
- Select from a list of options via helper. (currently only supports the attributes that are defined in the knowledgebase you are working on)
- Operator
- Condition Value
- Literal value. (i.e. 1, “1”, true) OR
- Select from the attribute’s ranges if available. (currently only supports attributes that are defined in the knowledgebase you are working and is recognizable when the input is disabled with a helper button.
- Under Action, create a new action by selecting “Trigger Assign DA Value” and the available action(s) will be created. (note: application only supports one action type per condition)
- toSearchExpression – the target attribute to be assigned the value. The target attribute should be the starting object (the sales item which triggering the trigger)
- Search expression to get the DA to be assigned OR
- Select from a list of options via helper. (currently only supports the attributes that are defined in the knowledgebase you are working on)
- toSearchExpressionValue / toValue
- Literal value. (i.e. 1, “1”, true) OR
- Select from a list of options via helper. (currently only supports attributes that are defined in the knowledgebase you are working) OR
- The search expression to get a value to be assigned.
- Go to Knowledge Base Snapshots, create a snapshot so that the latest settings are applied. Create a new Knowledge Base Snapshots every time after updated the trigger.
- You may also test the trigger by following the below steps
- Go to Quote and create a new quotation.
- Add a line Item by choosing the product with trigger configured.
- Clicks on the line item ID to open the configurator page
- d. Fill up the DA, the trigger will be fired if the condition is met
- toSearchExpression – the target attribute to be assigned the value. The target attribute should be the starting object (the sales item which triggering the trigger)
Trigger Assign DA Default Value
The trigger assigns the value of a DA if the condition/s are true, however, unlike Trigger Assign Value, the assigned value can be changed by the user. The value assigned by the trigger is no read only and hence editable. However, if the user removes (Deletes) the value assigned by him or her, the default value (that is the trigger assigned value) is applied again.
The steps to configure Trigger Assign DA Default Value are same as Trigger Assign DA (Dynamic Attribute) Value. The only difference is select “Trigger Assign DA Default Value” during the creation of action.
Trigger Change DA Meta Attribute
This trigger changes DA’s meta attribute value. Using this trigger one can control if a DA is hidden, read only or mandatory. The trigger executes if all its conditions turn out to be true.
- Ensure that pre-requisite prior to creating conditional trigger are met. (please refer to Pre-requisite prior to creation of conditional trigger)
- Create condition as per other condition trigger.
- Under Action, create a new action by selecting “Trigger Change DA Meta Attribute” and the available action(s) will be created. (currently, application only supports one action type per condition)
- toSearchExpression – The target attribute to be assigned the value
- toAttribute
- toBooleanValue – the Boolean value to be assigned (true | false).
Trigger Copy Attribute Value
This trigger copies the value of a DA from configuration, config item, of a sales item and makes it available on the sales item level. It can be used to map assigned/calculated/system derived values from configuration (config item) to sales item level for example: change sales item name based on a DA value or change the sales item / its children’s quantity based on a DA value. However, please note that it does not support to update the children if it does not exist yet by the parent's trigger.
- Ensure that pre-requisite prior to creating conditional trigger are met. (please refer to Pre-requisite prior to creation of conditional trigger)
- Create condition as per other condition trigger.
- Under Action, create a new action by selecting “Trigger Copy Attribute Value” and the available action(s) will be created. (currently, application only supports one action type per condition)
- fromSearchExpression – The attribute to get the value from (e.g. SalesItem().getDAValue(‘DA_Name_Custom’)[0]
- toSearchExpression – The target attribute to be assigned the value
- toAttribute – The target attribute (e.g. http://www.inmindcloud.com/application/schema.owl#objectName)
Trigger Product Recommendation
This trigger helps provide up/cross selling insights in CPQ. Using this a specific product can be recommended for a given line item. The recommended products can be next added as sub line item.
- Ensure that pre-requisite prior to creating conditional trigger are met. (please refer to Pre-requisite prior to creation of conditional trigger)
- Create condition as per other condition trigger.
- Under Action, create a new action by selecting “Trigger Product Recommendation” and the available action(s) will be created. (currently, application only supports one action type per condition)
- Value – The value for the attribute key. Use ‘,’ as separator for multiple values. (e.g. EASY400A,803)
You can test the trigger by adding/updating/deleting a product which is configured with the Trigger Product Recommendation into the line item. The system sends a product recommendation insight when the product is added into the line item as main / sub item.
Example
The product recommendation insight notification is shown when a product (which is configured with Trigger Product Recommendation) is added as line item into the quote.
A click on the insight opens the Product(s) Recommendation panel, showing all recommended products.
User can act on these recommendations and can add the additional products into the quote. Note that as the recommendations are targeted to a product/sales item the recommended (and system added products) are created as sub line items for that product/sales item.
1.1.1.1 Validation Trigger
This trigger helps to validate the configuration attributes of the sales item based on the conditions defined in the knowledgebase. It also sends the pre-defined validation message to the user as notification/insight.
- Ensure that pre-requisite prior to creating conditional trigger are met. (please refer to Pre-requisite prior to creation of conditional trigger)
- Create condition as per other condition trigger.
- Under Action, create a new action by selecting “Validation Trigger” and the available action(s) will be created. (currently, application only supports one action type per condition)
- messageType - Type of message.
- validationMessage - The label key in the message.properties.
- Example: trigger.validation.general.max.threshold = {0}:{1}->{2}. Value exceed the maximum threshold! where
- {0} = Item’s position,
- {1} = The name of the salesItem,
- {2} = The name of the trigger
- Example: trigger.validation.general.max.threshold = {0}:{1}->{2}. Value exceed the maximum threshold! where
*The parameters {0}, {1}, {2} are fixed in the code to show the item position,
sales item name and the trigger name to the user.
This trigger will be triggered after saving the line items
*The label key will be displayed if it is not found in the message.properties.
*The message.properties files is in the CMIS localization-> ui-customization folder.
Trigger Assign Business Type
This is a legacy trigger and is deprecated from 1902 release. Its purpose is to assigns a business type to the config item of a sales item. Note that the assigned business type needs to be a sun type of Schema.KnowledgeBase
- Ensure that pre-requisite prior to creating conditional trigger are met. (please refer to Pre-requisite prior to creation of conditional trigger)
- Go to Triggers, create a trigger to define the condition and the action.
- Create condition(s) and save it.
- Name – A name represents the condition.
- Search Expression – SalesItem().salesItemIncludedBy.isProduct.includesKnowledgeBase.types[0]
- Operator – IN
- Condition Value – The knowledge base URI to compare with. http://www.inmindcloud.com/application/products/products-schema.owl#MetalStamping-KB
4. Under Action, create a new action by selecting “Trigger Assign Business Type” and the available action(s) will be created. (currently, application only supports one action type per condition)
- Value – The value for the attribute key.
5. Create a snapshot at Knowledge Base Snapshots.
The attributes of the parent product will be inherited to the children product after the business type assigned to the children product.
Conditional Triggers Definition via Excel
A product modeler can define the conditional triggers using the rule sheet inside knowledge base excel. There are currently two features that can be used to define the conditional rules with excel.
- Standard conditional rule definition
- Simplified conditional rule definition
Standard Conditional Rule Definition
The standard conditional rule is mainly for advanced user where he/she had the knowledge about IMCScript syntax (See also IMCScript Guide documentation) as it needs to write the IMCScript syntax in Conditions and Actions properties.
In order to download the standard conditional rule,
- Click the knowledge base and download with an option (Conditional) and specify the number of conditional rules to include the workbook.
The new sheet starting with name RULE_ will be generated and a product modeler can write the conditions and action part. Based on the action type selected, the corresponding action cells will be highlighted for the modeler to specify the actions.
The details of which action value can be entered depending on action type can be found in sheet, _ConditionalTriggersMasterData.
The details of which value can be put in condition and action arguments, can be found in 6.3.1. The syntax of IMCScript to put as part of left or right condition and action argument values can be found in IMCScript Guide.
Simplified Conditional Rule Definition
The purpose of simplified conditional rule is to support for the simple case where a product modeler wanted to define the simple conditional like if [DA1] value EQUAL TO [Value 1] then assign [DA2] value to [Value 2]. This feature is only available via excel upload.
In order to download the simplified conditional rule, here is some information that the user can create.
- Click the knowledge base and download with an option (Conditional Simple - Using direct names and values)
- Select the Attribute name and Attribute Value as condition
- Select the Action Type. The following actions will be available.
- ASSIGN_DA_VALUE
- ASSIGN_DA_DEFAULT_VALUE
- HIDE_ATTRIBUTE
- SHOW_ATTRIBUTE
- MARK_READ_ONLY
- MARK_MANDATORY
- MARK_PRICING_RELEVANT
- UNMARK_READ_ONLY
- UNMARK_MANDATORY
- UNMARK_PRICING_RELEVANT
- Depending on the Action Type, a product modeler can select the TO ATTRIBUTE NAME and TO ATTRIBUTE LITERAL VALUE.
Note: Please note that the operator EQUAL is only supported in Simple Conditional Rule and also the assignment of DA value must be done with range value. It is not supported to assign some DA value coming from another DA. In order to support this case, it is needed to use the Standard Conditional Rule sheet user a product model has rich features of IMCScript capability.