| Oracle® Application Integration Architecture Oracle Communications Order to Cash Integration Pack Implementation Guide for Siebel CRM, Oracle Communications Order and Service Management, and Oracle Communications Billing and Revenue Management Release 11.3 Part Number E37675-02 |
|
|
PDF · Mobi · ePub |
This chapter explains how the Bill Fulfillment Order business flow interfaces orders from Siebel customer relationship management (Siebel CRM) to Oracle Communications Billing and Revenue Management (BRM) through an order management system like Oracle Communications Order and Service Management (OSM).
The Bill Fulfillment Order business flow is enabled by the following Pre-Built Integration option of the Oracle Communications Order to Cash Integration Pack for Siebel CRM, OSM, and BRM (the integration):
Oracle Communications Order to Cash for Siebel CRM, OSM, and BRM Pre-Built Integration option
In the Bill Fulfillment Order business flow, OSM uses orders submitted in Siebel CRM to create transaction data and bill customers in BRM.
You can also use an order management system other than OSM to call these services, provided it meets certain expectations. See "Expectations from an Order Management System for Billing Integration" for more information.
The integration supports purchasing the following in BRM in new orders or change orders:
Products of type Item that apply to an account (for example, promotion penalty charges) or service (for example, one-time charges).
Products of type Subscription that apply to an account (for example, charges for mailing a monthly paper invoice) or service (for example, wireless service).
Discounts of type Subscription that apply to an account (for example, account-level discounts) or service (for example, a free minutes discount).
BRM products and discounts design-time data is synchronized to Siebel CRM by the process integration for product lifecycle management (PLM). See "Understanding the Process Integration for Product Lifecycle Management" for more information.
See "Supporting MACD Actions and Attribute Changes" for examples of supported products.
This section describes the actions taken by the process integration when interfacing new or change orders to BRM.
When interfacing orders, the integration creates or updates service instances and purchased product and discount instances in BRM.
The integration supports the following actions: Add, Delete, Update, Suspend, Resume, MoveAdd, and MoveDelete.
It communicates updates to the service identifier, billing account, billing profile, and price changes on existing services.
When an old product is canceled as part of service cancellations or promotion upgrade or downgrades, whether the customer gets a refund for (billed) monthly charges or whether the refund is prorated depends on product level controls in BRM.
The integration lets you change the service identifier, billing account, and billing profile as part of a Move-Add/Move-Delete transaction. The integration does not support purchasing new products or canceling existing products as part of a Move transaction.
Transferring a service from one location to another in Siebel CRM results in lines with the action of Move-Add and Move-Delete.
See "Supporting MACD Actions and Attribute Changes", "Examples of Changing the Paying Parent on Subordinate Accounts" and "Mapping Billing Dates" for more information.
When interfacing orders, the integration communicates pricing information such as price or discount overrides, discounts, and onetime and penalty charges.
For price changes that occur mid-cycle, the integration passes the price or discount overrides on a purchased product as is, the new price goes into effect from the following billing period, and no credits or debits are issued for the current period. If you want the new price to go into effect immediately, then the Siebel CRM user must disconnect the product and then add it with the new price.
One-time charges for actions such as suspend and resume are applied as service-level charges. Penalty charges incurred for compromising a promotion agreement are communicated to BRM as account-level charges. See "About One-Time Charges for Service Activation and Changes to Promotions and Service Bundles" for information about one-time and penalty charges in BRM.
Siebel CRM supports defining charges for Suspend, Resume, Move, and Delete actions. You can extend Siebel CRM beyond the ready-to-use support to define charges for other actions such as Update.
For example, you can charge a customer a fee for requesting a change to their phone number or billing profile. The order billing integration supports such charges regardless of the action that triggered the charge.
The integration expects order lines representing such charges to be tied to the service bundle line using the related asset integration ID and due date (on the Siebel CRM order line) and using the charge parent line (on the order enterprise business message (EBM)). Therefore, any lines on the order that are tied to the service bundle line (regardless of the action on that line) using the related asset integration ID and due date (on the Siebel CRM order) and using the charge parent line (on the order EBM) are processed by the billing interface and applied to the respective service instance.
The one-time charge points to the service bundle line using the related asset integration ID. The integration assumes that the due date on the charge line equals the service bundle line with the new order or change order action that triggered the 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 are 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 are the same.
See "About Service Bundles" for more information about service bundles and "Supporting Balance Groups" for more information about service-level balance groups.
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.
The pricing commit type on the order line 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 communicated as a price or discount override to billing. Price overrides cannot be accounted for in General Ledger in BRM but discount overrides can be.
If the pricing commit type is set to Committed, then the integration sets a price override when purchasing the product in billing.
If the pricing commit type is set to Dynamic, then the integration sets a discount override when purchasing the product in billing.
The Dynamic Discount method on the line controls whether the discount override is of type Percent or Amount.
In the case in which the intent is to use BRM pricing as is, the pricing commit type on the order line must have a value of Dynamic, and neither the discount amount nor the discount percent are set. In this case, the integration sets neither a price nor a discount override for the product purchased.
Note:
At most, for a charge type within a given product, BRM allows a single override price. If, for example, a BRM product is mapped to multiple events of the same type and is synchronized to Siebel CRM as a complex product with multiple simple products, Siebel CRM cannot override the price for the charge type that has multiple charges defined. If it does, it is applied as the override value for all charges of that charge type. This same constraint also applies to discount overrides.See Siebel Order Management Guide Addendum for Communications for more information about using the pricing commit type and dynamic discount method.
Orders submitted from Siebel CRM can specify a separate price list in the order header and at each order line. The integration communicates the price list ID from the creation of a sales order in Siebel CRM to orchestration and provisioning in OSM and to fulfillment in BRM. See "Supporting Multiple Price Lists" for more information about how the integration passes price list information from Siebel CRM to OSM.
The integration gets price list information from OSM in a ProcessFulfillmentOrderBillingEBM message and passes it to BRM as an ABM. The ABM contains price list IDs for the order header and each order line. BRM uses the price list IDs and associated rate plans to charge the appropriate amount for the products or services purchased on the order lines.
When interfacing orders, the integration communicates the service identifiers on the service bundle line in Siebel CRM to BRM. For telephony services, the service identifier is used as the phone number. For nontelephony service, it is used as the login and password.
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 the purchase date from 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.
The 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.
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 a Siebel CRM 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 in Siebel CRM are synchronized as bill units (/billinfo objects) in BRM.
For more information about Siebel CRM orders, see "About Sales Orders" and Siebel Order Management Guide.
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 "How BRM Tracks 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.
To disable service-level balance groups:
Open the AIA_home/aia_instances/AIA_Instance_Name/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 updating MDS in Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack 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 are enabling service-level balance groups when they were previously disabled, any services purchased when they 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 are disabling service-level balance groups when they were previously enabled, the services purchased when they 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.
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
Transfer services from one account to another
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
Billing all services separately: You assign each service a separate billing profile. 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
Billing some services together and others separately: You assign the same billing profile to some services and a separate billing profile to others. 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
When you purchase service bundles containing nested service bundles (including simple service bundles), you must assign the nested service bundles the same billing profile as their parent service bundle. When you submit the order, BRM tracks the nested service bundles in the same balance group as the parent service bundle.
See "How BRM Tracks Service Bundles and Products Purchased on Change Orders in Service-Level Balance Groups" for information about how BRM tracks services in balance groups when you use a change order to add new nested services to existing service bundles (Siebel CRM installed assets).
Figure 12-4 illustrates how BRM tracks nested service bundles when service-level balance groups are enabled.
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.
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 MoveAdd 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 their components, see "About Service Bundles".
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, 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 integration supports transferring services tracked in service-level balance groups. You can transfer services to a different billing profile on the same account or to a different service account.
To transfer services, submit a change order to change the service account and billing profile information 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. This restriction means that 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 Account
To transfer a service to a different 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.
About Transferring Services to a Different Billing Profile
To transfer a service to a different billing profile on the same 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.
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.
When you create subsequent orders for services (including nested service bundles and additional services purchased on change orders), you must use assign the same billing profile as the one selected on the first order.
Figure 12-5 illustrates how services are tracked under the account-level balance group.
Figure 12-5 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-5 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.
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.
This example shows how the integration maps a 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-6, 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.
When a 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-7.
Figure 12-7 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.
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.
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 MoveAdd or MoveDelete 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.
To support simple service bundles by mapping a single Siebel CRM 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.
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.
Billing fulfillment scenarios lead to one of two fulfillment patterns, each of which must be supported by the order management implementation.
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.
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.
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.
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.
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).
Tip:
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.
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.
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.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.
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-2 summarizes 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. |
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.
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.
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.
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.
The friends and family feature enables end customers to call certain phone numbers at discounted rates. The feature requires special rating products to be defined in Siebel CRM and included in a service bundle.
See "Supporting Friends and Family" for more information about how special rating products are supported and the methodology.
When orders for such service bundles are placed, the customer service representative (CSR) can create the lists, optionally add numbers to the lists, and associate the lists with the special rating products.
See "Profiles in Siebel Communications" in Siebel Communications Guide for more information.
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 list (special rating profile 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 solution assumes that if the same special rating list is referenced by multiple services, (for example, VOIP and Wireless Voice) those services are fulfilled in the same BRM instance.See "Supporting Friends and Family" and "Configuring Multiple BRM Instances for Communications Integrations" for more information.
Here are some recommendations for using change orders and special rating products.
Changing Special Rating list entries:
You can use either of the following two options to achieve this:
Tying a completely different list to the special rating product: You can use a change 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 billing with contents from the new list.
Adding or removing entries from a list currently referenced by a special rating product: You can use the Siebel Special Rating Profile user interface (UI) to make changes to the list and synchronize them to BRM. This synchronization is enabled by the following integration services:
ProcessInstalledProductSpecialRatingSetListSiebelCommsJMSConsumer
ProcessInstalledProductSpecialRatingSetListSiebelCommsReqABCSImpl
ProcessInstalledProductSpecialRatingSetListBRMCommsProvABCSImpl
Promotion upgrades and downgrades:
Promotion upgrades or downgrades can result in the cancellation or addition of Special Rating products for an existing service.
Cancellation: When such orders are processed, the integration deletes the respective list profile in BRM.
Addition: When such orders are processed, the integration creates new list profiles in billing for the given service instance.
Service cancellations:
Service cancellation results in the deletion of the list profile in BRM.
After a service that supports special rating has been purchased and the order fulfilled and asseted, you can use the Siebel Special Rating Profile UI to make changes to the list, and then update and synchronize the list to BRM.
The flow uses the ProcessInstalledProductSpecialRatingSetList operation on the ProcessInstalledProductSpecialRatingSetListBRMCommsProvABCSImpl service for this purpose. The specification group on the installed product EBM is used for communicating the list entries.
See "Implementing the Synchronize Customer Special Rating Profile Business Flow" for more information.
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 solution 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 Oracle Communications Billing and Revenue Management: 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.
The service account, billing account, and billing profiles are 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.
The integration does not support changing from nonpaying subordinate to self-paying account or changing from self-paying account to nonpaying subordinate. Changing accounts in this way does not produce an error but results in data that breaks the billing management integration flows.
A subordinate account cannot have multiple paying parents. This is not supported in BRM.
Any order changing the paying parent for a subordinate account using a new purchase or a change order for an existing service must include lines to change all the other services and account-level products for the subordinate account that was paid for by the old parent to the new parent so that it can successfully interface customer data to BRM.
Transactions that do not obey this assumption fail with a BRM error when an order is interfacing customer data to BRM.
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.
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|