Setting Up Multilevel Product Bundles

This chapter provides overviews of multilevel product bundles, configuration rules, and discusses how to:

Click to jump to parent topicUnderstanding Multilevel Product Bundles

This section discusses:

Click to jump to top of pageClick to jump to parent topicProduct Relationships for Multilevel Product Bundles

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:

See Also

Setting Up Product Relationship Codes

Click to jump to top of pageClick to jump to parent topicMultilevel Product Bundle Modeling

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:

  1. Create all functional components needed for the bundle using the Product Definition component.

    See Setting Up Product Components.

  2. Create all atomic offers (lowest level commercial components) needed for the bundle using the Product Definition component.

    See Setting Up Product Components.

  3. Create the Sells relationship between atomic offers and appropriate functional components using the Product Relationships component.

    See Managing Product Relationships.

  4. Create other higher level commercial components (for example, contract, plays, and offers) needed for the bundle using the Product Definition component.

    See Setting Up Product Components.

  5. Build the multilevel product bundle by associating all commercial components in a hierarchical fashion using the Package Components page.

    See Setting Up Multilevel Product Packages.

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

Click to jump to top of pageClick to jump to parent topicExport of Multilevel Product Bundle, Rule and Migration Action Definitions

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:

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:

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.

Click to jump to top of pageClick to jump to parent topicCommitment Products

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:

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.

Click to jump to top of pageClick to jump to parent topicSplit Billing Products

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

Setting Up Product Components

Understanding Split Billing

Click to jump to parent topicUnderstanding Configuration Rules

This section discusses:

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.

Click to jump to top of pageClick to jump to parent topicCommercial Eligibility Rules

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:

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:

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:

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:

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:

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:

See Also

Setting Up Commercial Eligibility Rules

Click to jump to top of pageClick to jump to parent topicBrings On Creation 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:

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

Click to jump to top of pageClick to jump to parent topicBrings and Removes 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:

See Also

Setting Up Brings and Removes Rules

Click to jump to top of pageClick to jump to parent topicCommercial Incompatibility 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:

Elements of Rule and Validation Result

The Commercial Incompatibility Rule is comprised of the following elements:

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:

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:

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

Click to jump to top of pageClick to jump to parent topicCommercial Incompatibility Rules for Attribute Values

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:

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.

Click to jump to top of pageClick to jump to parent topicCommercial Restriction Rules for Attribute Values

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:

Elements of Rule and Validation Result

The Commercial Restrictions on Attributes rule is comprised of the following elements:

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:

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

Click to jump to top of pageClick to jump to parent topicCommercial Prerequisite Rules

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:

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:

The Commercial Prerequisite Rule is invalid when the Left Hand Side is equal to true and the Right Hand Side is equal to false.

Click to jump to top of pageClick to jump to parent topicCommercial Relies On Rule

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:

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:

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:

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 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:

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

Functional Relies On Rules

Click to jump to top of pageClick to jump to parent topicCommercial Relies From Rules

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.

Click to jump to top of pageClick to jump to parent topicFunctional Incompatibility 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:

Elements of Rule and Validation Result

The Functional Incompatibility Rule is comprised of the following elements:

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:

See Also

Setting Up Functional Incompatibility Rules

Click to jump to top of pageClick to jump to parent topicFunctional Incompatibility Rules for Attribute Values

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:

See Functional Incompatibility Rules.

Elements of Rule and Validation Result

The Functional Incompatibility Rules for Attribute Value is comprised of the following elements:

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

Click to jump to top of pageClick to jump to parent topicFunctional Relies On Rules

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:

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:

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:

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

Commercial Relies On Rule

Click to jump to top of pageClick to jump to parent topicFunctional Relies From 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 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

Commercial Relies From Rules

Click to jump to top of pageClick to jump to parent topicCommitment Triggering and Covering 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:

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

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:

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:

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:

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:

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:

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

Click to jump to parent topicSetting Up Multilevel Product Bundles

This section discusses how to:

Click to jump to top of pageClick to jump to parent topicPages Used to Set Up Multilevel Product Bundles

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.

Click to jump to top of pageClick to jump to parent topicSetting Up Product Relations Codes

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

Click to jump to top of pageClick to jump to parent topicSetting Up Product Relationships

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

Click to jump to top of pageClick to jump to parent topicSetting Up Product Components

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.

Operations Count value will be not displayed in the order, however its value will be stored in order lines to enable future extension of this feature.

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

Defining Product Information

Click to jump to top of pageClick to jump to parent topicUpdating Obsolete Dates for Multilevel Product Components

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.

Click to jump to top of pageClick to jump to parent topicSetting Up Multilevel Product Packages

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:

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:

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

  • Quantities selected for X, Y and Z are within component quantity limit.

  • Sum of all component quantities (5) is within the group quantity limit (4-8).

5 of Y, 3 of Z

Valid

  • Quantities selected for Y and Z are within component quantity limit.

  • It is okay not to select X in the package because X is an optional component (minimum quantity is 0).

  • Sum of all component quantities (8) is within the group quantity limit (4-8).

10 of X

Invalid

  • Quantity selected for X (10) exceeds the component quantity limit (0-1).

  • Configuration should include Y and Z, which are required components (minimum quantities are 3 and 1 respectively).

  • Sum of all component quantities (10) exceeds the group quantity limit (4-8).

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

Defining Product Packages

Click to jump to parent topicSetting Up Migration Actions

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:

Refer to the see reference for an overview of migration actions.

See Understanding Migration Actions.

Click to jump to top of pageClick to jump to parent topicPages Used to Set Up Migration Actions

Page Name

Definition Name

Navigation

Usage

Migration Action

RB_MIG_ACT_DFN_PG

Set Up CRM, Product Related, Advanced Configurator, Define Migration Action, Migration Action

Define basic information of migration actions.

Migration Mapping

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.

View Target Hierarchy

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.

Related Objects

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.

Click to jump to top of pageClick to jump to parent topicDefining Migration Actions

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:

  • Are not exported to Advanced Configurator and are not viewable in configuration sessions.

  • Can be used by other migration actions as part of their migration scripts.

  • Are unavailable for reference in eligibility rule definitions.

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.

Click to jump to top of pageClick to jump to parent topicEstablishing Source and Target Product Migration Mappings

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:

  • The source product of the migration action is the same as the corresponding source product component in the Mapping section.

  • The status is set to active.

  • Context settings are identical.

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:

  • The same product ID as the source component if the option setting is Reparenting.

  • A blank value if the option setting is Remove.

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

See Viewing Target Product 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.

Click to jump to top of pageClick to jump to parent topicViewing Target Product Hierarchy

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:

Click to jump to top of pageClick to jump to parent topicViewing Related Eligibility Rules

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.

Click to jump to parent topicSetting Up Configuration Rules for Multilevel Product Bundles

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:

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.

Click to jump to top of pageClick to jump to parent topicCommon Elements Used in this Section

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.

Click to jump to top of pageClick to jump to parent topicPages Used to Set Up Configuration Rules for Multilevel Product Bundles

Page Name

Definition Name

Navigation

Usage

Eligibility Rule Definition

RB_RULE_INCO_PRE

Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules

Select the Commercial Eligibility rule type on the Multilevel Component Rules search page.

Create new or view existing commercial eligibility rules.

Brings On Creation Rule Definition

RB_RULE_BRN

Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules

Select the Brings On Creation rule type on the Multilevel Component Rules search page.

Create new or view existing brings on creation rules.

Brings and Removes Rule Definition

RB_RULE_BRN

Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules

Select the Brings and Removes rule type on the Multilevel Component Rules search page.

Create new or view existing brings and removes rules.

Commercial Incompatibility Rule Definition

RB_RULE_INCO_PRE

Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules

Select the Commercial Incompatibility rule type on the Multilevel Component Rules search page.

Create new or view existing commercial incompatibility rules.

Commercial Prerequisite Rule Definition

RB_RULE_INCO_PRE

Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules

Select the Commercial Prerequisite rule type on the Multilevel Component Rules search page.

Create new or view existing commercial prerequisite rules.

Commercial Relies From Rule Definition

RB_RULE_CRF

Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules

Select the Commercial Relies From rule type on the Multilevel Component Rules search page.

Create new or view existing commercial relies from rules.

Commercial Relies On Rule Definition

RB_RULE_FRO_SS

Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules

Select the Commercial Relies On rule type on the Multilevel Component Rules search page.

Create new or view existing commercial relies on rules for group offers.

Related Rules

RB_RL_REL_RULES

Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules

Select the Commercial Relies On, Commercial Relies From, Functional Relies On, or Functional Relies From rule type on the Multilevel Component Rules search page and click the Search button.

Select the Related Rules page.

View summary information for rules associated with the primary multilevel component rule.

Functional Incompatibility Rule Definition

RB_RULE_INCO_PRE

Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules

Select the Functional Incompatibility rule type on the Multilevel Component Rules search page.

Create new or view existing functional incompatibility rules.

Functional Relies from Rule Definition

RB_RULE_FRF

Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules

Select the Functional Relies From rule type on the Multilevel Component Rules search page.

Create new or view existing functional relies from rules.

Functional Relies On Rule Definition

RB_RULE_FRO_SS

Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules

Select the Functional Relies On rule type on the Multilevel Component Rules search page.

Create new or view existing functional relies on rules.

Functional Attributes Incompatibility

RB_RULE_FUNC_ATTR

Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules

Select the Functional Attrs. Incompatible rule type on the Multilevel Component Rules search page.

Create new or view existing functional incompatibility rules for attribute values.

Commercial Restrictions on Attributes Rule Definition

RB_RULE_COMM_ATTR

Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules

Select the Commercial Attrs. Restriction rule type on the Multilevel Component Rules search page.

Create new or view existing commercial restriction rules for attribute values.

Commercial Incompatibility between Attribute Values Rule Definition

RB_RL_COM_INC_ATTR

Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules

Select the Commercial Attrs. Incompatible rule type on the Multilevel Component Rules search page.

Create new or view existing commercial incompatibility rules for attribute values.

Commitment Triggering Rule Definition

RB_RULE_COMM_TRG

Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules

Select the Commitment Triggering rule type on the Multilevel Component Rules search page.

Create new or view existing commitment triggering rules.

Commitment Covering Rule Definition

RB_RULE_COMM_CVR

Set Up CRM, Product Related, Advanced Configurator, Multilevel Component Rules

Select the Commitment Covering rule type on the Multilevel Component Rules search page.

Create new or view existing commitment covering rules.

Add Group

RB_RULE_GRP

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.

Define left hand side and right hand side groups.

Click to jump to top of pageClick to jump to parent topicSetting Up Commercial Eligibility Rules

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

Commercial Eligibility Rules

Click to jump to top of pageClick to jump to parent topicSetting Up Brings On Creation Rules

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

Brings On Creation Rules

Click to jump to top of pageClick to jump to parent topicSetting Up Brings and Removes Rules

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

Brings and Removes Rules

Click to jump to top of pageClick to jump to parent topicSetting Up Commercial Incompatibility Rules

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.

See Defining Left Hand Side and Right Hand Side Groups.

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.

See Defining Left Hand Side and Right Hand Side Groups.

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:

  • Satisfied: the configuration is considered in violation of the rule if it is an incompatibility rule, and the configuration status is then set to Invalid or Valid with warnings based on the severity that is set for the rule.

    The system terminates the evaluation for this configuration if it is a prerequisite rule.

  • Not satisfied: the configuration is considered in violation of the rule if it is a prerequisite rule.

    The system terminates the evaluation for this configuration if it is an incompatibility rule.

See Also

Commercial Incompatibility Rules

Click to jump to top of pageClick to jump to parent topicDefining Left Hand Side and Right Hand Side Groups

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.

Click to jump to top of pageClick to jump to parent topicSetting Up Commercial Incompatibility Rules for Attributes

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.

Click to jump to top of pageClick to jump to parent topicSetting Up Commercial Restriction Rules for Attributes

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:

  • Commercial restrictions on attribute rule #1 references contract A, and the referenced attribute a is not set as required.

  • Commercial restrictions on attribute rule #2 references play B, and the referenced attribute a is set as required.

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

Click to jump to top of pageClick to jump to parent topicSetting Up Commercial Prerequisite Rules

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

Commercial Prerequisite Rules

Click to jump to top of pageClick to jump to parent topicSetting Up Commercial Relies On Rules

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.

Click to jump to top of pageClick to jump to parent topicSetting 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.

See Defining Left Hand Side and Right Hand Side Groups.

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.

Click to jump to top of pageClick to jump to parent topicReviewing Related Rules

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.

Click to jump to top of pageClick to jump to parent topicSetting Up Functional Incompatibility Rules

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

Click to jump to top of pageClick to jump to parent topicSetting Up Functional Incompatibility Rules For Attributes

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:

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

Click to jump to top of pageClick to jump to parent topicSetting Up Functional Relies On Rules

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.

Click to jump to top of pageClick to jump to parent topicSetting Up Functional Relies From 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.

Click to jump to top of pageClick to jump to parent topicSetting Up Commitment Triggering 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.

Click to jump to top of pageClick to jump to parent topicSetting Up Commitment 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 Defining Left Hand Side and Right Hand Side Groups.

See Commitment Triggering and Covering Rules.