12 Understanding the Bill Fulfillment Order Business Flow

This chapter provides an overview of the Bill Fulfillment Order business flow. It describes how the Oracle Application Integration Architecture (Oracle AIA) Oracle Communications Order to Cash Integration Pack (the integration) supports and synchronizes order data from Oracle Communications Order and Service Management (OSM) to Oracle Communications Billing and Revenue Management (BRM).

Overview of the Bill Fulfillment Order Business Flow

The Bill Fulfillment Order business flow is enabled by the following pre-built integration options:

Order to Cash for Oracle BRM
Order to Cash for OSM

The Bill Fulfillment Order business flow is initiated when OSM drops a transformed order into a Java Messaging Service (JMS) queue, where a JMS consumer picks it up and passes it to the integration. The integration transforms the messages and passes it to BRM for billing.

About Interfacing Orders to BRM

This section describes how the integration interfaces order information to BRM as part of the Bill Fulfillment Order business flow.

Creating and Updating Service Instances

The integration creates or updates service instances, purchased product instances, and discount instances in BRM depending on the action on the order line as follows:

For order lines with the Add action, the integration creates new service instances, purchased product instances, and discount instances in BRM.
For order lines with the Update action, the integration updates to the service identifier, billing account, billing profile, or price on existing service instances, purchased product instances, and purchased discount instances in BRM.
For order lines with the Delete action, the integration cancels the BRM service instances, purchased product instances, and discount instances in BRM. Any refunds and proration are determined in BRM by product level controls.
For order lines with a Move-Add or Move-Delete action, which are the result of transferring a service from one location to another in Siebel CRM, the integration moves the service instances, purchased product instances, and purchased discount instances in BRM. The integration also makes any updates to the service identifier, billing account, and billing profile. Move-Add and Move-Delete actions cannot include adding new assets or cancelling existing assets, only transferring assets.

Sending Pricing Information

When interfacing orders, the integration sends pricing information such as price or discount overrides, discounts, and one time penalty charges.

For price changes that occur within a billing cycle, the integration sends the price or discount overrides on a purchased product, the new price goes into effect from the following billing period, and no credits or debits are issued for the current period. To apply the new price immediately, submit an order to cancel the existing product, then submit another order to purchase the product at the new price.

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 "About One-Time Charges for Activating and Changing Services" 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 customer 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 base line 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.

Applying Pricing or Discount Overrides

Pricing and discount overrides are controlled by the following order line attributes:

Pricing Commit Type: Controls whether the difference between the list and the selling price (due to promotion bundling discounts, matrix discounts, or manual price overrides) on a purchased product is applied in BRM as a price or discount override. The BRM General Ledger component accounts for discount overrides but not price overrides.

The integration uses this attribute as follows:
- If the pricing commit type is set to Committed, the integration applies a price override in BRM.
- If the pricing commit type is set to Dynamic, the integration applies a discount override in BRM and the Dynamic Discount Method attribute is used.
Dynamic Discount Method: Controls whether a discount override is applied by percent or amount.

To use BRM pricing without any overrides for an order line, set the Pricing Commit Type to Dynamic and leave the discount blank.

BRM allows only one override for each charge or discount type for a single product. For example, if a BRM product is mapped to multiple events of the same type and synchronized to Siebel CRM as a complex product with multiple simple child products, the integration applies any override applied for one of the child products to all children of the complex product with the same charge or discount type.

Sending Price List Information

Orders submitted from Siebel CRM can specify a separate price list in the order header and at each order line. The integration includes the price list ID from the Siebel CRM sales order on the order messages sent to OSM and BRM.

BRM uses the rate plans associated with the price lists to charge the appropriate amount for the products or services purchased on the order lines.

Using Service Identifiers

When interfacing orders, the integration includes the service identifiers on the service bundle line to BRM. For telephony services, the service identifier is used as the phone number. For other services, it is used as the log in and password.

Communicating Promotion Information

To allow BRM to display promotion information on the invoice, the integration communicates the following information about the promotion when interfacing an order for billing:

For new promotion purchases, the integration creates bundle instances under the billing account on the order line with the following information:
- Promotion name
- Promotion description
- Effective start date: If there is a purchase date on the promotion order line, it is used. If not, the request date is used. If neither is available, BRM uses the current date by default.
The integration creates the purchased product and discount instances for the respective purchased bundle instance. Such references are not created for products of type Item.
As subsequent orders are processed, the integration creates new references as needed and maintains existing references such that the purchased products and discounts point to the bundle instance that is current.
When a purchased promotion is canceled as part of a downgrade, upgrade, or cancellation, the integration cancels the bundle instance in BRM by specifying an effective end date. The integration uses the actual delivery date (on the order line canceling the promotion). If the actual delivery date is not available, it uses the request date.

No support is provided for translation of promotion name or description. Changing the name and description of the promotion (design time data) in Siebel CRM does not have any effect on transactions that have been submitted for processing and interfaced to billing.

Rolling Back Transactions

The integration service that interfaces the order to BRM either processes all of the lines on the incoming message or none of them. If an error occurs while it is processing the lines, then the entire transaction is rolled back.

See "Understanding the Process Integration for Order Fallout Management" for more information about order fallout.

Supporting Balance Groups

The integration supports service-level and account-level balance groups.

A balance group is an object in the BRM database used for tracking account balances and bills. When you submit an order, the integration synchronizes service bundles as service instances in BRM and BRM tracks the balances for these services in balance groups. The billing profiles specified on the order are synchronized as bill units (/billinfo objects) in BRM.

When the integration creates a customer account in BRM during the Create/Sync Customer Account integration flow, it also creates a default account-level balance group pointing to a default bill unit associated with the primary billing profile for the account.

By default, the integration enables service-level balance groups to track the balances for each service separately. You can disable service-level balance groups to track all of the services on an account together in the default account-level balance group.

The default account-level balance group is used whether you enable or disable service-level balance groups. See "About Tracking Account-Level Products in the Default Account-Level Balance Group" for more information about how the default account-level balance group is used when service-level balance groups are enabled, and "Working with Service-Level Balance Groups Disabled" for more information about how the default account-level balance group is used when service-level balance groups are disabled.

Disabling Service-Level Balance Groups

To disable service-level balance groups:

Open the Comms_home/source/soainfra/apps/AIAMetaData/config/AIAConfigurationProperties.xml file.

Search for the following element:

<Property name="O2C.AccountLevelBalanceGroup">False</Property>

Set the O2C.AccountLevelBalanceGroup property to True:
```
<ModuleConfiguration moduleName="BalanceGroupParameters">
  <Property name="O2C.AccountLevelBalanceGroup">True</Property>
</ModuleConfiguration>
```
Note:
The O2C.AccountLevelBalanceGroup property is a system-level property. You enable or disable it for all accounts and services in the system.
Save and close the file.
Load the updated file to the Metadata Services (MDS) repository. See the discussion of uploading changed files to the Oracle Metadata Services repository in Oracle Application Integration Architecture Installation Guide for more information.

If the O2C.AccountLevelBalanceGroup property does not exist in the properties file, service-level balance groups are disabled. You must add the property and set it to False if you want to enable service-level balance groups. For information about the additional steps required when adding properties to the AIAConfigurationProperties.xml file, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.

If you enable service-level balance groups in an environment that has already processed orders, any services purchased when service-level balance groups were disabled continue to be tracked in the default account-level balance group. You cannot transfer these services to different accounts or assign them different billing profiles. To track these services in their own service-level balance groups, you must modify the services directly in BRM using opcodes.

If you disable service-level balance groups in an environment that has already processed orders, any services purchased when service-level balance groups were enabled continue to be tracked in their own service-level balance groups. You can still transfer these services to different accounts and assign them different billing profiles, but BRM tracks all new services under the account-level balance group and you cannot transfer them.

Working with Service-Level Balance Groups Enabled

When you work with service-level balance groups enabled, BRM tracks each service under its own balance group. Tracking services in service-level balance groups lets your customers do the following:

Track services individually
Pay for services of a single service account using multiple billing accounts
Transfer services from one account to another
Use sharing groups to share discounts, charges, and extended rating attributes

About Tracking and Billing Services with Service-Level Balance Groups Enabled

When you purchase multiple new services on one order, BRM tracks each service in a separate balance group. BRM bills the services based on which billing profile you assign each service. You can choose from the following options for billing services:

Billing all services together: You assign all services the same billing profile.

When you submit the order, BRM tracks each service in a separate balance group and the balance groups all point to the same bill unit. Figure 12-1 illustrates this option.

Figure 12-1 Service-Level Balance Groups with a Shared Bill Unit

Description of ''Figure 12-1 Service-Level Balance Groups with a Shared Bill Unit''
Billing all services separately: You assign each service a separate billing profile in Siebel CRM. When you submit the order, BRM tracks each service in a separate balance group and each balance group points to a separate bill unit. Figure 12-2 illustrates this option.

Figure 12-2 Service-Level Balance Groups with Separate Bill Units

Description of ''Figure 12-2 Service-Level Balance Groups with Separate Bill Units''
Billing some services together and others separately: You assign the same billing profile to some services and a separate billing profile to others in Siebel CRM. When you submit the order, BRM tracks each service in its own balance group. Some balance groups point to the same bill unit and others point to separate bill units. Figure 12-3 illustrates this option.

Figure 12-3 Service-Level Balance Groups with Shared and Separate Bill Units

Description of ''Figure 12-3 Service-Level Balance Groups with Shared and Separate Bill Units''

About Tracking Services in Nested Service Bundles in Service-Level Balance Groups

Nested service bundles, including nested simple service bundles, must have the same billing profile as their parent service bundle. BRM tracks the nested service bundles in the same balance group as the parent service bundle.

When you submit an order from Siebel CRM, you must manually assign the nested service bundles the same billing profile as their parent service bundle.

Figure 12-4 illustrates how BRM tracks nested service bundles when service-level balance groups are enabled.

Figure 12-4 Balance Groups for Nested Service Bundles

This graphic is described in the following text.

In Figure 12-4, Wireless Service 2 is a service bundle nested within Wireless Service 1. Wireless Service 1 and Wireless Service 2 represent separate service instances in BRM, but BRM tracks both in the same balance group. You must assign the same billing profile to Wireless Service 1 and 2.

Because nested service bundles are tracked with their parent service bundle, you cannot transfer a nested service bundle by itself. You must transfer the parent service bundle and all of its components together.

About Tracking Service Bundles and Products Purchased on Change Orders in Service-Level Balance Groups

When you use change orders to purchase additional service bundles and products, you can purchase them separately or as components of an existing service bundle.

BRM tracks the new service bundles and products as follows:

BRM tracks each service bundle purchased separately under its own balance group. You can assign any billing profile to separate service bundles.
BRM tracks a product purchased separately from any service bundle or nested more than two levels within a service bundle in the account-level balance group. You can assign any billing profile to the new product, but the integration overrides your choice with the primary billing profile on the account.
BRM tracks a product purchased as an addition to an existing service bundle in the same balance group as the parent service bundle. You must assign the same billing profile as the parent service bundle to the new product.
BRM tracks service bundles that you purchase as additions to an existing service bundle in the same balance group as the existing service bundle when the existing service bundle was purchased after service-level balance groups were enabled. You must assign the same billing profile as the parent service bundle to the new service bundle.

Note:
If you submit an Update or Move-Add change order for a service bundle and add a new nested service bundle on the same order, BRM tracks the new nested service bundle in a separate balance group from the parent service bundle. If you want BRM to track the new service bundle in the same balance group as its parent service bundle, you must submit a separate order to add the new nested service bundle.
BRM tracks service bundles that you purchase as additions to an existing service bundle in a new service-level balance group when the existing service bundle was purchased before service-level balance groups were enabled. BRM continues to track the parent service bundle in the account-level balance group. You can assign any billing profile to the new service bundle.

For more information about service bundles and their components, see "About Service Bundles".

About Tracking Account-Level Products in the Default Account-Level Balance Group

BRM automatically tracks account-level products in the default account-level balance group created in the Create/Sync Customer Account integration flow. You can assign any billing profile to account-level products in Siebel CRM, but the integration overrides your choice with the primary billing profile on the account. You cannot transfer account-level products to different accounts or different billing profiles.

The account-level balance group of a nonpaying child account is associated with a non-paying bill unit, which points to the parent's paying bill unit. This parent bill unit is unrelated to the parent's account-level balance group. Figure 12-5 illustrates how BRM tracks account-level products for nonpaying child accounts.

Figure 12-5 Account-Level Products in Nonpaying Child Accounts

This figure is described in the preceding text.

About Transferring Services in Siebel CRM

The integration supports transferring services tracked in service-level balance groups.

You can transfer services to:

A different billing profile on the same billing account
A different billing account
A different service account

To transfer services, submit a change order to change the service account, billing profile, or billing account on the service that you want to transfer. See the discussion of using asset-based ordering in Siebel Order Management Guide for information about submitting change orders.

The following restrictions apply to service transfers:

You can only transfer services tracked in service-level balance groups. You cannot transfer any services purchased when service-level balance groups were disabled or any services purchased at the account level.
You must transfer all services tracked in a single balance group at the same time. You must transfer nested service bundles along with their parent service bundle by changing the service account on both.
If more than one BRM instance is connected to a single Siebel CRM instance, the source and target accounts for a service being transferred must be in the same BRM instance.
You cannot add or remove nested billing products in the same order as a service transfer. You must submit one order to transfer the services and a separate order to add or remove nested billing products.

Note:

If you submit an Update or MoveAdd change order to transfer a service bundle and add a new nested service bundle on the same order, BRM tracks the new nested service bundle in a separate balance group from the parent service bundle. If you want BRM to track the new service bundle in the same balance group as its parent service bundle, you must submit a separate order to add the new nested service bundle.

About Transferring Services to a Different Billing Profile

To transfer a service to a different billing profile on the same billing account, submit a change order that lists the target billing profile on the service bundle order line that you want to transfer. You must also change the billing profile for any services nested within the service being transferred.

When you submit the change order, the integration creates a new balance group and bill unit in BRM assigned to the target billing profile. Because of the automatic naming conventions for balance groups, the new balance group will have the same name as the old balance group.

About Transferring Services to a Different Billing Account

To transfer a service to a different billing account, submit a change order that lists the target billing account and billing profile on the service bundle order line that you want to transfer.

When you submit the change order, the integration creates a new balance group and bill unit in BRM and assigns it to the target billing account and billing profile. The integration also identifies that the service account is different than the billing account and creates a /billinfo hierarchy.

See "Examples of Changing the Paying Account for Child Accounts" for examples of transferring services to different billing accounts.

About Transferring Services to a Different Service Account

To transfer a service to a different service account, submit a change order that lists the target service account for the service that you want to transfer. You can also transfer the service to a different billing profile on the same change order.

When you submit the change order, the integration transfers the service to the target account and creates a new balance group and bill unit in BRM assigned to the target account's billing profile.

Working with Service-Level Balance Groups Disabled

When you work with service-level balance groups disabled, BRM uses the default account-level balance group to track and pay for all of their services together.

The default account-level balance group is created at the same time as the customer account in the Create/Sync Account integration flow. When service-level balance groups are disabled, BRM tracks all services and products for an account under this default account-level balance group. You cannot use sharing groups or split billing when service-level balance groups are disabled.

When you create subsequent orders for services (including nested service bundles and additional services purchased on change orders), you must use the same billing profile as the one selected on the first order.

Figure 12-6 illustrates how services are tracked under the account-level balance group.

Figure 12-6 Tracking Services in the Default Account-Level Balance Group

Description of ''Figure 12-6 Tracking Services in the Default Account-Level Balance Group''

When you submit a single order for multiple products, the integration uses the billing profile of the first service on the order for all subsequent services on the same order. If an order for the services in Figure 12-6 assigned separate billing profiles to Wireless and Broadband, the result would remain the same because the billing profile for Wireless (the first service on the order) would be used for both services.

Supporting Product Bundling

When you submit an order in Siebel CRM containing bundled products, the integration synchronizes the service bundles to service instances and the component products and discounts to purchased product and discount instances in BRM.

The integration synchronizes account-level products, account-level discounts, and any product or discount nested more than two levels below a service bundle to account-level purchased product and discount instances in BRM.

Note:

Because dynamic and relationship classes are not sent to BRM with the Siebel CRM order, they do not help determine a nested service bundle or nested product's parent.

See "Understanding Product Bundling" for more information about product bundling in Siebel CRM.

Examples of Mapping for Bundled Products

This example shows how the integration maps a Siebel CRM service bundle containing products, discounts, non-service-bundle customizable products, and nested service bundles from Siebel CRM to BRM.

Billing Products A through G and Billing Discount A are all synchronized from BRM to Siebel CRM. The service bundle hierarchy in Siebel CRM, illustrated in Figure 12-7, is as follows:

Service Bundle 1 (SB1) contains Discount A, Billing Product A, and a non-service-bundle customizable product (CP1).
Billing Product A is modeled as the parent of Billing Product B.
CP1 contains Billing Product C, a second service bundle (SB2), and a simple service bundle (SSB1).
Billing Product C is modeled as the parent of Billing Product D.
SB2 contains Billing Products E and F.
SSB1 is the enriched form of Billing Product G, a BRM subscription product.

Figure 12-7 Example of Siebel CRM Service Bundle Hierarchy

This image is described in the preceding text.

When you submit an order for SB1, the integration creates the following elements in BRM:

A service instance for SB1 with purchased product instances for Billing Products A through C and a purchased discount instance for Billing Discount A
A service instance for SB2 with purchased product instances for Billing Products E and F
A service instance for SSB1 with purchased product instance for Billing Product G

The integration synchronizes Billing Product D to an account-level purchased product instance in BRM because it is nested more than two levels below a service bundle.

For the integration to synchronize Billing Product D to a purchased product instance under the service instance for SB1, you should model it in Siebel CRM as a sibling of Billing Product C, as in Figure 12-8.

Figure 12-8 Example of Remodeled Billing Products

Description of ''Figure 12-8 Example of Remodeled Billing Products''

You can submit orders for non-service-bundle customizable products that are not included in service bundles. However, because the integration does not create service instances in BRM for non-service-bundle customizable products, it maps billing products or discounts that are in a non-service-bundle customizable product but not included in a service bundle to account-level purchased product or discount instances in BRM. For example, on an order for CP1 alone, the integration maps Billing Products C and D to account-level purchased product instances.

Synchronizing Simple Service Bundles

When you submit an order for a simple service bundle, the integration synchronizes it as a service bundle, creating both a service instance and a purchased product instance in BRM. If the quantity on a simple service bundle line is greater than one, the quantity applies to the product instance alone.

Both single-phase billing and two-phase billing are supported for the simple service bundles.

Changing Purchased Simple Service Bundles

Suspending, resuming, or disconnecting the asset that represents a simple service bundle in Siebel CRM suspends, resumes, or cancels the service and purchased product instance in BRM. You cannot suspend, resume, or cancel the product without suspending, resuming, or canceling the service.

Transferring the asset that represents a simple service bundle in Siebel CRM using an order with Move-Add or Move-Delete line actions adjusts the cross-references of the service and purchased product instances in BRM.

Updating the service instance attributes (for example, Service ID, billing account, billing profile) on the asset that represents a simple service bundle in Siebel CRM updates the service instance in BRM.

Updates to product attributes other than quantity changes (for example, pricing changes, promotion reference) on the asset that represents a simple service bundle in Siebel CRM updates the purchased product instance in BRM. You can also make changes to billing dates as part of two-phase billing.

If you applied a onetime charge for a line action in Siebel, the integration applies the charge to the balance group for the simple service bundle's service instance in BRM.

Simple Service Bundle Cross-References Entries

To support simple service bundles by mapping a single asset to both a service instance and a purchased product instance in BRM, the integration creates a cross-reference entry in the InstalledProduct cross-reference table, as shown in Table 12-1.

Table 12-1 Simple Service Bundle Cross-References Example

Cross-Reference Type	Siebel_01	Common	BRM_01
InstalledProduct_Id	Siebel-S01	C-ON-01	BRM-A01
InstalledProduct_Id	--	C-ON-01+Child	BRM-B01

In this example, BRM-A01 is the BRM portal object ID (POID) for the service instance and BRM-B01 is the BRM POID for the purchased product instance. The common ID for the purchased product instance is the same value as the common ID for the service instance with the string "+Child" appended to it.

Synchronizing Promotion Groups

When you submit an order from Siebel CRM containing promotion groups, the integration creates sharing groups in BRM. Sharing groups are collections of accounts consisting of one owner account and one or more member accounts that share a discount, charge, or profile.

The integration uses promotion group line items on sales orders to create sharing group objects in the BRM database as follows:

Reward product: For each reward in the promotion group, the integration creates a separate sharing group object. A single promotion group definition in Siebel CRM can include several reward products of different types, but each BRM sharing group includes only one type of reward, so a single promotion group on a sales order can result in multiple sharing groups in BRM.
Owner membership product: The integration adds the service or account associated with the owner membership product as the sharing group owner. The integration adds the service-level or account-level balance group for that service or account as the sharing group's owning balance group.
Member membership product: The integration adds the services associated with the member membership products as sharing group members. If a bundled promotion is associated with the member membership product, the integration adds each service bundle nested within the bundled promotion as a sharing group member.

You can use change orders to add or delete optional components of bundled promotions that are associated with promotion group member membership products. The integration adds or deletes the components as sharing group members.

The integration also creates an ordered balance group for each member of a sharing group to set the order in which BRM applies shared rewards to usage events. By default, BRM applies discounts first, then chargeshares, then extended rating attributes. Any discounts that a sharing group member owns that are separate from the shared discounts are consumed before the shared discounts.

For example, for the order in Table 8-5, "Example of an Order for a Promotion Group", the integration creates the sharing group objects shown in Table 12-2 in BRM.

Table 12-2 Sharing Group Objects Created in BRM for an Example Promotion Group Order

Sharing Group Object	Owner	Owning Balance Group	Reward	Member
/group/sharing/discounts	Corporate's VoIP Service	Service-level balance group for corporate's VoIP Service	Corporate's VoIP 5000 Free Minutes discount	Andrew's VoIP Service
/group/sharing/charges	Corporate's VoIP Service	Service-level balance group for corporate's VoIP Service	Corporate's VoIP 50% Sponsorship chargeshare	Andrew's VoIP Service
/group/sharing/profiles	Corporate's VoIP Service	Service-level balance group for corporate's VoIP Service	Corporate's VoIP Employee Special Rating extended rating attribute	Andrew's VoIP Service

The integration also creates an ordered balance group for Andrew's VoIP service. This ordered balance group is represented in the BRM database by an /ordered_balgrp object that ranks the three sharing groups created on the order.

When Andrew uses his VoIP service and generates a usage charge, BRM discounts the charge according to the ordered balance group as follows:

BRM applies any discounts Andrew owns that are not part of the sharing group.
BRM applies the shared VoIP 5000 Free Minutes discount.
If the shared discount is used up, BRM applies the VoIP 50% Sponsorship chargeshare.
BRM applies any discounts from an extended rating attribute.
BRM bills Andrew for any remaining amount on the usage charge.

For more information about sharing groups and ordered balance groups in BRM, see:

The discussion of managing resource sharing groups in BRM Managing Accounts Receivable
The discussion of working with profile sharing groups in BRM Managing Customers
The discussion of how discounts and charges are applied in BRM Managing Accounts Receivable

Synchronizing Family Share Plans

When you submit an order from Siebel CRM containing service bundles that have the Community Member attribute enabled and discounts that have the Community Offer attribute enabled, the integration creates sharing groups in the BRM database.

For each order line with the Community Offer attribute enabled, the integration creates a sharing group in BRM. The integration adds the service of the ordering service account as the sharing group owner and the services on the same order with the Community Member attribute as members of that sharing group.

For example, for the order in Table 8-6, "Example of an Order for a Family Share Plan", the integration detects that the 5 GB Free Data discount has the Community Offer attribute enabled and creates the sharing group object shown in Table 12-3 in BRM.

Table 12-3 Sharing Group Objects Created in BRM for an Example Family Share Plan Order

Sharing Group Object	Owner	Owning Balance Group	Reward	Members
/group/sharing/discounts	Denise's Primary Line	Service-level balance group for Denise's Primary Line	Denise's 5 GB Free Data discount	Michelle and Jessica's Add-on Lines

The integration also creates ordered balance groups for Denise's Primary Line and Michelle and Jessica's Add-on Line services, ranking the new shared discount in order with any other discounts that they own.

Synchronizing Service Grouping

When you submit an order from Siebel CRM containing product promotions with service bundles that have the Service Grouping attribute enabled, the integration creates subscription groups in the BRM database (called service groups in PDC).

For each order line with the Service Grouping attribute enabled, the integration creates a subscription group in BRM, with nested services added as members under the parent service. All of the members of the subscription group are tracked together under one balance group in BRM.

For example, for the order shown in Table 8-6, "Example of an Order for a Family Share Plan", the integration detects that the Primary Line and Add-on Lines have the Service Grouping attribute enabled and creates the subscription groups shown in Figure 12-9.

Figure 12-9 Subscription Groups Created in BRM for an Example Family Plan Order

Description of ''Figure 12-9 Subscription Groups Created in BRM for an Example Family Plan Order''

BRM tracks Denise's three services under one balance group for the Primary Line, Jessica's three services under one balance group for her Add-on Line, and Michelle's three services under one balance group for her Add-on Line.

See the discussion of grouping services by subscription in BRM Managing Customers for more information about subscription groups in BRM.

Supporting Single-Phase and Two-Phase Billing

The integration supports both single-phase and two-phase billing. In single-phase billing, the order is interfaced to billing (or billing-fulfilled) after the service is provisioned. In two-phase billing, the order is billing-initiated before the service is provisioned, and is billing-fulfilled after service activation.

Choosing Between Single-Phase and Two-Phase Billing

Billing fulfillment scenarios lead to one of two fulfillment patterns, each of which must be supported by the order management implementation.

Single-Phase Billing

With single-phase billing, a service is interfaced to billing through billing fulfillment toward the end of the fulfillment flow, after the order is delivered and the actual delivery date is known.

You use single-phase billing in the following situation:

When you do not have time lag or validation concerns. In this situation, interfacing to billing takes place after the service or product is made available to the customer.

The date that a product is made available can vary based on jurisdiction and whether the product is a service or a physical good. For example, physical goods that require no network activation or on-site installation might be billed immediately after the goods are shipped. The exact timing is built into the fulfillment flows associated with the underlying product specification through the Actual Delivery Date and other billing date attributes.

Two-Phase Billing

With two-phase billing, the integration interfaces a service to billing twice:

Billing initiation: The service and purchased products are interfaced early in the fulfillment flow and before actual delivery dates are known.
Billing fulfillment: Accurate billing dates are updated in billing after the order is delivered and the actual delivery date is known.

You use two-phase billing in the following situations:

Fulfillment latency: when operational or deployment conditions produce a time between the time a service is made available for customer use and the time the service is interfaced into billing.

The time lag can cause errors in the usage records resulting in lost revenue. Rather than attempting to plan fulfillment of future-dated orders to meet the requested delivery date, build the fulfillment flow so that the Usage Start Date is set to the current date during billing initiation, and the Cycle Start Date is set to a distant future date. At billing fulfillment, the Cycle Start Date is then reset to match the Actual Delivery Date or Requested Delivery Date, depending on business practices and legal requirements.
Validation latency: When you have inadequate controls to guarantee that orders are valid, resulting in a high rate of invalid orders, and the cost of delaying order line validation for interfacing to billing is high.

In this situation, orders must be interfaced to billing early in the fulfillment flow to ensure that the order can be interfaced successfully later. Build the fulfillment flow so that the Purchase Start Date, the Usage Start Date, and the Cycle Start Date are set to a distant future date during Initiate Billing. At the time of Fulfill Billing, the Purchase Start, Usage Start Date, and Cycle Start Date are reset to match the Actual Delivery Date or Requested Delivery Date, depending on business practices and legal requirements.

Using Single-Phase Billing or Two-Phase Billing

To support various fulfillment latency requirements, the order billing interface can be called in two modes (by setting the ProcessFulfillmentOrderBillingEBM /DataArea/ProcessFulfillmentOrderBilling/FulfillmentModeCode):

INITIATE BILLING
FULFILL BILLING

To enable single-phase billing, the order management system calls the order billing interface using only the FULFILL BILLING mode.

To enable two-phase billing, the order management system calls the order billing interface using the INITIATE BILLING mode before the service is provisioned and then after service activation, calls it using the FULFILL BILLING mode.

INITIATE BILLING Mode

You can design an order orchestration flow to interface the order to billing before the order is sent to provisioning. Calling the interface in INITIATE BILLING mode is optional. The billing interface is called with either of the following:

The whole order: all of the lines on the order that are intended for a certain target billing system and related lines such as promotion lines.
Order components: promotion lines, service bundle lines and all service bundle component lines, and account-level products. All component lines for a single service bundle must be sent for billing initiation and fulfillment together. Any service bundle component lines sent only for billing fulfillment are not processed.

Depending on the requirements, you can set some or all of the following dates on new purchases of products or discounts to the future (in essence they are treated as inactive when interfaced to billing):

Purchase Date (ProcessFulfillmentOrderBillingEBM /DataArea/ProcessFulfillmentOrderBilling/FulfillmentOrderLine/FulfillmentOrderSchedule/PurchaseDate)
Cycle Start Date (ProcessFulfillmentOrderBillingEBM /DataArea/ProcessFulfillmentOrderBilling/FulfillmentOrderLine/FulfillmentOrderSchedule/CycleStartDate)
Usage Start Date (ProcessFulfillmentOrderBillingEBM /DataArea/ProcessFulfillmentOrderBilling/FulfillmentOrderLine/FulfillmentOrderSchedule/ServiceUsageStartDate)

For promotion lines, only the purchase date is relevant.

To rate usage as soon as the service is activated but start the cycle fees at the date that the customer requested the service when there is a fulfillment latency between service activation and billing, have your order management system set the purchase and usage start dates to current and the cycle start date to the future when calling this service. See "General Modeling and Implementation Recommendations" for more information.

In this mode, the order interface to billing processes only new purchases of services or account-level products, or new purchases of products for existing services.

If a promotion is purchased as part of the new purchase, then that is also processed. One-time charges for actions such as Suspend, Resume, Move, and Disconnect and promotion penalties are not processed in this mode.

See "Mapping Billing Dates" for more information about how dates are set in BRM.

Handling Revision Orders

BRM prevents the caller from resetting purchase and cycle start dates when they become current. The integration does not reset the purchase date as part of billing-initiation revision processing, but resets the cycle start and usage start date if asked by the caller.

However, when billing initiation is called to process a revision on order lines that are billing initiated, and the call resets the cycle start date when the previously set date is current, then billing initiation fails with a BRM validation error.

General Modeling and Implementation Recommendations

The interface validates that the cycle date is set to the future for products of type Subscription or Discount. For products of type Item, the interface validates that the purchase date is set to the future. Oracle recommends that you set the future billing date to a year ahead of the due date when calling billing initiation.

The purchase, cycle start, or usage start dates is in the future if the following is true about the billing date:

billing date > (Fusion Middleware current time converted to UTC + (25 or FutureTimeThreshold hours, whichever is greater)).

where FutureTimeThreshold is the value of the FutureTimeThresholdForBillingDates Oracle AIA configuration property. This property has a default value of 8640 hours (360 days in hours).

If you are highly confident of the lead time required to activate the service, then you can lower the value of the FutureTimeThresholdForBillingDates property such that the order management system does not have to call fulfill billing to reset the dates that were set in initiate billing. This also allows the billing dates to naturally become current soon after the service is activated. You can set this property for each BRM instance.

If the FutureTimeThresholdForBillingDates property is not specified for a given billing instance, then the integration assumes the default value of 8640 hours (360 days).

Products of billing type Item must be purchased with a future date in billing initiation to enable the integration to cross-reference them and therefore avoid repurchasing them in billing fulfillment. The 25 hour minimum threshold is hard-coded to enable this.

BRM requires that the purchase date be before or equal to usage and cycle start dates. If the caller does not follow this for any line*, then the billing interface (BRM ABCS) errors.

Recommendations for Purchase Fees or Activation Charges

BRM requires that the purchase date on a product be the same as or earlier than the usage start date. If activation (purchase fees) and usage charges were modeled on the same product to support the fulfillment latency situation, you must set both the purchase date and start usage date to current. However, if the customer cancels their order before the service was provisioned, you must manually process a refund of the activation charges to them. To avoid this manual process, you must model the activation (purchase) fee on a product of type Item, which is a separate product from the one on which the usage and cycle charges are modeled. Now to support the fulfillment latency situation, you set the purchase date for products of type Item to the future and set the purchase and usage start dates for the subscription products to current.

Recommendations for Discounts

If the service bundle includes products representing purchase or usage discounts, then to ensure that the customers get the discount, the purchase and usage start dates for the discount products must also be set to current when you are modeling the flow that sets the purchase and usage start dates to current for the subscription products.

FULFILL BILLING Mode

After provisioning is complete, the order orchestration flow can interface the order to billing in this mode. This is the default mode that the integration supports and is required to interface an order to billing.

In this mode, the integration processes all order lines that are sent on new orders or change orders. One-time charges for actions such as Suspend, Resume, Move, and Disconnect and promotion penalties are processed in this mode.

For order lines that have been interfaced in the INITIATE BILLING mode, the caller can now set a specific date* (based on the actual delivery date) for those new purchases whose billing dates were earlier set to the future. Therefore, for the case in which only the cycle start date was set to the future during billing initiation, it must now be reset to the actual delivery date. For the case in which the purchase, cycle start, and usage start dates were set to the future, the caller must now set them to the actual delivery date.

The integration determines that an attribute has changed if prior value fields are populated. Your order management system must set the prior value fields for the following billing dates:

PurchaseDate: ProcessFulfillmentOrderBillingEBM/DataArea/ProcessFulfillmentOrderBilling/ PriorFulfillmentOrder/FulfillmentOrderLine/FulfillmentOrderSchedule/ PurchaseDate
CycleStartDate: ProcessFulfillmentOrderBillingEBM/DataArea/ProcessFulfillmentOrderBilling/ PriorFulfillmentOrder/FulfillmentOrderLine/FulfillmentOrderSchedule/ CycleStartDate
ServiceUsageStartDate: ProcessFulfillmentOrderBillingEBM/DataArea/ProcessFulfillmentOrderBilling/ PriorFulfillmentOrder/FulfillmentOrderLine/FulfillmentOrderSchedule/ ServiceUsageStartDate

Caution:

If billing dates were set to current in billing initiation, resetting them in billing fulfillment causes a BRM error.

Assumptions and Constraints for Two-Phase Billing

For multi-event billing products, the integration honors billing dates (purchase start date -nrc_start_date, cycle start date - rc_start_date, usage start date - usage_start_date in Siebel CRM) on the parent complex product alone.
Billing initiation is optional, but billing fulfillment is mandatory for an order (or order lines) to be interfaced to billing.
The product that an order line references does not change after the line has been billing-initiated.
The order management system sends the one-time charge associated with a MACD action (Suspend, Resume, Move, Disconnect) with the service bundle on which the action is being performed.
Every MoveAdd line on a Siebel CRM order has a matching MoveDelete (and vice versa). The order management system sends MoveAdd lines along with the MoveDelete lines to billing.
After order lines are submitted for billing fulfillment, they are assumed to have hit a hard point of no return and cannot be revised in Siebel CRM.
Service ID is always sent as input to the billing interface (Initiation or Fulfillment).

See "Mapping Billing Dates" for more information about how dates are set in BRM.

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 resubmitted, then the order management system compares the revised line against what was submitted to billing initiation, 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 "Supporting MACD Actions and Attribute Changes" 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).

Caution:

The integration does not check for changes to the Special Rating List reference on revision orders when the List product has been billing-initiated.

Table 12-4 summarizes revision actions.

Table 12-4 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.

Supporting Time-Based Offerings on Orders

Time-based offerings let you use a Siebel CRM product class to set validity periods for products and discounts synchronized from BRM. You purchase time-based offerings on orders in the same way as other products and discounts and the integration calculates the validity periods as described in "Supporting Time-Based Offerings on New Orders" and "Supporting Time-Based Offerings on Change Orders".

For information about creating time-based offerings and managing expired time-based offerings, see "About Time-Based Offerings".

Note:

If you are using an order management system other than OSM, Oracle recommends that you configure your system not to set end dates during billing initiation. End dates are not required for billing initiation, and setting them during billing initiation avoids the requirement to manage them as part of revisions.

OSM AIA cartridges do not set end dates during billing initiation.

Supporting Time-Based Offerings on New Orders

The integration processes new orders for time-based offerings as follows:

When you submit the order, Siebel CRM calculates the end date based on the start date (defaulted from the due date) and the Duration, DurationUnitOfMeasure, and DurationValidityStart transaction attribute values and sends the order through the integration to OSM for fulfillment.
When fulfilling the order, the OSM AIA cartridges set the purchase, cycle start, and usage start dates based on service actual delivery date and recalculates the end date.
When the order is billing fulfilled, the integration communicates the end date for the purchased product or discount to BRM.
OSM sends the actual start and end dates through the integration to Siebel CRM as part of the order update message.

Supporting Time-Based Offerings on Change Orders

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

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.
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
When the order is billing fulfilled, the integration communicates the new end date for the purchased product or discount to BRM.
OSM sends the changed end dates through the integration to Siebel CRM as part of the order update message.

Supporting Friends and Family Lists

Friends and family lists, implemented as special rating products and included in service bundles in Siebel CRM, let your customers call certain phone numbers at discounted rates.

Your customers can share a common friends and family list by purchasing promotion groups that include special rating products as rewards. See "About Promotion Groups" for more information about promotion groups.

When customer service representatives create orders for service bundles and0 promotion groups that include special rating products, they create the friends and family lists, optionally add numbers to the lists, and associate the lists with the special rating products.

When the order is interfaced to BRM, the integration creates a list profile for every order line that has a special rating product. These list profiles are associated with the service instance in BRM. For the list profile to get created during order billing integration, a special rating list must be associated to the special rating product on the order.

When the order is successfully interfaced to BRM and is auto-asseted, the special rating product used to capture the list is tracked as an asset in Siebel.

Caution:

The integration assumes that if the same special rating list is referenced by multiple services, such as VoIP and Wireless Voice, those services are fulfilled in the same BRM instance. See "Configuring Multiple BRM Instances for Communications Integrations" for more information.

See "About Friends and Family Lists" and the discussion of profiles in Siebel Communications Guide for more information about creating special rating product and profiles at design time.

Using Change Orders with Special Rating Products

You can use change orders in to make changes to special rating products in the following situations:

Changing special rating list items:
- You can associate a completely different list with the special rating product using a modify order to update the special rating list reference on the existing special rating product asset to a different list reference. When the integration processes the change, it updates the list profile in BRM with contents from the new list.
- You can add or remove items from a list currently associated with a special rating product. Use the Siebel Special Rating Profile subview to make changes to the list and synchronize them to BRM.
Upgrading or downgrading promotions:

Upgrading or downgrading promotions can add or cancel special rating products for existing services. When special rating products are cancelled, the integration deletes the respective list profile in BRM. When special rating products are added, the integration creates new list profiles in billing for the given service instance.
Cancelling services:

When you cancel a service bundle that includes a special rating product, the integration deletes the list profile in BRM.

Supporting Split Billing

You can split bills among multiple parent and child accounts using /billinfo hierarchies. When you submit an order that has order lines that include a billing account that is different from the service account, the integration creates a /billinfo hierarchy under the service account while creating the account in BRM.

The /billinfo hierarchy includes an entry for each paying /billinfo associated with the billing account and billing profile on the order line. When BRM generates the bill for the child account's services, it uses the /billinfo hierarchy to assign the bill to the correct paying account.

For example, for the order described in Table 8-7, "Order Including Split Billing", the /billinfo hierarchy under Scott's account would include entries for the /billinfo objects corresponding to the Duncan-Scott billing profile and the Cathy-Scott billing profile. When BRM generates the bills for Scott's account, it uses Scott's /billinfo hierarchy to send the bill for the broadband service to Duncan and the bill for the wireless service to Cathy.

For more information about /billinfo hierarchies and how they relate to account hierarchies in BRM, see the discussion of hierarchical bill units in BRM Managing Accounts Receivable.

Assumptions and Constraints for the Bill Fulfillment Order Business Flow

The assumptions and constraints for the Bill Fulfillment Order business flow are as follows:

The integration only supports defining a single brand within a single instance of BRM.
After an order in Siebel CRM is submitted for processing and successfully interfaced to billing, it cannot be changed and resubmitted. You must enforce this by defining rules in the Siebel CRM state model. The order can be revised and resubmitted for processing if it has not reached a point of no return. The integration assumes that the order line reaches the point of no return after the line has been sent for billing fulfillment.
The integration does not support copied orders in Siebel CRM because Siebel CRM does not regenerate the asset integration ID that uniquely identifies purchases on the copied order. Instead of copying orders, Oracle recommends that you use the Siebel CRM Favorites feature.
Regarding quantity support for service bundles and account-level products, the solution assumes that the auto-explode flag on service bundle products is set to Yes and that the customer is using Siebel Asset Based Ordering processes to enforce service item instantiation.
- The service bundle line always has a quantity of 1 when the order is handed off from Siebel CRM to the integration with the integration creating a single service instance in BRM (per service bundle line on the Siebel order).
  
  No special handling exists for order quantity > 1 for products whose auto-explode flag in Siebel is set to No.
- Quantity (and not extended quantity) on service bundle components or account-level products is interfaced to BRM; this creates purchased product or discount instances (one instance per product or discount purchased) with the specified quantity, which is used to determine charge calculation.
- When an order line is interfaced to Siebel CRM assets it creates a single asset with the specified quantity.
  
  Additionally, the integration does not look at quantity changes on revisions, or change orders (for existing products) and therefore such changes are not communicated to BRM.
No special handling exists for shippable goods. No support is available for returns or credit orders.
If you are also using the Agent Assisted Billing Care pre-built integration, order lines that must be sent to different billing systems must have different billing profiles.
Order lines are interfaced to billing only after they have been provisioned.

Based on this assumption, the service that interfaces the lines with billing creates the service instances, purchased product instances, purchased discount instances, or a combination of these as active. This applies to scenarios of single-phase billing, in which billing interface is called one time in Fulfill Billing mode.
For self-paying accounts, the service account, billing account, and billing profiles must be the same on all order lines for components in a service bundle.
- When service-level balance groups are enabled, you must ensure that these fields are the same for service bundles and their components.
- When service-level balance groups are disabled, any integration logic that works on these fields looks only at the service bundle line. This constraint also applies to one-time charges that are added for MACD actions such as suspending or resuming a service, in that the integration ignores the service account, billing account, and billing profiles on such lines and applies the charge to the default account-level balance group.
For nonpaying child accounts, when service-level balance groups are enabled, the billing account can be different for service bundles and simple service bundles nested within a service bundle. For example, if two parents pay for the services of one child, one service bundle component could list one billing account, while a different component in the same service bundle could list a different billing account. An order including multiple billing accounts for the same service account results in a /billinfo hierarchy in BRM.
The integration does not support changing from nonpaying child account to self-paying account or changing from self-paying account to nonpaying child account. Changing accounts in this way does not produce an error but results in data that breaks the billing management integration flows.
A nonpaying child account can have multiple paying parents. In Siebel CRM, this relationship is represented in the account hierarchy, and by assigning different billing accounts to the services for one service account. In BRM, this relationship is represented by a /billinfo hierarchy.
All lines within a service bundle reference products from the same billing system.

A single Siebel CRM asset can be mapped to a service instance or a purchased product or discount instance in only one billing system.
The integration assumes that the service bundle and its component products reference the same billing service type. This assumption applies only to component products that represent BRM products of type Subscription or BRM discounts. Violation of this assumption results in a BRM error. Nested service bundles do not have to have the same service type as the root parent service bundle. See "About Billing Service Types for Service Bundles" for more information.