Working with Orders for Multilevel Product Bundles

This chapter provides overviews of the use of orders for multilevel product bundles, group offers, product component migration, split billing, commitments, trial periods, selling periods for multilevel product bundles and components and discusses how to:

Note. The Order Capture application supports the creation of orders, quotes, and service management orders for multilevel product bundles.

Click to jump to parent topicUnderstanding Use of Orders for Multilevel Product Bundles

This section discusses:

Click to jump to top of pageClick to jump to parent topicUnderstanding Convergent Orders

Convergent Order is a capture type that allows new orders for multilevel product bundles and service requests for multilevel installed services to be captured in one single order. In a convergent order, product configuration and validation for multilevel product bundles and installed services is performed within the same configuration session. Similar to simple orders, convergent orders capture data (besides product details) that is necessary for order fulfillment, such as billing (nonrecurring and recurring), shipping, and installation site information.

Upon submission, based on the line items and actions currently selected, the convergent order is either converted to a simple order (if convergent order contains only one new multilevel product bundle), a service management order (if convergent order contains only one multilevel installed product), or it generates child regular and service management orders (if convergent order contains a mix of new and installed products) for order fulfillment. In the case of child order generation, child orders of the convergent order are synchronized for fulfillment if there are order line relationships (for example, the brings and removes relationship) that span across multiple child orders. Billing, shipping and installation site information is copied over to child simple orders for fulfillment purposes. The information is not populated in child service management orders as it is not applicable in the service management process.

See Convergent Order Submission.

Before a simple order is submitted, you can convert it to a convergent order manually using the Convert to CO toolbar button if you wish to file service requests for multilevel installed services in same order as well. The same is true for service management orders—they can be converted to convergent orders so that new multilevel product bundles can be ordered, configured, and validated in the same session. Convergent orders can be created and searched manually under the Orders and Quotes navigation menu.

Note. The Order Capture self service application does not support the ordering of multilevel product bundles. Orders and quotes are shown in read-only mode and not editable if they contain multilevel product bundles and are opened in the self service application.

Convergent Order Submission

The submission of convergent orders for fulfillment may result in the generation of child orders, or conversion to simple orders or service management orders depending on the products (new or installed) that are included in the order lines.

This diagram illustrates the convergent order submission process flow:

Convergent order submission process flow, which can result in the generation of child orders or conversion to regular or service management orders

Upon submission, the system:

Order ID Autonumbering Assignment

As delivered, the system automatically assigns IDs to convergent orders (prefix: CO0) and simple orders (prefix: COM) at the time they are saved. If a saved convergent order is later on submitted and converted to a simple order, the ID of the old convergent order becomes the ID of the newly converted simple order. If the convergent order does not already have an assigned ID when it is converted to a simple order, the system assigns the next available ID to the new simple order based on autonumber setup for simple orders.

Business Project for Child Order Generation and Submission

The CRM system delivers the Submit Convergent Order business project that is responsible for generating and submitting child orders for convergent orders. This business project consists of three components:

Ordering Actions and Various Capture Types

In addition to convergent orders which support the ordering and servicing of multilevel product bundles, the Order, Quote, and Manage Service components are enhanced to facilitate the ordering and service management of multilevel and non-multilevel product bundles. You can add both multilevel and non-multilevel product bundles in the same order or quote. This table summarizes the type of actions each delivered capture type supports:

Action

Simple Order

Service Management Order

Quote

Convergent Order

Ordering new multilevel product bundles

Yes

-

Yes

Yes

Ordering new non-multilevel products

Yes

-

Yes

Yes

Servicing multilevel installed service

-

Yes (one installed service per order)

-

Yes

Servicing non-multilevel installed service

-

Yes (one installed service per order)

-

Yes

Migrating components within or across multilevel product bundles

-

-

-

Yes

360-Degree View Support

Customer 360-Degree View supports the creation, search and viewing (by status) of convergent orders under the Orders node of the Activities section.

Clicking a status link in the Orders node populates the dynamic grid on the right hand side with orders of the selected status with information such as order ID, order date, capture type and order status. When you select an order from the dynamic grid, the system displays any related installed products in a sub-grid. This screenshot shows a dynamic grid with a list of orders that are returned after clicking a status link:

You can add convergent orders from the Actions field of the 360-Degree View page as well. The option is enabled for users who are associated with the Communications market.

Click to jump to top of pageClick to jump to parent topicUnderstanding Orders

This section discusses behaviors of simple orders that are specific for handling multilevel product bundles.

Refer to the Managing Orders and Quotes chapter for information on the core order functionality.

See Understanding Order Capture.

While convergent order is the primary component used by Communications users for ordering multilevel product bundles because of its ability to capture new orders (and service requests) for multiple multilevel product bundles, there are situations where the system would use simple order for multilevel product bundle purchases. They are:

Note. As delivered, Communications users cannot add simple orders manually from the Order and Quotes menu folder. They always use convergent orders as the starting point to capture new orders.

While the ordering process for both type of products is almost identical, changes are made to the Order component to support order fulfillment for multilevel product bundles. This list includes some of the behavioral differences that orders demonstrate when handling multilevel product bundles. Simple orders containing multilevel product bundles:

Click to jump to top of pageClick to jump to parent topicUnderstanding Service Management Orders

This section discusses behaviors of service management orders that are specific for handling installed contracts.

Refer to the Working with Service Management chapter for information on the core service management functionality.

See Understanding Service Management.

Service management orders are created to process service requests for existing multilevel installed services in one of these ways:

Note. Each service management order is responsible for processing only one multilevel installed service. An error message appears if you attempt to add more than one multilevel installed service to a service management order.

When you select an installed service to add to a service management order, you must choose a top-level installed service. The system creates one order line for the selected top-level installed service initially, which essentially represents its multilevel hierarchy. An error message appears if a non-top-level installed service is selected. After the configuration session is completed and data is returned to the service management order, additional line items (for the same order line number) are added in the service management order for other installed services of the same hierarchy that were selected in the session. Different from service management orders that handle non-mulitlevel installed services, service management orders for multilevel installed services:

For data that is needed to complete the service management process but not captured in configuration sessions, it is collected directly from the service management order after returning from the configuration session. Upon submission, the service management order is fulfilled by one of the delivered BPEL business processes, based on the selected action of the order (change, disconnect, suspend, suspend and change, and resume).

Click to jump to top of pageClick to jump to parent topicUnderstanding Common Practice for All Capture Types

This section discusses parts of the ordering process that are common and applicable to all three capture types. Topics are:

Order Fulfillment

As mentioned earlier, multilevel product bundles are fulfilled in the form of orders or service management orders. In the case of convergent orders, either they are being converted to orders or service management orders, or they generate child orders (orders and service management orders) to be fulfilled. The fulfillment of orders and service management orders of the Communications market are performed by these BPEL business processes.

See Delivered Business Processes.

These business processes are also responsible for the creation and service management of installed links.

See Installed Links.

Holds

The system delivers and enables these hold codes for the SO, SM and CO capture types to ensure that orders for multilevel product bundles are validated and that errors are caught and corrected before they're sent to fulfillment:

Note. As delivered, these hold codes cannot be overridden manually; they need to be resolved by taking the appropriate corrective actions.

Hold Code

Capture Type

Explanation

Concurrent Orders Validation

(COV)

SO and SM

Hold is triggered if there are other orders in the system with the same multilevel product bundles as the order you are going to submit, and these orders have already been submitted for fulfillment. For reference purposes, information of concurrent orders is logged on the Related Actions page of the order that's put on hold as a result of this hold violation.

How to address the issue: Wait until all concurrent orders are completed before resubmitting the order.

Cyclical Migration Validation

(MLCMV)

CO

Hold is triggered if a cyclical migration is identified on the order. An example of a cyclical migration: a component migrates from contracts A to B, then to contract C, and back to contract A within a single order.

How to address the issue: Reconfigure the order, or split migration process into two separate orders.

Header Customer Migration Validation

(MLBHC)

CO

Hold is triggered if there is no order line for the Sold-to customer selected on the order header.

How to address the issue: Include a multilevel installed contract (owned to the customer on the header) in the order, or replace the customer on the header.

Migrated Component Billing Account Validation

(MLBAV)

CO

Hold is triggered if the billing account for the migrated installed product order line is not filled and service is migrated to the installed contract.

How to address the issue: Fill the missing billing account information and resubmit the order.

Multilevel Contract Type Validation

(MLCTV)

SO and SM

Hold is triggered if the configuration status of any multilevel product bundle stored in the order is invalid when the order is submitted or validated.

How to address the issue: Reconfigure any invalid multilevel product bundle until they become valid before resubmitting or revalidating the order.

Related Bill To Address Hold (RADRBL)

Related Bill To Contact Hold (RNBILC)

Related Bill To Customer Hold (RNBILL)

Related Ship To Address Hold (RADRSH)

Related Ship To Contact Hold (RNSHPC)

Related Ship To Customer Hold (RNSHIP)

Related Site Contact Hold (RNSITC)

Related Site Address Hold (RADRSI)

Related Credit Card Hold (RCRCD)

Related Credit Card Required Hold (RNOCC)

Related Site Hold (RNOSIT)

Related Product Site Contact Hold (RPSITC)

Related Product Site Hold (RPSITE)

Related Shipment Date Hold (RSHPDT)

CO

Hold is triggered if any of this information is missing for one of the related customers in a simple order (SO):

  • Address (bill-to, ship-to, or site)

  • Contact (bill-to, ship-to, or site)

  • Customer (bill-to or ship-to)

  • Credit card

  • Site

  • Product site

  • Contact of product site

  • Shipment date

How to address the issue: Fill the missing information and resubmit the order.

Selling Period Conflict

(SELCON)

CO, SO, and SM

Hold is triggered when an order consists of products that are available currently (for example, selling period is this month) and in the future (for example, selling period is two months from now). The order is going to be put on hold for selling period conflict when it's being validated.

Note. This hold is informational and can be manually overridden as delivered.

How to address this issue: Either:

  • Create two orders: one for fulfilling current product elements, and the other for future product elements (a future dated order).

  • Let the order be fulfilled on the date when the last available future element (the one on the order with the last selling period start date of all) becomes available. The fulfill by date of the order is automatically set to this date when future elements are added.

Selling Period Violation

(SELPER)

CO, SO, and SM

Hold is triggered if a product with a past selling period is added to an order to be fulfilled. A selling period is considered a past one if it ended before the product selling date that is specified on the order (or the system's current date if product selling date is unavailable).

How to address this issue: Remove the past product element and choose one that is currently available. If you have to order and fulfill the past product, back-date the product selling product so that it falls within the selling period of the past product element and re-validate the order.

Standalone Multilevel Components Validation

(MLCTL)

SO and SM

Hold is triggered if the order being submitted or validated contains any order lines with multilevel product components that are non-top-level and do not belong to any multilevel product bundle.

How to address the issue: Remove the components from the order lines before resubmitting the order.

In addition to adding new hold codes, existing hold codes for SO and SM capture types are also enhanced to support multilevel product bundles.

The hold validations for convergent orders are executed only at the convergent order level; they do not apply and therefore disabled for child orders that are generated for convergent orders.

Refer to the see references for additional hold codes that are specific to the selling period and split billing functionality.

See Selling Period Hold Validations, Holds, Defining Hold Codes.

Links

After the configuration of a multilevel contract or installed contract is completed, the result is displayed in the order. For each multilevel component that is related to a functional component, an icon appears in the Link column to identify the linkage that the multilevel component (commercial) has with its associated functional components. Similarly, when a component is moved or transformed from one contract to another, icons are also presented in this column to identify the source and target objects of the migration.

This table lists delivered icons that can be visible in the Link column in orders to show line and component relationships:

Note. Some of these icons are available for display in the Installed Product Hierarchy and the Configuration and Attributes section of orders as applicable.

Indicates that the corresponding multilevel product component (commercial) is linked to a functional component in a Sells relationship.

Suppose that the Network Access Offer commercial product is set to sell the Network Access functional component in the system. If the Network Access Offer commercial product is selected in an order, this icon appears in the Line Summary section of the order, indicating that the product is related to a functional component.

Clicking the icon transfers you to the order line of the functional component (in this case, Network Access) on the Line Details page, where you view the actual relationship type and functional component from the perspective of the functional component: Network Access Is Sold By Network Access Offer.

Clicking the product description link transfers you to the order line of the commercial component (in this case, Network Access Offer) on Line Details page, where you view the actual relationship type and functional component from the perspective of the commercial component.

Indicates that the corresponding multilevel product component (commercial) is linked to a functional component in a Sells relationship and that functional component relies on another functional component.

Suppose that the Network Access Offer commercial product is set to sell the Network Access functional component in the system, and the Network Access functional component relies on the DSL Modem functional component. If the Network Access Offer commercial product is selected in an order, this icon appears in the Line Summary section of the order, indicating that the product is related to a functional component that relies on another functional component.

Clicking the icon transfers you to the order line of the functional component (in this case, Network Access) on the Line Details page. From there, you see a total of two order line relationships:

  • Network Access Is Sold By Network Access Offer.

  • Network Access Applies On DSL Modem.

Indicates that the corresponding multilevel product component (commercial) is linked to a functional component in a Sells relationship and that functional component is relied on by another functional component.

Suppose that the Network Access Offer commercial product is set to sell the Network Access functional component in the system, and another functional component called Internet TV relies on the Network Access functional component. If the Network Access Offer commercial product is selected in an order, this icon appears in the Line Summary section of the order, indicating that the product is related to a functional component that is relied on by another functional component.

Clicking the icon transfers you to the order line of the functional component (in this case, Network Access) on the Line Details page. From there, you see a total of two order line relationships:

  • Network Access Is Sold By Network Access Offer.

  • Network Access Is Used By Internet TV.

Indicates that the corresponding multilevel product component (commercial) is linked to a functional component in a Sells relationship and that functional component both relies on and is relied on by functional components.

Suppose that the Network Access Offer commercial product is set to sell the Network Access functional component in the system. The Network Access functional component relies on the DSL Modem functional component and is relied on by the Internet TV functional component. If the Network Access Offer commercial product is selected in an order, this icon appears in the Line Summary section of the order, indicating that the product is related to a functional component that relies on and is relied on by other functional components at the same time.

Clicking the icon transfers you to the order line of the functional component (in this case, Network Access) on the Line Details page. From there, you see a total of two order line relationships:

  • Network Access Is Sold By Network Access Offer.

  • Network Access Is Used By Internet TV.

  • Network Access Applies On DSL Modem.

(group offer members details)

Indicates that the corresponding product component (commercial) is a group offer. It appears only when new members are added to or existing members are removed from the group offer, and it doesn't appear if the group offer doesn't change.

Click to access the order line details of the group offer on the Line Details page. The line detail contains a section that lists all members that are added and removed within the order.

(shared offer users details)

Indicates that the corresponding multilevel product component (commercial) is a shared offer. It appears only when new members are added to or existing members are removed from the shared offer, and it doesn't appear if the shared offer doesn't change.

Click to access the order line details of the shared offer on the Line Details page. The line detail contains a section that lists all members that are added and removed within the order.

(product is covered by commitment)

Indicates that the corresponding multilevel product component is being covered by a commitment product from another order line.

Click to access the order line details of the commitment product on the Line Details page. The line detail contains a section that shows additional information of the commitment product.

Indicates that the corresponding multilevel product component (commercial) is a shared offer that is linked to a service (functional component), which is currently shared by other services.

Suppose that the Shared Directory Offer commercial product is set to sell the Shared Directory functional component in the system, and the functional product is linked to the Mobile Line functional component in the relies on relationship. If the Shared Directory Offer commercial product is selected in an order, this icon appears in the Line Summary section of the order, indicating that the product is related to a shared functional component.

Clicking the icon transfers you to the order line of the functional component (in this case, Shared Directory) on the Line Details page. From there, you see a total of two order line relationships:

  • Shared Directory Is Sold By Shared Directory Offer.

  • Shared Directory Applies On Mobile Line.

Indicates that the corresponding multilevel product component (commercial) is an offer that is linked to a functional component, and the functional component is currently using the resource of a shared service.

Suppose that the Network Access Offer commercial product is set to sell the Network Access functional component in the system, and the functional product is linked to the 1000 Shared Minutes functional component in the relies on relationship. If the Network Access Offer commercial product is selected in an order, this icon appears in the Line Summary section of the order, indicating that the product is related to a shared functional component.

Clicking the icon transfers you to the order line of the functional component (in this case, Network Access) on the Line Details page. From there, you see a total of two order line relationships:

  • Network Access Is Sold By Network Access Offer.

  • Network Access Benefits From 1000 Shared Minutes.

(group & shared offer details)

Indicates that the corresponding multilevel product component (atomic offer) is added (or removed) as a member or user of the group or shared offer in the current order. This icon is not shown in the case where the product component is already a member or user of another offer and it was not changed in the current order.

Click to access the order line details of the offer on the Line Details page.

Indicates that the corresponding component is the target product of a migration link.

The target product is added to the target contract as a result of the execution of the migration action (reparenting or transformation).

Indicates that the corresponding component is the source product of a migration link.

The source product is removed from its source contract as a result of the execution of the migration action (removal, reparenting or transformation).

Indicates that the corresponding component is a product that is covered by a commitment.

Indicates that the corresponding component is available for sale in the future. Place the cursor over the icon to view the date when the selling period of the component begins.

 

Indicates that the corresponding component is a past element. Place the cursor over the icon to view the date when the selling period of the component ended.

Click to jump to parent topicUnderstanding Group Offers

A group offer is 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.

Group offers are similar to shared offers, but differ in that group offers:

You define group offers and group offer rules using:

 

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

Group offers vary depending on how the resources of the offer are shared between group members. For a family group offer, all group members benefit from a single pool; for example, a common pool of free minutes for all offer members to be used when calling other group members. For a tribe group offer, each group member benefits from an individual pool of resource; for example, each member has his or her own pool of free minutes to use when making calls to other group members.

Click to jump to top of pageClick to jump to parent topicSimple and Complex Group Offers

Group offers also vary depending on the number of shared services with which they are associated. A simple group offer is associated with a single shared service, which is shared among all group offer members. A complex group offer is associated with multiple shared services, and those services can either be identical or varied. For example, a simple group offer might provide each member a single pool of resources and link with a separate instance of a shared service, while a complex group offer might provide shared minutes and text messaging that are bundled into a one group offer and sold as a package.

The following diagram illustrates the difference between a simple and complex group offer:

Simple and complex group offers

A complex group offer can have one of two bundling options associated with it:

The following diagram illustrates the difference between an individual and dedicated complex group offer:

Individual and dedicated complex group offers

Note. All family and tribe offers are complex group offers.

Click to jump to parent topicUnderstanding Product Component Migration

This section discusses:

Click to jump to top of pageClick to jump to parent topicUnderstanding Package Migrations

Product migrations refer to actions being executed in configuration sessions that result in:

Through product migrations, new and installed multilevel product components can be merged, split, transferred or transformed within one single or across different contracts (which belong to the same or different customers) using convergent orders. Migration requests are subject to validation within configuration sessions prior to fulfillment. If configurations are invalidated due to rule violations, corresponding errors return and configurations must be fixed and revalidated successfully before orders can be submitted for fulfillment.

Product migrations cover a range of operations, including:

Migration of Functional Components Within or Across Multilevel Product Bundles

This migration involves the removal of one commercial atomic offer and the addition of another one within the same or across different multilevel contracts in a configuration session. At the end of the migration:

Migration of a functional component across different commercial atomic offers within a single installed multilevel contract

The target multilevel contract can be a new one or it can be an existing one, and they can belong to one or different customers.

Migration of a functional component between different commercial offers in different installed multilevel contracts

Migration of Commercial Components Within or Across Multilevel Product Bundles

This migration, which is a type of reparenting, involves the transfer of a commercial component from one parent (a commercial component) to another in the same or across multilevel contracts. At the end of the migration, this transferred commercial component, along with its descendants as well as any links to functional components, are moved under the new parent. This is done by disconnecting the existing Child Of installed link between the commercial component and its old parent and creating a new installed link with its new parent, which can either be another instance of the same commercial offer as the old parent, or another commercial offer that has a parent-child relationship with the transferred commercial component in product definition.

Migration of a commercial component across different commercial offers within a single installed multilevel contract

In case of a cross-contract migration, the target multilevel contract can be a new one or it can be an existing one, and they can belong to one or different customers.

Migration of a commercial component between different commercial offers in different installed multilevel contracts

Package Migration Scenarios

Multilevel product bundles support various forms of migrations and they can be summarized into these types:

C1 stands for contract 1, and C2 for contract 2.

Migration Type

Example

Contract change

Migrate all offers or services from the existing C1 contract to the new C2 contract and terminate C1.

Contract takeover

Migrate all offers or services from the existing C1 contract to the existing C2 contract and terminate C1.

Contract split

Migrate all offers or services from the existing C1 contract to the new C2 contract and new C3 contract. Terminate C1.

Contract merge

Migrate all offers or services from existing C1 and C2 contracts to the new C3 contract. Terminate C1 and C2.

Contract separation and merging

Migrate some offers or services from the existing C1 contract to the new C2 contract. C1 remains active after order fulfillment.

Transfer between contracts (split and merge)

Migrate some offers or services from the existing C1 contract to the existing C2 contract and at the same time migrate some other offers or services from C2 to C1. C1 and C2 remain active after order fulfillment.

This table lists the supported package migration scenarios and their migration results at a high level:

Use this legend to read the tables:

Example: EC1 of customer A stands for an existing contract called C1 that belongs to customer A; NC2 stands for a new contract called C2.

Scenario

Description

Same Contract Customer?

Migration Result

1

Migration of all products and services from EC1 to NC2

(contract change)

Yes

  • Termination of EC1.

  • Creation of NC2.

2

Migration of all products and service from EC1 and EC2 to NC3

(contract merge)

Yes

  • Termination of EC1 and EC2.

  • Creation of NC3.

3

Migration of all products and services from EC1 to EC2

(contract takeover)

Yes

  • Termination of EC1.

  • EC2 remains active.

4

Migration of all products and services from EC1 of customer A to EC2 of customer B

(contract takeover)

No

  • Termination of EC1 for customer A.

  • EC2 of customer B remains active.

  • Change of ownership for migrated products and services.

5

Migration of some products and service from EC1 to NC2

(contract separation and merging)

Yes

  • EC1 remains active.

  • Creation of NC2.

6

Migration of some products and services from EC1 of customer A to NC2 of customer B

(contract separation and merging)

No

  • EC1 of customer A remains active.

  • Creation of NC2 for customer B.

  • Change of ownership for migrated products and services.

7

Migration of all products and service from EC1 to NC2 and NC3

(contract split)

Yes

  • Termination of EC1.

  • Creation of NC2 and NC3.

8

Migration of some products and services between EC1 and EC2

(transfer between contracts)

Yes

EC1 and EC2 remain active.

9

Migration of some products and services from EC1 of customer A to EC2 of customer B

(transfer between contracts)

No

  • EC1 and EC2 remain active.

  • Change of ownership for migrated products and services.

10

Migration of products and services from EC1 and EC2 to NC3

(contract separation and merging)

Yes

  • EC1 and EC2 remain active.

  • Creation of NC3.

11

Migration of products and services from EC1 (all) and EC2 (some) to NC3

(contract separation and merging)

Yes

  • Termination of EC1.

  • EC2 remains active.

  • Creation of NC3.

12

Migration of products and services from EC1 (some) of customer A and EC2 (all) of customer to NC3 of customer A

(contract separation and merging)

No

  • EC1 customer A remains active.

  • Termination of EC2 for customer B.

  • Creation of NC3 for customer A.

  • Change of ownership for migrated products and services.

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

This section discusses:

Migration Action Definitions

Migration actions specify all the details involved in migrating multilevel product components within or across contracts, which include:

There are two types of migration actions, public and private:

Each package migration is associated with one migration action or sometimes multiple ones, which is referred to as migration scripts. A migration script contains a group of migration actions that are part of the parent migration action definition and they can be nested based on these rules:

Note. Atomic offer migration actions (both source and target components are atomic offers) are considered atomic operations on products and they cannot be nested.

See Setting Up Migration Actions, Setting Up Commercial Eligibility Rules.

Integrity Checks on Migration Actions

To ensure data integrity, the system performs a number of validations when a migration action definition is saved. They are:

How Are Functional Components Handled During Product Migrations

All the commercial components that are defined in the system can potentially be selected as source and target components in migration action definitions. And for functional components relating to atomic offers that are subject to be reparented or transformed to other atomic offers, one of these things happen:

Click to jump to top of pageClick to jump to parent topicUnderstanding Package Migration Requests

This section discusses:

Creation of Convergent Orders for Product Migration: Example

Convergent orders are used for capturing package migration requests and supporting the transfer of commercial and functional components between existing contracts as well as new and existing contracts. The capture type allows multiple customers to be selected in an order, facilitating cross-contract migrations that involve different customers.

Here is an example on migrating an atomic offer in a convergent order. In this example, a change service request is made to upgrade the 8-5 BB support atomic offer to the 24/7 BB Support atomic offer in a different contract. This transformation occurs as a result of the system-delivered 8-5 BB support to 24/7 BB Support migration action.

To migrate an atomic offer to a different contract:

  1. Create a convergent order. Select customer for the order.

  2. Add related customers to the order.

    This step is necessary if you want to migrate package components across different multilevel contracts that belong to customers other than the one already selected in the previous step.

  3. Select multilevel installed contracts and add new multilevel contracts needed for the migration. Select the Change line action.

    Installed contracts that belong to or associated with selected customers on the order are available for selection.

    If you add a new multilevel contract and related customers are selected in the order, you must identify a customer for which the new contract is created. If no related customers are selected, the customer of the order header is by default the owner of the new contract.

    You cannot change the customer of a new contract customer once the customer has been assigned. If you need to make that change, you have to add another new contract (and this time assign it to the desired customer) to the order and remove the previous one with the wrong customer.

  4. Add the source and target products for the migration in the order and select the Change line action.

  5. Click the Reconfigure Product link to initiate a configuration session and perform package migrations. A configuration session opens for the customer and it displays the two contracts previously selected in the convergent order.

  6. Click the Migrate icon next to the atomic offer. A list of possible migrations are displayed in two sections: one section includes migrations to contracts that are currently identified in the configuration session, another section includes possible migrations to contracts that will be created as a result of the selection of any migration within this section. Select a migration action for the atomic offer.

    Important! The system uses the current date as the reference date for determining the list of valid migration actions to be evaluated and presented after evaluation as possible migrations for any given product configuration. In the case of multilevel configuration rules, the order's product selling date is used to determine which of the rules are subject to evaluation in configuration sessions.

    There will be no validation to check for the validity of the selected migration action against the current date after the order is submitted.

  7. The migration is shown in both the source and target product structures. The configuration indicates that the removal of the 8-5 BB Support atomic offer from the source product and addition of the 24/7 BB Support atomic offer to the target product as a result of the migration.

  8. Verify and submit the new configuration. When finished, configuration information is updated and displayed in the convergent order.

    Configuration sessions can be saved and submitted at a later time. If the configuration result comes back as invalid, reconfigure the product until it is valid, otherwise the order cannot be submitted.

  9. Click the 8-5 BB Support link to access the Line Details page and view the line relationships that are impacted as a result of the migration.

    They are:

  10. Click the 24/7 BB Support link to access the Line Details page and review the line relationships.

    They are:

  11. Enter remaining information needed for the order to be fulfilled, for example, shipping and billing information. Submit the order.

    If related customers are selected in the order, the order captures shipping and billing information separately for each one of them. Upon the submission of the order, this information is populated to child simple orders that are generated for these customers. The shipping and billing information, however, is not copied to service management orders because it is not applicable to the service management capture type.

When the order is completed, components with the Add line action are created; for those that are associated with the Remove line action, they are removed in the system. For all components that are present both in the source and target structures (reparenting), the attributes of the target component are updated accordingly.

Cross-contract Migration

In a package migration, the source contract must already exist (that is, an installed service for a purchased multilevel product bundle and is also referred to as installed contract in this document), whereas the target contract can be a new contract, an installed contract, or a combination of both. In a cross-contract package migration where the target contract is a new product bundle selected in the order, its installed service gets created as a result of the fulfillment of that order.

In order for a commercial component instance to be moved successfully to another contract structure (new or existing), the commercial component needs to be part of the structure at the exact same level to which the instance is migrating and the component must still be a valid, active member of the target contract structure, which means that it is not obsolete. Similarly, for a functional component instance to be migrated and validated successfully, the new atomic offer that it associates with has to be set up to sell it.

When a cross-contract package migration involves more than one customer, some of the information in the migrated multilevel installed products is subject to update in order to maintain the integrity of the installed product. This information includes:

Orders involving cross-contract package migration are validated upon submission to make sure that errors are caught and correct prior to fulfillment.

See Holds.

If the migration of a multilevel installed product causes an update to its owner, or billing account, the change of information is captured and available for review in the Line Relationship section of the Line Details page of the order, after the completion of the configuration session and retrieval of configuration information to the order.

Note. Components of installed contracts cannot be migrated to other contracts that are being disconnected simultaneously in configuration sessions.

Line Relationships in Convergent Orders for Package Migration

After the submission and validation of configuration sessions, configuration information is returned to the order and all of the corresponding order actions are shown on the Line Details page. Based on the nature of package migration requests, the Line Relationship section supports the display of these line actions:

Line Relationship Type

Applicable Action

Description

Child Of

Add/Remove

Indicates the creation (Add) of the child of relationship between a migrated installed product (commercial component) and its new parent (commercial component), and the deactivation (Remove) of the relationship with its old parent as a result of the migration.

As a result of the migration, the parent installed product ID of the migrated installed product is updated with the ID of the new parent installed product.

Sells

Add/Remove

Indicates the creation (Add) of the sells relationship between a migrated functional component and a new atomic offer (commercial component) that sells the component, and the deactivation (Remove) of the relationship with its old atomic offer as a result of the migration.

Billed To

Add/Remove

Indicates the change of billing account for a migrated installed product if the migration involves contracts that are associated with different billing accounts. If the target contract is a brand new one and a new billing account is created for it, the migrated installed product is then assigned to this new account; if the target contract is an existing one, the installed product can be assigned to one of the billing accounts belonging to the owner of the target contract.

As a result of the migration, the account ID of the migrated installed product and all its child installed products is changed to the newly selected one that belongs to the target contract owner.

Owned By

Add/Remove

Indicates the change of ownership for the migrated installed product if the migration involves two contracts that are owned by different customers.

As a result of the migration, the customer ID of the migrated installed product and all its child installed products is changed to the ID of the owner of the target contract.

Migration

Add

Indicates that the corresponding object or installed product is either the source or target component of a migration, based on the relation stated on the order line. The system creates a migration link (not installable) behind the scene between the source component order line and the target component order line and it cannot be removed without initiating a configuration session.

As a result of the migration, the source component is removed and the target component added to the system.

Note. Migration links do not apply to reparenting migrations as both the source and target components refer to the same entity.

How Is Migration Information Presented in Convergent Orders - Example

This section provides an example of a how data is presented in a convergent order and child orders created for an commercial offer migration. The first table shows the customer, order line and line relationship information of a sample convergent order that is created to migrate a commercial offer named OB from Play PB to Play PA across different contracts (from CB to CA) belonging to different customers (from Customer B to Customer A).

Data presented in a parent convergent order for migrating an offer from one contract to another that are owned by different customers (1 of 2)

Data presented in a parent convergent order for migrating an offer from one contract to another that are owned by different customers (2 of 2)

These tables show the customer, order line, and line relationship information that is populated to its child orders that are generated for each multilevel installed service (multilevel installed contracts C1 and C2) involved in the parent convergent order:

Data presented in a child service management order (child order 1) of a convergent order created for package migration (1 of 2)

Data presented in a child service management order (child order 1) of a convergent order created for package migration (2 of 2)

Data presented in a child service management order (child order 2) of a convergent order created for package migration (1 of 2)

Data presented in a child service management order (child order 1) of a convergent order created for package migration (2 of 2)

Order Submission and Generation of Child Orders

Upon the submission of convergent orders for package migration, corresponding child orders are generated based on the available order lines and selected customers.

In a situation where a convergent order includes multiple customers, new multilevel contracts and multilevel installed services, the system generates:

Generated child orders are submitted for fulfillment at the same time. In the case of future dated convergent orders, child orders are generated together on the execution date of the convergent orders.

See Understanding Convergent Orders.

Order Pricing

All pricing information (including pricing adjustments) applied on the parent convergent order is populated automatically to its child orders. Line-level pricing adjustments is copied over with the order line to which they apply. As for header-level pricing adjustments:

Removal of Multilevel Contracts with Migrated Components

Multilevel contracts that are involved in migration processes cannot be removed from convergent orders. A system message is displayed when you attempt to delete a contract that has any migrated components, which states that the remove operation cannot be performed unless the migration action is reversed for that contract in a configuration session.

Note. If you want to migrate some components in a contract and the migration actions selected call for the removal of all components in the contract, the system automatically changes the action of the contract from Change to Disconnect in the convergent order.

Order Fulfillment for Package Migration

In case of package migrations, the fulfillment process for convergent orders includes the synchronization between child orders for contracts that are impacted by the migrations (contacts being the source or the target of the migrations). The reparenting action is always performed in the order created for the target contract. During the fulfillment process, child orders are synchronized at two steps:

The submission child orders kicks off the fulfillment process. This table highlights some of the steps in the process where major events in installed products occur based on the previous example (migration of OB offer from CB to CA contracts):

Step

Child Order #1 (target contract CA)

Child Order #2 (source contract CB)

Description of the Step

1

Synchronization Step

-

Pending installed products created for the target contract (CA) is put on hold until the source contract (CB) is set to pending status.

2

-

Installed Products for child order #2 in pending status

Source contract (CB) is set to pending status.

3

Installed Products for child order #1 in pending status

-

Target Contract (CA) is set to pending status.

This step can proceed only after the source contract is set to pending status.

4

-

Synchronization Step

Message to provisioning step for the migration source Contract (CB) is put on hold until message to provisioning is sent for migration target contract (CA) .

5

Message sent to provisioning system

-

Message sent to provisioning system for the migration target contract (CA).

6

Callback message sent from provisioning system

Message sent to provisioning system

Message sent to provisioning system for the migration source contract (CB).

7

-

Callback message sent from provisioning system

The migration target contract (CA) is updated to the Installed status (only selected components).

8

Installed Products for child order #1 in installed status

Installed Products for child order #2 in disconnected status

The migration target contract (CA) is updated to the Installed status (only selected components), whereas the migration source Contract (CB) is updated to the Disconnected status (only selected components). Synchronization of these steps is not required.

During the fulfillment process, installed links are created and their statuses updated based on the status change of their associated installed products. Status updates take place in these steps: (data fields that are updated within the corresponding step are highlighted in blue)

Relationships Between Installed Products and Service Agreements After Migration

If an installed product is covered by a service agreement and it is moved to another multilevel contract that is owned by a different customer, the fulfillment process terminates the relationship between the migrated installed product and the service agreement (belonging to the old customer) upon the completion of package migration. The migration also breaks any existing commitment that the migrated installed product has.

See Cross Selling Agreements with Products.

Click to jump to parent topicUnderstanding Split Billing

PeopleSoft Enterprise CRM provides robust billing capabilities to support the ordering and service management of multilevel product packages, which often include a combination of products and services from different lines of businesses and can potentially be consumed by multiple customers. For example, a phone directory that can be shared between a mobile and landline service of one or more customers, or a 1000-minute mobile air time that can be shared by a group of customers. With the nature of communications-specific product packages where components can be shared by different individuals, customers prefer to be charged only for the portion of the package that they use. For example, a company may agree to pay for the monthly subscription and weekday minutes of its employees' mobile phone plans, but each employee is responsible for their weekend minute usage. The split billing functionality meets this business need by allowing order payments to be charged to multiple billing accounts that belong to the order's sold-to customer as well as customers with which it has a bill-to relationship.

At a high level, the split billing functionality enables, but not limited to:

More details on the split billing functionality are discussed in this section.

This section discusses:

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

Refer to the see section for information on split billing products.

See Split Billing Products.

Click to jump to top of pageClick to jump to parent topicOrders and Service Management

The split billing functionality allows you to:

Note. A prepaid account can only be used to pay for products and services that belong to one single contract or product package. In addition, you cannot select both prepaid and postpaid billing accounts within an order.

Billing Account Selection and Split Billing At Order Line Level

For order lines containing products that are set as billing account selectable, the Billing Account Details section appears in the Line Details page at the order line level, prepopulated with the same number of billing accounts that are predefined in each of the respective product definitions. Each row has information such as the required and primary properties of the account, account number and purpose. The system prepopulates customer accounts in this section based on the defaulting logic, and you can select a different contact and billing account manually if applicable.

The number of rows in the Billing Account Details section comes from product definition and is not available of edit. For products that are set as billing account selectable but not split billing enabled, only one row appears in this section. You can still select a billing account in this case but cannot perform split billing for the order line.

Use of Billing Accounts From Different Customers

The CRM system allows you to charge payment, at the order line level, to billing accounts that do not belong to the order's sold-to customer (that is the customer selected at the order header). You can choose from billing accounts that are owned by bill-to customers of the sold-to customer.

The bill-to relationship between companies are established in the Company component.

Communications Setup Options for Split Billing

The system delivers several communications setup parameters that are used to enable or disable features related to split billing. This table lists the delivered parameters and their values are set to Y for the COM01 setID:

Name

Description

RBTACCNONREC

When enabled (value = Y), the Billing Account option becomes available as an option to pay for nonrecurring charges in orders.

RBTCUSTSPLITBIL

When enabled (value = Y), the system allows you to select a billing account (which belongs to the sold-to customer or any customer that has a bill-to relationship with the sold-to customer) to pay for recurring charges in orders. In addition, you can select a customer and contact in the Billing Account Details section on the Line Details page.

RBTSMNONREC

When enabled (value = Y), the Nonrecurring Billing Summary section appears in service management orders, which allows you to capture nonrecurring billing information in service management orders.

RBTREUSEPPACC

When enabled (value = Y), the system allows you to reuse a prepaid billing account (the account that is being marked for creation for the bill-to customer within the same convergent order) to pay for recurring charges in orders.

See Setting Up the Configuration Table.

Holds

The system delivers a number of hold codes to support split billing in the ordering process, making sure that errors are caught and corrected before order are sent to fulfillment.

Note. As delivered, these hold codes cannot be overridden manually; they need to be resolved by taking the appropriate corrective actions.

This table lists the split billing-specific hold codes that are added to the COM01 setID through the Capture Setup Tables Workbench:

Hold Code

Explanation

Prepaid and Postpaid accounts referenced in a single order

(BAIMIX)

Hold is triggered if the order being validated contains both prepaid and postpaid billing accounts. The system only allows one type of billing accounts to be selected for each individual order line in any given order.

How to address the issue: Make sure that all the billing accounts select for the order (at the header level and order line level) belong to the same type, that is, either prepaid or postpaid, but not both.

Prepaid Account Reuse Validation

(BAPRH)

Hold is triggered if the prepaid account that is currently selected in the Recurring Billing Summary section of the order is already assigned to pay for charges of another contract. A prepaid account can only be used to pay for one contract on the same order and therefore cannot be referenced on two or more contracts within the same order.

How to address the issue: Use a prepaid account that is not already assigned to another contract or product package.

New billing account selected for nonrecurring charges, but not marked for creation

(BANAN)

Hold is triggered if the Billing Account option with the *New Account* value is selected for paying the nonrecurring charge in the order, but currently no new account has been marked for creation (in the Recurring Billing System section) for the bill-to customer in the system.

How to address the issue: Either select to pay for recurring charges using the New Account option and select to create an account for the bill-to customer, or select to pay for nonrecurring charge using an existing billing account.

New billing account selected for reuse, but not marked for creation

(BANAH)

Hold is triggered if either the *New Account* option or the Reuse New Account option is selected for paying the recurring charge in the order, but currently no new account has been marked for creation for the bill-to customer in the system.

How to address the issue: Either select a type of billing account to create for the bill-to customer, or select to pay for nonrecurring charge using an existing billing account.

Nonrecurring Billing Details not provided

(BANRM)

Hold is triggered if the order has one-time charges but no information is available in the Nonrecurring Billing Summary section to provide payment details.

How to address the issue: Provide details in the Nonrecurring Billing Summary section before submitting the order again.

Duplicate billing accounts marked for creation

(BADMC)

Hold is triggered if more than one new billing account for the same bill-to customer and contact have been marked for creation on the order.

How to address the issue: Update the order to not request more than one new account for the same bill-to customer.

Pending billing account selected

(BAPND)

Hold is triggered if any of the billing account that is selected to pay for nonrecurring or recurring charges is still in the Pending status upon order submission.

How to address the issue: Wait until the account is in Active status or choose another active account for the bill-to customer.

Insufficient prepaid account balance

(BABAL)

Hold is triggered if the prepaid account that is currently selected to pay for nonrecurring charges does not have enough fund to make the payment. The system repeats this check next time the order is validated or submitted.

In the case where the account balance is sufficient to cover the order's nonrecurring charges to begin with, information is stored in the order and the system does not repeat this check when the order is validated or submitted again in the future.

Hold validation is performed when there is a change of value in nonrecurring charges to make sure that the current balance of the prepaid account is able to cover the payment.

For future dated orders, this hold validation applies only to the final order submission. This hold logic is not triggered on orders that are in the Queued status.

How to address the issue: Top-up the account with the required amount or select a different billing account or payment method.

New billing account selected, but not marked for creation.

(BANAL)

Hold is triggered if the *New Account* option is selected for nonrecurring or recurring charges, but no account for the corresponding bill-to customer has been marked for creation on the order.

How to address the issue: Mark new account for creation for the selected bill-to customer in the Recurring Billing Summary section or select a different billing account.

Billing Account required, but not selected

(BARNS)

Hold is triggered if a billing account is required but is not currently selected at the order line level.

How to address the issue: Select a billing account for the order line.

Prepaid Account Reuse Validation

(BAPRL)

Hold is triggered if the prepaid account that is currently selected for an order line is already assigned to another contract or package. A prepaid account can only be used to pay for one single contract or package.

How to address the issue: Update the order to use a prepaid billing account that is not linked to another contract or package in the system.

Bill To customer validation

(BANBT)

Hold is triggered if the current bill-to customer does not have an active bill-to relationship with the sold-to customer of the order.

How to address the issue: Establish a bill-to relationship between the this bill-to customer and the sold-to customer, or select a different billing account to pay for the order.

Pending billing account selected

(BAPNL)

Hold is triggered if a billing account that is currently selected to pay for recurring charges at the order line level is still in the Pending status upon order submission.

How to address the issue: Wait until the account is in Active status or choose another active account.

See Defining Hold Codes.

Convergent Orders

In convergent orders where multiple sold-to customers can exist in the same order, the system provides an option to use the new billing account in order lines of the convergent order in addition to the order line for which it is created, and these order lines can belong to different sold-to customers.

Here is an example. You create a convergent order that references two customers (one at the header level and one a related customer) for a package migration. In the Recurring Billing Summary section of the order for sold-to customer 1, you select a bill-to customer of customer 1 (customer A) and opt to create a new billing account. The account is marked for creation. Now, if you look at the Recurring Billing Summary section of the order for sold-to customer 2, the Reuse New Account option appears if the selected bill-to customer of this section for customer 2 is also customer A. If you choose to reuse the new account for customer A, the system populates customer A and new account as the default bill-to customer and billing account for all new order lines that are created for customer 2. The billing account defaulting logic applies.

Upon submission, a validation check is performed to make sure that no more than one new billing account for the same bill-to customer and contact can be created within a single convergent order.

On the Line Details page, you can manually select, or override existing default bill-to customer and billing account that pays for the recurring charge of the order line. If installed product is selected in the order line, you can change the billing account that is currently associated with the installed product to a different one, including a new account that is marked for creation (the option is available in the Account Number field if the bill-to customer of the new account is also the bill-to customer of the installed product order line).

Service Management Orders

You can use service management orders to perform these billing related updates for installed products and services:

Prepaid to Postpaid Billing Account Conversion

The prepaid and postpaid account conversion business process is not applicable to prepaid billing accounts that are used for multilevel product bundles or multilevel installed products. While the conversion cannot be performed automatically behind the scenes, you can still manually change billing accounts (from prepaid to postpaid) for multilevel installed products using service management orders. If, however, the multilevel product component that you want to a billing account change actually cannot be associated with a postpaid account (it happens if its product definition is set to be paid for by prepaid billing accounts only), the product component needs to be migrated to a product hierarchy that accepts postpaid billing accounts, so that when the migration completes, the migrated multilevel installed product can select to associate with a postpaid billing account that belongs to its new owner.

In the case where an installed product is owned by an anonymous customer and paid for using a prepaid account, the prepaid to postpaid account conversion can be done through package migration as well. First, you migrate the installed product to a product hierarchy that belongs to an identified customer who owns a postpaid billing account. After the migration, you can select the postpaid billing account for the migrated installed product in a service management order.

Viewing Split Billing Information In Self Service Application

While the Order Capture Self Service application does not support the ordering of split billing products, it supports the display of billing account information for split billing product or installed products.

The View Services page of the Account Management component in Order Capture Self Service lists the services of a user along with their account, status and pricing information in the Services Summary section. If a service is split billing-enabled and is associated with more than one billing account, the number of the first billing account on the product definition is listed, and a More Details link appears. Clicking this link transfers you to the Service Details page where summary information of all the associated billing accounts is displayed in the Billing Account Details section. Information provided is in read-only mode and it includes the number of account, account customer and contact, account number and description, as well as account status.

See Managing Services.

Click to jump to top of pageClick to jump to parent topicBilling Account Defaulting

The system provides defaulting of billing accounts for products that require billing accounts. It uses the Required and Primary options of billing accounts in product definition to determine if and which customer account is to be populated in any given order line as the default account. Typically, billing account defaulting occurs at the order line level when:

For billing account rows that do not meet these requirements, no billing account defaulting occurs. For example, the system does not populate default customer billing accounts in rows where the account is set as optional. Another scenario where the system doesn't set billing account defaults is if it cannot find any customer billing account that matches the billing account type specified in the product definition. When that happens, the system generates this message: Due to the billing account type mismatch some of order lines have been not assigned to any billing account. Please review billing accounts configuration and select billing accounts manually where required. In this case, you can review each order line with the Billing Account Details section and select customer and billing account manually as you see fit. All billing accounts which have been not automatically defaulted will need to be manually selected.

Validation check is executed upon order submission to make sure that billing account information is entered properly.

This is how the billing account defaulting works at a high level:

Billing Account Defaulting

Configurator Controller employs the following processing rules to default billing accounts:

Billing Account Defaulting In Migrated Order Lines

Billing account defaulting does not occur to order lines that are impacted by package migration. After the migration, no additional action is performed automatically to change the billing account that is associated with any migrated order line. You can, however, manually select a different billing account for a migrated order line if needed. In doing so, the system may be able to cascade the newly selected billing account to the child order lines of the migrated order line, if the child order lines meet the condition for billing account defaulting.

In a cross-contract migration where the contracts belong to different customers, it is possible that the bill-to customer of the migrated order line does not have a bill-to relationship with the target customer. A validation check is triggered upon order submission to make sure that all billing accounts that are selected to pay for recurring charges belong to customers that have a bill-to relationship with the order's sold-to customer.

Billing Account Cascading

During a configuration session you can modify the bill to customer and the billing accounts defined in the order lines. When you perform these modifications, Configurator Controller automatically cascades these changes to the descendent products. The same process occurs when you modify the bill to customer and the billing accounts defined in the order header for a specific sold to customer.

Note. Before cascading the change of BillTo Customer and/or the Billing Account to its descendent Order lines, you are prompted for confirmation.

A warning message ‘The new Billing Account will be cascaded to all the descendent products of [Product ID] – [Product Description]. Do you want to cascade the Billing Account to all its descendent products?’ displays to ensure you understand that the account will be cascaded down to all child products as well. The Controller will continue with cascading the changes if the user response is ‘OK’.

Configurator Controller cascades changes to the bill to customer and billing accounts when:

Configurator Controller cascades changes to the following billing accounts of descendent order lines:

When the default Account and/or the BillTo Customer for recurring charges of a SoldTo customer is changed, the Controller will cascade the changes to all the contracts owned by the SoldTo.

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

The CRM system makes billing account information available in installed products for viewing and service management purposes. The Billing Account Details section appears if the associated product definition of the installed product is defined as billing account selectable with at least one billing account type selected.

See Also

Entering Installed Product Information

Click to jump to top of pageClick to jump to parent topic360-Degree View Support

360-Degree View supports the display of split billing information for multilevel installed products under the Account node of the Activities section.

See Multilevel Installed Products in 360-Degree View.

Click to jump to parent topicUnderstanding Commitments

PeopleSoft Enterprise CRM provides commitments capabilities in ordering and service management processing to prevent customers from churning to other communication service providers (CSP). A commitment is an agreement between a customer and a CSP. It is assigned to products and services with a purpose to ensure that the customer does not terminate the products or services before a specified period of time has elapsed. In the case where the commitment is violated, the customer can be subject to a mutually-agreed penalty payment.

This section discusses:

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

Refer to the see section for information on commitment products.

See Commitment Products.

Click to jump to top of pageClick to jump to parent topicCommitment Configuration Rules

Configuration rules drive the assignment of commitment products to other products and services. These rules are in place to support the commitments functionality:

See Commitment Triggering and Covering Rules, Commercial Eligibility Rules.

Click to jump to top of pageClick to jump to parent topicOrders and Service Management

Commitment products are added to orders as a result of the execution of commitment triggering rules in configuration sessions. The addition can either be automatic (if only one applicable commitment product applies) or manual (if multiple commitment products are applicable and the agent needs to select one). After the verification and submission of product configuration, information of the configuration is stored and displayed in the order. The system adds a commitment-specific icon to lines in the line summary for products that are associated with a commitment product, indicating that the products are linked to a commitment.

A commitment product (or installed commitment), once added to a product configuration, appears in the Line Summary section of an order in a separate order line, which is not part of the product bundle that the commitment product is assigned to. The order line comes after the last order line of the hierarchy and it has a line number just like the top-level product of that hierarchy.

You can use the service management framework to handle these requests that are filed for installed commitments:

Commitment Product Relationships and Links

The Line Relationship section of the Line Details page displays relationships between commitment products and their covered products that can be grouped into these types:

See Product Relationships for Multilevel Product Bundles.

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

After the fulfilment is completed for an order that includes a commitment product, the system creates a commitment contract for reference. The commitment contract is a read-only record that contains information of:

As delivered, a batch process runs daily to provide status updates for commitment contracts in the system. If a customer violates a commitment (for example, by terminating one of its covered service before the commitment end date is reached), the commitment contract status is set to Violated. The batch process also looks for expired commitments and makes appropriate updates. The process changes the status to Expired for installed commitments and commitment contracts with an elapsed end date. Additionally, it deactivates (by setting the status to Inactive) installed links between expired installed commitments and the installed products that they cover, so that termination of covered installed products is no longer considered a violation.

See Also

Viewing Commitment Contracts

Click to jump to top of pageClick to jump to parent topicInstalled Commitments and Installed Products

The CRM system stores and displays installed commitment information for viewing and service management purposes. The information circulates and is easily accessible in these records:

This diagram illustrates how commitment information flows between its related commitment contract, installed commitment and commitment-covered installed products:

Availability of commitment product in commitment contract, installed commitment and commitment-covered installed products

A commitment contract references:

An installed commitment references:

A commitment-covered installed product references the ID of the installed commitment that assigns to it, which is a link that takes you to that commitment contract record.

Installed Products

The system makes commitment information available in installed products that are created for commitment-covered products. The Commitment Information section appears if at least one commitment is assigned to the installed product and it displays commitment data, such as:

Installed Commitments

Installed commitments are a type of installed product that are used to represent commitment products. To support the display of commitment specific information, additional fields appear for installed products of type Commitment, they are:

See Also

Entering Installed Product Information

Click to jump to top of pageClick to jump to parent topic360-Degree View Support

Customer 360-Degree View supports the search and viewing (by status) of installed commitments in the system under the Commitments node of the Activities section.

See Multilevel Installed Products in 360-Degree View.

Click to jump to top of pageClick to jump to parent topicProduct Catalog Export of Commitment Products and Rules

Prior to exporting commitment products and rules to Configurator application data structures for product configuration purposes, the system performs these integrity checks to make sure that the entities exported can be used to support to the commitments functionality:

The Product Catalog export process needs to be executed regularly to pick up all the latest updates on product and rule definitions for use in product configurations.

See Also

Export of Multilevel Product Bundle, Rule and Migration Action Definitions

Understanding Design Time Integration and Product Catalogue Synchronization

Click to jump to parent topicUnderstanding Trial Periods

A trial period in an order provides the customer the ability to test-drive newly purchased products and services for a specified period of time, during which the customer can return products or cancel services freely without any obligation or penalty. PeopleSoft Enterprise CRM supports the definition of trial durations and the computation of trial period end dates on all capture types—simple orders (single and bulk), convergent orders, service management orders (single and bulk), and quotes.

Click to jump to top of pageClick to jump to parent topicTrial Period Setup

The setup of the trial periods capability involves two tasks:

  1. Enabling the functionality at the business unit level.

  2. Defining the default trial period for each source and sub-source combination.

Trial Period Enablement

You enable the trial periods functionality by selecting the Allow Trial Period field on the Communications page of the business unit definition.

See Specifying Order Capture Telecommunications Service Options.

Trial Period Definition

You can specify a trial duration (the minimum number of days as required by law) for each source code and sub source code combination on the Sub Source Mapping Workbench page within the Order Capture Setup Workbench at the setID level.

See Defining Sub Source Codes.

Click to jump to top of pageClick to jump to parent topicTrial Periods in Orders

At runtime, for orders belonging to the setIDs that support the trial periods functionality, the system populates the default trial durations in them based on their selected source and sub source values. You can update the number of trial duration days in orders by increasing the number value, because the default values (specified on the Sub Source Mapping Workbench page) supposedly represent the minimum trial period lengths as permitted by law in your country.

The field remains editable prior to order submission and becomes read-only after the submission. The same is true for quotes.

The system automatically populates the default trial periods in orders that are created through component interface as applicable.

Trial Period End Date Computation

The trial period of an order begins on the date the order is completed, which is when all of its order lines are processed completely. The system calculates the end date of a trial period by adding the trial duration days to the trial period start date:

Trial Period End Date (or Order Completion Date) = Trial Period Start Date + Trial Period (in days)

The trial period end date is displayed on the order after its completion.

This table summarizes the support of trial period end date computation for all supported capture types:

Capture Type

Trial Period End Date Computed?

Note

Convergent Order

Yes

-

Simple Order

Yes

-

Service Management Order

Yes

Trial period end date is available for the Change and Change and Suspend actions only.

Quote

No

Quote needs to be converted to Order to complete successfully. For cancelled or expired quote, end date of Trial period is not applicable.

Bulk Order

No

Only the generated child orders are associated with a trial period end date.

Bulk Service Management Order

No

Only the generated child service management orders are associated with a trial period end date.

Multiline Service Management Order

No

Only the generated child service management orders are associated with a trial period end date.

Trial Periods in Bulk Orders and Bulk Service Management Orders

Trial periods are supported in bulk orders and bulk service management orders as well. The system cascades the applicable trial period of any bulk order or service management order to its generated child orders.

Trial Periods in Quotes

During the quote to order conversion process, the system populates the trial duration that is available in a quote to its order.

See Also

Creating Orders for Multilevel Product Bundles

Click to jump to parent topicUnderstanding Selling Periods for Multilevel Product Bundles and Components

A selling period of a multilevel product bundle or product component specifies the time frame during which the bundle or the component is available for sale. The setting of selling periods allows the definition, ordering and service management of product packages and components that are seasonal (available certain times of the year) or promotional (available for only a period of time) in nature.

Selling periods for multilevel product bundles and components are defined on the Package Components page. At design time, each multilevel product bundle can be associated with one selling period and any products (with current or future selling periods) as package components, whereas a product (as a component) can be associated with multiple product bundles at the same time and has a different selling period (past, current or future) in each of the bundles.

At runtime, the system restricts the visibility and availability of multilevel product bundles and components within configuration sessions based on selling periods, specifically, only products that are available for sale currently and in the future can be fulfilled. As for past product elements, they can only be fulfilled if the product selling dates of their orders are backdated to the time when the past elements were current. To determine if a product is eligible for order fulfillment, the product selling date on the order is used (the current date is used if the product selling date is not specified). This date serves two purposes:

While it is possible to add products with past selling periods to an order if products are selected from catalogs that are accessed directly from the left hand navigation menu, when the order is validated prior to being submitted for fulfillment, it is going to be placed on hold for a violation as it contains past product elements. The hold is called Selling Period Violation and it is not be overridden manually. The order cannot be submitted until it no longer has any past products. If you must add past products to an order, you need to change the product selling date on the order to a past date that past products were considered current. Similarly, an order can be placed on hold (named Selling Period Conflict Hold) if it contains products that are available currently as well as in the future. In this case, you can either let the order to be fulfilled when all of the product elements are available, or create two orders, one for current product elements that can be fulfilled now, and the other for future product elements that are fulfilled later when all of them become available.

Note. If a product selling date is not specified for an order at submission, the system's current date is used as default. Updating a product selling date invalidates the order and any configuration sessions it associates with. Make sure to re-validate the order if the product selling date of the order is changed.

Service management can be performed on multilevel installed products regardless of selling periods, in other words, you can add, remove, migrate, and change features of an installed contract even if the corresponding contract product itself or any of its products is no longer available for sale.

For the purpose of product element compilation and deployment that take place on the Advanced Configurator server, all product elements (past, current, and future) are exported along with their selling period dates (if available) when the export batch process runs.

See Defining Product Packages, Export of Multilevel Product Bundle, Rule and Migration Action Definitions.

Click to jump to top of pageClick to jump to parent topicPast, Current, and Future Product Elements

A product is considered a past, current, or future element on an order based on:

As each of these elements has its own properties and behavior, the product selection and ordering process changes slightly based on the type of elements that are selected on orders. Here are lists that summarize the properties of past, current and future elements:

PAST ELEMENTS:

The selling period of past product elements does not impact the status of their product definitions. This diagram shows the selling period of a past element on a timeline in relation to the product selling date of an order:

Selling period of a past element, which falls before the order's product selling date on the timeline

CURRENT ELEMENTS:

Note. A product is considered current if no selling period is defined for it. In the case where a product does not have its selling period end date defined, it is considered current if its selling period start date comes earlier than the order's product selling date; it is considered future if its selling period start date comes later than the order's product selling date.

For current elements, the status of their product definitions can be maintained manually based on business needs. This diagram shows the selling period of a current element on a timeline in relation to the product selling date of an order:

Selling period of a current element, which covers the order's product selling date on the timeline

FUTURE ELEMENTS:

For orders where future elements are selected (future-dated orders), users can update or cancel these orders while they are in the Queued status waiting for order execution. This diagram shows the selling period of a future element on a timeline in relation to the product selling date of an order:

Selling period of a future element, which falls after the order's product selling date on the timeline

Click to jump to top of pageClick to jump to parent topicValidations on Product Selling Status During Rule Execution

This table lists configuration and validation rules that involve the inclusion of additional product elements to orders either as a result of rule execution (configuration rule) or rule compliance (validation rule), and provides information on whether selling status validations are performed on associated product elements when these rules are executed:

Rule Type

Selling Status Validation

Brings on Creation

Example: Product A <brings on> product B

No validation on product B's selling period is performed. Should a brings on rule apply, product B would be added automatically to the order regardless of its selling status.

Brings and Removes

Example: Product A <brings and removes> product B

No validation on product B's selling period is performed. Should a brings and removes rule apply, product B would be added to or removed from the order automatically regardless of its selling status.

Commercial Prerequisite

Example: Product A <is a prerequisite of> product B

No validation on product A's selling period is performed. Should a commercial prerequisite apply, users would be able to add product A to orders successfully regardless of its selling status.

Functional Relies On

Example: Product A <relies on> product B

Validation on product A's selling period is performed prior to establishing a functional link between products A and B.

There is no selling period validation performed on past installed products when relies on links are created (with past elements as the source or the target).

If any of these rules cannot be committed due to unavailability of participating product elements, an error is logged in the system and the validation status of the configuration is set to Validated with Warnings.

Click to jump to top of pageClick to jump to parent topicSelling Period Hold Validations

Two hold validations are delivered around selling periods and they are:

These hold codes are delivered for the COM01 setID and is applicable to all capture types.

Click to jump to top of pageClick to jump to parent topicSelling Period Indicator

The system provides information on the availability of products in orders and catalog search based on selling periods, so that when users place orders or file service requests, they can make informed decisions about whether or not to purchase products as they may be only available some time in the future, or simply unavailable for sale. Based on the order's product selling date or the system's current date, the system determines and displays the selling status (Past, Current, or Future) of products selected on orders and catalog search. When moving the cursor over the status, the actual selling period appears as mouse over text. If the product is a current element and it is available for sale, the status is left blank.

Note. If the product selling date is specified on an order, it is used to determine the selling status of products selected in the order or displayed in the catalog search result that is invoked from the order. In case the product selling date is not available (it's not specified on the order), the system's current date is used.

Selling period indicators are present in these areas:

Click to jump to top of pageClick to jump to parent topicSelling Periods in Service Management Orders

As mentioned earlier, you can file service requests for multilevel installed products even if their corresponding products are not longer available for sale. When you reconfigure an installed contract, the existing configuration can be kept intact as long as it doesn't violate any validation rules that are triggered. For example, you file a request to add a wireless phone service feature to your existing Direct TV and 1500 megabit broadband internet package (the 1500 megabit broadband internet service is no longer available). The existing configuration does not need to be altered as long as adding the new feature doesn't introduce any rules that invalidate the new configuration. However, if the new wireless phone service is associated with a rule that allows only 1000 megabit or 2000 megabit broadband internet to be selected, then the existing 1500 megabit internet service must be removed and replaced by one of the available options.

Click to jump to top of pageClick to jump to parent topicFuture Dated Orders

Orders containing future product elements have future fulfill by dates and they are called future-dated orders. If an order contains multiple future elements with different selling periods, the fulfill by date is the latest date of all the product selling period start dates on the order. When the order is submitted, the system changes its status to Queued.

A background process runs regularly to identify queued orders that are ready to be processed for fulfillment (system current date = order execution date). In the meantime, queued orders can go into the maintenance mode in which they are subject to modification or cancellation.

When the order is resubmitted, the system checks for any hold violation again before the order is sent for fulfillment.

Click to jump to top of pageClick to jump to parent topicQuote to Order Conversion

When quotes are converted to orders, all of their products are copied over to orders regardless of selling status. If converted orders contain past elements (current elements that became expired by the time quotes were converted), they are placed on hold for the selling period violation like any other orders. Past elements are copied over to converted orders for informational purposes, allowing customer service representatives (CSRs) and customers to keep track of what happened to the elements and giving CSRs the upsell opportunity to recommend other products to customers as alternatives. Among other quote details, the conversion process also brings over the product selling dates of quotes (if specified) to orders.

Converted orders do not inherit the fulfill by dates from quotes as the date does not apply to quotes. The system computes the fulfill by date based on the presence of future product elements in converted orders. If future elements are available, the last selling period start date of all future elements is used as the fulfill by date; otherwise, the field is left blank.

Click to jump to top of pageClick to jump to parent topicRetiring Components from Multilevel Product Bundles

To retire a product component from a multilevel product bundle structure, simply update the obsolete date of that component from the product bundle on the Package Components page (product elements can also be removed physically from multilevel product bundles on the Package Components page). Logic is in place to make sure that products selected in new orders are valid when orders are being validated. For future-dated orders that contain retired or expired product elements (they were current when the future dated orders were first submitted), they are put on hold so CSRs can take proper actions to address the issue.

See Updating Obsolete Dates for Multilevel Product Components.

Click to jump to parent topicCommon Elements Used in This Chapter

Selling Status

Displays the status of availability for the selected product based on its selling period.

If a product is currently available, the field is blank; if the product is going to be available in the future, the value of Future appears. The system displays the actual selling period as hover text if you move the cursor over the Future status.

Product Selling Date

Enter the date when the multilevel product bundles added to the order are sold.

Advanced Configurator uses this date as a reference for executing configuration and validation rules that pertain to the selected multilevel product bundles.

Note. The system uses the current date as reference when evaluating possible migration actions to be available in configuration sessions.

In order for a rule to be triggered in a configuration session of an order, it must be in an active status on the date specified as the product selling date.

In addition, the product selling date is also used by the system to determine the availability of products (for ordering) based on selling periods. If an order contains past or future product elements (products with selling periods prior to or after the specified product selling date), the order is put on hold for selling period conflict when it is being submitted. The product selling date can be updated on the order (in situations where you want to order past product elements, you can back-date the product selling date so that it falls within the selling period of past product elements to make them available for sale). However, changing the product selling date invalidates the order and its configuration sessions if they have already been validated; make sure to re-validate the order after a change is made to the product selling date.

The product selling date is not visible and therefore not modifiable within configuration sessions.

Click to jump to parent topicCreating Orders and Quotes for Multilevel Product Bundles

This section discusses how to:

Important! This section uses the interface of convergent orders as the base of discussion as convergent orders, simple orders and quotes share a lot of common sections and fields. Unless otherwise stated, information available in this section apply to these three capture types.

Click to jump to top of pageClick to jump to parent topicPages Used to Create Orders and Quotes for Multilevel Product Bundles

Page Name

Definition Name

Navigation

Usage

<capture type> - Entry Form

RO_FORM

  • Orders and Quotes, Add Order, Convergent Order - Entry Form

  • Orders and Quotes, Add Order, Order - Entry Form

  • Orders and Quotes, Add Bulk Order, Bulk Order - Entry Form

  • Orders and Quotes, Add Quote, Quote - Entry Form

  • Orders and Quotes, Search Orders and Quotes, Convergent Order - Entry Form

  • Orders and Quotes, Search Orders and Quotes, Order - Entry Form

  • Orders and Quotes, Search Orders and Quotes, Bulk Order - Entry Form

  • Orders and Quotes, Search Orders and Quotes, Quote - Entry Form

  • Click the Convert to CO toolbar button on the Manage Service - Entry Form page or the Order - Entry Form page.

Create orders or quotes for multilevel product bundles.

Convergent Order - Shipping Billing

RO_SHIP_BILL_INFO

(For new orders) Click the Shipping & Billing button in the Related Customer section of the Convergent Order - Entry Form page. You must select a customer on the Customer section before prior to selecting a related customer.

(For existing orders with multiple customers) Orders and Quotes, Search Orders and Quotes, Shipping Billing

Capture shipping and billing information for all customers on the order.

<capture type> - Line Details

RO_CAPTURELINE_DTL

  • Orders and Quotes, Add Order, Convergent Order - Line Details

  • Orders and Quotes, Add Order, Order - Line Details

  • Orders and Quotes, Add Bulk Order, Bulk Order - Line Details

  • Orders and Quotes, Add Quote, Quote - Line Details

  • Orders and Quotes, Search Orders and Quotes, Convergent Order - Line Details

  • Orders and Quotes, Search Orders and Quotes, Order - Line Details

  • Orders and Quotes, Search Orders and Quotes, Bulk Order - Line Details

  • Orders and Quotes, Search Orders and Quotes, Quote - Line Details

View order line details, such as pricing, relationships with other order lines, upsell and cross-sell opportunities, as well as configuration and attribute information.

Attributes for <multilevel product name> page

RO_ATTR_RUN_SEC

Click the View Attributes link on the <capture type> - Entry Form page.

View attributes for multilevel product bundles, which are only available for edits in configurations sessions.

External Service Details

RO_EXT_SVC_DTL_SEC

Click the External Service Details link on the <capture type> - Line Details page.

Displays information about the external service associated with a group offer member.

Click to jump to top of pageClick to jump to parent topicCreating Orders for Multilevel Product Bundles

Access the Convergent Order - Entry Form page (Orders and Quotes, Add Order, Convergent Order - Entry Form).

Note. As delivered, this component is only accessible to users who are associated with the Communications vertical solution (navigation: Set Up CRM, Security, User Preferences, Overall Preferences) and are assigned to either the CSP Admin or CSP Agent role (navigation: PeopleTools, Security, User Profiles, Roles).

The Convergent Order component is built based on the Order component. Note that most of the sections and component pages are shared between the two components as they support the capturing of data that is often common to both ordering processes (though billing, shipping, and installation site information is not used in service management orders). Please refer to the Managing Orders and Quotes chapter for documentation on controls and sections that are common to the Convergent Order and Order components. This chapter focuses on new information that is specific to convergent orders.

Order Details or Header Details

This section is called Header Details in quotes.

Trial Duration

Displays the default trial period (in days) for the selected source and sub source combination that is currently defined on the Sub Source Mapping Workbench page. The value is available for edit as long as the order is not submitted for fulfillment, and the new value must be higher, not lower, than the default value.

Related Customer

Use this section to specify additional customers to be included in the order. Convergent orders support the migration of new and installed contract components among customers that are specified in this section and the Customer section.

Note. This section is applicable to convergent orders for package migration purposes.

Shipping & Billing

Click to access the Convergent Order - Shipping & Billing Info page to enter shipping and billing information for the corresponding customer and contact.

Add Customer

Click to access the customer search to add a customer to the convergent order.

If you delete a customer from this section and the order currently has order lines that are created for this customer, a system message is displayed, asking if you want to continue with the customer deletion if it also means removing its order lines. If you opt to continue, the system deletes both the customer and its order lines. In a situation where any of the order lines involves package migration (for example, a component in an installed contract belonging to this customer is migrated to another contract), the customer cannot be deleted unless the migration has been reversed in the configuration session. Also, the system does not allow you to delete contracts that contain (in whole structure) links going out of its structure. An example of these links is a relies on link that goes out and relates to a functional product that belongs to another contract's structure.

Capture Line Summary or Line Summary

Use this section to search and add multilevel product bundles to the convergent order. Similar to simple orders, you can add a multilevel product bundle by entering its name or ID directly, accessing a product catalog or launching an advisor session.

If related customers are selected for the convergent order, the system:

Note. This section is called Line Summary for simple orders.

Configuration Status

Displays the configuration status of the corresponding multilevel product bundle. Click the link to access the Configuration Session Details page to view additional information about the configuration result. Values are:

  • Not Validated: configuration is saved and stored in the order but it has not been validated.

  • Valid: configuration is submitted for validation and is validated.

  • Valid with Warning: configuration is submitted for validation and is validated with a warning.

  • Invalid: configuration is submitted for validation and is invalidated due to rule violation.

  • Invalidated: configuration was validated but later on an operation executed on the configuration caused it to be invalidated. Such operation can be a change of customer, or cloning or removal of any multilevel product bundle order line.

This link is visible on the top-level order line only.

Link

See Links.

Configure Package or Reconfigure Package

Click to start a configuration session for the selected multilevel product bundle. This link is available to the top-level order line only.

See Configuring Multilevel Product Bundles.

View Attributes

Click to view attribute values entered for corresponding order item. This link is available to each multilevel product bundle service that has an attribute specified during the configuration session. Attributes are not editable directly from any capture types.

See Viewing Attributes.

(clone line)

Click to clone the corresponding multilevel product bundle and its configuration, attributes and line relationships (if available).

The configuration status of the new cloned order line is set to Invalidated. The product bundle must be revalidated prior to order submission.

Add Product(s) and Search or Browse Catalog

Enter or look up from catalogs multilevel product bundles to add to the order. Only top-level multilevel product components can be added to orders.

Note. When administrators design pricing and promotional rules that apply to multilevel product bundles, it is important that these rules, when applied, do not result in adding non-top-level product components to orders. Orders are put on hold upon submission, if they contain order lines for multilevel product bundles and those lines do not have top-level multilevel product components.

Service Line Summary

Use this section to add multilevel installed services to the convergent order for service management. Similar to service management orders, clicking the Select Installed Services button transfers you to a tree structure in which a list of installed services belonging to the selected customer (and contact, if available) are displayed. From there you can select the installed services you want to perform service actions. Make sure to add all the installed contracts necessary for the order before initiating a configuration session as they cannot be added from the session.

Note. This section does not appear for simple orders or quotes.

If related customers are selected for the convergent order:

Note that the Show Add Products link, which is available to service management orders to add new products in the Manage Service component, is not available to convergent orders.

Shipping Summary, Nonrecurring Billing Summary, and Recurring Billing Summary

If related customers are selected for the convergent order, these sections are displayed on the Convergent Order - Shipping & Billing Info page for each customer being viewed.

See Specifying Shipping and Billing Information.

Child Orders

This section displays a list of child orders (simple orders and service management orders) that are generated for all line items in the convergent order after order submission.

The section provides this information about child orders: order ID, order action (for service management orders only), description of the ordered product, customer name, contact name and the order status.

The Product Description field for regular child orders supports the display of multiple products as a multilevel product bundle added to an order can contain a number of product components.

Note. This section does not appear for simple orders or quotes.

Totals

The charges displayed in this section are calculated for both new order as well as service management line items.

See Also

Understanding Order Capture

Click to jump to top of pageClick to jump to parent topicSpecifying Shipping and Billing Information

Access the Convergent Order - Shipping Billing page (Orders and Quotes, Search Orders and Quotes, Convergent Order - Shipping Billing).

Note. This page appears if the convergent order is associated with more than one customer (in other words, at least one related customer is selected in the order). If the order does not have any related customers, the Shipping Billing page is not visible and the Shipping Summary, Nonrecurring Billing Summary and Recurring Billing Summary sections appear on the Entry Form page.

Related Customers

This section lists all customers (including the customer in the header) that are associated with the convergent order. When you select a customer in the section, the system populates the line summary and any shipping and billing information that is currently available for this customer.

Line Summary

This section displays summary information of order lines (for both new and installed products) that pertain to the selected customer. For each line in the section, the top-level component of the product bundle is shown, along with line action and reason (for service management order lines), configuration status, product description and product ID.

Shipping Summary

Use this section to specify the shipping and installation site information for the selected customer. It looks and behaves the same in both simple and convergent orders.

Note. This section appears on the Entry Form page if the order does not have any related customers.

See Entering Shipping Information.

Nonrecurring Billing Summary

Use this section to specify the one-time billing information for the selected customer. It looks and behaves the same in both simple and convergent orders.

Note. This section appears on the Entry Form page if the order does not have any related customers.

Billing Account

Select to charge the customer using the billing account that is selected in the Account Number field.

Account Number

Select from a list of prepaid or postpaid accounts that the bill-to customer (the one selected in this section) owns, including the ones that are currently in active or pending activation statuses. Active accounts are shown in a concatenated <account number - account name> format. For those that are pending activation, only the account number is displayed.

The Transfer button takes you to the actual record of the selected billing account, which must already exist in the system. In other words, it does not work for the New Account value.

Note. Make sure that selected billing accounts are all activated by the time orders are submitted; orders are put on hold if associated existing billing accounts are not in the Active status.

Select *New Account* if you want to choose a new postpaid billing account to pay for the order. This option is available if a new postpaid billing account has been marked for creation in the Recurring Billing Summary section for the bill-to customer.

Note that this option doesn't apply if the new billing account to be created is a prepaid one because the system doesn't allow the use of new prepaid billing accounts to pay for nonrecurring charges. When that happens, the validation process puts the order on hold.

See Managing Billing Information.

Recurring Billing Summary

Use this section to specify the recurring billing information for the selected customer. It looks and behaves the same in both regular and convergent orders.

Note. This section appears on the Entry Form page if the order does not have any related customers.

See Managing Billing Information.

Click to jump to top of pageClick to jump to parent topicViewing Order Line Details

Access the Convergent Order - Line Details page (Orders and Quotes, Add Order, Convergent Order - Line Details).

Billing Account Details

This section displays billing account assignments for products that are billable; it appears if the product referenced in the order line is set as billing account selectable.. Use this section to select a billing account for the order line or multiple billing accounts to split the order line payment in case the selected product is split billing-enabled. Upon order submission, a validation check takes place to make sure that information for all the required billing accounts is collected properly.

You cannot add or remove billing accounts in this section.

No (number)

Displays the sequence number of the corresponding account based on the product definition.

Primary

Indicates, if selected, that the corresponding account is the primary one for the product. This column appears only if the product referenced is a split billing product. This information comes from the product definition.

Required

Indicates, if selected, that the corresponding account is required for the product. This information comes from the product definition.

Customer

Displays the owner or sold-to customer of the order line by default. If you want to select a different customer for the order line, click the Search button to choose a bill-to customer of the sold-to customer as the new customer for the order line.

Contact

Select a contact for the customer. The list refreshes as a different customer is selected.

Account Number

Select a billing account from the list of existing accounts that belongs to the customer selected for the order line. The list can contain a mix of prepaid and postpaid accounts, only prepaid accounts, or only postpaid accounts depending upon the account type that is defined in the product definition for each row.

You can also select the *New Account* option providing that a new account for the same customer has been marked for creation in the Recurring Billing Summary section.

Click the Transfer button to access the view details of the selected account in the Account component.

Purpose

Displays the account purpose as defined in the product definition.

Commitment Details

This section appears if corresponding product is a commitment product.

It displays additional information about the commitment product, such as the associated commitment triggering rule and the commitment duration for the products it covers.

Configuration Status

Order Configuration Status

Displays the configuration status of all multilevel product bundles within the order. Values are:

  • Not Validated: configuration is saved and stored in the order but it has not been validated.

  • Invalid: configuration is submitted for validation and is invalidated due to rule violation.

  • Valid: configuration is submitted for validation and is validated.

  • Valid with Warning: configuration is submitted for validation and is validated with a warning.

  • Invalidated: configuration was validated but later on an operation executed on the configuration caused it to be invalidated. Such operation can be a change of customer, or cloning or removal of any multilevel product bundle order line.

Contract Configuration Status

Displays the configuration status of the multilevel product bundle to which the current order line belongs.

Line Configuration Status

Displays the configuration status of the current order line.

Functional Component Status

Displays the configuration status of the functional component that is related to the commercial product of the current order line.

This field does not appear if the corresponding product is a functional component.

Configuration Status Details

See Viewing Configuration Details.

Reconfigure Product

Click to open the configuration session to view or edit the corresponding product.

Group & Shared Offers Details

This section appears if the corresponding product is a member or consumer of a shared offer.

Action

Displays the order line action that is set in the configuration session. Values are:

Add: group offer member was added from the offer.

Remove: group offer member was removed from the offer.

 

Offer Type

Displays the offer type associated with the order line.

Values are Shared and Group.

 

Customer

Displays the name of the offer holder associated with the order line.

 

Contact

Displays the name of the contact associated with the customer.

Users of Shared Product or Users of Group Product

This section appears if the corresponding product is a shared offer or group offer. It shows the list of members associated with the offer.

Action

Displays the order line action that is set in the configuration session. Values are:

Add: group offer member was added from the offer.

Remove: group offer member was removed from the offer.

 

Customer

Displays the name of the offer holder associated with the order line.

If the offer holder is part of an external service, you can select the name of the offer holder.

 

Contact

Displays the name of the contact associated with the customer.

If the contact is part of an external service, you can select the name of the contact.

 

Details

Click to view additional details about the order line. Available links include:

Order Line Details: Clicking this link transfers you to the line details of the functional component that is sold by the corresponding product.

Installed Product Details: Clicking this link transfers you to the Installed Product page.

External Service Details: Clicking this link transfers you to the External Service Details page.

Line Relationship

This section displays order line relationships between the product component that is listed in the Line Details section (the source component) and the rest of the components (target components) within the same multilevel product bundle. This section does not apply to non-multilevel product bundles or installed services.

Important! Refer to this section for all field descriptions and values that are supported in the Line Relationship section for all capture types. Field values are available for viewing depending on the nature of the order and the line action, some of these fields or values may not apply.

Action

Displays the order line action that is set in the configuration session. Values are:

ADD: Establish a new relationship of the specified type between two product components.

REMOVE: Inactivating existing relationship of the specified type between two product components.

If the specified relationship type is installable, adding or removing the relationship means creating or inactivating the corresponding installed link in the order fulfillment process. Removing an installed link changes its status and this action doesn't remove the link physically from the database. If the relationship type is non-installable, adding or removing the relationship doesn't create or remove any installed links.

To keep track of when an installed link instance is added or removed, the Installed Date field is updated when the link is created; the Disconnect Date is updated when the link is being removed.

Type and Relation

Displays the relationship type between the source component (specified in the Line Details section) and the target component (specified on the Product Description field or the Object Description field) and the description of the relation viewed from the source component's perspective. Values are:

Brings Commitment. Supported relations are Brings Commitment and Covers because of.

Committed. Supported relations are Commits and Is Committed.

Sells. Supported relations are Sells and Is Sold By.

Relies On. Supported relations are Applies On and Is Used By.

Brings On Creation. Supported relations are Brings and Is Brought By.

Child Of. Supported relations are Is Child Of and Is Parent Of.

Brings and Removes. Supported relations are Brings and Removes and Removes.

Migration. Supported relations are Migrates to or Migrated from.

Owner. Supported relation is Owned by.

Billed to. Supported relation is Billed to.

Object Description

Displays the product name, customer name or account name, depending on the related object type.

Related Line ID

Displays the order line ID to which the target component belongs. This value is not available, for example, if the target component is a functional component.

Related Order ID

Displays the order ID of the target component if this component is from another order. This field applies to convergent order child orders as order line relationship spans across multiple orders.

Related Object Type

Displays one of these values depending on the line relationship type:

  • Installed Product for types such as Relies On, Child Of or Shared With.

  • Customer for types such as Owned By.

  • Billing Account for types such as Billed By.

  • External Service for an external service provided by an external carrier.

Related Object ID

Displays the ID link of the corresponding object type, which can be installed product ID, customer BO ID, billing account number, or external service detail.

Manual Price Adjustments

The behavior of this section is the same between simple and convergent orders.

See Viewing or Modifying Line Details.

Cross/Up Sell Opportunities

This section displays any cross-sell and up-sell opportunities for the current order. For multilevel product bundles:

These changes do not apply to non-multilevel product bundles in the order.

Configuration and Attributes

This section displays the product hierarchy of the current order. It presents the target contract structure and it takes into consideration all the actions captured in the configuration session. Migrated components are displayed in the context of the target contract. For multilevel product bundles:

Note. This product hierarchy does not show functional components.

These changes do not apply to non-multilevel product bundles in the order.

Click to jump to top of pageClick to jump to parent topicViewing Attributes

Access the Attributes for <multilevel product name> page (click the View Attributes link on the Entry Form page of a capture type).

For multilevel product bundles, attributes are entered during configuration sessions based on the setup of the Configurator attribute object type. The Configure properties button appears for product components that are associated with attributes. After submitting the configuration to the Configurator server, attribute values are passed and stored in the order.

Clicking the View Attributes link on the Entry Form page brings up this page that displays the values in read-only mode.

See Also

Entering Attributes

Click to jump to top of pageClick to jump to parent topicViewing External Service Details

Access the External Service Details page (click the Details link on the Line Details page)

The External Service Details page displays information about the external service associated with a group offer member.

Click to jump to parent topicCreating Service Management Orders for Multilevel Installed Products

This section discusses how to:

Click to jump to top of pageClick to jump to parent topicPages Used to Create Service Management Orders for Multilevel Installed Products

Page Name

Definition Name

Navigation

Usage

Manage Service - Entry Form

RO_FORM

  • Service Management, Maintain Service, Manage Service - Entry Form

  • Service Management, View Service Management Order, Manage Service - Entry Form

  • Service Management, Bulk Maintain Services, Manage Bulk Services - Entry Form

  • Service Management, View Service Management Order, Manage Bulk Services - Entry Form

Create service management orders for multilevel installed products.

Manage Services - Select Installed Services

RO_INSSVC_TREE

Click the Add Installed Product button on the Manage Service - Entry Form page or the Manage Bulk Services - Entry Form page.

Select multilevel installed products for the service management orders.

Manage Service - Line Details

RO_CAPTURELINE_DTL

  • Service Management, Maintain Service, Manage Service - Line Details

  • Service Management, View Service Management Order, Manage Service - Line Details

  • Service Management, Bulk Maintain Services, Manage Bulk Services - Line Details

  • Service Management, View Service Management Order, Manage Bulk Services - Line Details

View line details for service management orders.

Click to jump to top of pageClick to jump to parent topicCreating Service Requests for Multilevel Installed Products

Access the Manage Service - Entry Form page (Service Management, Maintain Service, Manage Service - Entry Form).

Important! Select only one multilevel installed service for each service management order. Use convergent orders if you wish to process multiple multilevel installed services in a single configuration session.

When a multilevel installed service is added to the order initially, only one order line is created (for the top-level component of the multilevel installed service). Additional order lines (associated with the same line number) for other components are displayed subsequently based on the result of the configuration session.

Suspension or resumption of a multilevel installed service can be filed directly on a service management order without the need to go through a configuration session.

Header Details

Sub Source

Select the sub source of the service management order to indicate the origin from where the order is created. Available sub source values are based on the selected source. The default value of this field is specified in the definition of the associated order capture business unit.

Sub sources are established in the Order Capture Workbench.

Line Summary

Line Action

Select an action to perform on the selected installed service. Delivered values are:

*Change

Disconnect

Suspend

*Suspend/Change

Suspend/Resume

Note. Validations (through configuration sessions) are required for servicing installed services with actions that are appended with an asterisk (*). Validation is not required for performing any of the remaining actions through service management orders.

Reason

Select a reason for the selected line action. The list of reasons change based on the selected line action.

Reasons are mapped to reason types (line actions) on the Capture Setup Tables - Reason Codes page.

See Defining Reason Codes.

Configuration Status

Displays the configuration status of the corresponding multilevel product bundle. Click the link to access the Configuration Session Details page to view additional information about the configuration result.

This link is available to the top-level order line only.

See Viewing Configuration Summaries.

Link

Displays, if any, links that are established between corresponding installed services (commercial components) and their functional components.

See Links.

Note. The Line Summary section shows only commercial components; functional components are always hidden.

Configure Package or Reconfigure Package

Click to start a configuration session for the selected installed service. This link is available to the top-level order line only.

See Configuring Multilevel Product Bundles.

View Attributes

Click to view attribute values entered for corresponding order items. This link is available to each installed service that has an attribute specified during the configuration session. Attributes are not editable directly from any capture types.

See Viewing Attributes.

Line Status

Displays status of each line item. This information is available after the submission of the service management order.

Nonrecurring Billing Summary

Use this section to enter payment information for any nonrecurring charge that incurs in the service management order. Upon submission, validation check is executed to make sure that payment information is in place should any one-time charge be applied to the service management order.

See the Viewing Line Details of Convergent Orders section for more information on nonrecurring billing. The business and display logic of this section is the same for convergent orders and service management orders.

Recurring Billing Summary

Use this section to enter details for the new account that you want to create as part of the service management order. Unlike simple and convergent orders, the bill-to customer and existing billing account selected here are not used as values for billing account defaulting.

See the Viewing Line Details of Convergent Orders section for more information on recurring billing. With the exception of what is mentioned here, the business and display logic of the Recurring Billing Summary section is the same for convergent orders and service management orders.

See Holds.

Click to jump to top of pageClick to jump to parent topicSelecting Multilevel Installed Products

Access the Manage Services - Select Installed Services page (click the Select Installed Services button on the Manage Service - Entry Form page).

The installed service tree shows all the installed services that belong to the customer and contact of the order as filtered by the selected filtering criteria (if available).

If the search is not for a specific service, the tree displays the top two levels (contracts and plays as delivered in the system) of multilevel installed services. The top level is expanded so that all of its immediate descendents are shown.

If the search is for a specific service, the tree displays the top two levels of the multilevel hierarchy to which that service belongs. For the branch in which the searched service resides, it is expanded all the way until the searched service is shown.

Non-multilevel installed services matching the search criteria appear according to existing functionality and are not impacted by changes that are specific to multilevel installed services.

Click to jump to top of pageClick to jump to parent topicViewing Line Details of Service Management Orders

Access the Manage Service - Line Details page (Service Management, Maintain Service, Manage Service - Line Details).

Line Details

Shipment

This field is editable for multilevel installed services, but not non-multilevel installed services.

End Date

This field is not used by multilevel installed services as temporary services are not supported.

Billing Account Details

This section allows you to change the billing account (belonging to the same bill-to customer or a different bill-to customer) for the current installed product.

Refer to the see reference below for more information on billing account details.

See Viewing Order Line Details.

Line Relationship

Refer to the see reference below for field descriptions and values that apply to service management orders.

See Viewing Line Details of Service Management Orders.

Manual Price Adjustments

This section is editable for multilevel installed services, but not for non-multilevel installed services.

Click to jump to parent topicConfiguring Multilevel Product Bundles

This section discusses how to:

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

Page Name

Definition Name

Navigation

Usage

(Request Information)

CFG_HTML_SEC

Click the Show Request Info button on the configuration session.

View general and customer term information used in presenting the corresponding configuration session.

<capture type> - Configuration Session Details

RO_CONFIG_DTL_SEC

Click a configuration status link in the Line Summary section on the <capture type> - Entry Form page.

View configuration details.

Configuration Session Details - Error/Warning Message Details

RO_CONFIG_EXT_SEC

Click the View Details button of an error or warning message on the <capture type> - Configuration Session Details page

View error or warning messages that are generated for configurations.

Click to jump to top of pageClick to jump to parent topicConfiguring Multilevel Product Bundles

Access the configuration session (click the Configure Package or Reconfigure Package link on the Entry Form page).

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.

The configuration of multilevel product bundles or multilevel installed products is always initiated from the top-level component order line, where the Configure Package link appears on the Entry Form page. A configuration session can support a variety of actions, such as adding and removing product components, adding, modifying and removing product relationships, and setting product attributes. The actual list of actions that are available to a product or installed product in a configuration session is determined by a number of factors, including the nature and current status of the product or installed product. All multilevel product bundles that are added or selected on an order with the Change or Suspend/Change action are subject to validation in the same configuration session. Other service management actions, such as Disconnect or Resume, do not require validations in configuration sessions and can be processed directly from service management orders.

For the purpose of rule validations, the Pending Activation, Suspended, Pending Suspension and Pending Resumption statuses are considered active statuses for installed products and links. The suspension of a multilevel installed contract doesn't impact installed links that point to it, as multilevel installed contracts that are associated with the Suspend or Resume action do not need to be validated in configuration sessions. However, in case of package migrations, you cannot initiate a configuration session with a suspended multilevel installed contract (or one that has not been resumed yet) and these multilevel installed contracts are not available for modification in configuration sessions.

Suppose that an order contains four contracts and each one is associated with a different action:

When you click the Configure Package link of any given contract, a configuration session is initiated and it includes all of the contracts in this order that are associated with the Add (for new products), Change or Suspend/Change action, that is contracts A and D in this example. Contract C and D are excluded because Suspend and Disconnectactions do not require configuration or validation. These contracts are configured and validated in one single session and they can be reconfigured and revalidated until the submission of the order.

Note. The links to initiate configuration sessions in catalogs are disabled for multilevel product bundles.

Verify

Click this button to validate the current product configuration for the order.

If the validation is successful, the Configuration is valid message is displayed.

If the validation fails, Configuration is invalid message is displayed and you can locate the actual error messages in the Verification results element.

Show Request Info (show request information)

See Viewing Configuration Request Information.

Submit

Click to submit the current configuration session and pass the configuration data back to the order for display and further order processing.

If you click to reconfigure the product that was invalid at the time it was submitted, the Configuration is not validated message is displayed when you return to work on it for the first time.

Save

Click to save the current product configuration and return to the order.

If click to reconfigure the product that was invalid at the time it was saved, the Configuration is not validated message is displayed when you return to work on it for the first time.

Cancel

Click to return to the order without saving the current product configuration.

Verification results

Click to open the folder and view validation errors that pertain to the current product configuration. This element appears only when validation errors occur.

(add instance)

Click to add another unit of the corresponding product in the configuration.

(remove selected)

Click to remove the corresponding product from the configuration.

(show links)

Click to display for the corresponding product information on:

  • Any existing links to other products in the system.

  • Any configuration rules that are defined for it.

  • Any products that it can establish new links with instantly.

(error on product)

Indicates that one or more validation errors are present for the corresponding product component. Expand the Verification results element to view the actual error messages.

(configure properties)

Click to enter attributes for the corresponding product component.

See Entering Attributes.

(migrate)

Indicates that the product component can be migrated to another contract (new or existing).

Click to view a list of available migrations that can occur to the corresponding product component

See Migrating Product Components.

(show members)

Indicates that the corresponding product component is a group offer. Click to display:

  • Any configuration rules that are defined for it.

  • Any existing members that are using the offer.

  • Any potential members that can be using the offer.

See Viewing Offer Members.

(brings on creation)

Indicates that the corresponding product component (A) has a brings on creation relationship with another product (B), which means that selecting A causes the automatic selection of B in the configuration session.

Click the Show links icon to identify the product at the other end of the brings on creation relationship.

(brings and removes)

Indicates that the corresponding product component (A) has a brings and removes relationship with another product (B), which means that selecting A causes the automatic selection of B in the configuration session.

Click the Show links icon to identify the product at the other end of the brings and removes relationship.

(future product)

Indicates future product. Place a cursor over the corresponding product component to view its selling start and end dates.

Indicates that corresponding component is a billable product, which has the Billing Account Selectable option selected in its product definition.

Click this icon if you wish to change the current billing account of the corresponding product component (which can be a contract, a play, an offer, or an atomic offer).

When you place the cursor over the icon, information of each billing account that is currently associated with the corresponding product component appears as hover text in one of these formats:

  • For an identifiable account:

    <An asterisk if the account is required><Account Sequence Number>: <Account Purpose> -- <Account Number> -- <Account Name>

  • For an unidentifiable account:

    <An asterisk if the account is required><Account Sequence Number>: <Account Purpose> -- [not specified]

    It occurs if the billing account is not required as defined in product definition and no actual billing account has been selected for the product component (which can be newly added in the session or selected among installed products).

The hover text also includes the billing account information of the product component's functional component, if the Billing Account Selectable option is selected in the product definition of the functional component. The Functional Component subtitle appears when functional component-specific billing account information is available.

See Viewing and Changing Recurring Billing Accounts

Indicates that both the corresponding product component and its functional component have the Billing Account Selectable option selected in their product definitions, and you can view their account information as well as change the account assignment in the configuration session.

The same icon also shows if only the functional component requires billing options.

Click this icon if you wish to change the current billing account of the corresponding product component (which can be a contract, a play, an offer, an atomic offer, or a functional component).

See Viewing and Changing Recurring Billing Accounts.

 

(show active commitment)

Indicates that the corresponding product component is covered by a commitment product.

Click this icon to view the commitment details and the list of the product components that are covered by this commitment product.

See Viewing Commitment Information.

Customer Details

The first level of tabs represent customers (the sold-to customer and related customers selected for the order) that are available in the configuration session. You can place the cursor over a tab and view summary information of the customer, which includes the name and ID of the customer and its contact.

Contract Details

The second level of tabs represent contracts that are available in the configuration session. You can:

Note. For every product component that is added to or removed from the configuration, validation is performed automatically to the entire configuration automatically.

Product Details

The third level of tabs represent plays that are available within the selected contract in the configuration session. You can:

Automatic Selection of Components in Multilevel Product Hierarchy

From the multilevel product hierarchies that appear in the configuration session, you can select components to add to or remove the ones that are no longer needed from the configuration. When you select a component and its parent is not already being selected, the system automatically selects the parent component in the configuration. Similarly, if you remove a selected component with child components that are currently selected, the system automatically removes its child components as well.

In the case where you add a product component to the configuration and this component is associated with a brings on creation or brings and removes rule, the controller application adds the new product automatically as required by the rule, if there is no ambiguity as to where the new product should be added in the hierarchy. If ambiguity does exist, you are asked to indicate where the product needs to go in the hierarchy. This situation can occur when the new product is added under a multi-instantiated component (multiple instances of the same product component, which are shown separately as individual hierarchy in the configuration session).

Click to jump to top of pageClick to jump to parent topicAdding Contracts or Plays

Click the Add Instance button to add new (or installed) contracts or plays.

This section displays a list of new contracts or installed contracts of the customer that can be added to the configuration session. Select a desired contract and click the Submit button to add it to the configuration session.

The same user interface is used for adding plays.

Click to jump to top of pageClick to jump to parent topicViewing and Changing Recurring Billing Accounts

Access the configuration session to view and change recurring billing account information. For new orders, the Default Billing Options for <Customer Name> section appears if products (which have the Billing Account Selectable and Split Billing options selected in its product definition) are selected in the configuration sessions.

Default Billing Options for <Customer Name>

This section appears to display recurring billing account information that pertains to the order. In this section, you can change the billing account for recurring payments by selecting a different account that the same bill-to customer owns, or selecting a different account that is owned by a different bill-to customer.

Bill To Customer

Displays the bill-to customer that is currently selected in the order for recurring billing. Other available values in this field are customers that have a bill-to relationship with the sold-to customer of the order.

This field is not visible if the option to allow customer level split billing is not selected in the Communications Setup page.

Bill To Contract

Displays the bill-to contact that is currently selected in the order for recurring billing. Other available values in this field are bill-to contacts of the selected bill-to customer.

This field is not visible if the option to allow customer level split billing is not selected in the Communications Setup page.

Account

Displays the billing account that is currently selected in the order for recurring billing. Other available values in this field are all accounts that the selected bill-to customer owns, plus *New Account*.

If the option to allow customer level split billing (RBTCUSTSPLITBIL) is not selected in the Communications Setup page, only accounts that are owned by the sold-to customer of the order plus *New Account* are available for selection.

If the option to allow the reuse of existing prepaid accounts (RBTREUSEPPACC) is not selected in the Communications Setup page, current prepaid accounts for the bill-to and sold-to customers are not available for selection.

(create new recurring billing account)

Click to create a new billing account for recurring billing from the configuration session. The configuration session is refreshed and a new section appears to capture the information needed for creating a new billing account for the corresponding product.

(reload billto customers and accounts)

Click to invoke a web service which reloads values of the Account field in the Default Recurring Account section. It also refreshes the Bill To Customer field values if the the option to allow customer level split billing (RBTCUSTSPLITBIL) is selected.

(modify new recurring billing account)

Click to modify the corresponding new account.

Billing Accounts for <Name of Contract>

This section appears if you click the Billing Account icon of the top-level component in the configuration session.

Note. When the section appears, page tabs at the play level are not available for viewing or editing.

Purpose

Displays the purpose description of the corresponding account.

Customer

Same as the Bill To Customer field in the Default Recurring Account section.

Contact

Same as the Bill To Contact field in the Default Recurring Account section.

Account

Displays the number and name of the default billing account. Other available values include billing accounts that match the predefined account type and are owned by the selected bill-to customer, plus *New Account*.

Note. Prepaid accounts are available for selection if the option to allow the reuse of existing prepaid accounts option is selected. In the case where one of the billing account rows in this section is defined as prepaid accounts only and the option to reuse existing prepaid accounts is not selected, the row becomes unavailable for edit.

Billing Accounts for <Name of Non-Contract>

This section appears if you click the Billing Account icon of a non-top-level component (for example, play or offer) in the configuration session.

The display logic and elements of this section is the same as the Billing Accounts for <Name of Contract> section.

Functional Component Billing Accounts for <Name of Non-Contract>

This section appears if you click the Billing Account icon of a non-top-level component (for example, play or offer) in the configuration session AND the component is linked to a functional component that has the Billing Account Selectable option selected in its product definition.

The display logic and elements of this section is the same as the Billing Accounts for <Name of Contract> section.

See Also

Understanding Split Billing

Click to jump to top of pageClick to jump to parent topicCreating New Recurring Billing Accounts

Click the Create New Recurring Billing Account icon in the configuration session to create new billing accounts.

Request New Account

The Request New Account window appears .

Customer and Contact

Displays the customer and contact for which the new account is going to be created.

If the the option to allow customer level split billing (RBTCUSTSPLITBIL) is not selected, the Bill To Customer and Bill To Contact fields are not visible. As a default, the system creates the new account for the sold-to customer and contact.

Account Name

Displays the system-assigned name for the new account.

Account Type

Select the type for the new account. Values are Individual, Prepaid, Sponsored and Subordinate.

OK

Click to perform checks to make sure that all the information needed for account creation is available in the section, save the information, and return to the configuration session main page.

Note. If the billing account validation comes back with an error, a visual indicator appears (a red square) and the error message appears close to the billing account row that causes the error.

Cancel

Click to abort the account creation action and return to the configuration session main page.

See Also

Understanding Split Billing

Click to jump to top of pageClick to jump to parent topicMigrating Product Components

Refer to the Creation of Convergent Orders for Product Migration: Example section of the see reference for a walkthrough on package migration.

See Understanding Package Migration Requests.

Click to jump to top of pageClick to jump to parent topicEntering Attributes

Click the Configure Properties icon to enter attributes for the corresponding product component.

The first section displays offer (atomic offer) attributes, if any. The second section presents product (functional component) attributes. Depending on the attribute type, a free-text field or a drop-down field is displayed for you to enter the attribute value. Here, you can set attribute value or remove an existing attribute if permitted by the eligibility rule.

Click the Submit button to confirm the selection and click the Return button to go back to the previous configuration screen.

Note. In case of atomic offers, you select attribute values for them as well as their corresponding functional components at the same time.

Click to jump to top of pageClick to jump to parent topicViewing Link Summaries

Click the Show Links icon to view link summary for the corresponding product component.

The first section displays the configuration rules (grouped by type) that are defined for the corresponding product. The second section displays existing (added) links between the corresponding product and the other product. These links are grouped by types and direction. The third section displays products that can possibly be linked to the corresponding product. You can perform additional actions (action buttons are displayed accordingly) based on eligibility rules, for example, remove an existing link or add a new one.

Search

Click to enter search values to find link destinations. The section lists a number of fields for you to enter search values, or you can search just by customer ID.

The search result is a list of possible link destinations for the products listed on the same section (below the Search and SEARCH BY CUSTOMER ID buttons). You can select a product in the search result with which a link is created.

Click to jump to top of pageClick to jump to parent topicViewing Offer Members

Click the Show members icon to view existing or add new members for the corresponding offer.

The first section displays the configuration rules (grouped by type) that are defined for product. The second section shows existing (added) members of the shared product. The third section displays members that can be added to the product. You can perform additional actions (action buttons are displayed accordingly) based on eligibility rules, for example, remove an existing member or add a new one.

Click to jump to top of pageClick to jump to parent topicViewing Commitment Information

Click the Show Active Commitment icon to view information of an existing or newly added commitment.

The first section displays basic information of the commitment currently assigned to corresponding product component and possible actions (like shorten or extend the commitment duration) that can be performed. The second section lists the products that the commitment product covers in the current configuration session. The third section allows you to change (remove) commitment coverage for product components, though doing so can cause the commitment triggering rule to break, which invalidates the configuration session.

Click to jump to top of pageClick to jump to parent topicViewing Configuration Request Information

Access the (Request Information) page (click the Show Request Info button on the configuration session).

This page displays information gathered from request data. The first section presents general information that is passed in the request. The second section is generated for each customer included in the corresponding order; it lists all the terms (with IDs and values) that pertain to each customer.

Click to jump to top of pageClick to jump to parent topicViewing Configuration Summaries

Access the <capture type> - Configuration Session Details page (click a configuration status link in the Line Summary section on the <capture type> - Entry Form page).

The same page is used in simple orders, convergent orders and service management orders.

Configuration Session Details

This header section includes basic configuration information such as session ID, configuration status and the time when the configuration session was initiated.

Contract

For each contract that is validated in the order, the Contract section appears and it displays high-level information pertaining to its corresponding contract: customer name, customer contact name, configuration status, order line number, product ID and description.

Reconfigure Product or Configure Product

Click to launch a configuration session from the page directly without returning to the Entry Form page.

See Configuring Multilevel Product Bundles.

Configuration Session Context

This section displays the user role retrieved by configurator for the purpose of eligibility criteria evaluation. This section will be presented only if debug mode is enabled for the configurator.

Customer Criteria

This section displays customer criteria values retrieved by configurator for the purpose of eligibility criteria evaluation. This section will be presented only if debug mode is enabled for the configurator.

Products

This section identifies all products for the contract that were configured and validated in the configuration session for which configuration status was set to Invalid or Valid with Warnings.

Error/Warning Messages

This section displays any error or warning messages that were returned after configuration validation for any products within the contract. Each entry contains this information: product ID and name for which the message is issued, the order line number of the product, the severity level of the rule by which the message is issued, and the actual message text, which is specified in the definition of the corresponding rule.

View Details

Click to access the Configuration Session Details - Error/Warning Message Details page to view additional information about the rule violation.

Click to jump to top of pageClick to jump to parent topicViewing Configuration Details

Access the Configuration Session Details - Error/Warning Message Details page (click the View Details button of an error or warning message on the Convergent Order - Configuration Session Details page).

Error Code

Displays the error code that is returned from Advanced Product Configurator.

Message Text

Displays the message text that is defined for the error code.

Error codes are defined on the Error Codes Setup page.

Exception Message Text

Displays the error message issued for the product, which is set up in the definition of the rule that the listed product has violated.

Technical Description

Displays the technical details of the error that is returned from Advanced Product Configurator.

Click to jump to parent topicViewing Commitment Contracts

To view commitment contracts, use the Commitment Contract (RF_COMMITMENT_CONT) component.

This section discusses how to view commitment contracts.

Click to jump to top of pageClick to jump to parent topicPage Used to View Commitment Contracts

Page Name

Definition Name

Navigation

Usage

Commitment Contract

RO_COMM_CONT_PG

Customer Contracts CRM, Commitments, Commitment Contracts

View commitment contract information for customers, including the duration of the commitment and the list of products that are covered under the commitment contract.

Click to jump to top of pageClick to jump to parent topicViewing Commitment Contracts

Access the Commitment Contract page (Customer Contracts CRM, Commitments, Commitment Contracts).

When an order, containing a commitment product, is submitted for fulfillment, the Communication New Order BPEL process is invoked and among other tasks, it creates a commitment contract for the commitment product. A commitment contract contains information such as:

Information on this page is read-only.

See Also

Understanding Commitments