This chapter provides overviews of multilevel product bundles, configuration rules, and discusses how to:
Set up multilevel product bundles.
Set up migration actions.
Set up configuration rules for multilevel product bundles.
This section discusses:
Product relationships for multilevel product bundles.
Multilevel product bundle modeling.
Export of multilevel product bundle, rule and migration action definitions.
Commitment products.
Split billing products.
New product relationships are introduced to support the ordering and service management of multilevel product bundles. While some of the product relationships are established between multilevel product components using the Product Relationships component, others are rule-based, which means that relationships are established between products dynamically based on configuration rules that apply during the ordering or service management process.
After order fulfillment processes complete, some product relationships can be carried over and maintained between installed product instances for information purposes. The link information is particularly useful in service management scenarios where, for example, installed products with brings and removes relationships are involved. Suppose that a user creates a service management order wanting to remove an installed product, and it is the source installed product of a relationship. Because of the presence of the installed link, the system (Advanced Configurator) removes the target installed product of this relationship automatically from the configuration session along with the source product.
The system delivers these product relationships for use in multilevel product bundles:
Brings on creation
This product relationship is rule-based and is established between product A (commercial) to product B (commercial) in a configuration session by a brings on creation rule. The rule adds product B (target) in the configuration automatically upon the selection of product A (source) and links these two products together through the brings on relationship—product A brings on product B.
Child Of
This product relationship is established between product A (commercial) to product B (commercial) in the Package Components component. When product A is added as a component to a multilevel package where product B is the parent, these two products are automatically linked through the child of relationship—product A is the child of product B.
Brings and removes
This product relationship is rule-based and is established between product A (commercial) to product B (commercial) in a configuration session by a brings and removes rule. The rule adds product B (target) in the configuration automatically upon the selection of product A (source) and links these two products together through the brings and removes relationship—product A brings and removes product B.
The source and target products of a brings and removes relationship are coupled throughout their entire product lifecycles. After order fulfillment completes, an installed link that represents the relationship is maintained between installed products for service management purposes. When the source product of a brings and removes relationship is set to be removed in a service management order, its associated target product is removed from the configuration as well.
Relies on
This product relationship is established between product A to product B in a configuration session, marking a dependence between the two (the target product is the prerequisite of the source product, or the target product uses the resources provided by the source product).
Each functional product must have a relies on relationship with another functional product in order for any applicable functional relies on rule to be triggered.
After order fulfillment completes, an installed link that represents the relationship of installed products A and B is maintained.
Sells
This product relationship is established between product A (commercial) and product B (functional) in the Product Relationships component. Product A is typically a commercial offer that sells product B, a functional component that is not sellable.
After order fulfillment completes, an installed link that represents the relationship of installed products A and B is maintained.
Owner
This is not a product-to-product relationship, instead it is a relationship between an installed product and the customer that owns it, and it is displayed in the Line Relationship section of the Line Details page in a convergent order when the installed product is undergoing a migration from one multilevel contract to another (contracts are owned by different customers). In the section, two lines appear for the owner relation: one to remove the association with the current owner and the other one to create a relationship with the new owner.
Billed to
Similar to the owner relationship, the billed to relationship is established between an installed product and a billing account, which is displayed in the Line Relationship section of the Line Details page in a convergent order when the installed product is undergoing a migration from one contract to another and a different billing account is used. In the section, two line appear for the bill to relation: one to remove the association with the current billing account and the other one to create a relationship with the new billing account.
Migration
This product relationship is established between the source component and its mapped target component as a result of a migration and it is displayed in the Line Relationship section of the convergent order after the migration request is submitted in the configuration session. From the source component's perspective, a link is added with a Migrates to relationship pointing to the target component. From the target component's perspective, a migration type link with a Migrated from relationship is added pointing to the source component.
Committed
This product relationship links together a commitment product and a product that is covers. It is rule-based and is established between product A (commercial) to product B (commercial) in a configuration session by a commitment triggering rule. The rule adds product B (a commitment product) in the configuration automatically upon the selection of product A (a product covered by the commitment product) and links these two products together through the committed relationship. From the commitment product's perspective, it is a commits relationship pointing to its covered product; for the covered product, it is a Is Committed one pointing to the commitment product.
After order fulfillment completes, an installed link that represents the relationship of installed products A and B is maintained.
Brings Commitment
This product relationship links together two commercial components, which are the scope object of the triggering product and the commitment product, as a result of the execution of a commitment triggering rule. Each commitment triggering rule is associated with a reference scope. At runtime, the execution of the rule adds the corresponding commitment product to the configuration session and assigns it to any of its covering products that can be found within the specified reference scope in the session.
For example, if the reference scope is direct parent, a brings commitment relationship is established between the commitment product and the direct parent of the products that are being covered by the commitment product.
From the commitment product's perspective, it is a brings commitment relationship pointing to a scope object of covered product to which it assigns; for the scope object, it is a Covers because of one pointing to the commitment product.
This linkage is useful in cases where a triggering product is deselected from the configuration session and its commitment product is no longer required to be selected in the session. With the help of this product relationship, the system knows which commitment product to remove.
Commitment Scope
This product relationship is rule-based and is established between product A (commercial) to product B (commercial) in a configuration session by a commitment covering rule to support scope object tracking in the installed product. The rule creates a commitment scope link between the installed product of its scope object (product A) and the installed commitment product (product B).
For example, if the reference scope is direct parent, a commitment scope relationship is established between the installed commitment and the direct parent of the products that are being covered by the commitment product.
From the installed commitment's perspective, it is a Is scoped by relationship pointing to the scope object; for the scope object, it is a Tracks scope for one pointing to the installed commitment.
An installed link is established to connect each installed commitment with its corresponding commercial component that is used as the scope object for the commitment covering rule evaluation. The system uses this link type for commitment validation purposes in future service management orders.
See Also
Setting Up Product Relationship Codes
Once all the definitional components for building multilevel product bundles are in place, you can create multilevel product bundles using the steps that are illustrated in this diagram:
See Creating Product Definitional Elements.
Process flow for creating multilevel product bundles, which starts from creating all functional and commercial components needed in the bundle, to associating lowest-level commercial components with functional components using the “Sells” relationship, and linking all commercial components hierarchically into a bundle structure
To create multilevel product bundles:
Create all functional components needed for the bundle using the Product Definition component.
Create all atomic offers (lowest level commercial components) needed for the bundle using the Product Definition component.
Create the Sells relationship between atomic offers and appropriate functional components using the Product Relationships component.
Create other higher level commercial components (for example, contract, plays, and offers) needed for the bundle using the Product Definition component.
Build the multilevel product bundle by associating all commercial components in a hierarchical fashion using the Package Components page.
Refer to the Setting Up Product Definitional Elements chapter for more information on definitional elements that pertain to multilevel product bundles, such as multilevel component types and multilevel structure assignments.
See Also
Creating Product Definitional Elements
PeopleSoft CRM is the master reference of multilevel product bundle, rule and migration action definitions. For product configurations to be done in a more accurate fashion, this data needs to be exported to the Configurator application data structures to make it available for use by Advanced Configurator generic models as frequent as it is updated.
The CRM system delivers a batch process that synchronizes data between the CRM system and PeopleSoft Advanced Product Configurator models in an asynchronous mode. The process, when executed, transforms and exports product catalog data to Configurator application data structures. Visual Modeler compiles the generic template model, which is then sent to the Configurator server for deployment.
When this process is run, it exports:
Active rule definitions, including future dated ones.
Obsolete rules can also be exported based on the batch process setup. Obsolete rule definitions are not subject to exportation if they are currently being used in validations.
Important! As the removal of product catalog information that is exported to Advanced Configurator may result in configuration errors if the information is referenced in existing orders and installed products, it is recommended that inactive definition in product catalog be exported to avoid potential configuration errors.
Attributes of the Configurator object type, regardless of start and end dates. For attributes that are expired, they are handled in configuration sessions based on their individual expiration handling setting (which is specified in the Attributes - Configurator page).
Multilevel product packages and their components, regardless of start and end dates.
Expired product packages and components are not displayed in configuration sessions and cannot be fulfilled by orders. However, it is still possible to modify or remove such product if it is already installed.
See Understanding Selling Periods for Multilevel Product Bundles and Components.
Prior to exporting a migration action, the system performs the same integrity checks that occur when migration actions are saved.
See Understanding Package Migration Requests, Understanding Design Time Integration and Product Catalogue Synchronization.
The batch process also performs a series of integrity checks to ensure that the structure of product catalogue definition being exported is both complete and consistent. These checks are in place to make sure that:
Multilevel product bundles are built with adherence to the bundle structure and properties that are set in the Multilevel Component Types component.
Each multilevel product bundle component belonging to the commercial type that is set to link to functional component is in fact associated with a functional component through the Sells relationship. A commercial component can be linked to only one functional component, and the relationship does not base on any date-specific condition.
As delivered, only commercial components of the Atomic Offer type can be linked to functional components.
A commercial component cannot be included more than once in a single multilevel product bundle; it can, however, be referenced in multiple product bundles.
The Installability option is set properly for related package components based on these rules:
The Contract type component can be set to not installable only if all its plays are also not installable.
The Play type component can be set to not installable only if all its commercial products are also not installable.
For each atomic offer and functional component pair that is linked by the Sells relationship, both components must have the same setting, that is, either installable or not installable.
The lowest installable level of a commercial hierarchy, as delivered, is Atomic Offer.
No attributes that use automatic retrieval rules (not supported in the Advanced Configurator) are specified for the Configurator object type.
Note that the integrity checks mentioned above do not apply to rule definitions, and they do not perform tasks to make sure that the updated version of product catalogue data is in fact compatible with existing installed products in the system. It is the administrator's responsibility to maintain the compatibility between the newer product catalogue data and existing installed products.
Integrity checks are performed prior to exporting commitment products and rules to Configurator application data structures for product configuration purposes.
See Product Catalog Export of Commitment Products and Rules, Understanding Design Time Integration and Product Catalogue Synchronization.
A commitment product represents a commitment (a contract between a vendor and a customer), which is assigned to other products or services purchased by customers to specify a time period during which the cancellation of such products and services can lead to penalty payment. It:
Is associated with a commitment covering rule, which defines a list of products that need its commitment coverage and the duration of the commitment.
The automatic selection of a commitment product triggers the evaluation of the commitment covering rule that is created for the commitment product, which, if rule conditions are met, results in the assignment of the commitment product to instances of its covered products that are available in the configuration session.
Gets exported to Advanced Configurator along with commitment rules for use in product configurations.
Can be added to configuration sessions automatically through the execution of a commitment triggering rule.
Important! Commitment products can only be added in configuration sessions as a result of the execution of commitment triggering rules. Logic is in place to prevent commitment products from being added manually to orders, such as by entering the product name or ID or from the catalog search.
Is stored as an installed commitment after order fulfillment for service management purposes.
Installed links are established between the installed commitment and installed products that are covered by the installed commitment.
During configuration sessions, agents cannot alter the commitment such as adding or removing its covered products, or renewing the duration of commitment for any given covered product unless they are given permission to do so. You can use eligibility rule to specify actions that can be performed on commitment products.
Note. Commitment products must be in active status in order to be referenced in commitment rules and to be available for selection in configuration sessions.
See Commitment Configuration Rules.
Split billing product definitions represent billable products that are associated with more than one billing account for different billing purposes. The split billing functionality is only available in the ordering process to products that are split billing-enabled. In a split billing product definition, you can specify a number of billing account types that can be used to pay for charges of the product. For each billing account type that is listed, you can identify its purpose, which is a description that is displayed in orders and installed products at runtime to show the type of charges that the billing account handles.
For a product to be split billing-enabled, the Billing Account Selectable option must first be selected to indicate that the product is billable. Then, select the Split Billing option and add billing accounts that can be used to pay for the split billing product. A split billing product can be associated with both prepaid and postpaid accounts; a product package can contain a mix of product components that are associated with both types of accounts. However, beware that the system does not allow the selection of both prepaid and postpaid accounts in a single order. When that happens, the validation check that executes upon order submission puts a hold on this order.
Note. As delivered, setup fields that are related to split billing are available to product definitions that are created for the communications solution (setID=COM01) through display templates.
See Also
This section discusses:
Commercial eligibility rules.
Brings on creation rules.
Brings and removes rules.
Commercial incompatibility rules.
Commercial incompatibility rules for attribute values.
Commercial restriction rules for attribute values.
Commercial prerequisite rules.
Commercial relies on rules.
Commercial relies from rules.
Functional incompatibility rules.
Functional incompatibility rules for attribute values.
Functional relies on rules.
Functional relies from rules.
Commitment triggering and covering rules.
PeopleSoft CRM delivers a number of configuration and validation rules for multilevel product bundles. These rules enable the definition of various configuration constraints for products and product attributes that need to be validated during order capture and service management configuration sessions.
Commercial eligibility rules can be used to restrict the display of data and the availability of actions on products, relies on links, service migrations, commitments and product attributes in configuration sessions based on rule conditions. Rule conditions are built using a combination of these criteria: source, sub-source, user and customer criteria that are represented in AAF (Active Analytics Framework) terms.
When a configuration session is initiated from an order or service management order, Advanced Configurator retrieves needed information from the order, specifically:
Source and sub-source values, which the Order Capture application passes directly to the session.
User and customer criteria values, which the Configurator controller program retrieves from the CRM system using web services, as well as the customer ID and user ID pertaining to the order, which is provided by the Order Capture application.
The controller program evaluates retrieved criteria values against active rule conditions. A rule is deemed applicable if all of its conditions are met.
After the initiation process is completed and appropriate rules applied, the Configurator GUI solution presents the configuration session with all rule-based configuration restrictions in place. These restrictions can be one or more of these items:
Hiding of a product or disallowing the addition or removal of a product.
Disallowing the creation or removal of relies on links between products.
Disallowing migration actions for products.
Hiding a product attribute or disabling attribute update.
Hiding actions that can be performed on a commitment type product, adding or removing covered products from a commitment product, and restricting the duration options that are available to the commitment product.
Important! The delivered Configurator GUI solution is a sample one and it does not cover all the possible configuration scenarios for multilevel product bundles. The CRM system provides APIs to handle product configurations that the sample GUI solution does not support.
Additionally, eligibility rules can be set up to perform validations on configuration sessions based on rule definition. For example, suppose that the Product non-eligible setting is selected for a product in a commercial eligibility rule (which means that the product cannot be added during configuration sessions). At runtime, if you select to add that product in a session after all the configuration restrictions of the rule have applied, the system would invalidate the configuration because of the selection of a product that cannot be added to the configuration. The status of the configuration becomes Invalid or Valid with warnings, depending on the severity that is specified for the rule.
Elements of Rule and Validation Result
The Commercial Eligibility Rule is comprised of the following elements:
Rule type, not including logical expressions
Rule date
Product
The Commercial Eligibility Rule is invalid when the eligibility criteria associated with the contract matches the criteria from the rule.
The validation process uses one of the following operators associated with a rule to help determine its validity:
Equal
Not Equal
Is Empty
Is Not Empty
In List
Not In List
Commercial Eligibility Rule - Example
This section provides a sample commercial eligibility rule definition and explains how the rule impacts a configuration session when applied.
This table shows the details of the sample rule definition:
A sample commercial eligibility rule definition (1 of 3)
A sample commercial eligibility rule definition (2 of 3)
A sample commercial eligibility rule definition (3 of 3)
At runtime, when a user creates an order (or service management order) and initiates a configuration session, all active rules are being evaluated, including this sample rule that is valid between May 27, 2008 and December 31, 2099 if the product selling date of the order falls within this time frame. The order meets all the rule conditions if the order source is Store from either Partner 1 or Partner 2, and the order is for a customer in Poland. Here is what the user can see and perform on the configuration session after the sample rule is applied:
User can see product TEL000093 but cannot add or remove this product in the session.
User can add links originating from the functional component that is sold as product TEL000093 but cannot remove these links.
User cannot see the attribute ATTR0005.
User can manually (free-text) change the duration of an existing commitment product TEL000039.
User can choose between 6, 12, and 24 months as the duration for the TEL000039 commitment product in the configuration session; the 36 month option (specified in the commitment covering rule for TEL000039 with the other three options) is unavailable for selection.
If this restriction is violated in the session, the session becomes invalidated.
At the end, the system updates the status of the configuration based on the result of the evaluation:
Valid: submitted configuration does not violate any rules; order can be processed.
Valid with warnings: submitted configuration violates some rules and this status is issued based on the specified rule severity (Warning); order can be processed.
Invalid: submitted configuration violates some rules and this status is issued based on the specified rule severity (Error); order cannot be processed.
See Also
Setting Up Commercial Eligibility Rules
Brings on creation rules enable the automatic addition of commercial products (target products) in configuration sessions upon the selection of their associated products (source products) that triggered the rules.
In a brings on creation rule, the relationship between the source product (also known as the left hand side product) and target products (also known as the right hand side products) are coupled together until order fulfillment is completed. Specifically, the selection of the left hand side product in a configuration session of a new order automatically adds the right hand side products to the session, and the removal of the left hand side product causes the removal of its right hand side products as well, as long as the order has not been fulfilled. When the order is successfully fulfilled and installed products created for products of both sides, the removal of the left hand side installed product in a service management order does not cause the removal of its right hand side installed products. In other words, they are independent entities in the service management phase.
The system creates links between the left hand side product and its right hand side products after order fulfillment. These brings on creation links persist only in orders for the purpose of restoring configuration sessions and as delivered, they are not stored as installed links.
Elements of Rule
The Brings On Creation Rule is comprised of the following elements:
Rule type, configuration rule
Rule date
Left Hand Side/Right Hand Side
Products (single product on the Left Hand Side and list of products on the Right Hand Side)
Product status
Product scope (only on Right Hand Side)
Note. The Configurator Controller application validates the Brings On Creation rule.
Brings On Creation Rule - Example
This section provides a sample brings on creation rule definition and explains how the rule impacts a configuration session when applied.
This table shows the details of the sample rule definition:
A sample brings on creation rule definition
At runtime, when a user creates an order (or service management order) and initiates a configuration session, all active rules are being evaluated, including this sample rule that is valid between June 11, 2008 and June 13, 2099 if the product selling date of the order falls within this time frame. In each session that has the 3G Wireless Postpaid Package product (ID: TEL000023) selected, the system automatically selects the Internet Access product (ID: TEL000093) in the session, if this product is available within the same play as the 3G Wireless Postpaid Package product. If the Internet Access product is unavailable in the same play, it is not going to be automatically selected in the configuration.
See Also
Setting Up Brings On Creation Rules
Brings and removes rules are similar to brings on creation rules in a sense that they are both used to automatically add target products to configuration sessions after the source products have been selected. These rules are different in terms of the duration in which the original and target products are coupled together. In a brings and removes rule, the source product is tied to its target products in the same relationship forever, even after the order is fulfilled. The removal of the source product results in the removal of its target installed products.
The system creates links between the left hand side product and its right hand side products after order fulfillment. These brings and removes links persist in orders for the purpose of restoring configuration sessions as well as between installed products to enable the coupling of left hand side and right hand side installed products in service management orders.
Note. The brings and removes relationship is also referred to as the brings and removes relationship in this documentation.
Elements of Rule
The Brings and Removes Rule is comprised of the following elements:
Rule type, configuration rule
Rule date
Products (single product on the Left Hand Side and list of products on the Right Hand Side)
Product status
Product scope (only on Right Hand Side)
See Also
Setting Up Brings and Removes Rules
Commercial incompatibility rules can be used to restrict the selection of commercial products in configuration sessions (by displaying warnings or errors) upon the selection of certain commercial products due to incompatibility.
A commercial incompatibility rule consists of:
Rule reference scope
The scope determines the context within which the rule evaluation occurs.
For example, if the scope is Contract, the system evaluates the rule at the contract level and all products selected in the contract can potentially be considered when the rule execution condition is being evaluated. If the scope is Play, the system evaluates the rule separately for each play selected in the contract, the rule execution condition will only be evaluated against products belonging to the same play.
Rule execution condition
Represented by the left hand side sentence in the rule definition, the rule execution condition defines some specific configuration selections that make the rule potentially applicable to the configurations.
Rule constraint condition
Represented by the right hand side sentence in the rule definition, the rule constraint condition identifies the specific configuration selections that, when evaluated to TRUE, cause the violation of the incompatibility rule.
For an incompatibility rule, the product selection conditions for the left hand side and the right hand side should be mutually exclusive. A configuration session is in violation of an incompatibility rule if both sides of the rule are evaluated to TRUE at runtime.
Product groups
Product groups are components of the rule execution condition and the rule constraint condition. A product group is created by specifying a list of commercial products and the conditions for each product that a configuration needs to have and satisfy in order for it to be evaluated further by the rule. Within a group, there are product-level and group-level conditions that a configuration must fulfill before it can move onto the next step—which can be another evaluation by another group in the validation process, or a result that indicates if the configuration has violated an incompatibility rule.
Elements of Rule and Validation Result
The Commercial Incompatibility Rule is comprised of the following elements:
Rule type, including logical expressions
Rule date
Left Hand Side/Right Hand Side
Scope of rule
Product and product rule group
Product status
Product scope (only on Right Hand Side)
Local and Global cardinality
AND/OR/()
The Commercial Incompatibility Rule is invalid when both the Left Hand Side and Right Hand Side are true.
Commercial Incompatibility Rule - Example
This section provides a sample commercial incompatibility rule definition and explains how the rule impacts a configuration session when applied.
This table shows the details of the sample rule definition:
A sample commercial incompatibility rule definition
At runtime, when a user creates an order (or service management order) and initiates a configuration session, all active rules are being evaluated, including this sample rule that is valid between June 14, 2008 and December 31, 2099 if the product selling date of the order falls within this time frame. For each play (which is the specified rule reference scope) selected in the configuration, the evaluation of the left hand side (L1 and L2) sentence first applies. This table shows the condition defined for the L1 group:
A left hand side group definition of the sample commercial incompatibility rule definition
Based on the group definition, a play configuration satisfies the condition of the L1 group if it:
Contains one Inexpensive Calling Plan product that is in the new status.
Contains at least one but no more than two Basic Phone products that are in the new status.
Includes a total of at least two but no more than three of the Inexpensive Calling Plan and Basic Phone products combined.
Next, the play configuration is being evaluated by the L2 group condition. If the condition is again satisfied, then the rule execution condition (specified by the left hand side sentence) is resolved to TRUE, which triggers another set of evaluations that checks if the configuration is indeed in violation of the sample rule.
In this example, all the plays that meet the left hand side sentence condition are subject to the evaluation that is set by the right hand side sentence (R1 OR R2).
This table shows the of the condition defined for the R1 group:
A right hand side group definition of the sample commercial incompatibility rule definition
Based on the group definition, a play configuration satisfies the condition of the R1 group if it:
Contains at least three but no more than five Free Mailbox products that are in the new status. These products must be selected within the same play (specified by the scope).
Contains at least two but no more than three Caller ID products that are in the new status. These products must be selected within the same contract (specified by the scope).
Includes a total of at least six of the Free Mailbox and Caller ID products combined.
Next, the play configuration is being evaluated by the R2 group condition. The rule constraint condition (specified by the right hand side sentence) is resolved to TRUE if either R1 or R2 is satisfied. In the case of the sample rule (rule type = commercial incompatibility), when both left hand side and right hand side sentences are evaluated to TRUE, the configuration being evaluated is considered in violation. As a result, the status of the configuration is shown as Invalid, based on the specified rule severity.
See Also
Setting Up Commercial Incompatibility Rules
Use the commercial incompatibility rules for attribute values to restrict the value of any commercial product that is a descendant of the functional product and has an attribute attached. For example, a hypothetical 'Student Offer' can restrict the value 4096 of the DSL Speed attribute, which is attached to the DSL access product.
The underlying logic of commercial incompatibility rules for attribute values is the same as the functional incompatibility rules for attribute values, except that with the former rule type, the rule definition includes an additional section where you can select a commercial product as part of the rule execution condition and rule constraint condition. This rule definition provides the ability to apply restrictions on incompatible attribute values based on commercial products. A commercial incompatibility between attribute values rule is executed if the values that are specified for commercial product, functional product and attribute in the Restricting Attribute section of the rule are met in a configuration session at runtime. Next, the system checks if the configuration meets the condition that is defined in the Restricted Attributes section of the rule. If yes, the entire rule constraint condition is automatically resolved to TRUE, which means that the configuration is in violation of the commercial incompatibility rule for attribute values, causing the product configuration to become invalid.
Refer to the Functional Incompatibility Rules for Attribute Values for an overview and an example of the rule type.
See Functional Incompatibility Rules for Attribute Values.
Elements of Rule and Validation Result
The Commercial Prerequisite Rule is comprised of the following elements:
Rule type, excluding logical expressions
Rule date
Product
Product status
Attribute and attribute value
The Commercial Incompatibility Rules for Attribute Values is invalid when any of the incompatible elements (such as product id, functional product ID, or attribute ID) exists in the contract, a product is an descendant of the functional product in the contract structure, and an attribute is attached to the functional product.
Use the commercial restriction rules for attribute values to restrict the selection of attribute values or the use for certain format for specifying attributes on commercial products in configuration sessions (by displaying warnings or errors) through the manipulation of the functional products that they sell. For example, a call number attribute value can be restricted to one starting with 69 for a mobile telephone offer.
In the rule setup where the rule execution condition is defined, you specify one single commercial product, which can either be an atomic offer that sells the functional product used in the rule, or the package containing the atomic offer that sells the functional product (it is possible that the same functional product is sold by different commercial offers within different commercial packages. For product configurations that satisfy this condition, additional evaluations are performed to verify if these configurations have selected attribute values of the functional product that are in fact defined as restricted values in the rule.
At the end, the system updates the status of the configuration based on the result of the evaluation:
Valid: submitted configuration does not violate any rules; order can be processed.
Valid with warnings: submitted configuration violates some rules and this status is issued based on the specified rule severity (Warning); order can be processed.
Invalid: submitted configuration violates some rules and this status is issued based on the specified rule severity (Error); order cannot be processed.
Elements of Rule and Validation Result
The Commercial Restrictions on Attributes rule is comprised of the following elements:
Rule type, including logical expressions
Rule date
Product
Product status
Attribute and attribute value
The Commercial Restrictions on Attributes rule is invalid when any of the incompatible elements (such as product id, functional product ID, or attribute ID) exists in the contract, a product is a descendant of the functional product in the contract structure, and an attribute is attached to the functional product.
Commercial Restriction on Attributes Rule - Example
At runtime, when a user creates an order (or service management order) and initiates a configuration session, all active rules are being evaluated, including this sample rule that is valid between April 6, 2008 and June 30, 2008 if the product selling date of the order falls within this time frame. Based on the rule definition, the rule execution condition (specified in the Restricting Attributes section) is satisfied if:
Any commercial atomic offers within the 3G USIM package is selected in the configuration session.
That atomic offer sells the Prod 1 functional product that is specified in the Restricted Attributes section.
A sample commercial restriction between attribute values rule definition (1 of 2)
The configuration, having met the rule execution condition, is now subject to the evaluation that is set by the Restricted Attributes section. This table shows the rule constraint condition:
A sample commercial restriction between attribute values rule definition (2 of 2)
The system checks if the value selected for the COLOR_SELECTION attribute is in fact a restricted value. In this example, if the selected color for Prod 1 is Grey, Putty, or White (all of them are restricted attribute values), the rule constraint condition is then resolved to TRUE, which means that the configuration is in violation of the commercial restriction rule for attribute values. As a result, the status of the configuration is shown as Invalid, based on the specified rule severity. In addition, because the attribute is set as required, the configuration becomes invalid as well if no value is selected for the COLOR_SELECTION attribute upon submission.
See Also
Setting Up Commercial Restriction Rules for Attributes
Commercial prerequisite rules can be used to require the selection of commercial products in configuration sessions (by displaying warnings or errors) upon the selection of certain commercial products due to prerequisite requirements.
The composition of commercial prerequisite rules is the same as commercial incompatibility rules, which includes a rule reference scope, a rule execution condition and a rule constraint condition. The ways the two rule types are evaluated at runtime are also identical. The only difference between them is the way evaluation results are being interpreted. Specifically:
A configuration is considered invalid of a prerequisite rule if the rule execution condition (left hand side sentence) is evaluated to TRUE whereas the rule constraint condition (left hand side sentence) is evaluated to FALSE.
For a prerequisite rule, the product selection conditions for the right hand side should be a prerequisite of the left hand side selection.
A configuration is considered invalid of a incompatibility rule if both conditions are evaluated to TRUE.
See Commercial Incompatibility Rules, Setting Up Commercial Prerequisite Rules.
Elements of Rule and Validation Result
The Commercial Prerequisite Rule is comprised of the following elements:
Rule type, including logical expressions
Rule date
Left Hand Side/Right Hand Side
Scope of rule
Product and product rule group
Product status
Product scope (only on Right Hand Side)
Local and Global cardinality
AND/OR/()
The Commercial Prerequisite Rule is invalid when the Left Hand Side is equal to true and the Right Hand Side is equal to false.
Commercial relies on rules restrict for each shared service how many other services and what types of services can be connected simultaneously to the shared service.
Use commercial relies on rules to restrict the selection of commercial products in configuration sessions (by displaying warnings or errors) upon the selection of certain commercial products based on predefined resource sharing criteria.
In the rule setup where the rule execution condition is defined, you specify an atomic offer or a complex group offer (a package product).
For product configurations that satisfy the rule execution condition, they are further evaluated by the rule constraint condition, which consists of commercial components (as well as external services) and specific conditions based on which they are permitted to leverage the resources. For a configuration session to be validated by a commercial relies on rule, all the required commercial products listed in the rule must be selected in the same session, the functional products of these commercial products must be linked as well—the functional product of the commercial product specified in rule execution condition must be related to functional products of commercial products specified in rule constraint condition through the relies on product link. This linkage can be established during the configuration session before it is submitted for rule validation.
A Relies On product link can relate two products from the same or different contracts, as different product scopes are supported when you specify commercial products in the rule constraint condition section of the rule definition:
If Contract is selected, the left hand side and right hand side commercial components must belong to the same contract in order for the evaluation of the rule constraint condition to continue.
If Play is selected, the left hand side and right hand side commercial components must belong to the same play in order for the evaluation of the rule constraint condition to continue.
If Direct Parent is selected, the left hand side and right hand side commercial components must have the same direct parent in order for the evaluation of the rule constraint condition to continue.
If Same Customer is selected, the left hand side and right hand side commercial components must belong to different contracts that are owned by the same customer in order for the evaluation of the rule constraint condition to continue.
If Other Customer is selected, the left hand side and right hand side commercial components must belong to different contracts that are owned by the different customers in order for the evaluation of the rule constraint condition to continue.
If External Service is selected, the right hand side commercial components must be customers of other communications service providers in order for the evaluation of the rule constraint condition to continue.
The system selects this value as the default scope if the corresponding right hand side product is an external service. The External Service scope is the only available value for external services.
A configuration is in violation of a commercial relies on rule if the rule constraint condition resolves to FALSE, which can be caused by missing relies on relationships between products, or missing prerequisite products. The configuration is considered valid if the rule constraint condition is resolved to TRUE. At the end, the configuration status is updated on the corresponding order or service management order:
Valid: submitted configuration does not violate any rules; order can be processed.
Valid with warnings: submitted configuration violates some rules and this status is issued based on the specified rule severity (Warning); order can be processed.
Invalid: submitted configuration violates some rules and this status is issued based on the specified rule severity (Error); order cannot be processed.
Relies On product links become installed links after the completion of the fulfillment process for service management purposes.
Elements of Rule and Validation Result
The Commercial Relies On Rule is comprised of the following elements:
Rule type, including links with logical expressions
Rule date
Left Hand Side/Right Hand Side
Product and product rule group (groups only on the Right Hand Side)
Product status
Product scope (only on Right Hand Side)
Local and Global cardinality (only on Right Hand Side)
AND/OR/() (only on Right Hand Side)
The Commercial Relies On Rule is invalid when the Left Hand Side is equal to true and the Right Hand Side is equal to false. Also, the rule is invalid when an incoming prerequisite link is not in a permissible range.
See Setting Up Commercial Relies On Rules.
Commercial Relies On Rule - Example
This section provides a sample commercial relies on rule definition and explains how the rule impacts a configuration session when applied.
This table shows the details of the sample rule definition:
A sample commercial relies on rule definition
At runtime, when a user creates an order (or service management order) and initiates a configuration session, all active rules are being evaluated, including this sample rule that is valid between June 26, 2008 and December 31, 2099 if the product selling date of the order falls within this time frame. Based on the rule definition, the rule execution condition (specified in the Left Hand Side Product section) is satisfied if a new or active Shared Directory product is selected in the configuration session.
The configuration, having met the left hand side product condition, is now subject to the evaluation that is set by the right hand side sentence (R1 AND R2). This table shows the condition defined for the R1 group:
A right hand side group definition of the sample commercial relies on rule definition
The system evaluates the condition of the right hand side sentence against each instance of the left hand side product found in the configuration. For any identified left hand side product (the Shared Directory, the R1 group condition is satisfied if:
The configuration includes at least one but no more than three quantities of the Voice Over IP 11 product that is in New or Active status and it is in the same contract as the Shared Directory.
The total quantity of the Voice Over IP 11 product ordered in the configuration session is at least one (minimum group quantity = 1) but no more than three (maximum group quantity = 3).
The right hand side sentence consists of only two right hand side groups, the rule constraint condition is resolved to TRUE when the conditions of both R1 and R2 groups are satisfied. If any of these groups is not satisfied, the rule constraint condition is resolved to FALSE, and the configuration being evaluated is considered in violation. Based on the specified rule severity, the status of the configuration can be:
Valid with warnings: submitted configuration violates some rules and this status is issued based on the specified rule severity (Warning); order can be processed.
Invalid: submitted configuration violates some rules and this status is issued based on the specified rule severity (Error); order cannot be processed.
Note. Exercise caution when introducing changes to commercial relies on rules as they can cause incompatibility in installed products and invalidate configurations inadvertently. For instance, an installed link was created between two installed products after a configuration was validated by a commercial relies on rule and the order was fulfilled. Assume that the commercial relies on rule is now expired, and an installed link that was previously created by it is identified in a configuration session of a service management order, the configuration becomes invalid because the rule is no longer present to validate the relationship.
You can set up relies on rules for functional components as well. Refer to the see also reference for more information on functional relies on rules.
See Also
The commercial relies from rules function in the same manner as the functional relies from rules and let you define the reverse cardinality of the commercial products that rely on shared products.
Refer to the see reference for more information on functional relies from rules.
See Functional Relies From Rules.
Functional incompatibility rules can be used to restrict the selection of functional products in configuration sessions (by displaying warnings or errors) upon the selection of certain functional products due to incompatibility. The definition and the validation logic for functional incompatibility rule is almost identical to commercial incompatibility rule, with the exception that functional incompatibility rules are set between functional products.
At runtime, a functional product is selected in a configuration session through the selection of the commercial offer that sells it.
See Commercial Incompatibility Rules.
For rules with the Direct Parent reference scope, it is understood as the direct parent of the commercial offer which sells the functional product.
Rule Reference Scope
Before the evaluation of a rule execution condition occurs, the system needs to know the scope for which this condition should be evaluated, so that it can determine which products in the configuration are to be considered when the rule execution condition is being evaluated. Similar to commercial incompatibility rules, three scope values are available:
Contract
All products selected in the contract are considered when the evaluation occurs.
Play
The rule execution condition is being evaluated in every play that is selected within the contract. For each play, all products selected in it are subject to evaluation. For example, if the rule execution condition requires functional products FA and FB, this condition is met only if products FA and FB are selected in the same play.
Direct Parent
The rule execution condition is being evaluated in every offer that is selected within the contract. For each offer, the condition is evaluated against functional products that are sold by the commercial atomic offers which are direct children of this offer. For example, if the rule execution condition requires functional products FA and FB and the scope is Direct Parent, this condition is met if products FA and FB are sold by two atomic offers that have the same immediate parent.
Elements of Rule and Validation Result
The Functional Incompatibility Rule is comprised of the following elements:
Rule type, including logical expressions
Rule date
Left Hand Side/Right Hand Side
Scope of rule (contract, play, direct parent)
Product and product rule group
Product status
Product scope (only on Right Hand Side)
Local and Global cardinality
AND/OR/()
The Functional Incompatibility Rule is invalid when the Left Hand Side and the Right Hand Side are equal to true.
Functional Incompatibility Rule - Example
This section provides a sample functional incompatibility rule definition and explains how the rule impacts a configuration session when applied.
This table shows the details of the sample rule definition:
A sample functional incompatibility rule definition (1 of 2)
A sample functional incompatibility rule definition (2 of 2)
At runtime, when a user creates an order (or service management order) and initiates a configuration session, all active rules are being evaluated, including this sample rule that is valid between June 12, 2008 and May 31, 2099 if the product selling date of the order falls within this time frame. For each commercial offer (rule reference scope: direct parent) selected in the configuration, the evaluation of the left hand side (L1) sentence first applies. This table shows the of the condition defined for the L1 group:
A left hand side group definition of the sample functional incompatibility rule definition
Based on the group definition, an offer configuration satisfies the condition of the L1 group if it contains one commercial atomic offer that sells the PSTN functional product and is in the new status.
In this example, because the left hand side sentence consists of only L1, the rule execution condition is automatically resolved to TRUE as soon as the L1 group condition is satisfied, which then triggers another set of evaluations that checks if the configuration is indeed in violation of the sample rule.
All the offers that meet the left hand side sentence condition are subject to the evaluation that is set by the right hand side sentence (R1). This table shows the of the condition defined for the R1 group:
A right hand side group definition of the sample functional incompatibility rule definition
Based on the group definition, an offer configuration satisfies the condition of the R1 group if it contains at least two but no more than three quantities of the commercial products that sells the ISDN functional product. These products must be selected within the same contract (specified by the scope) as the PSTN functional product.
Because the right hand side sentence consists of only one right hand side group, the rule constraint condition is automatically resolved to TRUE as soon as the R1 group condition is satisfied.
In the case of the sample rule (rule type = functional incompatibility), when both left hand side and right hand side sentences are evaluated to TRUE, the configuration being evaluated is considered in violation. Based on the specified rule severity, the status of the configuration can be:
Valid with warnings: submitted configuration violates some rules and this status is issued based on the specified rule severity (Warning); order can be processed.
Invalid: submitted configuration violates some rules and this status is issued based on the specified rule severity (Error); order cannot be processed.
See Also
Setting Up Functional Incompatibility Rules
Functional incompatibility rules for attribute values can be used to restrict the attribute values or formats allowed for functional products based on certain attribute values or formats entered for other functional products due to incompatibility. They are the super-set of the standard functional incompatibility rules in that you can set up product incompatibility based on attribute values as well as the format in which the values are entered.
In the rule setup where the rule execution condition is defined, you specify a functional product-attribute pair and attribute values (or formats). For configuration sessions that select the specified functional product and attribute values (through the selection of commercial product that sells the functional product), additional evaluations of the functional incompatibility rule are performed to check if these sessions have also selected another functional product with certain specified attribute values, which are in fact defined as restricted values in the rule.
At the end, the system updates the status of the configuration based on the result of the evaluation:
Valid: submitted configuration does not violate any rules; order can be processed.
Valid with warnings: submitted configuration violates some rules and this status is issued based on the specified rule severity (Warning); order can be processed.
Invalid: submitted configuration violates some rules and this status is issued based on the specified rule severity (Error); order cannot be processed.
See Functional Incompatibility Rules.
Elements of Rule and Validation Result
The Functional Incompatibility Rules for Attribute Value is comprised of the following elements:
Rule type, excluding logical expressions
Rule date
Scope
Attribute and attribute value
The Functional Incompatibility Rules for Attribute Value is invalid when any of the incompatible elements (such as a restricting attribute ID of a given Functional product ID or restricted attribute value) exists in the given scope. The matching of attribute value can be done either by equality of values, or by matching format of a value, depending on restriction type.
Functional Incompatibility between Attribute Values Rule - Example
This section provides a sample functional incompatibility rule definition for attribute values and explains how the rule impacts a configuration session when applied.
This table shows the details of the sample rule definition:
A sample functional incompatibility between attribute values rule definition (1 of 2)
At runtime, when a user creates an order (or service management order) and initiates a configuration session, all active rules are being evaluated, including this sample rule that is valid between April 6, 2008 and June 30, 2008 if the product selling date of the order falls within this time frame. Based on the rule definition, the rule execution condition (specified in the Restricting Attributes section) is satisfied if the 3G USIM product is selected in the configuration session, and value 2 of the ATTR_KAROLA attribute is specified for the product.
The configuration, having met the rule execution condition, is now subject to the evaluation that is set by the Restricted Attributes section. This table shows the rule constraint condition:
A sample functional incompatibility between attribute values rule definition (2 of 2)
The system checks if the configuration includes the selection of the Prod 1 product within the same play as the 3G USIM product. If yes, it continues to check if the ATT_STX1 attribute of the Prod 1 product has been filled out in this format: \(\d{3}\)\d{3}-\d{4} (it is a Java expression that represents the US phone number format: (800)555-5555). If the attribute condition is again satisfied, the entire rule constraint condition is automatically resolved to TRUE, which means that the configuration is in violation of the functional incompatibility rule for attribute values. As a result, the status of the configuration is shown as Invalid, based on the specified rule severity.
See Also
Setting Up Functional Incompatibility Rules For Attributes
Functional relies on rules let you define functional prerequisite relationships between one functional component and a group of functional components. They evaluate product configurations for possible prerequisite violations and issue proper validation statuses to configurations as a result.
In order for functional products to be evaluated by functional relies on rules in configuration sessions, they have to be linked already through the relies on product relationship during the sessions. Functional relies on rules do not create installed links.
The concept of rule reference scope does not apply to functional relies on rules as it does to commercial prerequisite rules. Because you only specify one product for the rule execution condition (left hand side condition), it is defaulted implicitly that the rule reference scope is Direct Parent.
Elements of Rule and Validation Result
The Functional Relies On Rule is comprised of the following elements:
Rule type, including links with logical expressions
Rule date
Left Hand Side/Right Hand Side
Scope of rule
Product and product rule group (groups only on the Right Hand Side)
Product status
Product scope (only on Right Hand Side)
Local and Global cardinality (only on Right Hand Side)
AND/OR/() (only on Right Hand Side)
The Functional Relies On Rule is invalid when the Left Hand Side is equal to true and the Right Hand Side is equal to false. Also, the rule is invalid when an incoming Relies On link is not in a permissible range.
Functional Relies On Rule - Example
This section provides a sample functional relies on rule definition and explains how the rule impacts a configuration session when applied.
This table shows the details of the sample rule definition:
A sample functional relies on rule definition
At runtime, when a user creates an order (or service management order) and initiates a configuration session, all active rules are being evaluated, including this sample rule that is valid between May 26, 2008 and December 31, 2099 if the product selling date of the order falls within this time frame. Based on the rule definition, the rule execution condition (specified in the Left Hand Side Product section for functional relies on rules) is satisfied if the ABC DSL Service Plan product that is in either New or Active status is selected in the configuration session, in which case triggers another set of evaluations that checks if the configuration is indeed in violation of the sample rule.
The configuration, having met the left hand side sentence condition, is now subject to the evaluation that is set by the right hand side sentence (R1). This table shows the condition defined for the R1 group:
A right hand side group definition of the sample functional relies on rule definition
The system evaluates the condition of the right hand side sentence against each instance of the left hand side product found in the configuration. For any identified left hand side functional product (the ABC DSL Service Plan, the R1 group condition is satisfied and the right hand side sentence resolved to TRUE if:
The configuration includes exactly one Sagem 23421 product that is in New or Active status and it is in the same contract as the ABC DSL Service Plan. Additionally, ABC DSL Service Plan is tied to this product through the relies on link.
The quantity of the Sagem 23421 product ordered in the configuration session is one.
Because the right hand side sentence consists of only one right hand side group, the rule constraint condition is automatically resolved to TRUE as soon as the R1 group condition is satisfied.
In the case of functional relies on rules, when the left hand side product is successfully identified in a configuration and the right hand side sentence is evaluated to FALSE, the configuration being evaluated is considered in violation. Based on the specified rule severity, the status of the configuration can be:
Valid with warnings: submitted configuration violates some rules and this status is issued based on the specified rule severity (Warning); order can be processed.
Invalid: submitted configuration violates some rules and this status is issued based on the specified rule severity (Error); order cannot be processed.
Note. Exercise caution when introducing changes to functional relies on rules as they can cause incompatibility in installed products and invalidate configurations inadvertently. For instance, an installed link was created between two installed products (functional products) after a configuration was validated by a functional relies on rule and the order was fulfilled. Assume that the functional relies on rule is now expired, and an installed link that was previously created by it is identified in a configuration session of a service management order, the configuration becomes invalid because the rule is no longer present to validate the relationship.
You can set up relies on rules for commercial components as well. Refer to the see also reference for more information on commercial relies on rules.
See Also
Setting Up Functional Relies On Rules
Functional relies from rules let you define the reverse cardinality of the functional products that rely on shared products.
For example, you may have defined a relies on rule that allows a family plan to support mobile lines (0 to 3 lines) and VOIP lines (1 or 2 lines). This relies on rule definition provides the cardinality from family plan to mobile line and family plan to VOIP line. You use functional relies from rules to specify the cardinality from mobile line to family plan and from VOIP line to family plan, for example:
The mobile line can support family plan (0, 2).
This rule definition provides the cardinality from the mobile line to the family plan.
The VOIP line can support family plan (1,1).
This rule definition provides the cardinality from the VOIP line to the family plan.
The functional relies from rule is not installable.
You can set up relies from rules for commercial components as well. Refer to the see also reference for more information on commercial relies from rules.
See Also
Setting Up Functional Relies From Rules
Commitment triggering and covering rules work hand in hand to automatically assign commitment coverage to products that are about to be added as well as those that are currently selected in configuration sessions. This diagram illustrates at a very high level what a commitment triggering rule and covering rule can accomplish when they are executed in a configuration session:
Use of commitment triggering rule and covering rule to add commitment coverage for newly added products and existing product in configuration sessions
Here are the assumptions set for the diagram:
A commitment triggering rule definition CT1 exists for atomic offers 1 and 2, and commitment product CMT2.
A commitment covering rule definition CC1 exists for the commitment product CMT2 and play 2.
At runtime, you select both atomic offers 1 and 2 in a configuration session. The selection triggers the evaluation and execution of commitment triggering rule CT1, which automatically adds a new commitment product CMT2 or extends the duration of an existing installed commitment CMT2.
The selection of commitment product CMT2 in the configuration session triggers the evaluation and execution of commitment covering rule definition CC1. As a result, play 2 (an existing installed product) is automatically selected in the configuration session and covered by commitment product CMT2.
Refer to these sections for more information on commitment triggering rules and commitment covering rules:
Commitment triggering rules.
Commitment covering rules.
Commitment triggering and covering Rules - example.
Commitment Triggering Rules
Use commitment triggering rules to add commitment products (or update the commitment period of existing commitment products) in configuration sessions upon the selection of products that these commitment products cover.
In a commitment triggering rule definition, you specify:
A left hand side product (if rule reference scope is set to Instance), or groups of left hand side products. For each product you reference in a left hand side group, you specify the minimum and maximum quantities of the product that belongs to the group (that is, local quantity) and product status. At the group level, you specify the minimum and maximum total count of products that belong to the group (that is, global cardinality).
These products are also referred to as triggering products in this documentation.
Rule reference scope, which identifies the extent of a multilevel product hierarchy within which the evaluation of rule conditions take place.
A commitment triggering rule is invoked for each product component in the session that matches the scope defined for the rule (the rule reference scope). For example:
If rule reference scope is set to Play, the evaluation of the left hand side sentence condition takes place for each instance of the play found in the configuration. For each play instance in which the left hand side sentence condition is met, a commitment product (defined in the rule definition) is added to it as a result. (that is, in that context applied means that Commitment is due to that instance of Play, Commitment that is applied might cover different products within or outside this Play). The commitment product is applied only once for each instance.
Note that a commitment product that is applied to any given scope (play in this example) of a product hierarchy may actually cover other products within or outside of the current scope.
If rule reference scope is set to Instance, the evaluation of the left hand side sentence condition takes place for each instance of the specified left hand side product found in the configuration. The commitment product is applied only once for each instance.
Logical sentence, also known as left hand side sentence, which consists of left hand side groups and logical operators that connect the groups.
A logical sentence does not apply if a rule has only one triggering product.
Note. The combination of product groups, rule reference scope and logical sentence forms the rule execution condition. A commitment triggering rule is executed if the product selection in the current configuration session meets the requirement set by the logical sentence and the specified reference scope.
A commitment product that is referenced in the configuration session to provide commitment coverage for the triggering products.
You can specify multiple commitment products in a rule definition. In this case, when the rule is executed at runtime, the agent needs to manually pick one from the list of available commitment products.
Note. In a rule definition, you can mandate the selection of a commitment product in configurations. At runtime, agents have the option to clear the selection of commitment products that are preselected by default.
The method to use to introduce the commitment product. Options are:
Create a new commitment product.
The agent has the option to choose a duration of the commitment product from a list of options that are defined in the rule definition.
Extend the duration of an existing installed commitment.
When a rule with this behavior is executed at runtime, it checks the configuration session for an existing commitment product matching the one that is specified in the rule definition and extends its duration. The agent can choose the length of the extension from a list of options that are defined in the rule definition.
Note. If multiple matching commitment products are found, the agent needs to pick one manually and the select the length of extension for it in the configuration session.
Renew the duration of an existing installed commitment.
The renew and extend behaviors are almost identical except that duration options sets they use in specifying commitment options in the commitment triggering rule definition are different.
The execution of commitment triggering rules, when applicable, occurs after the submission of product configurations for verification in configuration sessions. First, product selections are evaluated against the conditions defined for each triggering rule instance to check which rules to apply. If the condition of a rule is fulfilled, the system adds the commitment product to the session, or presents the agent a list of possible commitment products that are defined by the rule (if multiple commitment products are associated with the rule). The rule evaluates to TRUE if the required commitment is added for the product selected that needs coverage. In the case where a commitment product is mandatory for a product in the configuration session but the agent doesn't select one, the rule is considered broken and that invalidates the configuration.
Commitment triggering rules take into account the status of products in rule evaluation. There must be at least one product in the New status for the rule to be evaluated.
In the configuration session, a link is established between the triggering product and the commitment product that is added or extended for referencing purposes. In other words, if the agent removes the triggering product from the configuration, its commitment product should no longer be a required selection anymore and the system can make that happen with the presence of this link.
Then, product selections are evaluated against the constraints specified by the rule that applies to the submitted configuration. Depending on the rule severity and the results of rule evaluation, the configuration status can be set to:
Valid: submitted configuration does not violate any rules; order can be processed.
Valid with warnings: submitted configuration violates some rules and this status is issued based on the specified rule severity (Warning); order can be processed.
Invalid: submitted configuration violates some rules and this status is issued based on the specified rule severity (Error); order cannot be processed.
See Setting Up Commitment Triggering Rules.
Commitment Covering Rules
Use commitment covering rules to define products that any given commitment product covers. These covered products are selected automatically to configuration sessions upon the addition or extension of their associated commitment product, the result of a commitment triggering rule execution.
In a commitment triggering rule definition, you specify:
The commitment product, for which the commitment covering rule is created.
Each commitment product can only be referenced in one single active commitment covering rule.
Duration settings.
Two sets of duration settings are available: one for creating and renewing the corresponding commitment product, and the other for extending the commitment product.
These duration sets are used in commitment triggering rules to specify durations of commitment products based on the selected behavior.
Covering scope, which is the scope (contract, play, direct parent, and instance) that covered products must be in together with the commitment product in order for them to be covered.
Commitment activation option, which determines the installation order of covered products – either after the first committed product is installed or after all committed product are installed.
List of covered products, which are categorized in groups and processed with the AND logical operator.
These products are added in configuration sessions and covered by the rule's commitment product as a result of the execution of the commitment covering rule.
A commitment covering rule is executed upon the selection or addition of its commitment product in configuration sessions. The result of the rule execution is the automatic selection of the list of covered products in configuration sessions based on the specified product scope, status and quantities.
In the rule definition you specify a scope for each covered product that is referenced. Values of product scope are available based on the covering scope that is selected at the rule level. Here are the delivered product scopes for commitment covering rules and how commitment coverage is assigned based on product scope:
If product scope is Contract, the commitment product provides coverage to this product (covered product) if both this product and the triggering products of the commitment product reside in the same contract.
If product scope is Play, the commitment product provides coverage to this product if both this product and the triggering products of the commitment product reside in the same play.
If product scope is Direct Parent, the commitment product provides coverage to this product (covered product) if both this product and the triggering products of the commitment product have the same direct commercial parent in the product hierarchy.
If product scope is Instance, the commitment product provides coverage to every instance of the covered product, which must be the same as the left hand side product of the associated commitment triggering rule (the rule that triggered the creation or extension of the commitment product).
Note. This option is available only if the reference scope of the associated commitment triggering rule is also set to Instance. Only one product within the commitment covering rule definition can have its product scope set to Instance.
As part of the rule operation, logic is in place to also look at product status and allowable quantities at both group and product levels to determine the final covered product list. It identifies the number of covered product instances found in the configuration session (taking into account the status and scope of these products in the configuration) and evaluates their commitment availability (by checking to see if any of the products are currently linked to an active commitment product). One of two things happens:
If the number of instances found within the selected scope in the configuration session is outside the range of minimum and maximum quantities specified for the covered product, the covering rule cannot be fulfilled and that invalidates the configuration.
If number of instances found within the selected scope in the configuration session is within the range of minimum and maximum quantities specified for the covered product, the identified product instances are automatically linked to the commitment product. Otherwise the agent needs to manually select instances to be covered by the commitment product.
See Setting Up Commitment Covering Rules.
Commitment Triggering and Covering Rules - Example
This example includes discussion of both commitment triggering and covering rules as these rule types work close together in product configurations.
At runtime, when a user creates an order and initiates a configuration session, all active rules are being evaluated, including this sample rule that is valid between May 27, 2008 and December 21, 2099 if the product selling date of the order falls within this time frame. Based on this commitment triggering rule definition, the rule execution condition is satisfied if both Atomic Offer 1 and Atomic Offer 2 are selected within the same play in the configuration session.
A sample commitment triggering rule definition (1 of 2)
A sample commitment triggering rule definition (2 of 2)
Let's assume that product selections in the configuration session has met the triggering rule execution condition. The triggering rule is executed, which automatically adds a new commitment product (CMT2) to the configuration session for Atomic Offer 1 and Atomic Offer 2. It is a new commitment product because the selected commitment behavior is Create. The selected reference scope is play, which means that the rule adds a commitment product (CMT2) for each play found in the configuration session that has both Atomic Offer 1 and Atomic Offer 2 selected.
The addition of the CMT2 commitment product triggers the execution of its commitment covering rule automatically. Based on this commitment covering rule definition that is set up for CMT2, the execution adds coverage of CMT2 to three quantities of Play 2 that are found in the same contract.
A sample commitment covering rule definition (1 of 2)
A sample commitment covering rule definition (2 of 2)
See Also
Setting Up Commitment Triggering Rules
This section discusses how to:
Set up product relations codes.
Set up product relationships.
Set up product components.
Set up multilevel product packages.
Page Name |
Definition Name |
Navigation |
Usage |
Product Relations Codes |
RB_RELATIONS |
Products CRM, Product Relations Codes, Product Relations Codes |
Set up the codes that describe relationships between products. |
Product Relationships |
PROD_RELATIONS |
Products CRM, Product Relationships, Product Relationships |
Set up relationships between products. |
Product Definition - Definition |
PROD_DEFN |
Products CRM, Product Definition, Definition |
Set up components that build multilevel product packages. |
Package Components |
PRODKIT_SUMMARY |
Products CRM, Package Components, Package Components |
Set up multilevel product packages. |
Access the Product Relations Codes page (Products CRM, Product Relations Codes, Product Relations Codes).
These options are specific to multilevel product bundles.
Warning! Do not modify the predefined setup in the Product Relations Codes component for configured multilevel product bundles, as Advanced Configurator is set up to support the delivered code setup only.
Installable |
Select for the system to create links (called installed links) between installed products with the corresponding relation after the order fulfillment process completes. For example, product A is related to product B through the Relies On relation, which is set to be installable as delivered. When the fulfillment process for products A and B completes, the system creates an installed product for each of them for service management purposes, plus an installed link for the relies on product relation. |
Rule based |
Select if the corresponding product relation can only be established between products at runtime, through the execution of validation and configuration rules during configuration sessions in ordering or service management processes. Rule based product relationships cannot be established in design time therefore they are not available for selection in the Product Relationship component. |
Note. The product relations codes that appear in the preceding example are delivered as system data. You can add relations, but you should not remove any delivered relations.
See Also
Setting Up Product Relationship Codes
Access the Product Relationships page (Products CRM, Product Relationships, Product Relationships).
Among all the product relationships that are delivered specifically for multilevel product bundles, the Sells relationship can be established between products using this component. To set up a sells relationship between two products, the product in the header must be an atomic offer (a commercial component) with the Link to Functional option enabled at the component type level. The products selected in the Products to Relate section must be functional components
See Also
Managing Product Relationships
Access the Product Definition - Definition page (Products CRM, Product Definition, Definition).
Note. Information that is discussed in this section applies only to the definition of products (standard product, service product and package product) for multilevel product bundles to be used in the communications solution. COM01 is the system-delivered setID for the communications solution. Other sections within the product definition component are supposed to work the same for both multilevel and non-multilevel product structures unless stated otherwise.
See Defining Products.
Delivered communications-specific display templates control the presence of sections in the Product Definition component for the communications solution.
See Understanding Display Templates.
Configuration Information
Fields that are introduced in this section are applicable to products that are configured using the Advanced Configurator. If Sales Product Configurator or Oracle Configurator is selected on the General Options page as the configurator product that is used by the CRM system, these fields are hidden; the existing layout for non-multilevel products is displayed instead.
Multilevel Bundle Component |
Select this option if the product (standard product, service product, or package product) is part of a multilevel product bundle. When you select this option, the Component Type field becomes available for use. |
Hide in Order Lines |
Select to not show the product (standard product, service product, or package product) in the Line Summary section of the Entry Form page of orders and quotes. This option is not available to all functional components and top-level product components, which are commercial. |
Hide in Installed Product Hierarchy |
Select to not show the product (standard product, service product, or package product) on the Installed Product Hierarchy tree. If a package is set to be hidden, all of its descendants are hidden as well. This option is not available to all functional components and top-level product components, which are commercial. |
Hide in Configurator |
Select to not show the product (standard product, service product, or package product) in configuration sessions. This option is not available to all functional components and top-level product components, which are commercial. |
Disable in Configurator |
Select to disable any actions from being performed on the product (standard product, service product, or package product) in configuration sessions. This option is not available to all functional components and top-level product components, which are commercial. |
Component Type |
Select a multilevel bundle component type for the offer. In order for component type values to be available for selection, you must, as a prerequisite, specify a multilevel structure on the Multilevel Structure Linkage page for the setID that supports multilevel product bundles. See Setting Up Multilevel Structure Linkages. For example, associate the COM01 setID with the predefined MLPB01 structure. Based on this system setup, component type values are: Atomic Offer: Select this value for a single product or service. When you select this value, the Group Offer Details group box becomes available for use. External Service: Select this value if you want to define a service that is provided by an external carrier. Functional Component: Select this value if the offer is a functional product or service. Note. Standard products and service products can only be assigned to functional components, or commercial components that can be linked to functional components. Packages can only be assigned to commercial components that cannot be linked to functional components. |
Group Offer Details
This section appears if the selected component type is Atomic Offer.
Offer Type |
Select either Shared or Group offer type. Shared offers consist of a single shared service. Group offers consist of a single or multiple shared services. If you select either offer type, the Modification Count Type field becomes available for use. If you select Group offer type, the Bundling Type field becomes available for use. Note. This is not a required field. |
Bundling Type |
Specify how group offer members relate to the offer. Available values are: Individual Services: Select this value to link all members to a single instance of the shared service that is sold by the group offer. Dedicated Services: Select this value to link each member to a separate, dedicated instance of the shared service that is sold by the group offer. |
Modification Count Type |
Select an Operations Count AAF to calculate the number of operations performed on the offer (for example, adding or removing members). Operation count is calculated separately for each instance of the offer based on the specific algorithm associated with the selected Operations Count AAF. Clicking the lookup button opens the ‘Term selection’ screen, which enables you to select an Operation Count AAF for the offer.
Note. This is not a required field. |
Covering Rule Details
This section appears if the product type of the current definition is Commitment.
Covering Rule ID and Covering Rule Description |
Displays the identifier and textual description of the commitment covering rule that applies to the commitment product. In other words, if the commitment product is added automatically in a configuration session as a result of an execution of a commitment triggering rule, it triggers the execution of this commitment covering rule, which in turn adds products (products that are covered by this rule) to the configuration session. Each commitment product must be associated with one commitment covering rule before the product can be referenced in any commitment triggering rule definition. |
Order Standalone By
This section appears if the Order Standalone option is enabled in the multilevel component type setup for the component type that is assigned to the product (standard products, service products, and package products).
Service Information
Service Required |
This field is hidden for standard products, service products, package products and subscription products. |
Service ID |
This field is hidden for standard products, service products, package products and subscription products. |
Install as Service |
Select for the system to create an installed service for the package after the ordering process for the package is completed. If cleared, an installed product is created instead. This field appears if the package is set to track as installed product on the Installed Product page of its product definition. Note. The Track as Installed Product option is selected by default, if the Installability Default option is enabled in the multilevel component type setup for the component type that is assigned to the product (standard products, service products, and package products). |
Billing Options
Use this section to specify billing options for the product. This section appears if the product type is Standard Product, Service Product, or Product Package.
Billing Account Selectable |
Select to identify the corresponding product as billable and it needs to be associated with some type of accounts for billing purposes. When selected, the Billing Account Details group box appears, where you specify the types of billing accounts that can be used to bill the product's charges. Clear this field for products that are not billable and therefore don't need to link to any billing accounts in orders. In this case, billing accounts are not available for selection at the order line level at runtime. |
Split Billing |
Select to enable the split billing functionality for the corresponding product, making it a split billing product. When you add products that are split billing-enabled to orders, the system allows you to select one or more billing accounts for them at the order line level to pay for different kinds of charges (for example, recurring, non-recurring), and these billing accounts can belong to customers other than the sold-to customer (the one specified in the order header) of the order. |
Billing Account Details
Use this section to specify types of billing accounts that can be selected when ordering this product at runtime. This section appears if the Billing Account Selectable field is selected.
If the product is a split billing product, associate at least two billing account types (serving different purposes) with it and add more as deemed necessary. When you add this product to an order and want to select different accounts to pay for its charges, the number and type of billing accounts that can be selected is based on the selection made in this section.
If the product is not a split billing product, this section contains only one row and does not support adding or removing rows.
Refer to this see reference for more information on the split billing functionality.
See Orders and Service Management.
No (number) |
Assign a number to a newly added billing account. |
Primary |
Select to indicate that the corresponding billing account type is the primary one for the product. This column appears if the product is a split billing product (the Split Billing field is selected). At save time, the system checks to make sure that each split billing product must have one primary billing account. When a split billing product is added to an order at runtime, the system by default displays its primary billing account type at the order line level for the product on the Line Details page. You can change the customer contact and select a specific billing account as these options are made available by the system. |
Purpose ID |
Enter an identifier that specifies the purpose of the corresponding billing account. The system passes this information to the billing system when the product is being provisioned. Use the purpose ID to clarify the usage of various accounts that are selected for the product. The system sets the default value of this field to ALL for products that do not support split billing. The default value comes from the Message Catalog. |
Billing Account Type |
Select the type of billing account that can be used or created to pay for this product when ordered. Values are Either, Postpaid Only and Prepaid Only. Some products can only be serviced through a prepaid or a postpaid account. |
Required |
Select if this billing account is required to show in orders and must be selected when you add the corresponding non-split billing product to an order and capture the billing details for the product at runtime. |
Purpose |
Enter a textual description as the purpose of the billing account. Depending on how your company implements the split billing functionality, you can assign certain accounts to specific billing purposes. For example, use of postpaid accounts for local call charges, prepaid accounts for international call charges. The system sets the default value of this field to All recurring charges for products that do not support split billing. The default value comes from the Message Catalog. |
See Also
Access the Package Usage page (Products CRM, Product Definition, Package Usage).
Package Usage
This section lists all the multilevel product bundles which the current product is a part of. In this section, you can reset the selling period end date of the current product within the selected multilevel product bundles.
Product Component ID and Description |
Displays the identifier and the textual description of the immediate parent of the current product in the corresponding multilevel product bundle. |
Type Description |
Displays the type of the current product, for example, contract, play, offer and so on. |
Effective Date and Obsolete Date |
Displays the start and end dates of a selling period for the current product. The obsolete date must be a date later than the effective date. |
Obsolete Date |
Enter a date to be the new selling period end date of the current product within the selected multilevel product bundles. If you want to retire the current product from multiple product bundles that it associates with, use this field to set its selling period end date. This field is available for edit after one or more product bundles are selected. |
Access the Package Components page (Products CRM, Package Components, Package Components).
The Package Components component is used to define both standard product packages and multilevel product bundles. Here is a list of behaviors that apply when the component is used in defining multilevel product bundles:
When a product package is saved, a parent-child relationship is established automatically between the product in the header of the Package Components page and any product that is specified in the Components section. It is no longer necessary to declare the Child Of relationship between these two products explicitly in the Product Relationships component.
Validations are in place to make sure that each selected package component belongs to a sub-level that the component type of its parent supports, hence adhering the multilevel package structure to the predefined multilevel component type setup.
The minimum and maximum values at the component level specify the minimum and maximum numbers of instances of any given package component that its immediate parent can have. For rules in which a package component is referenced, the system populates its minimum and maximum values (specified in the Product Package component) as the default minimum and maximum quantities in the Group Definition section on the rule definition page.
The minimum and maximum values at the package level specify the minimum and maximum numbers of instances of components that a package can have.
For rules in which a package is referenced, the system populates its group minimum and maximum values (specified in the Product Package component) as the default minimum and maximum group quantities in the Group Definition section on the rule definition page.
The only unit of measure (UOM) that multilevel product bundles support is EACH.
The package hierarchy for multilevel product bundles does not have a limit on the number of levels it can display. It does not have a limit on the number of characters (in product names) it can display. The hierarchy can be scrolled both vertically and horizontally if needed. The product definition, however, has a maximum number of characters it allows in a product description, which is the name used in the package hierarchy (30 spaces).
Clicking the link of a product takes you to the product definition for that product.
Note. A product package cannot be built with a mix of multilevel and non-multilevel product components. Multilevel product packages contain only multilevel product components, whereas non-multilevel product packages contain only non-multilevel product components.
Minimum and Maximum Components in Packages
Here is an example to show how the minimum and maximum quantities defined in a product package are used in validating package configurations at runtime.
Suppose that a package definition for package A is available in the CRM system. It consists of three components (X, Y, and Z) and the minimum and maximum numbers of instances allowed for the product and each component are:
Minimum and maximum numbers of instances allowed for product X: 0,1
Minimum and maximum numbers of instances allowed for product Y: 3,5
Minimum and maximum numbers of instances allowed for product Z: 1,4
Minimum and maximum numbers of components allowed for package A: 4,8
Here are several sample configurations for package A at runtime and their validation results:
Sample Configuration |
Configuration Result |
Description |
1 of X, 3 of Y, 1 of Z |
Valid |
|
5 of Y, 3 of Z |
Valid |
|
10 of X |
Invalid |
|
1 of Y, 1 of Z |
Invalid |
Quantity selected for Y (1) falls below the component quantity limit (3-5). |
1 of X, 4 of Y, 4 of Z |
Invalid |
Sum of all component quantities (9) exceeds the group quantity limit (4-8). |
See Also
To define migration actions, use the Define Migration Action component.
Use the RB_MIG_ACT_SRCH_CP and RB_MIG_ACT_DFN_CMP component interface to load data into the tables for this component.
This section discusses how to:
Define migration actions.
Establish source and target product migration mappings.
View target product hierarchy.
View related eligibility rules.
Refer to the see reference for an overview of migration actions.
See Understanding Migration Actions.
Page Name |
Definition Name |
Navigation |
Usage |
RB_MIG_ACT_DFN_PG |
Set Up CRM, Product Related, Advanced Configurator, Define Migration Action, Migration Action |
Define basic information of migration actions. |
|
RB_MIG_ACT_MAP_PG |
Set Up CRM, Product Related, Advanced Configurator, Define Migration Action, Migration Mapping |
Define the mapping of source and target products for migrations. |
|
RB_MIG_ACT_MAP_SEC |
Click the View Target Hierarchy link on the Migration Mapping page. |
View the hierarchy of the selected target product as the outcome of the migration action. |
|
RB_MIG_REL_OBJ_PG |
Set Up CRM, Product Related, Advanced Configurator, Define Migration Action, Related Objects |
View any eligibility rules that reference the currently opened migration action in their rule definitions. |
Access the Migration Action page (Set Up CRM, Product Related, Advanced Configurator, Define Migration Action, Migration Action).
Migration Action ID |
Displays the unique identifier of the migration action that the system assigns automatically as the action is saved. You can override the value when at the time you create the migration action. By default, migration action IDs begin with the prefix MGA. |
Action Definition
Status |
Select Active or Inactive for the migration action. Only active migration actions can be exported to Advanced Configurator. If you want to export inactive migration actions as well, select the Include Obsolete Definitions field on the Export Product Definitions page. |
Start Date and End Date |
Enter the date range within which the migration action is considered valid and usable. The system uses the start and end dates as well as the status to determine the availability of the migration action at runtime. Only active, non-expired and public migration actions appear as selectable options in configuration sessions. |
Public Migration |
Select to make the migration of referenced source and target products available for selection in configuration sessions. This option is enabled by default. As for actions that are not marked as public (that is, private migration actions), they:
|
Scope |
Select the scope that the migration action can apply. Values are: Same Customer Only (default value): You can only perform the migration action only between contracts that belong to the same customer. Different Customers Only: You can only perform the migration action only between contracts that belong to different customers. All Customers: You can perform the migration action between contracts of any customer. If the migration action is associated with an eligibility rule and the rule definition has the Product Not Eligible setting selected for the same product that is currently referenced on this page as the source or target product, the rule setting supersedes this scope setting and when the rule applies at runtime, the product is not available for selection in configuration sessions. |
Source Information
Product ID |
Select the product component to be transformed (or reparented) by the migration action. The product can be a commercial component of any multilevel component type that is defined in the system. When a source product is selected, the system limits the selection of the target product to those that belong to the same multilevel component type as the source product. For example, if you choose a Play type component as the source product, you can only select another Play type component as the target product. The same is true to the source product if you select the target product first. The migration action is a reparenting one if both source and target products refer to the same product. In this case, only the Added Products section of the Migration Mapping page is available for edit. |
Context |
Select contracts that the source product must be a part of in order for the migration action to become available in configuration sessions. Values are: All Contracts: Select to let all contracts as the Source Context for the particular migration action. Selected Contracts (default value): Select if you only want certain contracts in the system to be considered. The Product ID lookup restricts the selection of products to those belong to component types that are marked as Top Level on the Multilevel Component Types page. Contract is the delivered top level component type. The context defines the boundary within which the migration action becomes available. If the context is set to All Contracts, the migration action is available for all contracts in the system, otherwise, the migration action is only available for the contracts that are selected in the subsequent Contracts section. Note. This section is not applicable if the component type is Contract. |
Target Information
The usage of the Product ID field and the Context group box in this section is identical to those in the Source Information section except that they are specific to the target product of the migration action.
Default in Configurator |
Select to allow default product selections to be made in the target contract after the execution of the migration action in configuration sessions. This setting does not impact the execution of any Brings on Creation, Brings and Removes or Relies-On automation rules—they are executed the same way as any manual product selections. |
Access the Migration Mapping page (Set Up CRM, Product Related, Advanced Configurator, Define Migration Action, Migration Mapping).
Source Hierarchy View
Product ID |
Displays the unique identifier of the selected source product. |
Migration Action |
Select a migration action defined in the system if you want to reuse the mapping of an existing migration action for the same pair of source and target products instead of entering the information manually. When selected, the system populates the Mapping section with the option settings and target products (migration script) that pertain to the selected migration action. If you select a private migration action to be reused in a public migration action, the system ensures that the reused product mapping is copied properly for the export of the public migration action. |
Mapping
This section displays the commercial hierarchy of the source product. You can either select a migration action and have its product mapping populated automatically, or choose a target product for each component in the hierarchy to map to manually. This mapping is subject to integrity check validations that are put in place in the system.
Note. This section does not appear for reparenting actions where the source and target components are identical and when the migration mapping is defined for two different atomic offer products.
Product ID |
Displays the identifier of a component in the source product hierarchy to be migrated. |
Option |
Select the action to be performed in the migration process for the corresponding component. Values are: Remove: the component (for atomic offers only), as well as its descendants, are no longer available in the target product hierarchy after the migration. All its children inherit this option setting automatically. When selected, the Migration Action and Target Product ID fields are blank and unavailable for edit. In the case where the component must be present in the target hierarchy (for example, due to cardinality restrictions in a rule), the system removes the source component and creates a new instance of that component in the target hierarchy so that the configuration can remain valid. Re-parent: the component is associated to a new parent product in the target product hierarchy with all its descendants after the migration. The system sets the values of the target product ID and description in these reparenting products to the same values as their corresponding source products and they unavailable for edit. Transform: if the component is an atomic offer, select another atomic offer in the target product hierarchy to migrate to. If the component is not an atomic offer, select an existing migration action and reuse its mapping. |
Migration Action |
Select a migration action according to which the corresponding component and its descendants are transformed. The system limits the selection to the ones that have the corresponding source product component as the source product. The option setting and target component of its descendants are populated based on the selected migration action. You can override the option setting manually, and update the target component when the field becomes available for edit. Public migration actions must meet these criteria in order to be referenced in this field:
|
Target Product ID |
Select a product that the corresponding source product is transformed or reparented as the end of the migration. This field is available for edit for atomic offers only. For all other component types, this field displays the target product ID in read-only mode, specifically, it shows:
In the case a Product Id is selected more than one time in the grid, the meaning of such action will be adding another Instance of the Product rather than merging different Atomic Offers together. |
View Target Hierarchy |
Added Products
This section displays products to be added to the target contract after the completion of the migration.
Add Product |
Click to add non-top-level commercial components (for example, atomic offers, offers and plays) that are added to the target contract as a result of the migration. Each chosen product must be part of the target Hierarchy. Note that if the maximum cardinality of an added product is exceeded in a configuration session, the configuration becomes invalid and you must address the issue prior to validating the configuration again. |
Access the View Target Hierarchy page (click the View Target Hierarchy link on the Migration Mapping page).
Click to access the View Target Hierarchy page and view the commercial hierarchy of the target product. For target products that are of type Atomic Offer, the system displays their corresponding source products on the page and indicates the actual migration actions that are performed as comments. Available comments are:
Added: Indicates that the corresponding target product is not part of the source hierarchy but it is present in the target hierarchy as it is added in the Added Products section of the Migration Mapping page.
Not Added: Indicates that the corresponding target product is not mapped to a source object; it is added by the system as a result of rule execution, for example, brings on creation.
Reparent: Indicates that the corresponding target product and its descendant are reparented from the source product hierarchy.
Access the Related Objects page (Set Up CRM, Product Related, Advanced Configurator, Define Migration Action, Related Objects).
Related Eligibility Rules
This section displays rules that can impact the migration action selection depending on the selected user or customer criteria in the rule definition. The selection of public migration actions can be restricted through eligibility rules. This page displays information as read-only and does not apply to private migration actions.
Rule ID |
Click the rule link to access the corresponding eligibility rule definition. |
Use the RB_RULE_SRCH, RB_RULE_BRN, RB_RL_COM_INC_ATTR, RB_RULE_COMM_ATTR, RB_RULE_ER, RB_RULE_INCO_PRE, RB_RULE_CRF, RB_RULE_FRO_SS, RB_RULE_COMM_CVR, RB_RULE_COMM_TRG, RB_RULE_FUNC_ATTR RB_RULE_FRF component interfaces to load data into the tables for these components.
This section discusses how to:
Set up commercial eligibility rules.
Set up brings on creation rules.
Set up brings and removes rules.
Set up commercial incompatibility rules.
Define left hand side and right hand side groups.
Set up commercial incompatibility rules for attributes.
Set up commercial restriction rules for attributes.
Set up commercial prerequisite rules.
Set up commercial relies on rules.
Set up commercial relies from rules.
Review related rules.
Set up functional incompatibility rules.
Set up functional incompatibility rules for attributes.
Set up functional relies on rules.
Set up functional relies from rules.
Set up commitment triggering rules.
Set up commitment covering rules.
Note. Configuration rules are setID-based. The system delivers a background process that synchronizes rule updates that are made in the CRM system to PeopleSoft Advanced Configurator. Rule changes do not take effective until they are exported successfully.
Rule Status or Status |
Displays the status of the rule instance. Values are Active and Inactive. Inactive rules do not apply in configuration sessions. |
Severity |
Enter rule severity. Values are Warning and Error. If the rule is being violated during a configuration validation, the configuration status is then set based on the selected severity of the rule. The status is set to: Invalid if the selected rule severity is Error. An order cannot be processed if its product configuration is being invalidated. Valid with Warning if the selected rule severity is Warning. An order can still be processed if its product configuration is in this status. Note. This field appears on definition pages for rules that are designed to check configuration sessions for possible violations, such as product incompatibility or missing prerequisites, and provide the appropriate configuration status as a result. |
Start Date |
Displays the date from which the rule becomes active and are subject to evaluation during configuration sessions. |
End Date |
Displays the date to which the rule remains active and are subject to evaluation during configuration sessions. |
Description |
Displays the short business description of the rule. |
Exception Message or Exception Message Text |
Enter the description for the rule to be displayed to users in case the rule is being violated in a configuration session. Note. This field appears on definition pages for rules that are designed to check configuration sessions for possible violations, such as product incompatibility or missing prerequisites, and provide the appropriate configuration status as a result. |
Reference Scope |
Enter the scope to which the evaluation of this rule applies. The system uses this information to determine which products in a configuration session are to be considered when the conditions of this rule are being evaluated. Values are: Contract (default value): All products selected in the contract are taken into account when rule conditions are being evaluated. Play: Rule conditions are evaluated for each individual play selected in the contract. Conditions are evaluated against products within the same play. For example, if the rule condition requires the selection of products A and B, the condition is met only if both products A and B are selected in the same play. Direct Parent: Rule conditions are evaluated for each individual commercial offer selected in the contract. Conditions are evaluated against products belonging to the same immediate parent. For example, if the rule condition requires the selection of products A and B, the condition is met only if both products A and B have the same immediate parent. Instance: Rule conditions are evaluated separately for each product instance selected in the contract. For example, product A is set to trigger the creation of commitment product B in a commitment triggering rule definition, and the reference scope is Instance. When this rule is executed at runtime in a configuration session, what happens is an instance of the rule is executed for each instance of product A found within the configuration, which results in the creation of the same number of commitment product B for all product A instances. |
Access the Eligibility Rule Definition page (Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules. Select the Commercial Eligibility rule type on the Multilevel Component Rules search page).
Rule Details
These fields are required if the Product Not Eligible validation restriction is defined for the rule.
See Common Elements Used in this Section.
Rule Conditions
Source and Sub Source |
Enter the sales channel and sub channels to be used as criteria in the rule conditions. Sources and sub sources are setID-based and they are established using the Order Capture Setup workbench. |
Add Term |
Select user-specific and customer-specific criteria in the form of AAF terms as rule conditions on the Term Selection page. User criteria are specific to the user who initiated the configuration session; the AAF Term infrastructure uses the ID of that user to resolve actual term values for the order for rule evaluation. Similarly, terms for customer criteria are resolved based on the customer selected for the order. The system delivers these terms that can be used to define eligibility rule conditions: Customer since more than 1 year: Customer term. Expected values are Y and N. The value is calculated based on the Customer Since field value. Customer Assessment: Customer term. Expected values are Bronze, Silver, Gold, and Platinum. Customer Segment: Customer term. Expected values are Low,Medium,High, and Superior. Manager Level: User term. Expected values are Non-Manager and First Line Manager, which are available values for the Manager Level field on the Worker - Job: Job Details page. Note. To create new terms for user criteria, the only bind variable necessary to resolve term values is the “user ID”; terms should always return string value as the resolution result. As for customer criteria, the bind variables necessary to resolve term values are the “business object ID” and the “role type ID”; terms should also always return string value as the resolution result. Level of Competency in ‘Communication System’: User term. |
Product Details
Use this section to list the commercial products and specific rule actions that are applied to these products if conditions of the corresponding rule are met.
Product Not Eligible |
Select to not allow the selected product to be included in configuration sessions. Product Not Eligible is a validation restriction and is evaluated during configuration validation. Validation warning or error is displayed if a non-eligible product is added during configuration sessions manually or automatically. |
Hide Product |
Select to hide the selected product from configuration sessions. |
Product No Add |
Select to disable the Add action for the selected product in configuration sessions so users cannot add the product manually to orders. This option doesn't restrict the selected product from being added automatically by the system through other rule operations, such as bring on creation, and brings and removes rules. |
Product No Remove |
Select to disable the Remove action for the selected product in configuration sessions so users cannot delete the product manually from service management orders. This option, doesn't restrict the selected product from being removed automatically by the system through other rule operations, such as the brings and removes rule. |
Relies On Link Action Restrict
Use this section to place restrictions on the addition or removal of relies on links in configuration sessions between the identified source and target products. This setup disables the manual operations of adding and removing relies on links sourcing from the related functional component of the specified source product leading to the specified target products. Note that the relies on link action restriction that is defined for a commercial product also has an impact on actions for the links that are defined for its related functional product, as functional products are added, removed and configured in configuration sessions through commercial offers that sells them. The restriction defined for the commercial product also restricts actions on links that are defined for its related functional product.
Source Product ID |
Enter the product component as the source product of relies on links on which you want to impose restrictions. |
Restrict Add |
Select to disable to manual creation of relies on links between the specified source product and target products. Note. Relies on rules do not add links between products if commercial eligibility rules prohibits such operation. |
Restrict Remove |
Select to disable to manual removal of relies on links between the specified source product and target products. |
To |
Select how the corresponding relies on link restriction (Restrict Add or Restrict Remove) should apply. Values are: All Targets: Select to disallow the creation or removal of any relies on links between the specified source product and any other products. All Targets with exception: Select to disallow the creation or removal of any relies on links between the specified source product and any other products except for the ones specified in the Exception Target List section. Selected Targets: Select to disallow the creation or removal of any relies on links between the specified source product and any other products that are specified in the Restricted Target List section. |
Restricted Target List or Exception Target List |
Enter the product components as the target products of relies on links on which you want to impose restrictions. The name of this section changes based on the value selected on the To field. For example, if you select the All Targets with exception value, the section name becomes Exception Target List and you list the target products for relies on links that would not be impacted by this restriction. |
Restricted Migration Actions
Use this section to list the migration actions that are prohibited from being available in configuration sessions, if conditions of the corresponding rule are met. Migration actions are restricted based on user or customer criteria that are specified in the Rule Condition section. Users or customers do not see an option to perform any restricted migration unless they meet the criteria defined in the eligibility rule.
Migration Action ID |
Select a migration action to be unavailable for selection in configuration sessions if the associated eligibility rule is evaluated to true at runtime based on the specified criteria in this rule definition. Only migration actions that are marked as public are available for selection. |
(Define Migration Actions) |
Click to view the definition of the corresponding migration action. |
Attribute Actions
Use this section to select commercial products, their attributes and specific actions that are applied to each of their attributes, if conditions of the corresponding rule are met. The system uses the selected product ID and market to refine the list of attributes that are available for selection.
Hide Attribute |
Select to hide the attributes of the selected product from configuration sessions. |
Disable Attribute |
Select to take away user's ability to add and update attributes of the selected product in configuration sessions. |
Commitment Product Actions
Use this section to specify actions that are allowed on commitment products in configuration sessions.
Product ID |
Enter the identifier of a commitment product to which restrictions apply. Only commitment products are available for selection. |
Cancel penalty |
Select to allow the cancellation of penalties that incur as a result of commitment violation. |
Deny Renew/Extend |
Select to disallow selected commitment product from being renewed or extended, which can potentially mean stopping the execution of a valid commitment triggering rule. |
Shorten Duration |
Select to allow a manual override (in free text) of the predefined duration for the selected commitment product. |
Add/Remove Product |
Select to allow the addition or removal of covered products that are predefined for the selected commitment product. You can select a different set of covered products as permitted by the corresponding commitment covering rule. |
Commitment Duration Options Exclusion
Use this section to manipulate available commitment duration options at runtime by excluding them based on eligibility criteria.
For example, a commitment covering rule for commitment product CMT2 exists in the system and the rule definition specifies 3 possible durations, which are 12, 18, 24 months. A business requirement comes in and recommends that customers using the web channel to place orders should not be allowed to commit for more than 12 months as research shows that many of these commitments turn out to be problematic. To meet this business requirement, you can create an eligibility rule that uses source equals self service as the rule condition, references commitment product CMT2 in this section and select to exclude 18 and 24 months from the list of available duration options. When this eligibility rule is executed at runtime in a configuration session where CMT2 is added, 18 and 24 months are not available as duration options for the self service user.
Product ID |
Select the identifier of a commitment product to which exclusion of duration options applies. Only commitment products are available for selection. |
Duration Option |
Displays the list of duration options that pertain to the selected commitment product. |
Exclude |
Select to remove the corresponding duration option from being available to the selected commitment product as a selectable option. |
See Also
Access the Brings On Creation Rule Definition page (Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules. Select the Brings On Creation rule type on the Multilevel Component Rules search page).
The Severity and Exception Message Text fields are not applicable to the brings on creation rule type because it is not used for validating configuration sessions.
See Common Elements Used in this Section.
Left Hand Side Product
Use this section to select the source product that, upon selection in configuration sessions, causes the addition of products that are specified in the Right Hand Side Products section.
Right Hand Side Products
Use this section to specify the target products to be added to configuration sessions automatically after the source product has been selected (manually or automatically).
Product ID |
Select a target product to be added to the configuration session together with the source target. Only non-top-level multilevel product components (commercial components) are available for selection. |
Scope |
Enter the scope of the right hand side product. Values are Contract, Play, and Direct Parent. Both the left hand side and right hand side products have to be in the same scope in order for the rule to be applied. For example, if the scope selected for the right hand side product is Play, the system adds the right hand side product only if it can find the product in the same play as the left hand side product. |
Single Instance |
Select for the system to check if there is already a new product instance being added to the configuration by another rule execution. A new product instance is automatically added only if there is no new instance of that product being added for the specified scope. |
Note. Brings on creation and brings and removes rules do not allow automatic addition of another products in different contracts.
See Also
Access the Brings and Removes Rule Definition page (Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules. Select the Brings and Removes rule type on the Multilevel Component Rules search page).
The page that is used for setting up brings and removes rules is the pretty much the same as the one for Brings on creation rules, except that the page title is different and the Single Instance field is not applicable to brings and removes rules.
The Severity and Exception Message Text fields are not applicable to the brings and removes rule type because it is not used for validating configuration sessions.
See Setting Up Brings On Creation Rules.
See Also
Access the Commercial Incompatibility Rule Definition page (Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules. Select the Commercial Incompatibility rule type on the Multilevel Component Rules search page).
See Common Elements Used in this Section.
Rule Reference Scope
Reference Scope |
Enter the scope to which the evaluation of this rule applies. The system uses this information to determine which products in a configuration session are to be considered when the conditions of this rule are being evaluated. Values are: Contract (default value): All products selected in the contract are taken into account when rule conditions are being evaluated. Play: Rule conditions are evaluated for each individual play selected in the contract. Conditions are evaluated against products within the same play. For example, if the rule condition requires the selection of products A and B, the condition is met only if both products A and B are selected in the same play. Direct Parent: Rule conditions are evaluated for each individual commercial offer selected in the contract. Conditions are evaluated against products belonging to the same immediate parent. For example, if the rule condition requires the selection of products A and B, the condition is met only if both products A and B have the same immediate parent. |
Left Hand Side Groups
Use this section to define the first set of product selection condition for the rule, which consists of one or more groups of products—components that are used to build the left hand side sentence.
For incompatibility rules, products specified in left hand side groups should be incompatible with products in the right hand side groups.
For prerequisite rules, products specified in right hand side groups should be prerequisites for the products in the right hand side groups.
Add Group |
Click to access the group definition page to create left hand side groups for the corresponding rule. |
Right Hand Side Groups
Use this section to define the final set of product selection condition for the rule, which consists of one or more groups of products—components that are used to build the right hand side sentence.
Add Group |
Click to access the group definition page to create right hand side groups for the corresponding rule. |
Rule Definition
Left Hand Side sentence |
Enter the first set of condition for the rule. The condition should be written in a logical sentence using left hand side group IDs that are created and supported operators (AND and OR). Here is an example of a left hand side sentence: L1 AND L2, which means that if a product configuration satisfies the product selection conditions set in both L1 and L2, additional evaluation of the configuration will be performed based on the right hand side sentence to validate whether the configuration is indeed in violation of the rule. If the condition specified in the left hand side sentence is not satisfied, the system terminates the evaluation for this configuration. |
Right Hand Side sentence |
Enter the final set of condition for the rule, which is used to further evaluate product configurations for violation. It should be written in the same format as the left hand side sentence. A product configuration will be evaluated the second time against the right hand side sentence, if it satisfies the condition of the left hand side sentence. If the condition specified in the right hand side sentence is:
|
See Also
Commercial Incompatibility Rules
Access the Add Group page (click the Add Group link or any group link on the Commercial Incompatibility Rule Definition, Commercial Prerequisite Rule Definition, Functional Incompatibility Rule Definition page, Functional Relies From Rule Definition page, or Functional Relies On Rule Definition page).
Note. The same page screens are used for creating left hand side and right hand side groups that are used in various configuration rules. The page title changes based on the on the rule that is currently being viewed.
Rule Details
Group ID |
Displays a unique, auto-generated ID for the group you just created. Left hand side group IDs use L as the prefix (L1, L2 and so on); R is used for right hand side group IDs. |
Group Type |
Displays the type of product group, which is preset based on the section from which the group is added. Values are Left Hand Side and Right Hand Side. |
Group Name |
Enter a descriptive name for the group. |
Minimum Group Quantity and Maximum Group Quantity |
Enter the minimum and maximum quantities of products (specified in the group) allowed in a configuration session for the group-level condition to be satisfied. In a runtime configuration session, when the conditions (on minimum and maximum quantities) that are set for all products within the groups are satisfied, the next step is to evaluate the configuration to see if it meets the group-level condition, which is set by defining the range of total quantities of products belonging to this group that the configuration must have to pass the group-level evaluation. If the total quantities of products in the configuration session falls below the minimum group quantity or exceeds the maximum group quantity, the group-level condition is not satisfied. The numbers must fall into the 0-999 range. The value of the minimum group quantity must be smaller or equal to the value of the maximum group quantity. Additionally, the minimum group quantity must not exceed the total of minimum quantities that are specified for all products within the group. The same holds true for maximum group quantity. |
Product ID |
Enter a product to be included in the group. Products that are available for selection are non-top-level multilevel product components. |
Status or Product Status |
Select the status that the corresponding product must be in to be taken into account when the rule is being evaluated. Values are: Active New Removed (this value does not apply to the Product Status field) New/Active Note. For the Functional Relies On Rule Definition page, the label of this field becomes Product Status. |
Minimum Quantity and Maximum Quantity |
Enter the minimum and maximum quantities allowed for the corresponding product in a configuration session for the product-level condition to be satisfied. For example, if the minimum and maximum quantities specified for product A in group X are 1 and 3 respectively. In a configuration session where product A is selected, the evaluation of the rule terminates if the selected quantity for product A does not fall into the 1-3 range because the product-level condition set of product A is not satisfied. In other words, the configuration session is not subject to violation of this rule. The value of the minimum quantity must not be greater than the value of the maximum quantity. |
Scope |
Enter the scope in which the corresponding product is expected to be evaluated. Note. This field is specific to right hand side group definitions. The system populates available values based on the reference scope (or covering scope in the case of commitment covering rules) that is selected on the rule definition page. If the selected rule reference scope is: Direct Parent: Available scope values are Direct Parent, Play, and Contract. Play: Available scope values are Play and Contract. Contract: Available scope value is Contract, Other Customer, or Same Customer. Same Customer: Select this value if you want the product to be subject to evaluation only when it belongs to a different contract by the same customer (offer holder). Note. This option is specific to functional and commercial relies on rule definitions. Other Customer: Select this value if you want the product to be subject to evaluation only when it belongs to a different contract by different customers. Note. This option is specific to functional and commercial relies on rule definitions. External Service: Select this value if you want the product to be subject to evaluation only when it belongs to a customer using a third-party communication service provider. Instance: Available scope values are Instance, Direct Parent, Play and Contract. The Instance product scope is specific to commitment covering rules. If this scope is selected for a product within a group, the minimum and maximum quantities of the product must be set to 1. |
Add Product |
Click the button to add another product to the group. |
Access the Commercial Incompatibility between Attribute Values Rule Definition page (Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules. Select the Commercial Attrs. Incompatible rule type on the Multilevel Component Rules search page).
Refer to the Setting Up Functional Incompatibility Rules For Attributes section for descriptions of fields that are shared in these two rule types.
See Setting Up Functional Incompatibility Rules For Attributes.
Commercial Product ID |
Select a commercial product for the rule. This product must be in the same branch as the functional component specified in the Functional Product ID field in order for the rule to be executed. Only commercial components are available for selection. |
Description and Component Type |
Displays the text description and component type of the selected commercial product. |
Access the Commercial Restrictions on Attributes Rule Definition page (Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules. Select the Commercial Attrs. Restriction rule type on the Multilevel Component Rules search page).
See Common Elements Used in this Section.
Restricting Product
Product ID |
Enter a multilevel commercial product, which can be an atomic offer that sells the functional product specified in the Restricted Attributes section. Or, it can be a play or offer to which that atomic offer belongs. |
Restricted Attributes
Use this section to enter the rule constraint condition, which includes at least one functional product-attribute pair with at least one attribute value that, if specified here as required for the commercial product that sells the corresponding functional product in a configuration session, invalidates the configuration. The format of attribute values varies depending on the type of the attribute.
Specify restricted attribute values either by selecting them from a grid with prepopulated values or entering a Java expression.
You can also define value or format restrictions for external service attributes.
Required |
Select to mandate the selection of a value for the corresponding attribute. At runtime, the configuration session becomes invalid if the user doesn’t select a value for the attribute that appears in the session, if that attribute is set as required. In the case where more than one commercial restrictions on attributes rule are executed that impact the same attribute in a configuration session and they have different settings for the Required option (that is, the attribute is required in one rule but is optional in another rule), the rule that references the highest multilevel component type takes precedence. For example, these two rules are executed in a configuration session:
If contract A and play B belong to the same commercial branch, for example, contract A is the parent of play B, rule #1 takes precedence and attribute a is set as optional in the configuration session. |
See Also
Setting Up Functional Incompatibility Rules For Attributes
Commercial Restriction Rules for Attribute Values
Access the Commercial Prerequisite Rule Definition page (Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules. Select the Commercial Prerequisite rule type on the Multilevel Component Rules search page).
Note. The same page screens are used for creating commercial incompatibility rules, commercial prerequisite rules, and functional incompatibility rules. The page title changes based on the on the rule that is currently being viewed. Refer to the Setting Up Commercial Incompatibility Rules section for page descriptions that are shared by these rule types.
See Setting Up Commercial Incompatibility Rules.
See Also
Access the Commercial Relies On Rule Definition page (Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules. Select the Commercial Relies On rule type on the Multilevel Component Rules search page).
See Setting Up Commercial Relies From Rules.
Access the Commercial Relies From Rule Definition page (Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules. Select the Commercial Relies From rule type on the Multilevel Component Rules search page).
Note. The same page screens are used for creating Commercial Relies On rules, Functional Relies On rules, and Functional Relies From rules. The page title changes based on the on the rule that is currently being viewed.
Rule Details
Rule detail fields are common to this section and described in detail in a separate section of this chapter.
See Common Elements Used in this Section.
Left Hand Side Product
Use this section to select the source product that, upon selection in configuration sessions, causes the evaluation of the condition that is specified in the Right Hand Side Products section for possible functional product prerequisite violations.
Similar to commercial prerequisite rules, a product configuration is considered in violation of a functional prerequisite rule if the condition of the left hand side product section is satisfied but the condition of the right hand side statement is NOT.
Product ID |
Select a target product to be added to the configuration session. |
Product Status |
Select a status for the product. Available options are Active, New, and New/Active. |
Description |
Displays a description of the product you selected. |
Rule Right Hand Side Groups
Group ID |
Displays the unique ID for the group you associated with the selected product. |
Group Name |
Displays the name of the group associated with the group ID. You can click the Group Name link to access the Add Group page and modify information for this group. |
Add Group |
Click this link to access the Add Group page and create a new group. |
Rule Definition
Right Hand Side Sentence |
Enter the right hand side sentence you want to use to further evaluate product configurations for a violation. A product configuration is evaluated the second time against the right hand side sentence, when it satisfies the condition of the left hand side sentence. |
Access the Commercial Relies From Related Rules page (Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules. Select the Commercial Relies From rule type on the search page and click the Search button. Select the Related Rules page).
Note. The same page screens are used to view Commercial Relies From related rules, Functional Relies On related rules, and Functional Relies From related rules. The page title changes based on the on the rule that is currently being viewed.
Rule ID |
Displays the ID for the commercial relies on rule in which the product ID that is currently shown on this page is listed as the left hand side product. Similarly, if you are viewing a functional relies from rule, this page displays functional relies on rules in which the product ID currently shown is listed as the left hand side product in these rules. You can click the Rule ID link to access the definition of the rule. |
Add Related Rule |
Click to access the Commercial Relies On Rule Definition page and create a related rule to associate with the primary Commercial Relies From rule. The system sets the product ID currently shown on this page as the left hand side product of the new rule by default. |
Access the Functional Incompatibility Rule Definition page (Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules. Select the Functional Incompatibility rule type on the Multilevel Component Rules search page).
See Common Elements Used in this Section.
Important! The definition for functional incompatibility rules is almost identical to the definition for commercial incompatibility rules, except that when selecting products for left hand side and right hand side groups, you select functional components for functional incompatibility rules. At runtime, a configuration is subject to the evaluation of an active functional incompatibility rule if the configuration contains commercial products that sell the functional products specified in the left hand side groups, and the product selection of the configuration successfully meets the rule execution condition.
See Setting Up Commercial Incompatibility Rules.
See Also
Functional Incompatibility Rules
Access the Functional Attributes Incompatibility page (Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules. Select the Functional Attrs. Incompatible rule type on the Multilevel Component Rules search page).
See Common Elements Used in this Section.
Restricting Attributes
Use this section to specify the rule execution condition.
Product ID |
Enter the ID of a functional product. The system does not limit the selection of attributes based on product ID. |
Market |
Enter the market of the attribute that you want to select. Only markets that are supported by the attributes setup component are available for selection. |
Attribute |
Enter the attribute that must be present in configuration sessions for the corresponding rule to apply. Only edit field and manual drop-down type attributes are available for selection. |
Based on the type of the selected attribute, one of these sections appears:
For manual drop-down type: A grid appears and it lists all the drop-down values that are defined for the attribute. Select the attribute values that configuration sessions must match for this incompatibility rule to apply. If multiple values are selected, a configuration has to match only one of the values for the rule to apply.
For edit field type: A text field called Regular Expression appears, which allows free form text to be entered. Enter a valid Java expression for the system to evaluate attribute values based on the expression.
Restricted Attributes
Use this section to enter the rule constraint condition, which includes a scope, at least one product-attribute pair with at least one attribute value that, if selected in a configuration, invalidate the configuration because the product attribute value is incompatible with the other product attribute value that is selected (specified in the Restricting Attributes section) within the same scope in the configuration. Depending on the type of the attribute, specify attribute values either by selecting them from a grid with prepopulated values or entering a Java expression.
See Also
Functional Incompatibility Rules for Attribute Values
Access the Functional Relies On Rule Definition page (Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules. Select the Functional Relies On rule type on the Multilevel Component Rules search page).
See Setting Up Commercial Relies On Rules.
Access the Functional Relies From Rule Definition page (Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules. Select the Functional Relies From rule type on the Multilevel Component Rules search page).
See Setting Up Commercial Relies From Rules.
Access the Commitment Triggering Rule Definition page (Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules. Select the Commitment Triggering rule type on the Multilevel Component Rules search page).
See Common Elements Used in this Section.
Rule Reference Scope
If you select Instance as the reference scope for the commitment triggering rule, you can only select one product in the Left Hand Side Groups section.
See Common Elements Used in this Section.
Left Hand Side Groups
Use this section to define one or more triggering products, which is one of the three conditions leading to the execution the commitment triggering rule. The other two conditions are reference scope and the left hand side sentence specified in the rule definition.
Group Name |
Click to access the Add Group page to create one or more groups of triggering products. See Defining Left Hand Side and Right Hand Side Groups. Note. If the scope of a product is set to Instance in the Add Group page, both the minimum and maximum quantities must be set to 1. |
Commitment Behaviour
Commitment Behaviour |
Values are: Create: Select for the system to create new commitment products (specified in the Commitment Options section) in the configuration session as a result of the selection of a triggering product, which is specified in the Left Hand Side Group section. You can define one or more of triggering products in the Left Hand Side Group section of a rule definition, and the system uses the value entered for the Left Hand Side sentence field to determine the qualifying triggering product or product combinations for the rule. Extend: Select for the system to check the current configuration session of an existing commitment product (the same that is specified in the Commitment Options section) and extend its duration by the amount that is specified for the extend action in the rule definition. Renew: Select for the system to check the current configuration session of an existing commitment product (the same that is specified in the Commitment Options section) and push out the end date of the product by the amount that is specified for the renew action in the rule definition. Note. Each commitment product is associated with a commitment covering rule and you can specify in the commitment covering rule two sets of duration values, one for the create and renew behaviors and the other for the renew behavior. Depending on the selected behavior (extend or renew) in the commitment triggering rule, the corresponding duration values appear for you to choose a duration when you click the link of the product ID. |
Commitment Options
Commitment is mandatory |
Select to make selecting a commitment product in the configuration session a requirement. If one commitment product is currently selected in this section, the system adds it to the configuration session automatically as a result of the execution of the commitment triggering rule. If multiple commitment products are listed in this section, they become available for selection in the configuration session at runtime and you must select one of them manually. As the configuration gets verified and submitted, a link between the selected commitment product and the triggering product is established and displayed in the order. This field applies to the Create behavior only and is unavailable for edit for other behaviors. |
Product ID |
Click the product ID link to access the Add Commitment Product page where you specify the duration for the commitment product when it is created, renew or extended at runtime. The values that appear in the Duration Options section are specific to the selected commitment behavior. Duration sets are defined for the each individual commitment product in the Commitment Covering Rule Definition component. |
Rule Definition
Left Hand Side sentence |
Enter a logical sentence consisting of at least one left hand side group. An example of a left hand side sentence is L1 AND L2, which means that if a runtime product configuration satisfies the product selection conditions set in both L1 and L2, the system performs the action that is specified in the Commitment Options section. If the condition specified in the left hand side sentence is not satisfied, the system terminates the evaluation for this configuration. This section is not available if the reference scope of the rule definition is Instance, in which you can only select one left hand side product. |
See Commitment Triggering and Covering Rules.
Access the Commitment Covering Rule Definition page (Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules. Select the Commitment Covering rule type on the Multilevel Component Rules search page).
See Common Elements Used in this Section.
Duration (Months)
Use this section to add the list of available durations for the commitment product. These durations appear on the Add Commitment Product page, where you specify the default length of the commitment product in a commitment triggering rule definition. This set of duration options is used when create or renew commitment behavior.
Note. To maintain data integrity, the system doesn't allow you to remove any duration option that is currently selected in an existing commitment triggering rule. A system error appears and you cannot save the change.
Default |
Select to make the corresponding duration option appear as selected by default on the Add Commitment Product page. |
Duration Options |
Enter the length of the duration in number. |
Unit of Measure |
Display the unit of measure that is selected in the Commitment Details section. Values are days, weeks, months and years. |
Add Duration Option |
Click to enter new duration options. |
Duration Extension (Months)
Use this section to define the list of available durations that are used for the extend commitment behavior.
Rule Scope Setting
Covering Scope |
Select the scope within which the covered products must be found by the commitment covering rule in order for the commitment product to be assigned properly. The scope identified here determines the available values of product-level scope when you add groups in the Product Group Details section. |
See Common Elements Used in this Section.
Commitment Activation Option
Select when to install the covered products. Values are:
After One Item is Installed: after the first committed product is installed.
After All Items are Installed: after all committed product are installed.
Product Group Details
Use this section to specify groups of products to be covered by this commitment product. Groups are processed with the AND logical operator.
Group Name |
Click to access the Add Group page to create one or more groups of products that are to be covered by the commitment product. |
See Commitment Triggering and Covering Rules.