Skip Headers
Oracle® Application Integration Architecture Oracle Product Master Data Management Integration Implementation Guide
Release 11.1

Part Number E27426-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

5 Oracle Product Master Data Management Integration Option for Oracle Communications BRM

Oracle Communications Billing and Revenue Management (BRM) is available as an installation option in the Product MDM integration.

For more information about Oracle BRM, see the Oracle BRM product documentation.

This chapter includes the following sections:

5.1 Synchronization of Billing Products from Oracle Product Hub to Oracle BRM

Table 5-1 shows the types of billing products supported by the process integration:

Note:

Although these examples are communications-specific, these are billing products that can be used, based on industry requirements.

Table 5-1 Supported billing products

Product Type Applies To Charge Type Example Comments

Item

Account

One-Time

Penalty for cancellation for the service.

Recurring charges or cycle-forward charges are not applicable for product type of item.

--

Service

One-Time

One-time service charges such as suspend service fee and resume service fee.

Recurring charges or cycle-forward charges are not applicable for product type of item.

Subscription

Account

One-Time

One-time purchase fee that is not related to the service being purchased.

NA

--

Account

Recurring

Service provider (SP) charges a monthly flat fee of $10 for sending a hard copy of the invoice using FedEx.

NA

--

Service

One-Time

One-time fee related to the service being purchased. Activation or installation fee.

NA

--

Service

Recurring

Monthly charges associated with the service.

NA

--

Service

Usage

Charges are applied based on the usage generated in the billing application

NA


Note:

BRM supports multi-tier rating to be associated with rate plans. The OPH pricing model in the seeded telecommunications library can be used to define multi-tier rating for an item. The process integration supports multi-tier rating between OPH and BRM; however, the integration to Siebel does not support multi-tier rating. The canonical model (PriceListEBO) also supports multi-tier rating.

Every product is associated with events, which determine how much and how often to charge the customers. These events are called billable events. Products that have one billable event are called single-event product and products that have more than one billable event are called multi-event products in BRM. Every billable event is associated with the rate plan that defines the charge and the frequency of applying the charges.

The item name and item long description in OPH are used to define the billing product name and billing product description in BRM, respectively.

OPH provides a seeded UDA framework to define the billing products in OPH. These seeded attribute groups and attributes are used to define the billing product attributes in OPH:

5.1.1 Multi-Event Product Synchronization from OPH to Siebel

The products that have multiple charges and events are created as customizable products in Siebel. The events are created as separate products and are added as child products of the main product. The component products represent the charges and events and have the billing type of event that is set in Siebel. The item synchronization process from horizontal implementation supports both create and update of products in Siebel.

To support create and update of pricelist, the process integration to Siebel reuses the communications pricelist Siebel-provider-connector services. The OPH requestor item ABCS must create the corresponding item and pricelist line cross-references.

Billing Products with Single Rate Plan

  • Define the base-product-attribute values and define the rate plan. Ensure that the rate plan name is the same as the event name. Otherwise, the BRM service ends in error. This indicates that a single rate plan has been associated with the charge of the billing product.

  • For single rate plans, multi-tier rating can be defined in OPH using the seeded attribute framework. The process integration synchronizes the multi-tier rating from OPH to BRM. The Siebel connector ignores the multi-tier rating and sets the price to 0 (zero). Mostly one-time and recurring charges have single-rate plans defined.

  • For billing products with more than one charge, the pricing model in OPH provides multi-row attribute groups, which the product administrator must use to define multiple charges associated with the product.

Billing Products with Rate Plan Selector-Multiple Rate Plans

  • In case of BRM, multiple-rate plans can be associated by means of rate plan selectors or multiple single rate plans (custom event analysis).

  • If rate plan selectors must be associated with the charges, then specify the rate-plan-selector name in the pricing model and leave the rate plan name as NULL.

  • If multiple single-rate plans (custom event analysis) must be associated with the charges, specify the rate plan names and do not specify the rate-plan selector name in the pricing model. The rate plan names must be unique across events and charges.

  • The charges for the billing products are defined by means of the UDA pricing model supported by OPH. The charges must be created as events in BRM and the corresponding prices must be associated with the events. Mostly one-time and recurring charges have multiple rate plans defined.

Note:

The rate plan selector is defined in BRM. Subsequent updates made to the billing product in OPH and synchronized to BRM do not remove the rate plan selector enriched in BRM.

Billing Products with Usage Rating

The billing products with usage rating can be defined as follows:

  • A billing product where usage is the only event for the product.

  • A billing product where usage is one of the many events associated with the product.

In OPH, only the name of the usage rate plan is defined and published to the target applications. Oracle BRM uses pipeline-based rating for usage charges. The usage-based rating is enriched in Oracle BRM. Only Delayed Telco GSM usage event/charge is supported as the product is delivered. You can add more usage type events and charges and define the corresponding usage rating in the target billing applications.

Note:

The pipeline rate plan is defined in BRM. Subsequent updates made to the billing product in OPH and synchronized to BRM do not remove the pipeline rate plan enriched in BRM.

Table 5-2 summarizes the support offered for pricing in OPH.

Table 5-2

-- -- -- --

Real-Time Rating

One-time

Single Rate Plan

Complete definition in OPH. The rate plan can also be enriched in BRM. The rate plan name must not be changed in BRM because subsequent updates override the changes.

--

--

Rate Plan Selector

OPH sends the rate-plan-selector name and the rate plans are defined and enriched in BRM.

--

--

Custom event analysis

Complete definition in OPH. The rate plans can also be enriched in BRM. The rate plan names must not be changed in BRM because subsequent updates override the changes.

--

Recurring

Single Rate Plan

Complete definition in OPH. The rate plan can also be enriched in BRM. The rate plan name must not be changed in BRM because subsequent updates override the changes.

--

--

Rate Plan Selector

OPH sends the rate-plan-selector name and the rate plans are defined and enriched in BRM.

--

--

Custom event analysis

Complete definition in OPH. The rate plans can also be enriched in BRM. The rate plan names must not be changed in BRM because subsequent updates override the changes.

--

Usage

Single Rate Plan

Complete definition in OPH. The rate plan can also be enriched in BRM. The rate plan name must not be changed in BRM because subsequent updates override the changes.

--

--

Rate Plan Selector

OPH sends the rate-plan-selector name and the rate plans are defined and enriched in BRM.

--

--

Custom event analysis

Complete definition in OPH. The rate plans can also be enriched in BRM. The rate plan names must not be changed in BRM because subsequent updates override the changes.

Pipeline Rating

Usage

Pipeline rate plans

OPH sends only the rate plan name. Enrichment of pipeline usage rating is done in BRM. The enrichment done in BRM is not removed when the updates are synchronized.


Pricing Hierarchy of BRM

Figure 5-1depicts the real-time rating in Oracle BRM.

Figure 5-1 Pricing Hierarchy

pricing hierarchy

The pricing hierarchy can be modeled in OPH by means of the seeded telecommunications library UDAs. The pricing hierarchy is defined in context of an item that represents the billing product and is published to the target Oracle BRM systems.

One-Time and Penalty Charges

The one-time and penalty charges are defined as simple products (products with one event or charge with real-time single rate plan) in OPH. These have to be synchronized to all the billing instances because these are applied during MACD (move, add, change, delete) orders.

For more information about associating the one-time charges and penalty charges to the corresponding products in Siebel, see the Siebel CRM documentation.

The one-time charges (suspend, resume, move, and so on) are modeled as service-level products and the penalty charges are modeled as account-level products. Some of the products of billing type as subscription (both single event and multi-event) are treated as service bundles. Ensure that the service instance-enabled flag is set for such products.

Service bundles represent products that contain other products and bundles. The billing service type for such products must be set to service bundle. For nonservice bundles, the billing type must not be set.

Support for Multiple-Rate Tiers and Rate Tier Effectivity

Multiple-rate tiers can be defined for the billing products in OPH. These are synchronized to BRM and Siebel. The multiple-rate tiers manifest as multiple pricelist lines on a product in Siebel.

The effectivity on the rate tier can be absolute dates or relative dates based on the product purchase date. The integration from Oracle Product Hub to BRM supports both the absolute and relative effectivity.

The integration from Oracle Product Hub to Siebel supports only absolute effectivity.

For more information about rate tiers and effectivity, see Appendix B, "Support for Rate Tiers and Effectivity".

For more information about synchronizing billing products and billing discount from OPH to BRM, see the Synchronization of Items and BOMs section in Chapter 2, "Oracle Product Master Data Management Integration Base Pack".

For more information on modeling the billing products with examples in OPH, refer to the whitepaper "Guidelines and Methodology to define and manage entities in Oracle Product Hub for Oracle Product MDM Integration" in article ID 1086492.1 on My Oracle Support.

For more information about Telco seeded Library attributes and their corresponding valuesets, see Appendix F: Seeded Item Metadata Libraries, Oracle Product Hub Implementation Guide.

Time-Zone-Dependent and Time-Zone-Independent Fields

Time-zone-dependent fields identify the absolute time when an event takes place or will take place. Such fields need to be translated to the time zone of the system or the user to identify that specific time, for example, order submission, start date, and end date for a product or other entity, time of failure, and so on.

The time-zone-dependent fields are translated to UTC time zone by OPH requestor. If OPH has captured the time as 10:00 AM PST, this is translated to 18:00 UTC. As all the time values are coming in UTC format, the Oracle BRM provider does not need to do further translation.

Note:

In the Oracle Product Hub integration, most date and time fields published by OPH are translated by the OPH requestor in UTC format; implying that they are time-zone-dependent.

Time-zone-independent fields are used to identify a time that should be used irrespective of the time zone in which the user or system is. Typically, the fields that identify ranges fall in this category. For example, if a time range of 7 P.M. through 7 A.M. is set as evening, the time specified in this range should not be translated across systems that are in a different time zone because evening would always remain 7 P.M. through 7 A.M irrespective of the time-zone differences.

The time-zone-independent fields are used as is by the OPH requestor. If OPH has captured time as 10:00 AM PST, this is translated to 10:00 UTC (without adjusting the hour difference). The Oracle BRM provider identifies these as time-zone-independent values and does not translate these to UTC time zone. Instead, such values are converted to other data types (strings or numbers) by the Oracle BRM provider as requested by the Oracle BRM services.

Billing systems depend on these time-zone-independent ranges to apply special discounts, premium rates, or promotions in certain hours of the day, certain days of the week, or certain days of the month.

The time-zone-independent date and time fields are in these attribute groups:

  • Day Time Range

  • Days of the Week Range

5.1.2 Synchronization of Discounts and Discount Models from Oracle Product Hub to Siebel CRM and Oracle BRM

This synchronization allows a centralized definition of common discount features in OPH so that discount entities are consistently defined across Siebel CRM and Oracle BRM. It allows modeling of discount models in OPH to allow generalization and reuse of features used by multiple discounts and mapping to discount model entities in Oracle BRM.

Discount models are used in BRM to increase reusability, improve performances in calculating discounts, and facilitate maintenance of discounts. Discount models capture information such as the type and value of the discount that is applied.

Figure 5-2 is a conceptual simplification of the Oracle BRM model, which describes a discount and discount model entity and the way they are associated with each other.

Figure 5-2 Conceptual model for discount entities

Conceptual model for discount entities

The billing-discount event map is a conceptual entity that associates the discount with its discount model in the context of a billing event to which the discount is applied. OPH uses a simplified model and only two entities are captured: discounts and discount models.

Discounts and discount models are represented as items in OPH. The attribute entity type in the item entity is set to discount or discount model respectively. The billing-discount event map entity is modeled as a multi-row attribute UDA within the discount entity in OPH.

Table 5-3 shows the seeded attribute groups that are used to model billing discount in OPH:

Table 5-3 Seeded attributes



Library

Attribute Group

Communications Services Billing Library - Vertical

Billing Discount Attributes

Billing Discount Event Map


For more information on the library and the attribute groups, see the Oracle Product Hub Implementation Guide.

Each row of the multi-row UDAs captures this information:

  • Event - The same discount may apply to multiple billable events. A single discount can have multiple events (purchase and cycle). Each event can have separate models, which identify the percentage or absolute discount for that event.

  • SnowBall - A flag that indicates whether the discount/event combination is a snowball discount. A snowball discount allows distribution of group discounts to group members.

  • StopDiscounting - This is an enumerator defining run-time behavior regarding when to stop giving the discount if the discount is inactive or canceled. Seeded values are:

    • Never

    • When Canceled

    • When Inactive

    • When Inactive or Canceled

  • Discount Structure Type - This is an enumerator identifying the type of discount model associated with the product. Possible values are:

    • Discount model - Only one discount model can be associated with the event.

    • Discount model selector - More than one discount model can be selected from a selector.

  • Discount Model Name - The name of the discount model or model selector associated with the discount for the specific event. The possible values are those returned by querying of the name of the items with the entity type as discount model.

  • Oracle BRM does not provide a separate API/Service for the creation and update of discount models. Instead, it uses an implicit creation or update of discount models within the API/service provided for discounts. When the Oracle BRM service for discount is invoked, the service looks at the discount model name; if it does not exist, it creates.

  • Only the discount model name is captured in OPH, which has minimal impact on the participating applications from the integration perspective.

    Note:

    The discount model name is a free text field that needs to be entered manually in OPH. Currently, no cross-validation is implemented by OPH between this field and the name of the discount-model entity.

    The name for the discount model should be descriptive because the product administrator in OPH can rely only on the name to assign the discount model to a discount. In OPH, the description field in the item can also be used to add additional information for the discount model; however, this information is limited to OPH and is not visible to the BRM administrator because no description field exists for the discount model in the BRM services.

    Two alternative approaches are supported:

    1. You can define a discount model in BRM and then create in OPH the corresponding item with the discount model as the value for entity type, making sure that the names match.

    2. You can first create the discount model in OPH and then enrich in BRM through the synchronize discount flow. Discount models are manually configured in OPH and are not explicitly synchronized to BRM.

When you define the model first in BRM, the benefit is that a discount model is used only after it has been fully defined in BRM and thus no risk is involved in releasing a discount with a shell discount model.

For more information on modeling Billing discounts and for examples in Oracle Product Hub, refer to the whitepaper "Guidelines and Methodology to define and manage entities in Oracle Product Hub for Oracle Product MDM Integration 2.5" Note ID - 1086492.1 on My Oracle Support.

5.1.3 Viewing Publishing Status of Items

For more information about how to view publishing status of items, see chapter "Viewing the Publishing History" in the Oracle® Product Information ManagementUser's Guide.

5.2 Oracle BRM Interfaces

The Oracle BRM integration for Oracle Product Hub uses this service: PCM_OP_PRICE_SET_PRICE_LIST.xsd

For more information about Oracle BRM services, see Oracle Communications Billing and Revenue Management (BRM) Documentation, BRM Documentation, Reference, API reference.

5.3 Oracle BRM Integration Services

These are the integration services required for Oracle BRM to integrate with Oracle Product Hub.

5.3.1 SyncItemListBRMProvABCSImpl

This single operation service receives SyncItemListEBM as a request from ItemEBS. This input is transformed to BRM Product ABM to invoke BRM PCM_OP_PRICE_SET_PRICE_LIST web service. When the web service returns back to the BPEL with BRM IDs, cross-reference values are updated with the BRM identifiers.

5.3.2 SyncPriceListListBRMProvABCSImpl

This single operation service receives SyncPriceListListEBM as input from PriceListEBS. This input is transformed to BRM Product ABM and BRM adapter is invoked to update the price information for the products. When the web service returns back to the BPEL with success notification, cross-reference values are updated with the BRM identifiers. A response EBM is constructed, which is used to invoke the PriceListResponseEBS.

5.4 Assumptions and Constraints for the Oracle Communications BRM Option

The assumptions and constraints for the Oracle BRM option are:

  1. No explicit synchronization flow exists for discount models from OPH to Oracle BRM.

  2. Multiple rate plans using rate plan selectors are not supported for item definition in OPH. This implies that for real-time rating either a single rate plan or multiple single rate plans must be associated with one-time, recurring, and usage charges in OPH and the rate plans for the rate plan selectors must be enriched in Oracle BRM.

  3. The usage-based products are defined in OPH as separate products and are not defined as a part of the multi-event product. The pipeline rating for usage products is defined and associated in Oracle BRM.

  4. The usage-based rating using pipeline rate plans cannot be defined in OPH and hence they are not supported by the integration. They must be defined in Oracle BRM.

  5. The enrichment for one-time and cycle charges must not change the rate plan names in Oracle BRM.

  6. The discount models are associated with the items that represent the discounts in OPH. The complete definition of the discount model is done in Oracle BRM. The discount model name must not be updated in BRM because the subsequent updates override the value.