This chapter discusses an overview of multilevel product bundles and lists common elements.
Multilevel product bundles are N-level product packages that can be purchased through orders and quotes and serviced through service management orders. From orders, agents configure product bundles in product configuration sessions that are orchestrated by the Advanced Configurator. Within configuration sessions, agents perform a number of actions, such as selecting product components to include in bundles and entering product attributes in new orders, changing service features and modifying attributes for multilevel installed products in service management orders, transferring components from one bundle to another in convergent orders, and so on. The multilevel product bundle framework supports the definition of rules, which are executed during configuration sessions to:
(configuration rule) Perform additional actions to multilevel product bundles, for example, automatically add another product to the bundle because it is a prerequisite of a product currently selected in the bundle.
Configuration rules define actions that are performed during the configuration session when the specified rule conditions are met.
(validation rule) Validate the configuration of multilevel product bundles.
Validation rules define conditions that multilevel product bundles in the configuration session need to meet to consider this configuration valid and complete. Depending on rule severity (error or warning), the configuration status is set to invalid or valid with warning due to validation rule violation.
Only orders with valid product configurations can be submitted for fulfillment. An exception to this rule is when agents resume or suspend multilevel installed products in service management orders, which does not trigger the initiation of configuration sessions.
New features as well as enhancements are developed in various applications and components to support the flexible modeling, ordering and service management of multilevel product bundles. They are categorized into these areas:
Product data model.
Orders, quotes and service management orders.
Installed products.
Advanced Configurator.
Service migration.
Family and tribe offers.
Commitments.
Split billing.
Important! As delivered, the multilevel product bundle feature is enabled for the communications solution. All the data that is needed to support this functionality, such as display templates, product relations codes, capture type information, validation rules and so on, is designed and made available to the communications industry (setID: COM01). Because there is no hardcoded logic that limits this feature only to the communications solution, the use of multilevel product bundles can potentially be extended to other areas in the CRM system with customizations.
Important! The multilevel product bundle feature is not supported in bulk orders, bulk service management orders, temporary services and the Order Capture self service application.
See Also
Understanding Multilevel Product Bundles
Understanding Configuration Rules
To support the modelling of multilevel product bundles:
The Multilevel Component Type component is created and is used to define the blueprints for building hierarchical product packages. In a multilevel component type definition, you specify the different component type levels and sublevels that are allowed in a bundle as well as their properties.
A component type can be commercial or functional. Commercial components are used to build commercial offers. Functional components are used to model functional products or services that are directly related to commercial components, which sell to customers.
The Product Definition component is enhanced to allow for the creation of multilevel product bundles and components. Multilevel bundle components can only be included in multilevel product hierarchies; similarly, multilevel product hierarchies cannot contain non-multilevel product components.
A new framework is built to enable the setup of complex configuration rules for multilevel product bundles. It delivers a set of predefined rule types to support the definition of various configuration constraints for products and product attributes that need to be validated during the ordering and service management processes.
These rules do not apply to non-multilevel product bundles.
New product relationships are delivered for multilevel product bundles. These new relationships are either defined on the Product Relationships component, or are rule-based, which means that the associations between product components are established dynamically, based on configuration rules, during the configuration sessions that occur in ordering and service management processes.
Product relationships, if configured, can be maintained between installed products for service management purposes.
See Also
Setting Up Multilevel Product Bundles
To facilitate the ordering and service management of multilevel product bundles:
A tight integration with the Advanced Configurator is established to allow users build complex and valid multilevel product bundles in orders, quotes and service management orders based on predefined rules.
A new capture type called convergent order is developed to support the ordering of new multilevel product bundles and service management of installed products to occur simultaneously within a single product configuration session.
The order line details section is enhanced to display information that is captured from the configuration session, which includes, but not limited to, attribute values, configuration status, and relationships between products that are selected in the bundle (which are shown in the form of product links).
See Also
Understanding Use of Orders for Multilevel Product Bundles
Creating Orders and Quotes for Multilevel Product Bundles
To support service management for multilevel product bundles, the Installed Products component is enhanced to store and display information of multilevel product bundles (installed for customers) and links that is necessary for entering and processing service requests.
Installed multilevel product bundles are also viewable and searchable for customers on the 360-Degree View.
See Also
Understanding Multilevel Installed Products
PeopleSoft Order Capture integrates with Advanced Configurator to provide streamline product configuration capabilities for multilevel product bundles. Instead of using the current approach for configuring products, which is developing a new model and GUI (graphic user interface) solution for each configurable product package that is available for sale or service management, Advanced Configurator adopts a new mechanism to support multilevel product bundle configurations. Using just one generic model and GUI solution, Advanced Configurator presents configuration sessions, applies constraints on product selections and display, and performs validations on configuration sessions based on applicable configuration and validation rules. With this approach, product catalog is maintained in just one location (in the PeopleSoft system); Advanced Configurator renders any given multilevel product structure based on its product hierarchy that is defined in a PeopleSoft product catalog.
Important! The ordering and service management of multilevel product bundles only works with the integration with Advanced Configurator and is not supported by other configurator applications, such as the Oracle Configurator.
See Also
Understanding Multilevel Product Bundle Integration
Service migration extends the multilevel product bundle functionality by enabling the removal, reparenting, or transformation (replacing one product with another) of multilevel product components (new or installed) within or across product packages using convergent orders.
Supported migration scenarios include:
Transfer of functional components between different commercial offers in a single multilevel product bundle.
Transfer of commercial components between different parents (commercial components) in a single multilevel product bundle.
Transfer of functional components between different commercial offers across different multilevel product bundles, where multilevel product bundles can belong to either the same or different customers.
Transfer of commercial components between different parents (commercial components) across different multilevel product bundles, where multilevel product bundles can belong to either the same or different customers.
Migration actions are used for specifying all the details involved in migrating multilevel product components within or across multilevel product bundles.
See Also
Understanding Product Component Migration
Family and tribe offers are bundle offerings for groups of customers. Individual customers within any given group share resources (for example, shared mobile minutes or shared phone directory) provided by their bundle offer and they sign up for the services as a group at a reduced price. From the communications service provider's perspective, these bundle offers attract customers in groups and lower customers' tendency to churn because of the lowered service fee.
Family and tribe offers are both commercial offers (with different product structures) that are dedicated for group of users. They are ordered by one customer (the offer holder) and can be used by multiple customers (offer members). Offer holder and offer members constitute a group of users that mutually benefit from the offer.
Depending on the offer definition there can be different commercial restrictions specifying the minimum and maximum number of members allowed and which of the member's services can be related to the group offer. Commercial conditions defined for the offer can also restrict maximum number of operations (for example, adding or removing an offer member) that are allowed within a given period of time.
To support family and tribe offers in the multilevel product bundle framework:
The Product Definition component enables the definition of offers that consist of multiple shared services. From the product definition, you can specify the operation counter that can be used for defining various commercial restrictions on group or shared offer operations.
The rule framework allows for the setup of commercial and functional relies on and relies from rules to apply configuration restrictions needed for family and tribe offers.
The Order component captures the information of family and tribe offers from configuration sessions for display on the Entry Form and Line Details pages and for fulfillment purposes. Their configurations are subject to evaluation by applicable validation rules.
Information of installed products for family and tribe offers and their links are displayed in both the Installed Product component and Customer 360-Degree View for user reference.
See Also
Understanding Configuration Rules
The multilevel product bundle framework supports the creation of commitments in the ordering process. A commitment is an agreement between a customer and a communications service provider (CSP), which specifies a period of time during which any of the products and services that it covers cannot be terminated. It is another approach a CSP can adopt to lower customers' propensity to change to a different provider as a violation to an active commitment results in a penalty fee.
Commitments are defined in the CRM system as a type of products. At runtime, a commitment is added by the system to a configuration session if a product that is associated with the commitment in a commitment triggering rule is selected in the session. The selection of a commitment invokes its associated commitment covering rule, which automatically selects other products that the commitment covers as defined in the rule. Upon the submission of the configuration, information of the added commitment, together with the products it covers, is displayed in the order with visual indicators showing the commitment relationship.
See Also
Split billing provides flexibility in defining product billing options and capturing recurring and nonrecurring billing details on orders. The feature supports a number of enhancements, which includes:
The definition of split billing products, which can be billed in any given order by multiple billing accounts.
The selection of billing account to pay for nonrecurring order charges.
The selection of multiple billing accounts for split billing products at the order line level.
The selection of billing account which belongs to a related customer of the Sold To customer to pay for nonrecurring and recurring order charges.
The change of billing accounts for installed products through service management orders.
The display of billing account information in installed products and 360-Degree View.
The display of split billing information of installed product in CRM billing accounts.
See Also
Atomic Offer |
A system-delivered multilevel component type. It:
See Commercial Component |
Bill To Customer |
A customer who is responsible for the nonrecurring or recurring charge to which it is assigned once the order is fulfilled. See Sold To Customer |
Billing Account |
When a CRM account is created for a customer, an asynchronous process sends a message to the billing system (a PeopleSoft system or an external system) to create a billing account. When finished, the billing account number is returned and stored in the CRM system and referred to as the billing account number for that customer. See CRM Account |
Bundling Type |
A group offer property that specifies how group offer members are related to offers in the product definition. Two bundling types are available:
|
Catalog element |
A product element at any level within a multilevel product bundle. It is also referred to as multilevel product component or product component in this documentation. |
Commercial Component |
A commercial component represents a sellable unit in a multilevel product bundle that is used to sell a functional component. A functional component can be linked to and sold by different commercial components. As delivered, the multilevel product bundle framework supports these types of commercial components:
|
Commercial Offer |
A synonym of the term Atomic Offer. See Atomic Offer |
Commitment Contract |
A CRM component that displays commitment-related information such as its start and end dates, duration, and the list of products that it covers. A commitment contract is created after an order (which includes a commitment product) is set to completed. |
Commitment Product |
A type of product definition that represents sellable commitments. Commitment products are added to configuration sessions automatically upon the selection of products that are specified in commitment triggering rules. Upon the selection of commitment products in configuration sessions, the products that they cover, as identified in commitment covering rules, are added to the sessions automatically. |
Commits link |
A product link that is created in configuration sessions between an installed product and an installed commitment indicating the existence of an active commitment a customer has installed as a trade-off for bonus products or services. |
Complex Group Offer |
A group offer that sells multiple shared services, which can be:
|
Configuration Rule |
A type of rule that defines additional actions (for example, automatic selection of another product) that are performed during the configuration of multilevel product bundles if the rule conditions are met. |
Configured Product |
A product package that is configured using supported configurator products: PeopleSoft Advanced Configurator or PeopleSoft Sales Configurator. Multilevel product bundles are configured products that are configurable using PeopleSoft Advanced Configurator. |
Contract |
A system-delivered multilevel component type. It is:
In this documentation, terms top-level multilevel product component, top-level component and contract are used interchangeably. |
Controller |
An application in the PeopleSoft Advanced Configurator that functions as the configuration manager. At a high level, it:
|
Convergent Order |
A type of order that is used to capture new orders and service management orders for multilevel product bundles and validate product configurations in a single session. Upon order submission, a convergent order is either converted to a service management (SM) or a simple (SO) order, or child orders are generated for it to be fulfilled. |
CRM Account |
It is a billing account representation that is created in PeopleSoft CRM. See Billing Account. |
Current Element |
A product or service with a sale start date that is earlier than or equal to the product selling date on the order and a sale end date in the future. This element is currently available for sale. |
Default Trial Period Duration |
Same as the minimum trial period duration. The system defaults the minimum trial period duration for any new order in the Trial Duration field based on the channel and sub-channel selected. The customer service representative (CSR) can increase the value but cannot decrease it below the defined trial duration for the specified source and sub-source on the order. |
External Component |
See External Service |
External Group Offer Member |
A member of a group offer that has a service provided by another communication service provider. |
External Service |
A product definition that represents a service offered by a third-party service provider. It is primarily referenced in commercial relies on and functional relies on configuration rule definitions to specify configuration constraints for external services, which might be members of group offers. It can also be referenced in commercial restriction on attribute values rule definitions. External services are not referenced in multilevel product bundles as package components like commercial components, and they are not tracked as installed products. |
Family Offer |
A group offer in which all members benefits from a single pool (for example, a common pool of free minutes for all offer members to be used when calling other group members). |
Functional Component |
A functional component represents a service (a non-tangible product) or a product (a physical good) as perceived by the customer. Functional components are not sellable units; they are configured and sold through one or more commercial offers. The Sells product relationship is used to bind a commercial atomic offer with functional component it sells. After order fulfillment, the Sells installed link is created to store the link information between the installed product for the commercial component and the installed product for the functional component. |
Future Element |
A product or service with its sale start and end dates in the future with reference to the product selling date on the order. This element can be configured currently but is only available for sale in the future. |
Global Cardinality |
See Maximum Group Quantity, Minimum Group Quantity, and Local Cardinality |
Group Offer |
A commercial offer which is dedicated for a group of users. A group offer is ordered by one customer (the offer holder) and may be associated with other customers (offer members). The offer holder and offer members form a group of users who mutually benefit from the offer. Family offers and tribe offers are both types of group offers; they are different in terms of how the resources of the offer are shared between members of the offer. See Family Offer and Tribe Offer |
Group Offer Holder |
The customer who owns the group offer. |
Group Offer Member |
The customer who doesn't own the offer, but is associated with the group offer and uses offer resources. |
Installed Contract |
An installed product that is created for a fulfilled multilevel product bundle (also referred to as contract). |
Installed Link |
A product link between two related installed products or services. For example, if a commercial component is related to a functional component through the Sells relation, a Sells installed link is created for the installed products (created for the commercial and functional components) after the fulfillment of the order. |
Lightly Configured Package |
A product packages that is configured using the Lightly Configurator. |
Local Cardinality |
See Maximum Quantity, Minimum Quantity, and Global Cardinality |
Maximum Group Quantity and Minimum Group Quantity |
Minimum group quantity and maximum group quantity are used in rule definitions to specify the minimum and maximum numbers of products (specified within the current group) allowed in an order for the corresponding group definition (either for left hand side or right hand side) to be evaluated to TRUE. Suppose that a rule definition has this left hand side group definition:
This group-level condition of the left hand side (LHS) group is evaluated to TRUE for an order if the total count of Product A, Product B, Product C selected in the order is greater than 1 and smaller than 11. These fields are used in several rule types, including:
These group-level quantities are evaluated independently for each group for every rule instance that is invoked. |
Maximum Quantity and Minimum Quantity |
Minimum quantity and maximum quantity are used in rule definitions to specify the minimum and maximum numbers of any given product allowed in an order for the corresponding product-level condition within a group definition to be evaluated to TRUE. Suppose that a rule definition has these products selected for a left hand side group definition:
This product-level condition of the left hand side group is evaluated to TRUE for an order if all of the following requirements are met:
These fields are used in several rule types, including:
These product-level quantities are evaluated independently for each product component for each rule instance that is invoked (that is, different rule instances might specify different local cardinalities for the same component). |
Minimum Trial Period Duration |
This duration is the minimum trial period duration, in days, that must be allowed legally, while placing an order through different channels. |
Migration |
Refers to the execution of actions in configuration sessions that result in the removal of product components, reparenting of product components or a change of product offers (removal of a product component and addition of another product component in its place). |
Migration Action |
A definition in the system that specifies all the details involved in migrating one or more multilevel product components within or across contracts. In this definition, you identify:
When the migration request is submitted in the configuration session, the information of the operation is sent back to the convergent order for display. For example, if you look at the line details of a source atomic offer that is being transformed to a new component in the target product hierarchy, you can see that its Child Of link and Sells link are set to be removed, and a migration link to the new target component is set to be created. And if you look at the line details of the target component, you see that new Child Of, Sells and Migration links are set to be created when the order is completed. |
Multi-branching |
A feature that allows the same commercial component (that is, the same offer) to be placed under more than one branch of a single contract. Multi-branching is not supported for multilevel product bundles. |
Multilevel Component Type |
Represents the role of a product component in the multilevel product bundle structure. System-delivered multilevel component types are:
|
Multilevel Installed Product |
Refers to multilevel product bundle instances that are purchased and installed. They are called multilevel installed products generically in this documentation and they can contain both installed products and installed services. |
Multilevel Product Component |
A product definition that is a part of a multilevel product bundle structure and is assigned with one of the multilevel component types. |
Non-tangible product |
A product definition of type service that is delivered to customers. |
Offer |
A system-delivered multilevel component type. It:
|
Order Completion Date |
Refers to the date when all the order lines are processed completely. The services may or may not be activated by the order completion date. See Trial Period Start Date and Trial Period End Date |
Past Element |
A product or service with sale start and end dates in the past with reference to the product selling date on the order. This element is not available for sale. |
Play |
A system-delivered multilevel component type. It:
|
Product Link |
An object that relates two product instances together. The multilevel product bundle feature supports a number of product links, such as relies on, child of, brings and removes, committed, migration, and brings on creation. Links have different behavior and meanings depending on the type as well as the perspective (source product or target product) from which the linkage is being viewed. For example:
Depending on the nature of product links, they can be established between two installed products (for example, relies on and sells links) for service management purposes, though some only persist in the ordering process (for example, the brings on creation link) and unavailable for installed products. |
Product Selling Date |
The date on an order that is used by the system:
|
Relies On link |
A product link that is created in a configuration session between two functional components to establish functional dependence between them (that is, target product is a functional prerequisite of the source product). A Relies On link is used to enable the validation of Relies On rules (Relies On rule validation checks if a required Relies On link has been established between functional components) and is stored as an installed link after order fulfillment is completed. |
Reparenting |
Changing the parent of a commercial component. Reparenting results in the disconnection of the Child of link to the old commercial parent and creation of a new Child of link to the new commercial parent without disconnecting the services. |
Rule Product Group |
Rule product group is used in rule definitions to specify groups of products and conditions for these products at the product level and at the group level. Examples of conditions defined at the product level are:
Products can be accounted to the group only if all conditions defined at the product level are met. Examples of conditions defined at the group level are the minimum and maximum group quantities (that is, total count of components belonging to the group). During the evaluation of rule conditions, each condition is assessed and resolved to either TRUE or FALSE. Group condition is resolved to TRUE only if all conditions defined at the product level within that group and conditions defined at the group level are met. Rule group are used in these rule types:
|
Rule Product Status |
A rule product status is used to enable a more precise definition of rule conditions by specifying the status that products should be in for the product-level condition to be evaluated to TRUE. System-delivered rule product statuses are:
Rule product status that is used for rule evaluations is dependent not only on the installed product status, but also on the action selected on the product in the configuration session. For example, if the product statuses of a left hand side rule condition are:
The left hand side rule condition is evaluated to TRUE only if all of the these product-level conditions are met:
|
Rule Reference Scope |
Rule reference scope is used to specify the left hand side context for rule execution. It is relevant only when the left hand side rule condition enables more than one product. Rule reference scope applies to these rule types:
Available rule reference scopes are:
Here is an example. Suppose that the rule reference scope is defined as play and the left hand side rule condition sentence is defined as Product A AND Product B. In this scenario, the left hand side rule condition is evaluated to TRUE and the rule is executed only if products A and B are found under the same play; the rule is not executed if these products are found under the same contract but under different plays. |
Rule Scope |
Rule scope is used to specify the right hand side context for rule execution; it is defined for each product used in the right hand side condition for these rule types:
Available rule scopes are:
Rule scope has to be equal to or wider than the rule reference scope. In other words, if the rule reference scope is defined as Play, then the rule scope has to take one of these values: Play, or Contract. Here is an example. Suppose that the rule reference scope is defined as Play and the right hand side condition is defined as Play for Product A, then:
|
Selling End Date |
The last date a catalog element can be sold. |
Sales Period |
The time period in which a catalog element is available for sale. |
Selling Start Date |
The date from which a catalog element can be sold. |
Selling Period |
The duration during which a product or service is available for sale. The selling period of a product package is defined by the Start Date and the End Date fields on the Package Components page, whereas the selling period of a product component within a package is defined by the Effective Date and Obsolete Date fields on the Package Components page. A product is said to have a valid selling period if the current date falls within its selling period, or if its selling period is some time in the future. |
Sells link |
A product link that is created in configuration sessions between a commercial product component and a functional product component which was sold by this commercial product component. The functional component that is sold by the commercial component is automatically selected in the configuration based on the Sells product relationship. One atomic offer is linked to one functional component, and one functional component can be linked (therefore sold) by multiple atomic offers. The Sells link is stored as an installed link after the order fulfillment is completed. |
Simple Group Offer |
A group offer selling a single shared service that is shared among all group offer members. |
Sold To Customer |
A customer who becomes the owner of the order line product once the order is fulfilled. See Bill To Customer |
Split Billing Product |
A product that can be paid by multiple billing accounts. |
Source Contract |
A contract from which a product component is migrated. The same contract can serve as both the source and the target contracts if the migration takes place within a single contract. |
Tangible product |
Is a product that has a physical representation as opposed to non-tangible products, which are services. |
Target Contract |
A contract to which a product component is migrated. The migrated product component becomes part of the target contract after the completion of the transfer, or migration. The same contract can serve as both the source and the target contracts if the migration takes place within a single contract. |
Top-level Component |
The first-level parent component in a multilevel product bundle that does not have a parent. A multilevel product hierarchy or structure always starts with a commercial component in a multilevel component type that is marked as top level. |
Transferring component |
Transferring of a commercial component means disconnecting the Child Of relationship with the old parent of the commercial component and creating a new one with the new parent. Sometimes, a component can be transferred within the same contract or to another contract and it still has the same parent. An example is the reparenting of a commercial offer to another play in the same contract, and this offer contains atomic offers. In this case, atomic offers are transferred to the new play with their parent, and their Child Of product links to the current parent remains intact. Transferring of a functional component means disconnecting the Sells relationship or installed link with the old commercial offer and creating a new one with the new commercial offer. |
Trial Period End Date |
Trial Period End Date = Order Completion Date + Trial Duration specified in the order. |
Trial Period Start Date |
Trial Period Start Date = Order Completion Date |
Tribe Offer |
A group offer in which each member benefits from individual pool of resource (for example, each member have a separate pool of free minutes to be used when making calls to other group members). See Bundling Type |
Validation Rule |
A rule with conditions that multilevel product bundle configurations triggering it must meet in order for the configurations to be considered valid and complete. Depending on the specified rule severity, if a configuration is in violation of a validation rule, its configuration status is set to Invalid or Valid with Warnings. |