3 Request to Change Business Process

This chapter describes the features of the Request to Change business process and its features.

Overview of the Request to Change Business Process

The Request to Change business process comprises activities related to the subscriber's request for changes to in-progress orders, assets or services, as well as account updates.

The Request to Change business process includes the following features:

  • Revision Order

  • Follow-on Order

  • Cancellation Order

  • Move, Add, Change, Disconnect (MACD) Orders for Asset-Based Ordering

  • Updates to Subscriber Account Information

The sections that follow describe these features.

About Change Orders

In Siebel CRM, change order is the category of orders that make changes to previous orders. This category includes supplemental orders, follow-on orders, and modify orders.

About Supplemental Orders

Supplemental orders are revised versions of open orders that have been submitted for fulfillment but have not yet passed the point of no return.

Siebel CRM allows only one pending supplemental order for each open order.

When you submit a supplemental order from Siebel CRM, OSM does the following:

  1. Suspends the fulfillment flows associated with the revised order.

  2. Computes the changes for each order line.

  3. Creates a compensation plan for fulfillment activities that have occurred and that are affected by the revision. The compensation plan is merged with the fulfillment plan for the OSM revision order, and the revision fulfillment does not begin until order completion or another revision is submitted.

See Siebel Order Management Guide for information about revising an order in Siebel CRM.

Supporting Revisions

To provide support for revisions after order lines are billing-initiated but not yet billing-fulfilled, the order interface to BRM expects the order management system to pass in a fulfillment mode at the line-level.

The first time that billing initiation is called for order lines, the fulfillment mode should be set to DO.

If an order line is successfully billing-initiated and subsequently the order line is revised in Siebel CRM and the order is resubmitted, then the order management system compares the revised line against what was submitted to billing initiation. It determines whether any changes must be processed, and calls billing initiation with a fulfillment mode of REDO to process the delta. Old attribute values are supplied only for delta changes.

Changes to certain attributes on revised lines result in updates to billing. These attributes are:

  • On a revised promotion line: Billing Account, Purchase Date

  • On a revised account-level product line: Billing Account, Bill Profile, Promotion reference, Pricing Information, Billing Dates

  • On a revised service bundle line: Billing Account, Bill Profile, Promotion reference, Service ID

  • On a revised service bundle component line: Pricing Information (price list must be revised at service bundle level), Billing Dates

The Pricing Information attribute includes list price, selling (or net) price, pricing commit type, dynamic discount method, discount amount, and discount percent.

For the Billing Dates attribute, only cycle start and usage start dates should be changed if they are not yet current. The integration ignores requests to reset the purchase date.

See About MACD Orders (Asset-Based Orders) for more information about the order attributes.

Caution:

Revisions to order lines for products of type Item can be interfaced to BRM if the billing date is not current. When it is current, the call to update BRM fails.

If an order line is successfully billing-initiated and subsequently canceled in Siebel CRM (dropped from the Siebel CRM modify order) and the order resubmitted, then the order management system calls billing initiation with a fulfillment mode of UNDO.

If no changes are made to an order line as part of a revision, but it must still be submitted for context (for example, a service bundle component line is revised but the service bundle line is not, the service bundle line is still sent because the service bundle as a whole is sent to BRM), then the order management system calls billing initiation with a fulfillment mode of NOOP.

The Oracle AIA service that interfaces orders to BRM processes all of the lines or none of the lines. It does not do partial processing. When an order is successfully billing-initiated, when any subsequent revisions for lines on the base order are processed, the order management system must trigger compensation as described previously (using the REDO, UNDO, or NOOP fulfillment modes). If the order fails billing initiation (and triggers Order Fallout), a subsequent revision should be sent as is for billing initiation (DO mode).

Table 3-1 summarizes revision actions.

Table 3-1 Revision Actions

Action on Order Line Fulfillment Mode Processed As Comments

ADD

DO

ADD

Billing initiation processes only new purchases (lines with action of ADD).

ADD

REDO

UPDATE

Because billing initiation processes only new purchases (lines with action of ADD), changes to those lines are processed as updates. Prior value fields are set only for attributes that have changed on the revision.

ADD

UNDO

DELETE

Because billing initiation processes only new purchases (lines with action of ADD), cancellations to those lines are processed as deletes or disconnects.

ADD

NOOP

Ignored

Billing initiation processes only new purchases (lines with action of ADD); if on revision, those lines have not changed (from original order), then they are ignored.
Assumptions and Constraints for Revisions

  • Order lines are assumed to hit the point of no return after they have been interfaced to BRM in the Fulfill Billing mode. Revisions are only supported when order lines have been billing-initiated (interfaced to billing in the Initiate Billing mode) but not yet billing fulfilled (interfaced to billing in the Fulfill Billing mode).

  • Because only new purchases (lines with action ADD) are processed by billing initiation, revisions are only processed for new purchases.

  • The billing interface detects a changed attribute by the presence of an old attribute value for that attribute on the message. This is true for change orders and revisions.

Changing Price Lists on Supplemental Orders

As part of a supplemental order for a new order in Siebel CRM, you can change price lists for existing lines that use the ADD action.

  • Change price list for order header: When you change the price list for the order header, OSM populates new and existing order lines without a specified price list with the new price list for the order header.

  • Change price list for order line: When you change the price list for the order line, OSM updates the line item with the new price list.

  • Remove price list for order line: When you remove the price list on the order line, leaving it empty, OSM populates the empty field with the price list specified for the order header.

Table 3-2 shows an example of a revision of the order shown in Table 2-3.

Table 3-2 Example of Changing Price Lists on a Supplemental Order

Line Number Product Action Price List

1

Internet Access

Add

Premium Consumer Price List

2

Home Phone Service

Add

-

2.1

Home Phone Access

Add

-

2.2

Voicemail

Add

-

When you submit the order in Table 3-2, OSM changes the price list for the Internet Access product to Premium Consumer Price List and changes the price list for the Home Phone Service and its components to the price list specified for the order header. OSM sends the revised order through the integration to BRM for billing.

For more information about the product models used, see "About the Product Models" in the Oracle Communications Digital Business Experience Concept to Market Implementation Guide.

About Follow-On Orders

Follow-on orders are revised versions of open orders that have passed the point of no return but are not yet complete. Siebel CRM simulates the future completion of the open order to set up a dependency between the fulfillment of the open order and the processing of the follow-on order. When OSM receives a follow-on order that depends on an open order, it manages the dependency and does not process the follow-on order until the fulfillment of the order item on which the follow-on order depends is complete.

To ensure that the integration correctly updates Siebel CRM assets, do the following before creating a follow-on order:

  • Check that you have submitted the base order, establishing correct order dependency in OSM. If you submit the follow-on order before submitting the base order on which it depends, OSM processes the follow-on order as a base order.

  • Check that the base order is past the point of no return.

  • Discard any pending supplemental orders that you have not yet submitted for the open order.

You can submit supplemental orders and additional follow-on orders to revise follow-on orders.

About Modify Orders

Modify Orders modify installed Siebel CRM assets using the base order for those assets (the Siebel CRM documentation also calls them asset-based orders). You can submit Modify Orders only for orders that have been fulfilled and provisioned. OSM treats Modify Orders from Siebel CRM as new orders that modify the data created by the base order.

You can submit supplemental orders and follow-on orders to revise modify orders. See About MACD Orders (Asset-Based Orders) for more information about modifying orders.

Changing Price Lists on Modify Orders

You can change price lists for installed assets as part of a modify order in Siebel CRM and as part of a supplemental order for a modify order as follows:

  • Change price list for order header: When you change the price list for the order header for an existing asset and use the Add action to include new order lines without specifying a price list, OSM populates the price list for the order lines with the new price list for the order header.

    If existing assets use a price list originally populated from the order header, OSM does not repopulate these when the price list for the order header is changed. You must change the price list for existing assets manually at each order line.

  • Change or remove price list for order line: Because Siebel CRM does not send prior price list information to OSM, changes to price lists on order lines are ignored. To change or remove price lists for order lines on a modify order, you must first manually override the price for line items as follows:

    1. In Siebel CRM, enter the price in the Manual Price Override field for the line item. See the discussion of entering a manual discount for an individual line item in Siebel Order Management Guide for more information.

      The line action changes to Update.

    2. Assign the new price list to the order line or remove the price list, leaving it empty.

    3. If you are changing the price list for a service bundle, marketing bundle, or non-service-bundle customizable product, repeat step 1 for each component of the bundle.

    4. Submit the order.

      If you leave the price list empty, OSM populates the empty field with the price list specified for the order header.

Table 3-3 shows an example of the line items for a change order to change the price lists of the assets installed by the order in Table 3-2.

Table 3-3 Example of Changing Price Lists of Installed Assets on a Modify Order

Line Number Product Action Price List

1

Internet Access

Update

Consumer Price List

2

Home Phone Service

Update

Premium Consumer Price List

2.1

Home Phone Access

Update

-

2.2

Voicemail

Update

-

When you create the order in Table 3-3, you must manually override the price of each line item so that the line action changes to Update. When you submit the order, Siebel CRM populates the price list for the Home Phone Access and Voicemail products with Premium Consumer Price List. When AIA passes the order to OSM, OSM updates the price lists for the installed Internet Access and Home Phone Service assets. OSM sends the order through the integration to BRM for billing.

Note:

Siebel CRM does not track price lists for assets. When you update the price list of an order line on a change order, Siebel CRM only sends the new price list value. If you are using an order management system other than OSM, it must recognize that the Update action for a line with a non-empty price list attribute value means that the price list attribute has changed.

For more information about the product models used, see "About the Product Models" in the Oracle Communications Digital Business Experience Concept to Market Implementation Guide.

About Future-Dated Orders

A future-dated order is an order scheduled to start at a future date. Future-dated orders are created in Siebel CRM with the Due Date attribute set to a future date and submitted immediately to OSM. OSM manages the date that fulfillment starts. For asset-based ordering, Siebel CRM simulates the future state of assets in future-dated orders.

See OSM Concepts for more information about OSM future-dated orders and OSM Cartridge Guide for Oracle Application Integration Architecture for more information about handling current, past, future, and requested but not provided delivery date-time values.

To avoid complex future asset states, Oracle recommends that you do not create multiple future-dated orders for the same asset and that you limit future-dated orders to one per customer. If you must create multiple future-dated orders for the same asset, follow these guidelines:

  • Ensure that new future-dated orders to not invalidate previously-submitted future-dated orders.

  • Create the orders in chronological order.

  • When the requested delivery date for an order line is earlier than a future-dated order that you created previously, revise the previous order to ensure that it is based on the future state of the asset determined by the new future-dated order.

Supporting Time-Based Offerings on Change Orders

The integration processes orders that change the duration validity of previously-purchased time-based offerings as follows:

  1. Siebel CRM recalculates the end date based on the Duration, DurationUnitOfMeasure, and DurationValidityStart transaction attribute values and sends the order through the integration to OSM for fulfillment.

  2. When fulfilling the order, if the values for the validity attributes on the order are different from the prior values, the OSM AIA cartridges recalculate the end date based on the actual delivery date. The cartridges use the value for DurationValidityStart to calculate the new end date as follows:

    • Original End: The new value for Service End Date is the prior value for Service End Date plus the value for Duration.

    • Now: The new value for Service End Date is the value of Actual Delivery Date Time plus the value for Duration.

    • Original Start: The new value for Service End Date is the value of Service Start Date plus the value of Duration.

  3. When the order is billing fulfilled, the integration communicates the new end date for the purchased product or discount to BRM.

  4. OSM sends the changed end dates through the integration to Siebel CRM as part of the order update message.

About Cancel Order

Order cancellation for existing sales orders is possible as long as the sales order has not reached the point of no-return. For more information about the point of no return, see OSM Concepts.

When a subscriber requests for cancelling an existing order, the cancellation request is sent to fulfillment as a cancellation order by removing all order items in the existing order. Fulfillment receives the request and generates the orchestration plan based on the cancellation order. The fulfillment status provides details about the order cancellation progress. Order cancellation is successful when no new services are added.

About MACD Orders (Asset-Based Orders)

This section provides information about the Move, Add, Change, Disconnect (MACD) orders and the subsequent line actions that are supported for existing orders for a given product type. It also lists which changes to product attributes the integration communicates to a billing system, such as Oracle Communications Billing and Revenue Management (BRM).

MACD orders typically apply to asset-based orders wherein subscribers may have a change of mind and request for changes to be made to either services or assets in their initial (base) order.

Orders for disconnecting services are described under the Termination to Confirmation Business Process. For more information, see Termination to Confirmation Business Process.

About Adding and Removing Services

When a subscriber wishes to purchase additional services as an add-on to their existing order (Add action), the request is subjected to eligibility rules that determine if such a request is valid.

These eligibility rules are pre-defined and are validated during the creation of both new orders and new orders and change orders where change orders include Supplemental or Revision orders, Follow-on orders, and Modify orders.. If the order passes the validation, then the chosen services are added to, or removed from, the order. For more information about eligibility rules, see About Eligibility Rules.

Once the modified order is processed and the services are activated or disconnected, invoices are generated based on the modified services or assets and according to the billing frequency opted by the subscriber.

For more information about the applicability of the Add and Delete action, see Supporting MACD Actions and Attribute Changes.

About Moving Existing Services

When a subscriber calls to change the service address of the services or assets in their existing order to a new address, the request can be processed after the following requirements are validated:

  • Eligibility for the changing of service address.
  • Serviceability at the new address.

For the change in service address, a Move order is created in reference to the existing order and the service/asset to be moved. Upon completion of the Move order, invoices are generated based on the moved services or assets and according to the billing frequency opted by the subscriber.

For more information about the applicability of the Move action, see Supporting MACD Actions and Attribute Changes.

About Upgrading and Downgrading Services

Subscribers can choose to change their package to either upgrade or downgrade services or assets. Services or assets can be upgraded or downgraded based on migration rules for packages (such as compatibility or eligibility rules). These rules are used to validate upgrade or downgrade requests made by the subscriber; if it passes validation, an MACD order is created, and the subscriber's new package is activated and the older package is disconnected.

Migration may also entail penalties which are computed based on the subscriber request and associated rules. See Oracle Communications Digital Business Experience Concept to Market Implementation Guide for more information of these rules.

Furthermore, upgrade or downgrade fees are applicable when there is a commitment period defined for the packages. When both upgrade or downgrade fees as well as disconnect fees are defined for a package, only upgrade fees may be applicable.

For more information on defining migration rules during product definition, see Oracle Communications Digital Business Experience Concept to Market Implementation Guide. For more information about support for upgrade or downgrade, see Supporting MACD Actions and Attribute Changes.

About Suspending Services

This functionality allows you to suspend a subscriber's service (or asset) temporarily so they are not billed for the duration it is not in use.

A Suspend order is created with reference to the existing order of a subscriber and the service or asset to be suspended. It may include a service suspension date which indicates the date of service suspension. Optionally, a date for resuming services may also be indicated.

When you submit the suspend order, a sales order is created to pass on the fulfillment. The provisioning system consumes the order to suspend the service and informs BRM to halt the billing for the service suspension duration.

For more information about the applicability of the Suspend action, see Supporting MACD Actions and Attribute Changes.

About Resuming Services

This functionality allows you to resume suspended services.

A resume order reinstates the suspended service based on the recorded date of service resumption. The fulfillment system orchestrates the order to the provisioning system which resumes the service.

Upon service resumption, the subscriber is invoiced for the service based on the billing frequency and date.

For more information about the applicability of the Resume action, see Supporting MACD Actions and Attribute Changes.

About Updating Subscriber Account Profile

Account profile updates are key uses cases that must be handled as part of the Account Management business flow. As part of Subscriber Onboarding, a new account is created when a first time order is placed for the customer.

Over the subscriber lifecycle, there could be scenarios when an update is needed to the account profile. The most common or frequent updates to be made could be changes to contact name, email IDs, address, etc. The Account Update business flow manages these changes directly between Siebel CRM and BRM.

About Interfacing Orders to BRM

Interfacing order information to BRM for changes orders follows the same flow as the Order to Payment sales orders. For more information, see About Interfacing Orders to BRM.

Applying One-time and Penalty Charges

The integration applies one-time charges for Suspend and Resume actions as service-level charges and penalty charges for changing a promotion agreement as account-level charges. See DBE Concept to Market Implementation Guide for information about one-time and penalty charges at design time.

In Siebel CRM, you can define charges for Suspend, Resume, Move, and Delete actions by default. You can extend Siebel CRM to define charges for other actions, such as Update. For example, you can charge a subscriber a fee for updating their phone number or billing profile. The integration supports one-time and penalty charges regardless of the action that triggered the charge.

Order lines representing one-time and penalty charges are linked to the service bundle line using the asset integration ID and due date from the Siebel CRM order line and the charge parent line from the order enterprise business message (EBM). The integration applies order lines linked to service bundle lines in this way to the corresponding service instance in BRM to create the one-time or penalty charge.

For example, a service is suspended and resumed by the same order and two different charges are applied. The charge line applied for the Suspend action points to the service bundle line with the Suspend action, and the due date on both the lines is the same. The charge applied for the Resume action points to the service bundle line with the Resume action, and the due date on both the lines is the same.

If the application business connector service (ABCS) that transforms the Siebel CRM order application business message (ABM) to the order EBM is unable to resolve the baseline that a new order or change order one-time charge maps to, it does not populate the charge parent line and the charge is applied to the account when the charge line is interfaced to billing.