Understanding Multilevel Product Bundles

This chapter discusses an overview of multilevel product bundles and lists common elements.

Click to jump to parent topicMultilevel Product Bundles

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:

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:

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.

The multilevel product bundle feature is not supported in temporary services and the Order Capture self service application.

See Also

Understanding Multilevel Product Bundles

Understanding Configuration Rules

Click to jump to top of pageClick to jump to parent topicProduct Data Model

To support the modelling of multilevel product bundles:

See Also

Setting Up Multilevel Product Bundles

Click to jump to top of pageClick to jump to parent topicOrders, Quotes and Service Management Orders

To facilitate the ordering and service management of multilevel product bundles:

See Also

Understanding Use of Orders for Multilevel Product Bundles

Creating Orders and Quotes for Multilevel Product Bundles

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

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

Click to jump to top of pageClick to jump to parent topicAdvanced Configurator

PeopleSoft Enterprise 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

Click to jump to top of pageClick to jump to parent topicService Migration

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:

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

Click to jump to top of pageClick to jump to parent topicFamily and Tribe Offers

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:

See Also

Understanding Configuration Rules

Understanding Group Offers

Click to jump to top of pageClick to jump to parent topicCommitments

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

Understanding Commitments

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

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:

See Also

Understanding Split Billing

Click to jump to parent topicCommon Terms Used in This Part

Atomic Offer

A system-delivered multilevel component type. It:

  • Is defined as a commercial component in the product definition.

  • Is the sellable view of a single product or service.

  • Is the lowest-level commercial component in a multilevel product bundle hierarchy and is linked to a functional component it sells through the Sells relationship.

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:

  • Individual – all members are linked to a single instance of the shared service that is sold by the group offer.

  • Dedicated – each member is linked to a separate, dedicated instance of the shared service that is sold by the group offer.

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:

  • Contract: Top-level commercial component in a multilevel product bundle hierarchy. Descendants include plays, offers, and atomic offers.

  • Play: Immediate descendant of the contract. It is the second level commercial component in a multilevel product bundle hierarchy and represents a line of business (for example, broadband internet, voice, or cable TV). Descendants include offers and atomic offers.

  • Offer: Immediate descendant of plays. It is the third level commercial component in a multilevel product bundle hierarchy and an offer can have other offers and atomic offers as its descendants.

  • Atomic Offer: Immediate descendant of offers. It is the lowest level commercial component in a multilevel product bundle hierarchy and is linked to a functional component that it sells.

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:

  • Multiple shared services of the same type (for example, each member receives a separate pool of resources and is linked with a separate instance of a shared service).

  • Multiple different shared services (for example, shared minutes and shared SMS are bundled into a one group offer and sold as a package).

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:

  • A top-level commercial component in a multilevel product bundle hierarchy.

  • Used for grouping plays, offers and atomic offers.

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:

  • Accepts configuration requests from orders.

  • Initializes configuration sessions (for example, restoring data from installed products, restoring configurations that are stored in orders, and retrieving eligibility criteria for sessions.

  • Initializes validations in PeopleSoft Advanced Configurator.

  • Provides product catalog configuration to the GUI solution in PeopleSoft Advanced Configurator.

  • Processes configuration actions.

  • Executes validation rules in PeopleSoft Advanced Configurator.

  • Submits configuration operations to orders.

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:

  • Products selected for this group: Product A, Product B and Product C

  • Minimum group quantity: 2

  • Maximum group quantity: 10

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:

  • Commercial Prerequisite

  • Commercial Incompatibility

  • Commercial Relies From

  • Commercial Relies On

  • Functional Relies From

  • Functional Relies On

  • Functional Incompatibility

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:

  • Product A; maximum quantity = 2 and minimum quantity =1

  • Product B; maximum quantity = 4 and minimum quantity =3

  • Product C; maximum quantity = 6 and minimum quantity =4

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:

  1. Total count of Product A in the order is greater than 0 and smaller than 3.

  2. Total count of Product B in the order is greater than 2 and smaller than 5.

  3. Total count of Product C in the order is greater than 3 and smaller than 7.

These fields are used in several rule types, including:

  • Commercial Prerequisite

  • Commercial Incompatibility

  • Commercial Relies From

  • Commercial Relies On

  • Functional Relies From

  • Functional Relies On

  • Functional Incompatibility

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:

  • Source product from which the migration occurs.

  • Target product to which the migration occurs.

  • Context within which the source component must be present in order for the migration action to be applicable. The context can be specific contracts or any contract in the system.

  • Context within which the target component resides as a result of the migration. The context can be specific contracts or any contract in the system.

  • (optional) Other migration actions to be included, if applicable.

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:

  • Contract

  • Play

  • Offer

  • Atomic Offer

  • Functional Component

  • External Service

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:

  • Is defined as a commercial component in the product definition.

  • Is used for grouping atomic offers.

  • Is used for grouping other offers into manageable commercial, functional or display categories.

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:

  • Is defined as a commercial component in the product definition.

  • Is used for grouping offers and atomic offers.

  • Represents a line of business or primary access.

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:

  • Relies on: used to bind two products that are functionally dependent. Target product is a functional prerequisite for source product. This link is used to enable validation of relies on rules in configuration sessions.

  • Brings and removes: used to bind two products when the target product is automatically added to the configuration due to the selection of the source product and the subsequent execution of a brings and removes rule that involves these two products.

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:

  • As reference for executing all rules that are associated with multilevel product bundles on that order.

  • To determine the availability of products (for ordering) based on selling periods.

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:

  • Rule product status

  • Minimum and maximum quantities for product

  • Product scope (rule scope)

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:

  • Commercial Prerequisite

  • Commercial Incompatibility

  • Commercial Relies From

  • Commercial Relies On

  • Functional Relies On

  • Functional Relies From

  • Functional Incompatibility

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:

  • New

  • Active

  • New/Active (New or Active)

  • Removed

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:

  • Product A (New)

  • Product B (Active)

  • Product C (New/Active)

  • Product D (Removed)

The left hand side rule condition is evaluated to TRUE only if all of the these product-level conditions are met:

  • Product A is not yet installed and has been selected in the configuration session to be added.

  • Product B is in an installed product and exists in the current product configuration.

  • Product C is either not installed yet (but has been selected in the configuration session to be added), or is already installed (and not in the process of being removed from the current configuration).

  • Product D is already installed and has been selected in the configuration session to be removed.

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:

  • Commercial Prerequisite

  • Commercial Incompatibility

  • Functional Incompatibility

  • Commitment Triggering

Available rule reference scopes are:

  • Direct Parent

    Direct parent becomes the default value if no other value is specified.

  • Play

  • Contract

  • Instance

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:

  • Brings On Creation

  • Brings and Removes

  • Commercial Prerequisite

  • Commercial Incompatibility

  • Commercial Relies From

  • Commercial Relies On

  • Functional Incompatibility

  • Functional Relies From

  • Functional Relies On

  • Functional Incompatibility between Attribute Values

Available rule scopes are:

  • Direct Parent

  • Play

  • Contract

  • Same Customer

  • Other Customer

  • External Service

    This value appears if the corresponding product is an external service.

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:

  • The right hand side rule condition is evaluated to TRUE only if Product A is found under the same play where the left hand side rule condition has been evaluated to TRUE.

  • The right hand side rule condition is evaluated FALSE if Product A is found under the same contract but under a different play than the one where the left hand side rule condition has been evaluated to TRUE.

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.