| Oracle® Application Integration Architecture Oracle Communications Order to Cash Integration Pack Implementation Guide for Siebel CRM, Oracle Order and Service Management, and Oracle Billing and Revenue Management Release 11.1 Part Number E22651-03 |
|
|
PDF · Mobi · ePub |
This chapter provides information on how orders from Siebel Customer Relationship Management (Siebel CRM) are interfaced to Oracle Billing and Revenue Management (Oracle BRM), through an order management system like Oracle Order and Service Management (Oracle OSM). It lists various expectations of an order management system. Oracle OSM and the OSM AIA Cartridges obey these expectations.
This chapter includes the following sections:
This business flow is enabled using the Oracle Communications Order to Cash Siebel CRM, Oracle OSM, and Oracle BRM pre-built integration options.
A customer must be billed for the services purchased and their usage. 'The process integration for order lifecycle management (OLM) provides a service that can be called by an order management system (such as Oracle OSM) to interface the order to Oracle BRM. This creates the required transaction data so that Oracle BRM can bill the customer.
For more information about calling this service, see Appendix H, "Expectations from a COM System for Billing Integration."'
As part of interfacing a new order or change order to Oracle BRM, the process integration for OLM supports purchasing the following in Oracle BRM:
Products of type Item that apply to an account (for example, promotion penalty charges).
Products of type Item that apply to a service (for example, one-time charges).
Products of type Subscription that apply to an account (for example, charges for mailing a monthly paper invoice).
Products of type Subscription that apply to a service (for example, wireless service).
Discounts of type Subscription that apply to an account (for example, account-level discounts).
Discounts of type Subscription that apply to a service (for example, a free minutes discount).
Oracle BRM products and discounts design time data is synchronized to Siebel CRM by the process integration for product lifecycle management (PLM).
For more information about the process integration for PLM, see Chapter 2, "Understanding the Process Integration for Product Lifecycle Management."
For more information and examples of supported products, see Appendix D, "OLM Bill Fulfillment Order - Matrix of MACD Actions Supported Per Billing Product Type."
As part of interfacing a new order or change order to Oracle BRM, the process integration:
Creates or updates service instances and purchased product and discount instances in Oracle BRM as part of the order interface to Oracle BRM.
The integration supports the following actions: ADD, DELETE, UPDATE, SUSPEND, RESUME, MOVE-ADD, and MOVE-DELETE.
It supports communicating updates to the service identifier, billing account, billing profile, and price changes on existing services.
As part of service cancellations or promotion upgrade or downgrades, when an old product is canceled, whether the customer gets a refund for (billed) monthly charges or whether the refund is prorated depends on product-level controls in Oracle BRM.
As part of a Move transaction, the integration supports changing Service Identifier, Billing Account, and Billing Profile. The integration does not support purchasing new products or canceling existing products as part of a Move transaction.
Tip:
Transferring a service from one location to another in Siebel CRM results in lines with the action of MOVE-ADD and MOVE-DELETE. (This was previously referred to as Move).
For more information, see Appendix D, "OLM Bill Fulfillment Order - Matrix of MACD Actions Supported Per Billing Product Type," Appendix E, "OLM - Examples of Changing the Paying Parent on Subordinate Accounts," and Appendix C, "OLM - Mapping Billing Dates."
The solution supports account-level default balance groups alone.
The account-level balance group is created when the service account or billing account referenced on the order is created in Oracle BRM. A balance group in Oracle BRM can reference a single bill-info. When the account-level balance group is created, it uses the first billing profile referenced on the first order processed for an account. Thus all account-level products and services for a given account on the same order or subsequent orders must reference the same billing profile. An order violating this assumption fails billing integration with an Oracle BRM error.
The solution does support updating an existing billing profile in Siebel CRM; such changes are synchronized to billing outside of the order integration flow.
For more information, see the Siebel CRM Integration Pack for Oracle Communications BRM: Agent Assisted Billing Care Implementation Guide.
Because the solution supports only an account-level balance group, transfer of services (or account-level products) from one account to another is not supported.
Change orders that update the service account on existing services fails billing integration with an Oracle BRM error.
Communicates pricing information such as price or discount overrides, discounts, and onetime and penalty charges as part of the order interface to Oracle BRM.
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 the latter is desired, then the Siebel CRM user must explicitly disconnect and add the product with the new price versus changing the price on an existing product.
Onetime 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 Oracle BRM as account-level charges.
As delivered, Siebel CRM supports defining charges for any of these actions: Suspend, Resume, Move, and Delete. One can extend Siebel to define charges for other actions such as Update.
For example, a communications service provider (CSP) charges a customer a fee for requesting a change to their phone number or billing profile. The order billing integration generically 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 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 order**) and using the charge parent line (on the order EBM) are processed by the billing interface and applied to the respective service instance.
If the application business connector service (ABCS) that transforms the Siebel Order application business message (ABM) to the order EBM cannot to resolve the base line that a new order or change order onetime 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.
* Refer to the product bundling methodology for defining onetime charge products in Oracle BRM and synchronizing them to Siebel for tying them to new order or change order actions.
** The onetime 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, 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.
For more information about service bundles, see Section 3.3, "Understanding the Product Bundling Methodology."
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 (GL) in Oracle 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 Oracle 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, Oracle BRM allows a single override price. In other words, if an Oracle 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, the Siebel CRM application 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.
For more information about using the pricing commit type and dynamic discount method, see the Siebel product documentation.
Communicates service identifiers (for example, phone number for land-based or wireless phone service) to the billing system as part of the order interface to billing. The service identifier on the service bundle line in Siebel CRM is communicated to Oracle BRM. For telephony services, it is used as the phone number. For nontelephony service, it is used as the login and password.
Communicates Siebel promotion information for invoice display.
To allow Oracle 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 (purchase date from Promotion Order line, if available, else request date if available, else Oracle BRM defaults current date).
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 Oracle 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.
Caution:
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 Oracle 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.
For more information about order fallout, see Chapter 21, "Understanding the Process Integration for Order Fallout Management."
The Oracle Communications Order to Cash pre-built integration supports two product bundling methodologies: service bundles and simple service bundles.
For more information about the bundling methodologies, see Section 3.3, "Understanding the Product Bundling Methodology."
Order billing integration supports the simple service bundle methodology for all supported features, within the listed constraints.
Here is a summary of how the integration supports purchases of simple service bundles:
Purchasing a simple service bundle creates both a service instance and a purchased product instance in Oracle BRM. If the service was purchased within the context of a promotion, the product instance in Oracle BRM is tied to the purchased promotion (or bundle) instance. See Section 12.3.1, "Cross-Reference Impact."
The quantity (if > 1) on a simple service bundle line applies to the product purchase alone. Therefore, a single simple service bundle line creates:
A single service instance and
A single purchased product instance with a quantity as specified on the order line.
Both single-phase billing and two-phase billing are supported for the simple service bundle.
Here is a summary of how the integration supports changes to purchased simple service bundles:
Suspending or resuming the asset that represents a simple service bundle suspends or resumes the service and product on Oracle BRM.
Disconnecting the asset that represents a simple service bundle cancels the service and product instance in Oracle BRM.
When using a simple service bundle, you cannot cancel the product without canceling the service.
Transferring the asset that represents a simple service bundle in Siebel (Move-add or Move-delete) results in the cross-reference being adjusted for both the service and purchased product instance.
Updates to service instance attributes (for example, Service ID, billing account/billing profile) on the asset that represents a simple service bundle results in the appropriate updates to the service instance in Oracle BRM.
Updates to product attributes* (for example, pricing changes, promotion reference) on the asset that represents a simple service bundle results in the appropriate updates to the purchased product instance in Oracle BRM. Changes to billing dates as part of two-phase billing are honored.
* - Quantity changes are not propagated to Oracle BRM for this release.
If a onetime charge was defined and applied for a Move, Add, Change, and Disconnect (MACD) action in Siebel, it is applied in Oracle BRM to the balance group that the service instance points to.
With simple service bundles, a single Siebel asset (for the simple service bundle product) is mapped to both the service instance and the purchased product instance in Oracle BRM. To manage mapping to both instances, the integration creates an additional cross-reference entry in the InstalledProduct cross-reference, as shown in Table 12-1.
Table 12-1 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 Oracle BRM portal object ID (POID) for the service instance and BRM-B01 is the Oracle 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 solution 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.
In this pattern, a service is interfaced to billing through Fulfill Billing toward the end of the fulfillment flow, after the order is delivered and the actual delivery date is known.
The following business scenario requires this pattern:
All at Once
This scenario is the most common. Here the CSP does not have the concerns mentioned below for two-phase billing. In this case interfacing to Billing takes place after the service or product is made available* to the customer.
* - The interpretation of made available may vary among CSPs, based on jurisdiction and based on whether the subject 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.
In this pattern, a service is interfaced to billing twice:
Initiate Billing: The service and purchased products are interfaced early in the fulfillment flow and before actual delivery dates are known.
Fulfill Billing: Accurate billing dates are updated in billing after the order is delivered and the actual delivery date is known.
The following business scenarios require this pattern:
Phased for Time Latency
In this scenario, the CSP has these concerns:
Operational or deployment conditions produce a time lag between the time a service is made available for customer use and the time the service is interfaced into billing. Therefore, usage records can go into error logs and the CSP may lose revenue. CSPs attempt to plan fulfillment of future-dated orders to meet the requested delivery date, often using a safe margin that produces a time lag between the time a service is made available for customer use and the requested delivery date.
In these cases, the usage cycle must start sooner than the billing cycle date. The fulfillment flow must be constructed such that the Usage Start Date is set to the current date during Initiate Billing, and the Cycle Start Date is set to a distant future date. At the time of Fulfill Billing, the Cycle Start Date is then reset to match the Actual Delivery Date or Requested Delivery Date, depending on business practices and legal requirements.
Phased for Validation
In this scenario, the CSP has these concerns:
Inadequate controls are in place to guarantee that valid orders interface to billing. Therefore, the CSP faces a high rate of invalid orders.
The costs associated with delaying order line validation for interfacing to billing are prohibitive.
In these cases, orders must be interfaced to billing early in the fulfillment flow to ensure that the order can be interfaced successfully later. The fulfillment flow must be constructed such 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.
An implementer can design an order orchestration flow such that it first interfaces the order to billing before the order is sent to provisioning. Calling the interface in this mode is optional. In this mode, the billing interface is called with either the whole order* or order components such as promotion lines, service bundles**, and account-level products. Depending on the requirements, the implementer should set some or all of the following dates on new purchases of products*** 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)
Therefore, to support the scenario in which a fulfillment latency exists between service activation and billing, and you want to ensure that service usage is rated as soon as the service is activated but you want to start cycle fees only as of the date that the service was requested by the customer, you must have your order management system set the purchase and usage start dates to current and the cycle start date alone to the future when calling this service. See the subsequent section for certain modeling recommendations.
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. Onetime charges for actions such as Suspend, Resume, Move, and Disconnect and promotion penalties are not processed in this mode.
* - All of the lines on the order that are intended for a certain target billing system and related lines such as promotion lines.
** - Service bundle means the service bundle line and all its component lines. The solution does not support a scenario in which some service bundle component lines are sent for billing initiation and billing fulfillment, while others are sent only for billing fulfillment. In such a scenario, the service bundle component lines that are sent only for billing fulfillment do not get processed.
*** - A product referenced on the Siebel CRM order line may result in the purchase of a product or a discount based on how it was originally defined in Oracle BRM. For the promotion line, only the purchase date is relevant.
For more information about how dates are set in Oracle BRM, see Appendix C, "OLM - Mapping Billing Dates."
Oracle BRM has validation that 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. It does reset the cycle start and usage start date if asked by the caller. However, if billing initiation is called to process a revision on order lines that are billing-initiated, and billing initiation is asked to reset the cycle start date* if the previously set date is current, then billing initiation fails due to the Oracle BRM validation error.
* - In this case, the order management system sets the prior values for the billing dates to indicate to the billing integration that the dates are being reset.
Modeling and Implementation Recommendations
Here are some modeling and implementation recommendations:
General
The interface validates that the cycle date is set to the future for products of type subscription/discount. For products of type item, the interface validates that the purchase date is set to the future. As a best practice, it is recommended that when calling billing initiation, the caller set the billing date that is being set to the future to a year ahead of the due date.
Oracle AIA deems the purchase, cycle start, or usage start dates as being in the future if the billing date in question is > (Fusion Middleware (FMW) current time converted to UTC + (25 or XX hours, whichever is greater)).
XX is the value of the Oracle AIA configuration property: FutureTimeThresholdForBillingDates. This property has a default value of 8640 hrs (360 days in hours).
If an implementer is highly confident of the lead time required to activate the service, then they 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. This property is settable per Oracle BRM instance level.
If the property 'FutureTimeThresholdForBillingDates' is not specified for a given billing instance, then the integration assumes the default value of 8640 hours (365 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.
Oracle 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 (Oracle BRM ABCS) errors.
Purchase Fees or Activation Charges
Oracle 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 scenario, 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 scenario, 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.
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.
* - A product referenced on the Siebel CRM order line can result in the purchase of product or a discount based on how it was originally defined in Oracle BRM. For the promotion line, only the purchase date is relevant.
After provisioning is complete, the order orchestration flow can interface the order to billing in this mode. This is the default mode that the interface supports and is required to interface an order to billing.
In this mode, the interface processes all order lines that are sent (new and change orders). Onetime charges for actions such as Suspend, Resume, Move, and Disconnect and promotion penalties are processed in this mode.
For orders (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 (date when the service was delivered). 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.
Caution:
Billing dates that are set to current in billing initiation must not be reset in billing fulfillment because it causes Oracle BRM to end in error.
The following prior values must be supplied:
PurchaseDate: ProcessFulfillmentOrderBillingEBM/DataArea/ProcessFulfillmentOrderBilling/ PriorFulfillmentOrder/FulfillmentOrderLine/FulfillmentOrderSchedule/ PurchaseDate
CycleStartDate: ProcessFulfillmentOrderBillingEBM/DataArea/ProcessFulfillmentOrderBilling/ PriorFulfillmentOrder/FulfillmentOrderLine/FulfillmentOrderSchedule/ CycleStartDate
ServiceUsageStartDate: ProcessFulfillmentOrderBillingEBM/DataArea/ProcessFulfillmentOrderBilling/ PriorFulfillmentOrder/FulfillmentOrderLine/FulfillmentOrderSchedule/ ServiceUsageStartDate
* - The interface relies on the population of prior value fields to indicate that an attribute on the line has changed. So your order management system must set the prior value fields for the billing dates.
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) 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.
(Billing Initiation is defined as the billing interface called in Initiate Billing mode. Billing Fulfillment is defined as the billing interface called in Fulfill Billing mode.)
The product that an order line references does not change after the line has been billing-initiated.
The order management system sends the onetime charge associated with a MACD action (Suspend, Resume, Move, Disconnect) with the service bundle on which the action is being performed.
Every MOVE-ADD line on a Siebel order has a matching MOVE-DELETE (and vice versa). The order management system sends MOVE-ADD lines along with the MOVE-DELETE lines to billing.
After order lines are submitted for Fulfill Billing, they are assumed to have hit a hard point of no return (PONR) and cannot be revised in Siebel CRM.
Service ID is always sent as input to the billing interface (Initiation or Fulfillment).
For more information about how dates are set in Oracle BRM, see Appendix C, "OLM - Mapping Billing Dates."
To provide support for revisions after order lines are billing-initiated but not yet billing-fulfilled, the order interface to Oracle 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*.
Changes to the following attributes on a revised promotion line results in updates to billing: Billing Account, Purchase Date.
Changes to the following attributes on a revised account-level product line results in updates to billing: Billing Account, Bill Profile, Promotion reference, Pricing Information****, Billing Dates**.
Changes to the following attributes on a revised service bundle line results in updates to billing: Billing Account, Bill Profile, Promotion reference, Service ID.
Changes to the following attributes on a revised service bundle component line results in updates to billing: Pricing Information****, Billing Dates**.
Caution:
Revisions to order lines for products of type Item can be interfaced to Oracle BRM if the billing date is not current. When it is current, the call to update Oracle BRM fails.
For more information about these attributes, see Appendix D, "OLM Bill Fulfillment Order - Matrix of MACD Actions Supported Per Billing Product Type."
If an order line is successfully billing-initiated***** and subsequently the order line is canceled in Siebel CRM*** 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, the 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 Oracle BRM), then the order management system calls billing initiation with a fulfillment mode of NOOP.
* - Old attribute values are supplied only for delta changes.
** - 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.
For more information, see Section 12.4, "Supporting Single Phase versus Two-Phase Billing."
*** - On a Siebel revised order, this manifests as lines being dropped.
**** - Pricing information includes list price, selling (or net) price, pricing commit type, dynamic discount method, discount amount, and discount percent.
***** - The Oracle AIA service that interfaces order messages to Oracle BRM processes all lines or none of the lines. It does not do partial processing. Therefore, when an order is successfully billing-initiated, if any subsequent revisions for lines on the base order have to be processed, then the order management system must trigger compensation as described previously (using REDO, UNDO, or NOOP mode). If the order fails billing initiation (and triggers Order Fallout), a subsequent revision should be sent as is for billing initiation (DO mode).
Caution:
As delivered, 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 (expected from the calling order management system) | 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 PONR after they have been interfaced to Oracle BRM in the Fulfill Billing mode. Support for revisions is provided only for the case in which 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).
Only new purchases (lines with action ADD) are processed by billing initiation; hence billing initiation processes only revisions 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.
The time-based offerings feature allows the definition and usage of products and discounts in Siebel CRM that are valid only for a specific duration, and expire after that.
The solution for time-based offerings has two components: design time and order time.
For more information about the design time component, see Section 3.3.14, "Supporting Time-Based Offerings."
New Purchase - When an order for a time-based offering is placed and processed the following occurs:
Siebel CRM calculates the end date, taking into account the start date (defaulted from due date) and the Duration, DurationUOM and DurationValidityStart transaction attribute values.
The order is then submitted to the order management system for fulfillment. When the order is fulfilled, Oracle OSM AIA Cartridges set the purchase, cycle start, and usage start dates based on service actual delivery date and re-calculates the end date.
When the order is billing fulfilled, the integration communicates the end date for the purchased product or discount to Oracle BRM.
As part of the order update back to Siebel CRM, the order management system through the integration communicates the actual start and end dates to Siebel CRM.
Change Order (such as a promotion upgrade or downgrade that results in changes to the duration validity of a previously purchased time based discount):
Siebel CRM re-calculates the end date based on taking into account the Duration, DurationUOM and DurationValidityStart transaction attribute values.
The order is then submitted to the order management system for fulfillment. When the order is fulfilled, Oracle OSM AIA Cartridges re-calculates the end date based on the actual delivery date. The end date is recalculated only if any of the validity attributes have changed on the order (by comparing against prior values) as follows.
DurationValidityStart = Original End: Service End Date = Prior Value for Service End Date + Duration
DurationValidityStart = Now: Service End Date = Actual Delivery Date Time + Duration
DurationValidityStart = Original Start: Service End Date = Service Start Date + Duration
When the order is billing fulfilled, the integration communicates the new end date for the purchased product or discount to Oracle BRM.
As part of the order update back to Siebel CRM, the order management system through the integration communicates the changed end dates to Siebel CRM.
Tip:
It is recommended that end dates not be set during Billing Initiation since it is not required and avoids the requirement to manage them as part of revisions. Oracle OSM AIA Cartridges do not set end dates during Billing Initiation.
When using an order management system other than Oracle OSM, it must behave as described above to enable support for time based offerings.
The Implementer must schedule a recurring job (daily or some other frequency based on their requirements) in Siebel to execute the workflow (SWI Asset Status Update Workflow) to inactivate such assets (time based offering products whose end date has passed). This is required to ensure that change orders for services that include time based offering products are successfully processed.
To ensure that the purchased products and discounts reflect the correct status after the expiration date is passed, the Implementer must periodically run the Oracle BRM utilities pin_cycle_fees -cancel and pin_discount_cleanup in Oracle BRM.
When a subscription product that is duration-based (Time Based Offering) and is also marked as a simple service bundle in Siebel CRM, is purchased and fulfilled, the Siebel CRM asset changes to inactive on the duration expiring. This results in scenario where the service instance is still active in Oracle BRM, but the corresponding asset in Siebel is inactive (because the same Siebel asset is mapped to both the service and the purchase product or discount instance in Oracle BRM). To handle such cases, the implementer must develop custom scripts to inactivate the respective service instances in Oracle BRM.
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.
For more information about how special rating products are supported and the methodology, see Section 3.3.12, "Supporting Friends and Family."
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.
For more information, see the sections on friends and family plans in the "Profiles in Siebel Communications," chapter of the Siebel Communications Guide.
When the order is interfaced to Oracle 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 Oracle 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 Oracle 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 Oracle BRM instance.
For more information, see Section 3.3.12, "Supporting Friends and Family" and Appendix F, "Configuring Multiple Oracle BRM Instances for Communications Integrations."
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 Oracle BRM. This synchronization is enabled by the following integration services:
ProcessInstalledProductSpecialRatingSetListSiebelCommsJMSConsumer
ProcessInstalledProductSpecialRatingSetListSiebelCommsReqABCSImpl
CommunicationsInstalledProductEBSV2 (Operation: ProcessInstalledProductSpecialRatingSetList)
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 Oracle 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 Oracle BRM.
After a service that supports special rating has been purchased and the order fulfilled and asseted, the customer can use the Siebel Special Rating Profile UI to make changes to their list, and then update and synchronize the list to Oracle BRM.
The flow uses the operation ProcessInstalledProductSpecialRatingSetList on the enterprise business service CommunicationsInstalledProductEBS for this purpose. The specification group on the installed product EBM is used for Communicating the list entries.
For more information, see Chapter 20, "CM - Synchronize Customer Special Rating Profile: Implementation."
These are the solution assumptions and constraints for this integration flow:
The solution does not support an integration scenario in which multiple brands are defined within a single instance of Oracle 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 state model. The order can be revised and resubmitted for processing if it has not reached a point-of-no-return (PONR). The solution assumes that the order line reaches the PONR after the line has been sent for billing fulfillment.
The Siebel Copy Orders feature does not regenerate the identifiers (asset integration Id) that uniquely identify the customer purchases on the copied order. This makes the copied orders invalid to back-end systems. Therefore, copied orders are not supported by Oracle AIA. Instead of copying orders, it is recommended that you use the Siebel 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 Oracle 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 Oracle 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 Oracle BRM.
No special handling exists for shippable goods. No support is available for returns or credit orders.
Order lines that must be sent to different billing systems have different billing profiles.
Note:
This is a limitation only if the customer is also using the Oracle Communications Billing and Revenue Management: Agent Assisted Billing Care pre-built integration. The Billing Management flows available as part of that integration, do not support the ability to display information from multiple billing systems for the same billing profile.
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 (components) in a service bundle.
For service bundles, any integration logic that works on these fields looks only at the service bundle line. This constraint also applies to onetime 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 a line. The charge generated by such an order line is applied to the balance group that the service instance points to.
This is an Oracle BRM limitation and is enforced in Siebel CRM.
The solution supports account-level default balance groups alone. A balance group in Oracle BRM can reference a single bill-info. This is the first billing profile that is referenced on the first order processed for an account.
It follows that all services for a given account on the same order or subsequent orders must reference the same billing profile; an order violating this assumption fails billing integration with an Oracle BRM error.
If the order message contains multiple service being purchased, the integration (because of optimization), uses the billing profile on the first service for processing all of the services. In this case, the Oracle BRM validation and error are not raised.
It follows that all account-level product purchases for a given account reference the same billing profile. Violation of this assumption does not result in failure because order billing integration ignores the billing profile specified on order lines for such products.
The solution does support updating an existing billing profile in Siebel; such changes are synchronized with billing outside of the order integration flow.
In the case where an account is paying for its own services (and account-level products), the solution does not support changing the billing profile on existing services or account-level products to a different one using a change order:
Changing from one billing profile to another for a self-paying account is not supported.
Changing from one paying parent to another for a subordinate account is supported.
Changing from one billing profile to another (while retaining the same paying parent) for a subordinate account is supported.
Changing from self-paying to nonpaying subordinate is not supported*.
Changing from nonpaying subordinate to self-paying is not supported.
This is an Oracle BRM limitation with account-level balance group usage. Order integration to billing fails with an Oracle BRM error for the preceding scenarios that are not supported.
* - This specific scenario does not error but is not supported since it results in data that breaks the billing management integration flows.
Oracle BRM does not support a subordinate account having multiple paying parent.
Any order changing the paying parent for a subordinate account using a new purchase 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 so that it can successfully interface customer data to Oracle BRM.
Caution:
Transactions that do not obey this assumption fails with an Oracle BRM error when an order is interfacing customer data to Oracle BRM.
Any order changing the paying parent for an existing service on a subordinate account changes the paying parent for all the other services (and account-level products) under that subordinate account. To ensure that Siebel CRM assets are synchronized with Oracle BRM, it is recommended that the change order to update the paying parent include an update for all the services (and account-level products) for a given subordinate account.
For more information, see Appendix E, "OLM - Examples of Changing the Paying Parent on Subordinate Accounts."
Transfer of services (or account-level products) from one account to another is not supported.
For more information, see Section D.2, "Table B."
All lines within a service bundle reference products from the same billing system.
Based on this assumption, 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 product and its component products reference the same billing service type. This assumption applies only to component products that represent Oracle BRM products of type Subscription or BRM discounts. Violation of this assumption can result in Oracle BRM grouping the billed charges under the wrong bucket (bill-item). Nested service bundles do not have to have the same service type as the root parent service bundle.
|
 Copyright © 2001, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
