PK
mBoa, mimetypeapplication/epub+zipPK mB iTunesMetadata.plist
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 disab led, 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.
Handling of Revision Orders
BRM prevents the caller from resetting purchase and cycle start dates when they become current. The integration does not reset the purchase date as part of billing-initiation revision processing, but resets the cycle start and usage start date if asked by the caller.
However, when billing initiation is called to process a revision on order lines that are billing initiated, and the call resets the cycle start date when the previously set date is current, then billing initiation fails with a BRM validation error.
General Modeling and Implementation Recommendations
The interface validates that the cycle date is set to the future for products of type Subscription or Discount. For products of type Item, the interface validates that the purchase date is set to the future. Oracle recommends that you set the future billing date to a year ahead of the due date when calling billing initiation.
The purchase, cycle start, or usage start dates is in the future if the following is true about the billing date:
billing date > (Fusion Middleware current time converted to UTC + (25 or FutureTimeThreshold hours, whichever is greater)).
where FutureTimeThreshold is the value of the FutureTimeThresholdForBillingDates Oracle AIA configuration property. This property has a default value of 8640 hours (360 days in hours).
If you are highly confident of the lead time required to activate the service, then you can lower the value of the FutureTimeThresholdForBillingDates property such that the order management system does not have to call fulfill billing to reset the dates that were set in initiate billing. This also allows the billing dates to naturally become current soon after the service is activated. You can set this property for each BRM instance.
If the FutureTimeThresholdForBillingDates property is not specified for a given billing instance, then the integration assumes the default value of 8640 hours (360 days).
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.
Recommendations for Discounts
If the service bundle includes products representing purchase or usage discounts, then to ensure that the customers get the discount, the purchase and usage start dates for the discount products must also be set to current when you are modeling the flow that sets the purchase and usage start dates to current for the subscription products.
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.
Table 12-2 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.
This chapter describes the process integration for Order Lifecycle Management (OLM) and discusses a typical topology and order capture flow. It also describes the Qualify Customer Order and Deliver Customer Order subflows and design considerations for product definition and mapping.
The process integration for OLM extends from the time a quote or order is created to the time when the goods and services are delivered and billed. The Oracle Communications Order to Cash Integration Pack for Siebel customer relationship management (Siebel CRM), Oracle Communications Order and Service Management (OSM), and Oracle Communications Billing and Revenue Management (BRM) (the integration) works with participating applications to accomplish this process for customer relationship management, order management, billing, and service fulfillment. Integration to other fulfillment system types such as supply chain management and workforce management can be added as an extension project at implementation time.
Figure 7-1 illustrates the functional flow.
The functional flow for OLM is as follows:
Capture Customer Order: A customer order is captured and, if necessary, validated in Siebel CRM. When the order capture is complete and the order is validated, the system submits it to OSM in the central order management (COM) role for delivery. In Figure 7-1, the two arrows from Capture Customer Order to Fulfill Customer Order show the Qualify Customer Order and Deliver Customer Order subflows.
Recognize, Map, and Enrich: OSM recognizes customer orders (both Qualify and Deliver request types) as Oracle Application Integration Architecture (Oracle AIA) customer orders, maps them to fulfillment patterns, and enriches them with fulfillment metadata.
Decompose and Orchestrate: OSM decomposes and orchestrates the customer orders, dividing the order into suborders called order components. Order components have cross-order components, cross-order lines, and cross-order dependencies that reflect the specific demands of the communications service provider.
Generate Orchestration Plan: The outcome of decomposition and orchestration is an order orchestration plan. The fulfillment flow that is produced orchestrates fulfillment requests to different fulfillment providers (such as fulfillment system instances or stacks) using preconfigured fulfillment functions, like Sync Customer, Initiate and Fulfill Billing, and Provision Order. The OSM Order to Activate PIP cartridge product provides ready-to-use automatic integration with AIA web services. When BRM) pre-built integration option is in use, the integration forwards the billing related requests (Sync Customer, Initiate and Fulfill Billing) generated in OSM to BRM. The Sync Customer Account integration flow also uses the Siebel CRM pre-built integration option to get customer account details.
Manage OLM Events: OSM manages OLM events. For cancel and revision requests, OSM generates and executes compensation plans to match a change. OLM manages order data and status updates, and order fallout.
Update Customer Order: Throughout the fulfillment process, OSM maps fulfillment function responses to common statuses, which are then aggregated into order line statuses and order header status values. OSM updates Siebel CRM with relevant customer status and milestone values when order lines reach their point-of-no-return (PONR) to prevent the submission of new revisions. OSM also updates Siebel CRM with any enrichment to order lines that occurs during fulfillment.
Create/Update Trouble Tickets: OSM detects, reports, and resolves order fulfillment fallout incidents such as system, validation, and fulfillment errors. AIA also reports any integration errors to OSM. OSM then creates trouble tickets in Siebel CRM for error notification, reporting, and management.
Note: See "Understanding the Process Integration for Order Fallout Management" for more information about managing order fallout in OSM and creating trouble tickets in Siebel CRM. |
OSM delivers pre-built cartridges for use with the integration and provides an Oracle AIA Emulator, which you can use to emulate an order. See Oracle Communications Order and Service Management Cartridge Guide for Oracle Application Integration Architecture for more information about how to install and deploy the delivered cartridges and the emulator.
Note: This guide focuses on the automated integration points among Siebel CRM, OSM COM, OSM Service Order Management (SOM), and billing. This guide does not cover process details within OSM SOM, for example, service design, assign, and activation. |
The process integration for OLM enables the following business flows:
Process Sales Order Fulfillment:
Enabled using either the Oracle Communications Order to Cash for Siebel CRM and OSM Pre-Built Integration option or the Oracle Communications Order to Cash for Siebel CRM, OSM, and BRM Pre-Built Integration option.
Used when submitting orders from Siebel CRM to OSM for order fulfillment processing.
See "Understanding the Process Sales Order Fulfillment Business Flow" for more information.
Synchronize Fulfillment Order Billing Account:
Enabled using the Oracle Communications Order to Cash for Siebel CRM, OSM, and BRM Pre-Built Integration option.
Used when interfacing orders to create customer data in BRM.
See "Understanding the Synchronize Fulfillment Order Billing Account Business Flow" for more information.
Bill Fulfillment Order:
Enabled using the Oracle Communications Order to Cash for Siebel CRM, OSM, and BRM Pre-Built Integration option.
Used when interfacing orders to create transaction data in BRM.
See "Understanding the Bill Fulfillment Order Business Flow" for more information.
Provision Order and Update Fulfillment Order:
Enabled using either the Oracle Communications Order to Cash for Siebel CRM and OSM Pre-Built Integration option or the Oracle Communications Order to Cash for Siebel CRM, OSM, and BRM Pre-Built Integration option
Used when provisioning orders in OSM in the SOM role, and updating orders and statuses in OSM in the COM through explicit order updates from OSM in the SOM role.
See "Understanding the Provision Order and Update Fulfillment Order Business Flows" for more information.
Update Sales Order:
Enabled using either the Oracle Communications Order to Cash for Siebel CRM and OSM Pre-Built Integration option or the Oracle Communications Order to Cash for Siebel CRM, OSM, and BRM Pre-Built Integration option
Used when sending order updates from OSM in the COM role to Siebel CRM.
See "Understanding the Update Sales Order Business Flow" for more information.
Figure 7-2 illustrates a typical deployment topology for the integration. An order management system is at the center of the integration deployment
The figure shows order captures systems passing orders to the order management system that is central to the integration deployment. The order management system then decomposes the order into suborders called order components, each of which targets a particular fulfillment provider.
The topology in the figure uses the following fulfillment providers:
Three billing providers based on customer segment: wholesale, residential, and business.
Three provisioning stacks based on service family and geography: VoIP, UK Broadband, and Broadband.
Two shipping providers, one for in-house products and another for partner supplier products.
One workforce management provider
One customer relationship management (CRM) service provider for trouble ticketing
Figure 7-3 shows a typical order capture flow. The flow can vary by service provider for many reasons, including service family, customer segment, and line of business.
Order-based system interactions between different business support systems (BSS) and operational support systems (OSS) generally require order decomposition and orchestration to go through the order management layer. The process integration for OLM features integration points for the following systems interactions:
Qualify Customer Order: validates the availability of a service design and the capacity to fulfill the customer order
Deliver Customer Order: fulfills the products and services purchased by the customer or fulfills actions on existing customer assets.
Figure 7-3 shows the typical order capture flow. The CRM swim lane shows the typical order activities for the CRM system. The OLM swim lane shows the Qualify Customer Order and Deliver Customer Order subflows connected to the CRM activities.
A typical order capture flow is as follows:
New customer accounts are created or existing customer accounts are updated. Customer information might also be captured earlier, for example, when an opportunity or quote is created or updated during order capture.
(Optional) A credit check is run on the new customer.
The customer makes product choices and the CRM system validates the products.
The CSP prices the selected products and product options.
(Optional) When physical goods are chosen, the CRM system checks the availability to purchase (ATP).
(Optional) For some services, such as phone numbers, the CRM system reserves the resource.
(Optional) The orders passes through technical service qualification
(Optional) An appointment with an engineer is scheduled for the customer.
The order is submitted and the delivery process starts.
Figure 7-4 shows six swim lanes, one for each of the following applications: Siebel CRM, OSM, BRM, OSM Provisioning, Network Inventory (Service and Resource Inventory), and Activation. Each swim lane includes the typical application activities and user interactions that are part of that application. Arrows between such activities represent the typical sequence of events within the same application. Arrows across swim lanes represent system interactions across applications. The O2C hexagons between swim lanes represent existing integration points. See the legend in Figure 7-4 for other details.
This flow starts with a new order, an order revision, future-dated order, or a follow-on order submitted from Siebel CRM to OSM. OSM performs the following activities:
Transforms and enriches the order by mapping order lines to fulfillment flows and enriching them with fulfillment metadata and other relevant data.
Decomposes and routes the order by dividing the order into suborders, which are called order components. Order components can have cross-order components, cross-order lines, and cross-order dependencies. The outcome of decomposition is an order orchestration plan that is executed at the computed fulfillment start time to meet the requested delivery date. The produced fulfillment flow orchestrates fulfillment requests using preconfigured fulfillment functions, such as synchronizing the customer into BRM, initiating and fulfilling billing, provisioning the order, shipping the order, and installing the order. The OSM decompose and route order function also generates compensation plans that are associated with revision orders. Figure 7-4 illustrates a simple flow; orchestration plans are typically more complex, as shown in Figure 7-5.
Manages order fallout by creating trouble tickets in Siebel CRM.
The integration provides for detection, reporting, and resolution of order fulfillment fallout conditions such as validation, and fulfillment errors using Siebel CRM trouble tickets. System errors (such as an unreachable system) are handled differently.
See "Using Error Type to Control Response to Order Fallout" for more information.
Manages order status by mapping fulfillment function responses to common statuses which are aggregated into order line statuses and order header status values. OSM updates Siebel CRM with relevant customer status and milestone values. It also updates Siebel CRM when order lines reach their point of no return to prevent the submission of new revisions.
Figure 7-6 shows six swim lanes, one for each of the following applications: Siebel CRM, OSM, BRM, OSM Provisioning, Network Inventory (Service and Resource Inventory), and Activation. Each swim lane includes the typical application activities and user interactions that are part of that application. Arrows between such activities represent the typical sequence of events within the same application. Arrows across swim lanes represent system interactions across applications. The O2C hexagons between swim lanes represent existing Oracle Communications Order to Cash pre-built integration points. See the legend in Figure 7-6 for other details.
This flow starts with a request to qualify the technical validity of a customer order submitted from Siebel CRM to OSM. OSM performs the same four functions detailed for the Deliver customer order with one key distinction: the metadata used and the fulfillment flow produced is for qualifying the customer order rather than delivering the customer order. Deliver order flows and Qualify order flows produce different order and order line status updates.
The product and service definition methodology has the greatest effect on time to market and on the cost of an Oracle Communications Order to Cash deployment. Often, CSPs define products and services in different departments to serve the best interests of individual departments. This approach creates a challenge for bridging the gaps at run time. A balanced approach that requires departments to make calculated compromises that result in simplified overall product life cycle and order life cycle business flows is recommended.
Figure 7-7 aligns with Tele Management Forum (TMF) terminology and guidelines.
A balanced model produces a catalog with product specifications represented by the least number of entities. Product specifications represent unique capabilities with commercial value but only sold through product offerings. A more technical definition is that product specifications are types of products.
The product model shown covers the three TMF SID key entities: product, service, and resource.
Product offerings represent tangible and intangible goods and services made available for a certain price to the market in the form of product catalogs. Product offerings take one of three possible forms-simple offerings, bundled offerings, and promotional offerings:
Simple offerings are product offerings of a single good or service.
Bundled offerings are a grouping of two or more simple offerings into a single offer.
Promotional offerings are time-bound, contract-bound, or discounted combinations of simple and bundled offerings.
A key element of the Oracle methodology is a one-to-one mapping of every order line to a product specification. This approach is key to achieving fast time-to-market and low-cost operations. The Oracle solution facilitates this mapping by associating product offerings with a product class in Siebel CRM or Oracle Product Hub for Communications through the Fulfillment Item Code attribute.
Order management systems act on customer orders. Customer orders are composed of order lines. Each order line is represented by an action and a subject. Actions are verbs that represent the nature of the customer request, such as ADD to purchase an offering, UPDATE to modify a customer's subscription to an offering (for example, Customer Asset), and so on. A subject is the target of the action and can represent an offering, an asset, a discount, and so forth.
In the service fulfillment layer, a product specification can map to one or more technical services. A technical service is composed of one or more technical services and resources. The mapping from a customer order to a service order requires specific metadata modeled on products, product specifications, and service and resource configurations.
Figure 7-8 illustrates how the order management system takes advantage of the product model to map customer order lines to fulfillment flows according to the Oracle methodology. Other approaches may be plausible, but you must maintain a balanced approach that facilitates achieving the business objectives of fast time-to-market, and low-cost operations.
At run time, order capture copies key product offering attributes to each order line. These attributes include Fulfillment Item Code, Product Type Code, and Billing Type. OLM uses these attribute values to determine the corresponding product specification. The order header Fulfillment Mode attribute value determines the fulfillment requested type (for example, Deliver or Qualify). The intersection of a product specification and fulfillment request type determines the fulfillment actions and dependencies involved. When combined for all order lines in an order, an order fulfillment plan is generated dynamically.
The data requirements for Siebel CRM orders for the process integration for OLM are as follows:
An order must be of type Sales Order.
Any price list specified on an order must match one created in Siebel CRM and configured in the PRICELIST domain value map (DVM). The default price list must also be configured in the AIAConfigurationProperties.xml file.
If a price list is specified in the order header, any order lines that do not specify a price list will use the price list in the order header. If no price list is specified in the order header, each order line must specify a price list, with the exception of order lines for discounts synchronized from BRM as simple products in Siebel CRM. Price list information is not sent for billing discounts.
Service bundle lines or account-level product lines must have a service account, a billing account, and a billing profile.
Service bundle lines and simple service bundle lines must have a service ID before they are interfaced to a billing system.
Order lines referencing the same service account cannot reference different billing accounts. Refer to the solution constraint about having a single parent for subordinate accounts.
See "Assumptions and Constraints for the Bill Fulfillment Order Business Flow" for more information.
On any new order or change order for a service account, if the billing account is different from the billing account used on a previous order for the same service account, then all existing services paid for by the original billing account must appear on the order as updates to be paid by the new billing account.
The following enterprise business object (EBO) attributes are mandatory for integration with OSM:
Order header: Order ID, Order Number, Revision, Fulfillment Mode, Order Type
Order line: Line ID, Base Line ID, Action Code, Product Name, Product Type
Tip: The Sales Order EBO includes a vast set of attributes that are sufficient for most fulfillment systems, and it is extensible. |
This appendix describes the cross-references used in the process integration for Product Lifecycle Management (PLM) and provides information about the product synchronization flow and the discount synchronization flow between Oracle Communications Billing and Revenue Management (BRM) and Siebel customer relationship management (Siebel CRM).
Table A-1 lists the cross-references for the process integration for PLM.
Table A-1 Cross-References for Product Lifecycle Management
Operation | Entity | Siebel CRM ID | BRM ID |
---|---|---|---|
Inserts/Refers |
ITEM_ITEMID |
Product ID |
Product ID |
Inserts/Refers |
PRICELINE_ID (main products only) |
Price Line ID to Common ITEM_ITEMID of main product |
Product ID |
Inserts/Refers |
PRICELINETYPE_ID (for event/special type products) |
Price Line ID to Common ITEM_ITEMID |
Generated Product ID for Event products (ProductIDEvent Name) |
Inserts/Refers |
SIEBELPRODUCTEVENTXREF |
Common ITEM_ITEMID for the parent product to Common PRICELINETYPE_ID for event product |
$-- |
Table A-2 shows the values for the cross-reference entries for PLM.
Table A-2 Values of the Cross-References for Product Lifecycle Management
Entry | Description | COMMON Value | BRM_01 Value | SEBL_01 Value | ITEM_ID_COMMON Value | LINEPRICETYPECODE Value |
---|---|---|---|---|---|---|
ITEM_ITEMID |
Cross-references the BRM ProductID and the Siebel CRM ProductID. |
Auto-generated GUID |
POID of BRM Product ABM |
ProductID of Siebel CRM Product ABM |
NA |
NA |
PRICELINE_ID |
Cross-references the BRM Product ID and the Siebel CRM PriceLineID. Also links to the COMMON column of the ITEM_ITEMID entry. |
Auto-generated GUID |
POID of BRM Product ABM |
Siebel PriceListItemID for the main product |
From ITEM_ID.COMMON |
NA |
PRICELINETYPE_ID |
Cross-reference BRM Product's Event and the Siebel CRM PriceLineID. Also links to the COMMON column of the ITEM_ITEMID entry. |
Auto-generated GUID |
POID of BRM Product ABM and Event Name |
Siebel CRM PriceListItemID for the event product |
From ITEM_ID.COMMON |
NA |
SIEBELPRODUCTEVENTXREF |
Cross-references BRM Product's Event that is associated with the main product in Siebel CRM. |
NA |
NA |
NA |
From ITEM_ID.COMMON |
From PRICELINETYPE_ID.COMMON |
Figure A-1 illustrates the events that occur for product synchronization. Tables Table A-3, Table A-4, Table A-5, Table A-6, Table A-7, Table A-8, and Table A-9 describe the entries that are made in the XREF_DATA table for each event.
Before the SyncProductBRMCommslReqABCSImpl service makes the call to the SyncItemCompositionListSiebelCommsProvABCSImpl service, the entries listed in Table A-3 are made in the XREF_DATA table.
During the response back from Siebel CRM to the SyncItemCompositionListSiebelCommsProvABCSImpl service, the entry listed in Table A-4 is made in the XREF_DATA table.
Before the SyncProductBRMCommslReqABCSImpl service makes the call to the ProductOptimizedSyncPriceListListSiebelCommsProvABCSImpl service, the entries listed in Table A-5 are made in XREF_DATA table.
Before the ProductOptimizedSyncPriceListListSiebelProvABCSImpl service calls the SyncItemCompositionListSiebelCommsProvABCSImpl service, the entries listed in Table A-6 are made in the XREF_DATA table.
During the response from the SyncItemCompositionListSiebelCommsProvABCSImpl service, the entries listed in Table A-7 are made in the XREF_DATA table.
Table A-7 XREF_DATA
XREF_TABLE_NAME | XREF_COLUMN_NAME |
---|---|
ITEM_ITEMID |
COMMON GUID2 |
ITEM_ITEMID |
Siebel CRM ProductID of Event Product > |
Note: For the simple product synchronization, the previous call is not made because the main product is synchronized as an Item. |
Before the ProductOptimizedSyncPriceListListSiebelProvABCSImpl service calls Siebel CRM, the entries listed in Table A-8 are made in the XREF_DATA table.
During the response from Siebel CRM to the ProductOptimizedSyncPriceListListSiebelProvABCSImpl service, the entries listed in Table A-9 are made in the XREF_DATA table.
In the following example, a simple product is being synchronized from BRM to Siebel CRM.
Create a simple product in BRM to be synchronized to Siebel CRM, as shown in Figure A-2.
Verify the synchronized records in Siebel CRM, as shown in Figure A-3.
Verify the data entered into the XREF_DATA table is correct as shown in table Table A-10.
Table A-10 Data in XREF_DATA Table for Synchronized Example Simple Product
XREF_TABLE_NAME | XREF_COLUMN_NAME | ROW_NUMBER | VALUE |
---|---|---|---|
ITEM_ID |
BRM_01 |
ROWNUM_1 |
BRM_PROD_01 |
ITEM_ID |
COMMON |
ROWNUM_1 |
COMMON_PROD_01 |
ITEM_ID |
SEBL_01 |
ROWNUM_1 |
CRM_PROD_01 |
PRICELINE_ID |
BRM_01 |
ROWNUM_2 |
BRM_PROD_01 |
PRICELINE_ID |
COMMON |
ROWNUM_2 |
COMMON_PRICE_ID1 |
PRICELINETYPE_ID |
BRM_01 |
ROWNUM_3 |
BRM_PROD_01_EVENT1 |
PRICELINETYPE_ID |
COMMON |
ROWNUM_3 |
COMMON_PRICETYPE_ID1 |
SIEBELPRODUCTEVENTXREF |
LINEPRICETYPECODE |
ROWNUM_4 |
COMMON_PRICETYPE_ID1 |
SIEBELPRODUCTEVENTXREF _ID |
ITEM_ID_COMMON |
ROWNUM_4 |
COMMON_PROD_01 |
PRICELINE_ID |
ITEM_ID_COMMON |
ROWNUM_2 |
COMMON_PROD_01 |
PRICELINE_ID |
SEBL_01 |
ROWNUM_2 |
CRM_PRICE_01 |
In the following example, a complex product is being synchronized from BRM to Siebel CRM.
Create a complex product in BRM to be synchronized to Siebel CRM, as shown in Figure A-4.
Verify the synchronized records in Siebel CRM, as shown in Figure A-5.
Verify the data entered into the XREF_DATA table is correct as shown in table Table A-11
Table A-11 Data in XREF_DATA Table for Synchronized Example Complex Product
XREF_TABLE_NAME | XREF_COLUMN_NAME | ROW_NUMBER | VALUE |
---|---|---|---|
ITEM_ID |
BRM_01 |
ROWNUM_1 |
BRM_PROD_01 |
ITEM_ID |
COMMON |
ROWNUM_1 |
COMMON_PROD_01 |
ITEM_ID |
SEBL_01 |
ROWNUM_1 |
CRM_PROD_01 |
PRICELINE_ID |
COMMON |
ROWNUM_2 |
BRM_PROD_01 |
PRICELINE_ID |
BRM_01 |
ROWNUM_2 |
COMMON_PRICE_01 |
PRICELINETYPE_ID u;td> |
COMMON |
ROWNUM_3 |
COMMON_PRICETYP_01> |
PRICELINETYPE_ID |
BRM_01 |
ROWNUM_3 |
BRM_PROD_01_EVENT1 |
PRICELINETYPE_ID |
BRM_01 |
ROWNUM_4 |
BRM_PROD_01_EVENT2 |
PRICELINETYPE_ID |
COMMON |
ROWNUM_4 |
COMMON_PRICETYPE_02 |
SIEBELPRODUCTEVENTXREF |
LINEPRICETYPECODE |
ROWNUM_4 |
COMMON_PRICETYPE_01 |
SIEBELPRODUCTEVENTXREF _ID |
ITEM_ID_COMMON |
ROWNUM_4 |
COMMON_PROD_01 |
ITEM_ID |
COMMON |
ROWNUM_5 |
COMMON_PRICETYPE_02 |
ITEM_ID |
SEBL_01 |
ROWNUM_5 |
CRM_PROD_02 |
PRICELINE_ID |
ITEM_ID _COMMON |
ROWNUM_3 |
COMMON_PRICETYPE_01 |
PRICELINE_ID |
SEBL_01 |
ROWNUM_3 |
CRM_ITEM_PRICE_01 |
PRICELINETYPE_ID |
ITEM_ID _COMMON |
ROWNUM_4 |
COMMON_PRICETYPE_02 |
PRICELINETYPE_ID |
SEBL_01 |
ROWNUM_4 |
CRM_ITEM_PRICE_02 |
Figure A-6 shows a high-level overview of how the mappings are maintained in the cross-reference table.
Figure A-7 illustrates the events that occur for the discount synchronization flow.
Before the SyncDiscountBRMCommsReqABCSImpl service makes the call to the SyncItemCompositionListSiebelCommsprovABCSImpl service, the entries listed in Table A-12 are made in the XREF_DATA table.
During the response from Siebel CRM to the SyncItemCompositionListSiebelCommsProvABCSImpl service, the entry listed in Table A-13 is made in the XREF_DATA table.
In this example, a discount is being synchronized from BRM to Siebel CRM.
Create a discount in BRM to be synchronized to Siebel CRM, as shown in Figure A-8.
Verify the synchronized records in Siebel CRM, as shown in Figure A-9.
Verify the data entered into the XREF_DATA table is correct as shown in Table A-14.
Table A-14 Data in XREF_DATA Table for Synchronized Example Discount
XREF_TABLE_NAME | XREF_COLUMN_NAME | ROW_NUMBER | VALUE |
---|---|---|---|
ITEM_ID |
BRM_01 |
ROWNUM_1 |
BRM_PROD_01 |
ITEM_ID |
COMMON |
ROWNUM_1 |
COMMON_PROD_01 |
ITEM_ID |
SEBL_01 |
ROWNUM_1 |
CRM_PROD_01 |
Table A-15 shows an example of the values for the cross-reference data in the ITEM_ID entry.
Table A-15 Example of Discount Cross-Reference Values
XREF_TABLE_NAME | XREF_COLUMN_NAME | ROW_NUMBER | VALUE |
---|---|---|---|
ITEM_ID |
BRM_01 |
2E60E99F02D11DCBFCA/F1F293F06D61 |
0.0.0.1 /discount 60048 0 |
ITEM_ID |
COMMON |
2E60E99F02D11DCBFCA/F1F293F06D61 |
2d313734373134383431383534303233 |
ITEM_ID |
SEBL_01 |
2E60E99F02D11DCBFCA/F1F293F06D61 |
88-26YR5 |
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
E37675-02
June 2013
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
E37675-02
Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved.
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.
The Oracle Mediator Resequencer feature is used by various integration flows to ensure that messages are processed in a particular sequence.
See the discussion of resequencing in Oracle Mediator in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite for more information about resequencer.
Table I-1 lists the queues and flows that are enabled for sequencing.
Note: OSM manages scenarios where multiple revisions for the same order are sent out of sequence. If you are using a different order management system it must have similar support. |
Table I-1 Queues and Flows Enabled for Sequencing
Oracle AIA Queue | Flow | JMS Priority | Sequencing Criteria | Comments |
---|---|---|---|---|
AIA_UPDSO_OUT_JMSQ |
Update order flow from OSM to Oracle AIA for Siebel CRM. |
Not set |
Group By: Account ID mentioned in the ObjectCrossReference section of the update message(/UpdateSalesOrderEBM/EBMHeader/Sender/ObjectCrossReference/SenderObjectIdentification/AlternateObjectKey/ID[@schemeID = 'CUSTOMERPARTY_ACCOUNTID' and @schemeAgencyID = 'COMMON']) Order of Processing: FIFO (First in First Out). Composite Name: UpdateSalesOrderOSMCFSCommsJMSConsumer. |
Note: The consumer in the Create Trouble Ticket for Order Fallout business flow is only a sample. The resequencer in this flow ensures that multiple updates for the same order are processed in the right sequence. |
AIA_CRTCUST_OUT_JMSQ |
Order flow from OSM to Oracle AIA for customer data creation in billing. |
Set by OSM |
Group By: Account ID on the message (this is either the Billing account or the Service account on the order line that must be created in billing) and the target system identifier. concat($in.SyncCustomerPartyListEBM/ns0:SyncCustomerPartyListEBM/ns0:DataArea/ns0:SyncCustomerPartyList/ns0:CustomerPartyAccount/corecom:Identification/corecom:ApplicationObjectKey/corecom:ID[@schemeID='AccountId'], $in.SyncCustomerPartyListEBM/ns0:SyncCustomerPartyListEBM/corecom:EBMHeader/corecom:Target/corecom:ID) Order of Processing: FIFO (First in First Out). Composite Name: CommunicationsCustomerPartyEBSV2Resequencer. |
The resequencer in this flow ensures that the solution can successfully handle processing of concurrent orders for the same customer. |
-- |
Sync customer flow from Siebel CRM system to Oracle Customer Hub. |
Not Set |
Group By: AccountID. Order of Processing: FIFO (First in First Out). Composite Name: SyncAcctSiebelAggrEventConsumer SyncContSiebelAggrEventConsumer. |
Also available in the Agent Assisted Billing Care pre-built integration. The resequencer in this flow ensures that multiple updates for the same customer are processed in the right sequence. |
AIA_CRTFO_IN_JMSQ |
Order flow from Oracle AIA to OSM |
Set by ProcessSalesOrderFulfillmentOSMCFSCommsJMSProducer |
None. (Onus is on OSM.) |
NA |
AIA_CRTBO_OUT_JMSQ |
Order flow from OSM to AIA for billing. |
Set by OSM |
None as delivered. Customers can use ProcessFulfillmentOrderBillingOSMCFSCommsJMSConsumer to implement custom sequencing. |
NA |
AIA_UPDBO_IN_JMSQ |
Order flow from AIA (from billing) to OSM |
Set by ProcessFulfillmentOrderBillingResponseOSMCFSCommsJMSProducer |
None. (Onus is on OSM.) |
NA |
AIA_UPDCUST_IN_JMSQ |
Response of the customer creation in billing from AIA to OSM |
Set by ProcessFOBillingAccountListRespOSMCFSCommsJMSProducer |
None. (Onus is on OSM) |
NA |
AIA_CRTFO_OUT_JMSQ |
Create Fulfillment Order flow from OSM to Oracle AIA for the provisioning system |
Set by OSM. |
None as delivered. Customer can use ProcessProvisioningOrderOSMCFSCommsJMSConsumer to implement custom sequencing. |
NA |
AIA_FOCFS_IN_JMSQ |
Update Fulfillment Order flow from Oracle AIA (from the provisioning system) to OSM) |
Set by ProcessFulfillmentOrderUpdateOSMCFSCommsJMSProducer |
None. (Onus is on OSM) |
NA |
AIA_FOPROV_OUT_JMSQ |
Update Fulfillment Order flow from the provisioning system to Oracle AIA (for OSM) |
Set by provisioning system |
None as delivered. Customer can use ProcessFulfillmentOrderUpdateOSMPROVCommsJMSConsumer to implement custom sequencing. |
NA |
AIA_FOPROV_IN_JMSQ |
Create Fulfillment Order from Oracle AIA (from OSM) to the provisioning system. |
Set by ProcessProvisioningOrderOSMPROVCommsJMSProducer |
None. (Onus is on OSM) |
NA |
If an error occurs in the Oracle Communications Billing and Revenue Management (BRM) Customer provider, the message may be blocked in the CommunicationsCustomerPartyEBSV2Resequencer service and the error message may not propagate back to CommsProcessFulfillmentOrderBillingAccountListEBF. In these situations, fallout specialists must take corrective action on the resequencer to move the flow. If the message fails due to a system error (for example, if the target system is unavailable), then fallout specialists must retry the message from resequencer. If the message fails because of a business error, then the fallout specialist must unblock the resequencer.
An error may occur in the Siebel CRM provider after it is consumed by UpdateSalesOrderOSMCFSCommsJMSConsumer and sent for processing. In this situation the messages are rolled back to the resequencer for this consumer and any subsequent order updates for that particular order are not processed. If this occurs, the fallout specialist must take corrective action on this resequencer to move the flow like the ones described above. If the message fails due to a system error (for example, if the target system is unavailable), then fallout specialists must retry the message from resequencer. If the message fails because of a business error, then the fallout specialist must unblock the resequencer.
See the discussion of monitoring resequenced messages in Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite for more information on unblocking and retrying.
This chapter provides an overview of the Synchronize Product and Price business flow and describes the concepts from Siebel customer relationship management (Siebel CRM) and Oracle Communications Billing and Revenue Management (BRM) that are related to the business flow. It also lists the assumptions and constraints for the business flow.
This section describes process of synchronizing billing products and billing discounts in real-time and batches and synchronizing the updates to these billing products and billing discounts. as part of billing product and discount synchronization, synchronization of billing products with pricing details, and synchronization of billing discounts.
In this flow, the BRM product administrator creates billing products and billing discounts in Pricing Center. The BRM product administrator can either commit single billing products or discounts to the BRM database, or save sets of billing products and discounts to a file and commit the entire file to the BRM database.
When products and discounts are committed to the BRM database the Oracle Communications Order to Cash Integration Pack for Siebel CRM, OSM, and BRM (the integration) instantaneously synchronizes them to Siebel CRM. The Siebel CRM product administrator uses the synchronized billing products to create service bundles or promotions. The Siebel CRM product administrator can also add charges and penalties to the promotion.
See "Understanding Product Bundling" for more information about service bundles and promotions.
Figure 3-1 shows how billing products and billing discounts are created in BRM, synchronized to Siebel CRM in real time, and bundled in Siebel CRM for customers to purchase in promotions.
In this flow, the BRM product administrator updates the attributes of billing products and billing discounts in Pricing Center and commit them to the BRM database singly or as sets in a file.
When the updated billing products or discounts are committed to the BRM database, the integration instantaneously synchronizes the updates to Siebel CRM. The service bundles and the promotions in Siebel CRM are updated to use the latest version of the billing products. The Siebel CRM product administrator can make any necessary changes to promotions and bundles.
Figure 3-2 shows how billing products and billing discount are updated in BRM, synchronized to Siebel CRM in real time, and updated in Siebel CRM bundles and promotions for customers to upgrade their promotions.
In this flow, the BRM product administrator disables the event for real-time product synchronization, and then creates billing products and billing discounts in Pricing Center. The products can be saved in sets to a file. The BRM product administrator runs a batch utility to store the products singly or from the file in the BRM database and synchronize the products with Siebel CRM.
The Siebel CRM product administrator uses the billing products and billing discounts to create service bundles and promotions. The Siebel CRM product administrator can also add charges, such as penalties, to the promotion.
See "Understanding Product Bundling" for more information about service bundles and promotions.
Figure 3-3 shows how billing products and billing discounts are created in BRM, synchronized to Siebel CRM in batches, and bundled in Siebel CRM for customers to purchase in promotions.
See Oracle Communications Billing and Revenue Management Synchronization Queue Manager for information about how to disable the event for real-time product synchronization.
In this flow, the BRM product administrator disables the event for real-time product synchronization. The BRM product administrator can update the attributes of billing products and billing discounts in Pricing Center. The products can be saved singly or as sets in a file. The BRM product administrator runs a batch utility to store the updates singly or from the file in the BRM database and synchronize them with Siebel CRM.
The service bundles and the promotions in Siebel CRM are updated to use the latest version of the billing products and billing discounts. The Siebel CRM product administrator can make any necessary changes to the promotions or bundles.
Figure 3-4 shows the business process flow for synchronization of update batch billing products and billing discounts.
See Oracle Communications Billing and Revenue Management Synchronization Queue Manager for information about how to disable the event for real-time product synchronization.
When products are created in BRM, they are associated with billable events that determine how much and how often to charge customers. Each product created in BRM is associated with at least one billable event. Products that are associated with a single event are synchronized to Siebel CRM as simple products and products that are associated with multiple events are synchronized as customizable products.
Table 3-1 gives an example of how products are synchronized to Siebel CRM. Because the Internet product in BRM has multiple events, it is synchronized as a customizable product in Siebel CRM.
Table 3-1 Example of Synchronizing Products to Siebel CRM
In BRM | In Siebel CRM |
---|---|
Internet - Monthly Cycle Forward Event - $25 - Product Purchase Fee Event - $30 - Delayed Telcom GSM Session Event - 0.40 |
Internet - $25 - Internet Purchase - $30 |
Figure 3-5 shows the synchronization of billing products with pricing details.
For this flow, the following events occur:
A BRM user creates single-event and multi-event billing products in Pricing Center and commits them to the BRM database.
Real-time synchronization is invoked automatically or the product administrator invokes a batch utility to synchronize the products. The integration raises a ProductABM business event in BRM with the complete definition of the products.
The AQConsumer connecter service, which is subscribed to this business event, extracts the product-related details from the ProductABM and passes the message to the BRM requester service.
The requester service routes the message to the Siebel-specific connector service (Siebel Synchronize Product Provider).
The Siebel Synchronize Product provider service transforms the standardized product definition (ItemCompositionListEBM) to a Siebel application-specific definition of the product. It invokes the Siebel application web services to create the products in the Siebel application. The status of the web service call (Success or Fail) is returned back to the caller service (Siebel Synchronize Product provider).
The Siebel Synchronize Product provider service processes the status and sends the details to the Host Application connector service (BRM Synchronize Product requester ABCS) using a standardized response message (ItemCompositionResponseEBM).
Once the products are successfully created, the BRM Synchronize Product requester ABCS extracts the pricing information from the billing products and transforms them into a standardized representation of the pricing (PriceListEBM). The service provides the PriceListEBM as input.
The provider service routes the message to the Siebel-specific connector service (Siebel Synchronize Pricelist Provider).
The Siebel Synchronize Pricelist provider service transforms the standardized pricelist definition (PriceListEBM) to the Siebel-specific definition of the pricing. If there are multiple events associated with the pricing then simple products are created in the target CRM for each event. The prices related to the events are assigned to the corresponding simple products. To create simple products, the connector service transforms the events into a standardized representation of the items (ItemCompositionListEBM).
The provider service routes the message to the Siebel-specific connector service (Siebel Synchronize Product Provider).
The Siebel Synchronize Product provider service transforms the standardized product definition (ItemCompositionListEBM) to a Siebel-specific definition of the product. It invokes the Siebel application web services to create the simple products for each event in the Siebel application. The status of the web service call (Success or Fail) is returned back to the caller service (Siebel Synchronize Product Provider).
The Siebel Synchronize Product provider service processes the status and sends the details to the caller Siebel Synchronize PriceList provider service using a standardized response message (ItemCompositionResponseEBM).
The Siebel Synchronize PriceList provider service updates the simple products created earlier with the pricing attributes of the product (Price Type) by invoking the Siebel product creation web service. The status of the web service call (Success or Fail) is returned back to the caller service (Siebel Synchronize PriceList Provider).
The Siebel Synchronize PriceList provider service updates the pricelist for all products with the actual pricing information (List Price, Effectivity, and so on) associated with the products. The status of the web service call (Success or Fail) is returned to the caller service (Siebel Synchronize PriceList Provider).
Setting the Billable Flag for Products in Siebel CRM
During the product synchronization from Siebel CRM to BRM, the billable flag is set for all products of billing type Subscription. The billable flag is not set for products of billing type Event.
For service bundles, promotions, and simple products of billing type Special Rating, you must manually set the billable flag in Siebel CRM.
See Siebel Communications Guide for more information about setting the billable flag in Siebel.
These product attributes are included for all the products in the XML message that is sent to Siebel:
Product Name
Product Type
Purchase Level
Description
Billable Events
Rate Plan
Effective Start Date and Effective End Date
Rate plan details (charges) go into the price list line and all other attributes go into the product lines.
The values for the effective start date and the effective end date published by BRM are communicated from and set in Siebel CRM by the product synchronization process.
When the effective start date and effective end date are unspecified or the product has infinite effectivity, the BRM Enterprise Application Integration (EAI) infranet.eai.xml_zero_epoch_as_null parameter must be set to TRUE. Setting this parameter ensures that BRM publishes a null value for the effective start date and the effective end date.
Caution: This is a mandatory step as part of the post installation setup activity. |
See Oracle Communications Billing and Revenue Management Developer's Guide for more information defining infinite start and end date values.
Figure 3-6 shows the synchronization of billing discounts.
For this flow, the following events occur:
The product administrator creates billing discounts in Pricing Center and commits them to the BRM database.
Real-time synchronization with Siebel CRM is invoked automatically or the product administrator invokes a batch utility to synchronize the products. The integration raises a DiscountABM business event in BRM with the complete definition of the discounts.
The connecter service (BRM Synchronize Discount requester) that is subscribed to this business event extracts DiscountABM all the discount-related details and transforms them into a standardized representation of the discount (ItemCompositionListEBM).
The service routes the message to the Siebel-specific connector service (Siebel Synchronize Product provider). The discounts are created as simple products in Siebel CRM.
The Siebel Synchronize Product provider service transforms the standardized discount definition (ItemCompositionListEBM) to a Siebel-specific definition of the product. It invokes the Siebel application web services to create the products in the Siebel application that corresponds to the discount that is published from BRM. The status of the web services call (Success or Fail) is returned back to the caller (Siebel Synchronize Product Provider service).
If a billing product has only one event, then the billing product is synchronized with Siebel CRM as a simple product with no list price.
Table 3-2 shows an example of a product in BRM, Wireless Usage, with only one event, Delayed Telco GSM Session. Wireless Usage is synchronized as a simple product in Siebel CRM.
Table 3-2 Example of a Synchronizing a Billing Product with a Single Event
Product in BRM | Simple Product in Siebel CRM |
---|---|
Wireless Usage Delayed Telco GSM Session Event - 0.40 |
Wireless Usage |
If a billing product in BRM has two events and one of them is a usage charge event, then the billing product is synchronized with Siebel CRM as a simple product. The usage charge event is not synchronized with Siebel CRM. The list price of the simple product in Siebel CRM is set to charge on the other event of the billing product.
Table 3-3 shows an example of a product in BRM, Call Forwarding, with two events, Monthly Cycle Forward and Delayed Telco GSM Session, a usage charge event. Call Forwarding is synchronized as a simple product and the list price is the price of the Monthly Cycle Forward event.
Table 3-3 Billing Product with Two Events Example
Product in BRM | Simple Product in Siebel CRM |
---|---|
Call Forwarding: - Monthly Cycle Forward Event - $3.00 - Delayed Telco GSM Session Event - $0.40 |
Call Forwarding - $3.0 |
If a billing product in BRM has more than two events and one event is a usage charge event then the billing product is synchronized with Siebel CRM as a customizable product. The usage charge event is not synchronized with Siebel CRM. The list price of the customizable product in Siebel CRM is set to charge on another event of the billing product.
Table 3-4 shows an example of a product in BRM, Internet, with three events, Product Purchase Fee, Monthly Cycle Forward Fee, and Delayed Telco GSM Session, a usage charge event. Internet is synchronized as a customizable product and the list price is the price of the Monthly Cycle Forward Fee event.
Table 3-4 Billing Product with More Than Two Events Example
Product in BRM | Customizable Product in Siebel CRM |
---|---|
Internet: - Product Purchase Fee Event - $10.00 - Monthly Cycle Forward Event - $20.00 - Delayed Telco GSM Session Event - $0.40 |
Internet - $20.00: - Product Purchase Fee Event - $10.00 |
The solution is delivered with the events mapped, as shown in Table 3-5.
Table 3-5 Mapping Events - Solution
Event Name | Event Definition |
---|---|
Product Purchase Fee Event (Activation) |
"/event/billing/product/fee/purchase" |
Monthly Cycle Arrear Event |
"/event/billing/product/fee/cycle/cycle forward arrear" |
Monthly Cycle Forward Event |
"/event/billing/product/fee/cycle/cycle forward monthly" |
Bimonthly Cycle Forward Event |
"/event/billing/product/fee/cycle/cycle forward bimonthly" |
Quarterly Cycle Forward Event |
"/event/billing/product/fee/cycle/cycle forward quarterly" |
Annual Cycle Forward Event |
"/event/billing/product/fee/cycle/cycle forward annual" |
Cycle Forward Arrear Event |
"/event/billing/product/fee/cycle/cycle arrear" |
You can add more events in the PRICETYPE_EVENT domain value map. Events that are not present in this mapping are not synchronized.
See "About One-Time Charges for Service Activation and Changes to Promotions and Service Bundles" for more information about handling cancel fees (as a result of service, promotion cancellation/upgrade/downgrade).
See "Working with DVMs for Product Lifecycle Management" for more information about DVMs.
In Siebel CRM, a price list is a set of standard prices for products and services. You can use multiple price lists to offer separate prices for the same product and you can specify a default price list. The price list specifies a price, the currency for that price, and the frequency with which the price is charged.
For example, you can use separate price lists to charge business customers US$30 a month for internet service and to charge residential customers US$50 a month for the same service. In this example, the residential price list specifies that the price is 30, the currency is US dollars, and the frequency is monthly and the business price list specifies that the price is 50, the currency is US dollars, and the frequency is monthly.
You can use multiple price lists to offer different prices in different market segments (such as consumer or business customers, as in the previous example), different currencies, different sales channels (such as products purchased online or at a store), or different geographic locations.
Siebel CRM price lists map to rate plans in BRM. You create the price lists in Siebel CRM and set up the mapping between price lists and rate plans in the PRICELIST domain value map (DVM) before creating products in BRM. See "Configuring Siebel CRM for Integrated Product Lifecycle Management" for more information.
While creating products in BRM, you define rate plans to specify what to charge for the products. You associate the rate plans with corresponding price lists configured in Siebel CRM so that the integration can determine where Siebel CRM tracks charges.
Note: BRM also has a price list entity, but this is different from the Siebel CRM price list. When this document refers to price lists, it is referring to the Siebel CRM entity. For more information about BRM price lists, see Oracle Communications Billing and Revenue Management Setting Up Pricing and Rating. |
Note: Integration of multiple price lists is supported only with BRM version 7.5 and later. For earlier versions, you must use a single default price list. |
At design time, you create products in BRM and define the rates to charge for those products in rate plans.
You can define rates in BRM according to the following rate plan structures:
Single rate plan: charges according to one rate. The integration automatically associates the single rate plan structure with the default Siebel CRM price list.
Rate plan selector: charges according to different rates depending on event data. You must associate each rate plan in a rate plan selector with a separate Siebel CRM price list.
Custom event analysis: charges according to different rates depending on event data based on custom attributes. Using custom event analysis is similar to using a rate plan selector. You must associate each rate plan that uses custom event analysis with a Siebel CRM price list and you must modify BRM policy opcodes to define your custom rating criteria. See the discussion of using custom event analysis in the Pricing Center Help for more information about custom event analysis.
After you have created products in BRM and synchronized them to Siebel CRM, you can manage product pricing as described in "Managing Pricing in Rate Plans and Price Lists".
See Oracle Communications Billing and Revenue Management Setting Up Pricing and Rating for more information about rate plans, rate plan selectors, and custom event analysis.
You associate rate plans in BRM with Siebel CRM price lists in Pricing Center using a rate plan selector.
To associate a rate plan with a price list using a rate plan selector:
In Pricing Center, follow the steps for defining rate plan selectors described in the Pricing Center Help.
When setting up columns for your rate plan selector, create a column called EVENT.PIN_FLD_USAGE_TYPE.
Add a row for each rate plan and corresponding price list that you intend to use.
In the EVENT.PIN_FLD_USAGE_TYPE column:
To associate a rate plan with a specific price list, enter the name of the price list exactly as it appears in the PRICELIST DVM.
If you enter a name that does not appear in the PRICELIST DVM, an error will occur when you synchronize the products to Siebel CRM.
To associate a rate plan with the default price list, enter * in the place of a price list name. The integration maps * to the default price list. See Table 3-7 for an example.
In the Rate Plan column, enter the name of the rate plans that correspond to the price lists that you entered in the EVENT.PIN_FLD_USAGE_TYPE column.
Finish defining the rate plan selector as described in the Pricing Center Help.
Example Rate Plan Structures
In this example:
Two products have been synchronized from BRM to Siebel CRM: Broadband and GSM.
A default price list has been set up in Siebel CRM, and entered into the AIAConfigurationProperties.xml file and the PRICELIST DVM, as described in "Configuring Siebel CRM for Integrated Product Lifecycle Management".
Four additional price lists have been set up in Siebel CRM and entered into the PRICELIST DVM: ConsumerPL, BusinessPL, NewYorkPL, and CaliforniaPL.
Five rate plans have been set up in Pricing Center: ConsumerRP, BusinessRP, NewYorkRP, CaliforniaRP, and StatesRP.
Table 3-6 shows the rate plan structure for the Broadband product. For this product, the product administrator uses two price lists to offer different prices for consumer and business customers.
Table 3-6 Example Rate Plan Structure for Broadband Product
Rate Plan Name | Price List Associated with the Rate Plan | Tier | Start Date | End Date | Monthly Cycle Forward Fee |
---|---|---|---|---|---|
ConsumerRP |
ConsumerPL |
1 |
01/01/2013 |
12/31/2013 |
$40 |
BusinessRP |
BusinessPL |
1 |
01/01/2013 |
12/31/2013 |
$30 |
Table 3-7 shows the rate plan structure for the GSM product. For this product, the pricing administrator uses the NewYorkPL and CaliforniaPL price lists to offer different prices for customers in New York and California and the default price list for customers in all other states. To make the integration use the default price list, the product administrator enters * for the price list associated with the StatesRP rate plan.
Table 3-7 Example Rate Plan Structure for GSM Product
Rate Plan Name | Price List Associated with the Rate Plan | Tier | Start Date | End Date | Monthly Cycle Forward Fee |
---|---|---|---|---|---|
NewYorkRP |
NewYorkPL |
1 |
01/01/2013 |
12/31/2013 |
$45 |
CaliforniaRP |
CaliforniaPL |
1 |
01/01/2013 |
12/31/2013 |
$40 |
StatesRP |
* |
1 |
01/01/2013 |
12/31/2013 |
$35 |
In Siebel CRM, the Broadband product is mapped to price list line items under the ConsumerPL and BusinessPL price lists and the GSM product is mapped to price list line items under the NewYorkPL, CaliforniaPL, and default price lists.
To offer a product in multiple currencies:
In Siebel CRM, create price lists as described in "Configuring Siebel CRM for Integrated Product Lifecycle Management", and enter them in the PRICELIST DVM. Create a separate price list for each currency.
In Pricing Center, create rate plans that use the same currencies as the price lists in the PRICELIST DVM.
Define a rate plan selector for your product, associating the rate plans in the rate plan selector with the Siebel CRM price lists that use the corresponding currency. You must ensure that the currency in the rate plans matches the currency in the associated price lists. Currency matching is not validated by Siebel CRM or BRM.
Finish defining the rate plan selector and product as described in the Pricing Center Help.
Commit the product to the BRM database so that it is synchronized to Siebel CRM.
Example of Offering a Product in Multiple Currencies
To offer a product called Broadband in Canadian dollars and U.S. dollars, the BRM product administrator uses a separate rate plan associated with a separate price list for each currency while creating the product.
In this example:
A default price list has been set up in Siebel CRM and entered into the AIAConfigurationProperties.xml file and the PRICELIST DVM.
Two additional price lists have been set up in Siebel CRM and entered into the PRICELIST DVM: CanadaPL and USAPL. The currency for the CanadaPL price list is Canadian Dollars (CAD) and the currency for the USAPL price list is U.S. dollars (USD).
Two rate plans have been set up in Pricing Center: CanadaRP and USARP. The currency for the CanadaRP rate plan is Canadian dollars (CDN$) and the currency for the USARP rate plan is U.S. dollars (US$).
The product administrator uses the rate plan structure shown in Table 3-8 when creating the product.
Table 3-8 Offering the Broadband Product in Multiple Currencies
Rate Plan Name | Price List Associated with the Rate Plan | Tier | Start Date | End Date | Monthly Cycle Forward Fee |
---|---|---|---|---|---|
CanadaRP |
CanadaPL |
1 |
01/01/2013 |
12/31/2013 |
CDN$30 |
USARP |
USAPL |
1 |
01/01/2013 |
12/31/2014 |
US$35 |
When the product administrator commits the Broadband product to the BRM database to synchronize it to Siebel CRM, the Broadband product is mapped to price list line items under the CanadaPL and USAPL price lists.
After you have synchronized your products from BRM to Siebel CRM, you can manage the prices in the rate plans in BRM and resynchronize the products to Siebel CRM to update the price lists. You can manage prices by:
Changing the price of a product by updating the existing rate plan
Changing the price list associated with a product's rate plan
Changing a product from using multiple price lists to using the single default price list
Use the following methods to change the price of a product in the rate plan:
Change the price in the existing rate plan tier by changing the balance impact. See the discussion of defining balance impacts in the Pricing Center Help for more information.
Add a new rate plan tier with the new price and adjust the effectivity dates of the old tier. See the discussions of defining single rate plans and defining valid time periods in the Pricing Center Help for more information.
Examples of Changing the Price of a Product
To change the price of the Broadband product, the BRM product administrator uses Pricing Center to edit the rate plan structure shown in Table 3-6.
Table 3-9 shows how the product administrator changes the price by changing the balance impact of the monthly cycle forward fee in the existing rate plan tier to $35.
Table 3-9 Changing the Balance Impact for the Broadband Product
Rate Plan Name | Price List Associated with the Rate Plan | Tier | Start Date | End Date | Monthly Cycle Forward Fee |
---|---|---|---|---|---|
ConsumerRP |
ConsumerPL |
1 |
01/01/2013 |
12/31/2013 |
$35 |
BusinessRP |
BusinessPL |
1 |
01/01/2013 |
12/31/2014 |
$30 |
Table 3-10 shows how a product administrator changes the price by adding a new tier with a monthly cycle forward fee of $35 to the ConsumerRP rate plan and adjusting effectivity dates of the old tier.
Table 3-10 Adding a Rate Tier to the Existing Rate Plan for the Broadband Product
Rate Plan Name | Price List Associated with the Rate Plan | Tier | Start Date | End Date | Monthly Cycle Forward Fee |
---|---|---|---|---|---|
ConsumerRP |
ConsumerPL |
1 |
01/01/2013 |
01/31/2013 |
$40 |
ConsumerRP |
ConsumerPL |
2 |
01/31/2013 |
12/31/2014 |
$35 |
BusinessRP |
BusinessPL |
1 |
01/01/2013 |
12/31/2014 |
$30 |
When the product administrator has made the changes and committed the Broadband product to the BRM database, the Broadband product is resynchronized to Siebel CRM and the corresponding price list line items are updated.
To change the price list of a product:
In Pricing Center, set the duration end date to the current day for the rate plan that is associated with the old price list. See the discussion of defining the duration of a rate in the Pricing Center Help for more information.
Add a new row to the rate plan selector.
In the EVENT.PIN_FLD_USAGE_TYPE column, enter the name of the new price list for the rate plan exactly as it appears in the PRICELIST DVM.
If you enter a name that does not appear in the PRICELIST DVM, an error will occur during product synchronization.
Finish defining the new row for the rate plan selector as described in the Pricing Center Help.
Commit the product to the BRM database so that the product is resynchronized to Siebel CRM.
Example of Changing the Price List of a Product
To change the price list of the Broadband product with the rate plan structure shown in Table 3-6, the BRM pricing administrator uses Pricing Center to edit the rate plan structure. As shown in Table 3-11, the product administrator does the following:
Changes the end dates for the ConsumerPL price list to the current date.
Adds a new row to the rate plan selector for the ConsumerRP rate plan and new ConsumerPlusPL price list (which has already been created in Siebel CRM and entered in the PRICELIST DVM).
Table 3-11 Changing the Price List of the Broadband Product
Rate Plan Name | Price List Associated with the Rate Plan | Tier | Start Date | End Date | Monthly Cycle Forward Fee |
---|---|---|---|---|---|
ConsumerRP |
ConsumerPL |
1 |
01/01/2013 |
01/31/2013 |
$40 |
ConsumerRP |
ConsumerPlusPL |
1 |
01/31/2013 |
12/31/2014 |
$40 |
BusinessRP |
BusinessPL |
1 |
01/01/2013 |
12/31/2014 |
$30 |
When the product administrator makes the changes and commits the product to the BRM database, the product is resynchronized to Siebel CRM, the ConsumerPL price list line items are updated, and the Broadband product is mapped to new price list line items under the ConsumerPlusPL price list.
To change a product in BRM that has already been synchronized to Siebel CRM from using multiple price lists to using the default price list:
If the one of the rate plans in the rate plan selector is associated with the default price list (uses * in the EVENT.PIN_FLD_USAGE_TYPE column):
In Pricing Center, set the duration end dates to the current day for all of the rate plans for the product associated with non-default price lists. Leave the rate plan associated with the default price list as is.
See the discussion of defining the duration of a rate in the Pricing Center Help for more information about setting the duration end date.
Commit the product to the BRM database so that the product is resynchronized to Siebel CRM.
If none of the rate plans in the rate plan selector are associated with the default price list:
In Pricing Center, set the duration end dates to the current day for all of the rate plans associated with the product.
See the discussion of defining the duration of a rate in the Pricing Center Help for more information about setting the duration end date.
Commit the product to the BRM database so that the product is resynchronized to Siebel CRM.
Under the Rate Plan Structure column for the product, select Single Rate Plan.
Commit the product to the BRM database so that the product is resynchronized to Siebel CRM. The integration automatically associates the single rate plan structure with the default Siebel CRM price list.
Examples of Changing a Product from Multiple Price Lists to a Single Price List
To change the GSM product with the rate plan structure shown in Table 3-7 from using multiple price lists to using a single price list (the default price list), the BRM product administrator uses Pricing Center to edit the rate plan selector. The product administrator does the following:
Changes the end dates of the NewYorkRP and CaliforniaRP rate plans to the current date. See Table 3-12.
Table 3-12 Setting the End Date for Rate Plans for the GSM Product
Rate Plan Name | Price List Associated with the Rate Plan | Tier | Start Date | End Date | Monthly Cycle Forward Fee |
---|---|---|---|---|---|
NewYorkRP |
NewYorkPL |
1 |
01/01/2013 |
01/31/2013 |
$45 |
CaliforniaRP |
CaliforniaPL |
1 |
01/01/2013 |
01/31/2013 |
$40 |
StatesRP |
* |
1 |
01/01/2013 |
12/31/2013 |
$35 |
Commits the product to the BRM database to resynchronize the product to Siebel CRM and update the effectivity dates for the price list line items.
Setting the end date for the rate plans not associated with the default price list means that the integration only uses the default price list and StatesRP rate plan for that product.
To change the Broadband with the rate plan structure shown in Table 3-6 from using multiple price lists to using a single price list (the default price list), the BRM product administrator uses Pricing Center to edit the rate plan selector. The product administrator does the following:
Changes the end dates of the ConsumerRP and Business RP rate plans to the current date. See Table 3-13.
Commits the product to the BRM database to resynchronize the product to Siebel CRM and update the effectivity dates for the price list line items.
Selects Single Rate Plan under the Rate Plan Structure column for the Broadband product.
Commits the product to the BRM database to resynchronize the product to Siebel CRM.
Changing the rate plan structure to Single Rate Plan means that no price list is associated with the rate plan in BRM. The integration automatically associates this rate plan structure with the default Siebel CRM price list and maps the Broadband product to price list line items under the default price list.
A balance group is an object in the BRM database used for tracking the balance that your customers owe for their services. Because service-level balance groups are defined in plans in BRM, and plans are not synchronized to Siebel CRM, the integration does not provide design-time support for balance groups. The integration supports service-level balance groups and account-level balance groups at runtime when submitting Siebel CRM orders to BRM. You must enable or disable service-level balance groups for your entire system.
See "Supporting Balance Groups" for more information about balance groups and instructions for enabling or disabling service-level balance groups.
This section describes the methodology for using service bundles and marketing bundles with billing products synchronized from BRM to Siebel CRM.
Table 3-14 shows the mapping between BRM and Siebel CRM entities.
Table 3-14 Mapping Between BRM and Siebel CRM Entities
BRM Entities | Siebel CRM Entities | Description |
---|---|---|
Product with single event |
Simple product (automatically created) |
If a product is associated with a single billable event in BRM, then a simple product is created in Siebel CRM. |
Product with multiple events |
Customizable product (automatically created) |
If a product is associated with multiple billable events in BRM, then a customizable product is created in Siebel CRM. |
Product Event Binding |
Simple product (automatically created) |
Each recurring and nonrecurring event binding is represented as a simple product. |
Discount |
Simple product (automatically created) |
A billing discount is represented as a simple product regardless of the number of event bindings. |
Balance Impact |
Price list line (automatically created) |
The Price list line in Siebel is mapped to information in Rate Plan, Rate Tier, and Balance Impact in BRM. |
Deal |
Service bundle (manually created) |
If existing BRM customers have previously defined deals, those deals are not synchronized as part of the Product Lifecycle Management (PLM) integration. The service bundles must be created manually in Siebel CRM. |
Plan |
Promotion /marketing bundle (manually created) |
If existing BRM customers have been previously defined in a plan, those plans are not synchronized as part of the PLM integration. The Promotion/Marketing bundles must be created manually in Siebel CRM. |
Service Instance |
Service bundle asset (automatically created) |
Purchasing a service bundle results in a service bundle asset that is mapped to a BRM service instance to support changes to the service. |
Purchased Products |
Service bundle component asset (automatically created) |
Purchasing optional and mandatory components of a service bundle results in asset components that are mapped to BRM purchased products. |
When defining the products and discounts in BRM, use the following guidelines to fully leverage the flexibility and minimize the limitations of this integration:
Because usage events are not synchronized when they are included as a part of multi-event product in BRM, the name and description of products should include some user-readable identity of the usage. That way the product or price administrator can distinguish the synchronized products on the Siebel side.
Because the discount value of the BRM discount objects is not synchronized to Siebel CRM, the name and description of the discount objects should include the general intent of the discount to be conveyed on the Siebel order.
The discountable flag on billing products in BRM must be set to Y for all charges that can be discounted when orders are interfaced to billing.
The integration does not convert time zones when synchronizing BRM products and discounts to Siebel CRM.
The BRM Enterprise Application Integration (EAI) property infranet.eai.date_pattern controls which time zone BRM publishes datetime information in.
If the EAI infranet.eai.date_pattern property is not set, BRM publishes datetime information in the BRM local server time zone. This is the default behavior.
If the EAI infranet.eai.date_pattern property is set, BRM publishes the datetime information in UTC/GMT time zone.
See Oracle Communications Billing and Revenue Management Developer's Guide for more information about setting this property.
In BRM, the type of charge associated with a billable event can be either Scaled or Fixed.
From the user interface perspective, in the pricing center application of BRM, when the price must be associated to the event, two fields exist where the charge can be added.
Scaled amount: Specifying the scaled amount allows price overrides and discounts to be applied on the price. When the scaled amount field is used then the fixed amount field must be left empty (null). Zero must not be specified. The scaled amount is specified only for billable events that represent one-time or recurring charges.
Fixed amount: Discount override takes into consideration both fixed and scaled amounts. However, price override only overrides the scaled amount. The price overrides can still be applied for the charges but it gets added to the price specified as fixed amount. For example, if the fixed amount on the charge is $5 and a price override is $10 then the price is $15.
Consider the case where both the scaled amount and the fixed amount are specified for the product. The product integration synchronizes the product to Siebel CRM and the list price is the sum of the scaled and fixed amounts. If a discount override is specified for the product, when the order is interfaced to billing the discount override is applied on the sum for the purchased product instance in BRM.
For example, a billing product has a monthly cycle fee specified as: Scaled = $20 and Fixed = $10.
A discount override of 10% results in a final price of $27 and a discount override of $5 results in a final price of $25.
If a price override is specified for the product, when the order is interfaced to billing, BRM replaces only the scaled amount with the price override amount for the purchased product instance.
For example, a billing product has a monthly cycle fee specified as: Scaled = $20 and Fixed = $10.
A price override of $15 results in a final price of $25 (Scaled $15 + Fixed $10).
Caution: This behavior for the price override scenario results in a discrepancy between the final price for a product on the order in Siebel CRM and what the customer is actually charged in BRM. Therefore, it is recommended that you not use fixed amounts for either one-time or recurring charges in BRM for implementations where the intent is to use the Siebel price override functionality. |
See "About Real-Time Rate Plan" in Oracle Communications Billing and Revenue Management Setting Up Pricing and Rating for more information about using fixed and scaled amount fields.
You can use either of the following approaches:
Create physical goods as billing products in BRM at the account or service level. These are synchronized to Siebel CRM and can be added to the product hierarchy when creating bundles and promotions.
Define physical goods in Enterprise Resource Planning (ERP). In this case, you are responsible for synchronizing them between ERP and BRM. The product synchronization process, which is supported by the process integration, is used to synchronize the product from BRM to Siebel CRM. If the service or marketing bundle contains one or more physical goods, then those products are passed to BRM when the order is interfaced to billing.
After all of the BRM products are synchronized to Siebel CRM, you must add only those products that can be ordered to the catalogs (products whose orderable flag is set). If customizable products are added to the catalog then the components are automatically added.
Table 3-15 shows examples of products that would be included in the Siebel Catalog.
Table 3-15 Example of Products Included in the Siebel Catalog
BRM Entities | Siebel Synchronized Entities | Siebel Catalog |
---|---|---|
Product: Wireless (Yearly) Event: YCF - $100 |
Wireless - YCF - $100 |
It must be added as a component to a service bundle product, which must be added to the sales catalog. |
Product: Wireless (Monthly) Event: MCF - $40 Event: Usage - $0.40 |
Wireless - MCF -$40 |
The product must be added as a component to a service bundle product, which must be added to the sales catalog. |
Product: Wireless Activation Event: Activation - $10 |
Wireless Activation - $10 |
The product must be added as a component to a service bundle product, which must be added to the sales catalog. |
Product: SMS Activation Event: Activation - $10 |
SMS Activation - $10 |
The product must be added as a component to a service bundle product, which must be added to the sales catalog. |
Product: SMS Usage Event: Usage - $0.05 |
SMS Usage |
The product must be added as a component to a service bundle product, which must be added to the sales catalog. |
These are the recommendations for defining products:
BRM billing products that are defined with fixed charges should not be discounted in Siebel CRM (using promotion discounts, price overrides, and so forth) because communicating such overrides to BRM results in a price increase. Oracle recommends that only scaled charges be defined for the billing products of type item and subscription with one-time or recurring charges in BRM.
See "Using Fixed Amounts versus Scaled Amounts in BRM" for more information.
The Product Management integration maintains cross-reference information between BRM billing products and Siebel CRM products. If you delete a billing product in BRM that is synchronized with Siebel CRM, then the cross-reference data for that billing product is not deleted. This has to be purged manually. Instead of deleting the product, inactivate it by specifying an end date.
If products updated in BRM result in changing the product structure in Siebel CRM, then you must release the updated product in its respective workspace. This automatically updates the service bundles and the promotions that include the updated product as one of its components.
You can nest billing products within each other in Siebel CRM. Though there is no limit the levels of nesting, any product nested more than two levels below a service bundle is purchased at the account level. See "About Service Bundles" for more information about service bundles and their components.
This section describes customizable discounts that are time-based or that impact noncurrency resources and multiple event types.
Customizable discounts that are either time-based, or that impact noncurrency resources or multiple event types, must be defined in BRM. These can be account-level or service-level discounts. Because you can associate general ledger IDs (GLIDs) with them in BRM, you can account for them in the general ledger in separate accounts if needed.
These discounts are defined in BRM and synchronized to Siebel CRM as simple products (Structure type = none). The products that represent the discounts are identified using the billing type Discount. You manually bundle the service-level discounts into the service bundles.
These can be included or excluded during promotion bundling. The account-level discounts are directly added as components of the promotions and can be made optional based on promotional bundling.
You can define simple discounts in Siebel CRM when you bundle the billing products into service bundles and promotions. These are usually matrix or promotional discounts. If these discounts are applied on the order at run time, there will be a difference between the start or list price and the net price.
The following offers you greater control and flexibility in determining how pricing differences between the list price and the selling price are communicated to the billing system. Two new fields are on the Siebel product definition:
Pricing commit type.
The value of the pricing commit type field indicates whether a price override or a discount override is being defined on the product:
If the pricing commit type is Committed, then a price override has been defined on the product.
If the pricing commit type is Dynamic, then a discount override has been defined on the product. If a discount override has been defined on the product, then the Dynamic discount method field identifies the discount type.
Dynamic discount method.
If the dynamic discount method is Amount, then an amount is defined as the discount value.
If the dynamic discount method is Percent, then a percent discount has been defined as the discount value.
In BRM, discount overrides can be tracked in a separate sub-bucket within the GL code that is tied to the product. With discount overrides, mass price changes can also be supported because the list price on the product remains unchanged.
Service bundles are groups of related products that are sold as a package in Siebel CRM. You create service bundles in Siebel CRM to group the following types of product:
Billing products: BRM products synchronized to Siebel CRM as simple or customizable products.
Billing discounts: BRM discounts synchronized to Siebel CRM as simple products. Discounts included in a service bundle apply only to the products within the service bundle.
Non-billing products: Products you create in Siebel CRM that are not synchronized from BRM.
Non-service-bundle customizable products: Customizable products that you create in Siebel CRM to group service bundles and products (including account-level products and non-billing products) for re-use in promotions.
Service bundles must include at least one subscription-based billing product or discount. Model product bundles that do not include at least one as non-service-bundle customizable products.
You can also include other service bundles in a service bundle. These are nested service bundles. There is no limit to the levels of nested service bundles.
Account-level products, such as monthly charges for a hard copy of a bill, are charged to the account. Do not include these product in service bundles unless you nest them more than two levels below a service bundle.
You can nest billing products and discounts within another billing product or discount, but the integration synchronizes billing products or discounts nested more than two levels below a service bundle at the account-level when they are purchased on Siebel CRM order. See "Supporting Product Bundling" for more information about how the integration synchronizes the information on orders.
To create a service bundle in Siebel CRM, you manually create a customizable product with the billing type set to Service Bundle and choose which products to include in the service bundle.
You can flag subscription billing products synchronized from BRM as simple service bundles. See "About Simple Service Bundles" for more information.
Figure 3-7 shows an example of the hierarchy in Siebel CRM for a service bundle that contains billing products, a billing discount, a simple service bundle, and a non-service-bundle customizable product.
Figure 3-7 Example of Service Bundle Hierarchy
When multiple instances of BRM are connected to the same Siebel CRM instance, all products included in a service bundle must come from the same BRM instance. Siebel CRM does not store the target billing instance details. See "Configuring Multiple BRM Instances for Communications Integrations" for more information about connecting multiple BRM instances.
See Siebel Communications Guide for more information about service bundles in Siebel CRM.
The billing service type is a field in BRM that you set when you create products and discounts to indicate which type of service they apply to. For example, a product charging for text messaging might have the service type /service/telco/gsm/sms.
Siebel CRM automatically assigns service bundles the billing service type of their component products. Do not change the billing service type assigned to the service bundle in Siebel CRM.
For AIA to successfully send orders for service bundles to billing, you must only include products or discounts synchronized from BRM that have the same billing service type in a single service bundle.
Nested service bundles do not need the same billing service type as the service bundle that contains them (their parent service bundle), but all component billing products and discounts of a nested service bundle must have the same billing service type.
Because non-billing products and non-service-bundle customizable products are created in Siebel CRM, they do not have a billing service type.
A simple service bundle is a subscription product synchronized from BRM that you flag in Siebel CRM. When you submit an order for a subscription product flagged as a simple service bundle, the integration treats the product as a service bundle in BRM. See "Synchronizing Simple Service Bundles" for more information about how the integration synchronizes orders containing simple service bundles.
In Siebel CRM, you can model a simple service bundle by itself, nest it within another service bundle, or nest it within a non-service-bundle customizable product.
To flag a subscription product synchronized from BRM as a simple service bundle in Siebel CRM, you set the Service Instance flag to Y in Siebel CRM for that product.
Note: You set the Service Instance flag manually. The integration does not set, update, or overwrite the flag when products are created or synchronized. |
For more information about configuring simple service bundles with the Service Instance flag, see Siebel Communications Guide.
Table 3-16 shows how you can model the same products in Siebel CRM using se rvice bundles or simple service bundles.
The following acronyms are used in the table:
CP: Customizable product
SBC: Service bundle component product synchronized from BRM
SB: Service bundle manually created in Siebel CRM, billing type set to Service Bundle
SSB: Simple service bundle made of a subscription product synchronized from BRM with the Service Instance flag set to Y
Table 3-16 Modelling Using Service Bundles or Simple Service Bundles
Hierarchy | Service Bundle | Hierarchy | Simple Service Bundle |
---|---|---|---|
1 |
CP: Internet Access Service (SB) |
1 |
CP: Internet-MCF (SSB) |
1.1 |
----- CP: Internet - MCF (SBC) |
1.1 |
----- Internet - Activation (SBC) |
1.2 |
----- Internet - Activation (SBC) Note: The internet product is mapped to multiple events in BRM. |
-- |
-- |
2 |
CP: Internet Service (SB) |
2 |
CP: Internet Service (SB) |
2.1 |
---- Dynamic Class |
2.1 |
---- Dynamic Class |
Only 1 of these 3 is selected |
Basic High Speed Internet MCF (SBC) Premium High Speed Internet MCF (SBC) Elite High Speed Internet MCF (SBC) |
Only 1 of these 3 is selected |
Basic High Speed Internet MCF (SBC) Premium High Speed Internet MCF (SBC) Elite High Speed Internet MCF (SBC) |
2.2 |
----- Internet Secure Firewall (SBC) |
2.2 |
----- Internet Secure Firewall (SBC) |
2.3 |
----- CP: High Speed Internet Features (NSB-CP) Note: The NSB-CP is optional; without it the four-feature SBs have the Internet Service SB as the parent. |
2.3 |
----- CP: High Speed Internet Features (NSB-CP) Note: The NSB-CP is optional; without it the four-feature SBs have the Internet Service SB as the parent. |
2.3.1 |
-------- CP: Internet email (SB) |
2.3.1 |
---------- Internet email (SSB) |
2.3.1.1 |
------------- Internet email (SBC) |
2.3.2 |
---------- Internet Instant Chat (SSB) |
2.3.2 |
-------- CP: Internet Instant Chat (SB) |
2.3.3 |
---------- Internet Conference Chat (SSB) |
2.3.2.1 |
------------- Internet Instant Chat (SBC) |
2.3.4 |
---------- CP: Internet Media (SB) |
2.3.3 |
-------- CP: Internet Conference Chat (SB) |
2.3.4.1 |
--------------- Internet Content on Demand (SBC) |
2.3.3.1 |
------------- Internet Conference Chat (SBC) |
2.3.4.2 |
--------------- Internet Video on Demand (SBC) |
2.3.4 |
-------- CP: Internet Media (SB) |
2.3.4.3 |
--------------- High Speed Internet First Month-Free Discount (SBC) |
2.3.4.1 |
------------- Internet Content on Demand (SBC) |
-- |
-- |
2.3.4.2 |
------------- Internet Video on Demand (SBC) |
-- |
-- |
2.3.4.3 |
------------- High Speed Internet First Month- Free Discount (SBC) |
-- |
-- |
The assumptions and constraints for working with simple service bundles are as follows:
Simple service bundles can only ever have one billing product. They cannot include service-level billing discounts. To combine multiple products and discounts, you must use a regular service bundle.
Only products of type Subscription can become simple service bundles.
You cannot apply special rating, such as friends and family rates, to simple service bundles.
You cannot bundle additional billing product and discounts, special rating products, or other service bundles within a simple service bundle.
You cannot include existing products that have pending quotes, orders, or assets in Siebel CRM or are referenced by BRM in simple service bundles. Including such products would impact existing asset cross-references.
You can neither convert simple service bundles into regular service bundles, nor convert regular service bundles into simple service bundles because of possible effects on processing of change orders for existing assets. If your product bundling requirements change, you must create a different product in BRM, synchronize it to Siebel CRM, and bundle it differently.
A product that is flagged as a simple service bundle cannot be included in a regular service bundle. A product that is already in a regular service bundle cannot be flagged as a simple service bundle. If your product bundling requirements change, you must create a new product in BRM, synchronize it to Siebel CRM, and bundle it differently.
If you disconnect a simple service bundle, the integration disconnects both the service instance and the purchased product that instance in BRM. You cannot change from one simple service bundle to another while retaining the same service instance.
You must provide the service ID for both regular and simple service bundle lines for the integration to successfully interface purchases to BRM.
After all of the service bundles are defined, the marketing manager can create marketing bundles or promotions to group services and products that are to be sold as promotions. The promotions definition offers the flexibility to be upgraded to other promotions.
Table 3-17 is an example of a marketing bundle for a wireless promotion with SMS.
Table 3-17 Marketing Bundle for a Wireless Promotion Example
1 |
Nation 550 Minutes |
1.1 |
-- Wireless Plan |
1.1.1 |
----- Wireless Service |
1.1.1.1 |
-------- Basic Wireless 550 |
1.1.1.2 |
-------- Friends |
1.1.1.3 |
-------- Wireless Voice Service Feature |
1.1.1.3.1 |
---------- Wireless Voice Mail |
1.1.1.3.2 |
---------- Wireless Call Conference |
1.1.1.3.3 |
---------- Wireless Caller ID |
1.1.1.3.4 |
---------- Wireless Call Waiting |
1.1.1.3.5 |
---------- Wireless Call Forwarding |
1.1.1.4 |
-------- Text Messaging |
1.1.1.4.1 |
---------- Text Messaging SMS 200 |
1.1.1.4.2 |
---------- Text Messaging Usage |
1.2 |
-- 50% Activation Discount |
The definition of marketing bundles is also used as a grouping for balance groups. For example, each promotion defines the boundaries of a balance group such that each included service bundle's service uses shared resources.
By using the communications product bundling methodology, promotion variants can be created by reusing the same non-service-bundle customizable products or service bundles if the bundles have options as components.
Note: Options are defined as a class-type relationship with the product that represents the options that are included in the relationship domain in Siebel CRM. |
The same service bundle can create promotion variants. This ensures that the service is not disconnected during promotion upgrade or downgrade.
See "Product Definition Methodology for Friends and Family: Example" for more information on promotion variants created by reusing the service bundles
The following are defined in context of the Promotion in Siebel CRM.
Upgrades: Specify promotions to which the original promotion can be upgraded.
Pricing adjustments: specify the price or discount overrides for the component products at any level in context of the Promotion.
See "Understanding the Bill Fulfillment Order Business Flow"for more information about Price and Discount overrides.
See Siebel Pricing Administration Guide for more information about Promotion definition.
Because credit limits are typically defined at the billing-plan level in BRM, and such plans are not synchronized, you can optionally define the default credit limits for each separate service type. The integration does not support overrides of credit limits while bundling products or capturing orders.
You can charge your customers for the following actions using one-time charges:
Activating their services
Canceling, upgrading, or downgrading a promotion
Suspending, resuming, moving, or disconnecting a service bundle. These are called Move, Add, Change, and Disconnect (MACD) actions.
When charging for changes to a promotion, you can define proration plans in Siebel CRM to prorate the charge.
When charging for MACD actions on a service bundle, the integration uses related products in Siebel CRM instead of BRM-internal event mappings. Using Siebel CRM instead of BRM lets you see the charges on the order.
See the discussion of employee asset-based ordering in Siebel Order Management Guide Addendum for Communications for more information about setting up service charges using related products in Siebel CRM.
When you submit an order to cancel, upgrade, or downgrade a promotion, or suspend, resume, move, or disconnect a service bundle, Siebel CRM automatically adds the charge product with the appropriate charge amount to the order.
To charge your customers for cancelling, upgrading, or downgrading a promotion:
In BRM, define penalty charges as Item products with a one-time charge and
Commit the products to the BRM database so that they are synchronized to Siebel CRM.
In Siebel CRM, modify the promotion disconnect workflow process (ISS Promotion Disconnect Process) to use the penalty charge products synchronized from BRM.
See "Workflows for Employee Asset-Based Ordering" in Siebel Order Management Guide Addendum for Communications for more information about ISS Promotion Disconnect Process.
To charge your customers for Move, Add, Change and Disconnect (MACD) actions for service bundles:
In BRM, define the charges as Item products for every service type that you enable MACD charges for.
Commit the products to the BRM database so that they are synchronized to Siebel CRM.
In Siebel CRM, associate the charge products for the MACD actions to the service bundles as related products. See the discussion of setting up service charges in Siebel Order Management Guide Addendum for Communications for more information.
To charge your customers for service activation:
In BRM, define an Item product with a one-time charge.
Commit the product to the BRM database so that it is synchronized to Siebel CRM.
In Siebel CRM, set the Track as Asset flag for the charge product to Y.
The Friends and Family feature supports the ability to rate calls to certain phone numbers differently from others.
Special rating products and special rating profile lists in Siebel CRM are used to associate friends and family lists to services. Discounted rating for friends and family lists is defined in BRM.
Special rating products must be manually defined in Siebel CRM, included in the service bundle along with the usage-based subscription product, and eventually added into the promotion during product modeling. When a promotion is purchased, the customer service representative (CSR) associates lists to the special rating products and optionally adds numbers to the lists. After the order is fulfilled and completed, the customer can update their friends and family lists.
See "Supporting Friends and Family Lists" and "Implementing the Synchronize Customer Special Rating Profile Business Flow" for more information about how the lists are created and associated with the list product during run time.
Figure 3-8 shows the business process task flow for friends and family.
To enable friends and family:
You must perform the following in BRM:
Define discounted pricing for friends and family lists. This involves specifying a label name for each list type defined in billing.
Caution: The solution does not use the BRM Provisioning Tag Framework to support the Friends and Family feature. |
See "Working with Extended Rating Attributes" and "About rating based on Friends and Family ERA" in Oracle BRM Documentation for more information.
You must perform the following in the Siebel CRM Project Workspace:
Create a simple product with a name that is identical to the list label name used in BRM (while defining the discounted pricing for the lists).
Set the billing type of the product to Special Rating.
Leave the billing service type blank.
Tip: This allows the use of the same special rating product across different types of services (such as Wireless and VoIP) for which you want to enable Friends and Family. |
Set the billable flag to Y
Set the track as asset flag to Y
Add the special rating products to the service bundle that represents the service that supports friends and family lists. This service bundle must include a usage-based subscription product that is used to rate service usage.
Include the service bundle in the desired promotion(s) and release all the entities.
See "Profiles in Siebel Communications" in Siebel Communications Guide for more information on friends and family plans.
Table 3-18 and Table 3-19 are examples of the product definition methodology.
BRM Definition
Table 3-18 BRM Definition
Products in BRM | Service Type |
---|---|
Basic Wireless 550 ------ Monthly Cycle Forward Event ------ Delayed Telco GSM Event |
/service/telco/gsm/telephony |
Premium Wireless 800 ------ Monthly Cycle Forward Event ------ Delayed Telco GSM Event |
/service/telco/gsm/telephony |
Unlimited Wireless Voice ------ Monthly Cycle Forward Event ------ Delayed Telco GSM Event |
/service/telco/gsm/telephony |
Wireless Add On Line ------ Monthly Cycle Forward Event ------ Delayed Telco GSM Event ------ Product Purchase Fee Event |
/service/telco/gsm/telephony |
Wireless Voice Activation ------ Product Purchase Fee Event |
/service/telco/gsm/telephony |
Wireless Voice Mail |
/service/telco/gsm/telephony |
Wireless Call Conference |
/service/telco/gsm/telephony |
Wireless Caller ID |
/service/telco/gsm/telephony |
Wireless Call Waiting |
/service/telco/gsm/telephony |
Wireless Call Forwarding |
/service/telco/gsm/telephony |
Text Messaging SMS 200 |
/service/telco/gsm/sms |
Text Messaging SMS 400 |
/service/telco/gsm/sms |
Text Messaging SMS Unlimited |
/service/telco/gsm/sms |
Text Messaging Usage |
/service/telco/gsm/sms |
50% Activation Discount |
/account |
Define discounted pricing in BRM for rating phone numbers on the Special Rating lists. Use the label Friends and Family.
Siebel CRM Representation