4 Product Master Data Management Integration Option for BRM

Multi-Event Product Synchronization from Oracle Product Hub to Siebel CRM

The products that have multiple charges and events are created as customizable products in Siebel CRM. 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 CRM. The item synchronization process from horizontal implementation supports both create and update of products in Siebel CRM.

To support create and update of pricelist, the process integration to Siebel CRM reuses the communications pricelist Siebel CRM-provider-connector services. The Oracle Product Hub requester 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 Oracle Product Hub using the seeded attribute framework. The process integration synchronizes the multi-tier rating from Oracle Product Hub to BRM. The Siebel CRM 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 Oracle Product Hub 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.

  • In case of Multiple Rate Plans, associate each rate plan to a pricelist.

  • In case of multi-currency, create separate rate plans and associate it with different pricelists. Each pricelist represents prices of products in a single currency.

• 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 Oracle Product Hub. 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.

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 Oracle Product Hub, only the name of the usage rate plan is defined and published to the target applications. BRM uses pipeline-based rating for usage charges. The usage-based rating is enriched in 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.

Table 4-2 summarizes the support offered for pricing in Oracle Product Hub.

Pricing Hierarchy of BRM

Figure 4-1 depicts the real-time rating in BRM.

Figure 4-1 Pricing Hierarchy

Description of ''Figure 4-1 Pricing Hierarchy''

The pricing hierarchy can be modeled in Oracle Product Hub 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 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 Oracle Product Hub. 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 CRM, 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 Oracle Product Hub. These are synchronized to BRM and Siebel CRM. The multiple-rate tiers manifest as multiple pricelist lines on a product in Siebel CRM.

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 CRM supports only absolute effectivity.

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

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

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

For more information about Telco seeded Library attributes and their corresponding valuesets, see the discussion of seeded item metadata libraries in 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 you 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 Oracle Product Hub requester. If Oracle Product Hub 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 BRM provider does not need to do further translation.

Time-zone-independent fields are used to identify a time that should be used irrespective of the time zone in which you 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 Oracle Product Hub requester. If Oracle Product Hub has captured time as 10:00 AM PST, this is translated to 10:00 UTC (without adjusting the hour difference). The 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 BRM provider as requested by the 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

Synchronizing Discounts and Discount Models to Siebel CRM and BRM

This synchronization allows a centralized definition of common discount features in Oracle Product Hub so that discount entities are consistently defined across Siebel CRM and BRM. It allows modeling of discount models in Oracle Product Hub to allow generalization and reuse of features used by multiple discounts and mapping to discount model entities in 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.

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. Oracle Product Hub uses a simplified model and only two entities are captured: discounts and discount models.

Discounts and discount models are represented as items in Oracle Product Hub. 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 Oracle Product Hub.

Table 4-3 shows the seeded attribute groups that are used to model billing discount in Oracle Product Hub.

For more information on the library and the attribute groups, see 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.

• 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 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 Oracle Product Hub, 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 Oracle Product Hub. Currently, no cross-validation is implemented by Oracle Product Hub 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 Oracle Product Hub can rely only on the name to assign the discount model to a discount. In Oracle Product Hub, the description field in the item can also be used to add additional information for the discount model; however, this information is limited to Oracle Product Hub 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 Oracle Product Hub 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 Oracle Product Hub and then enrich in BRM through the synchronize discount flow. Discount models are manually configured in Oracle Product Hub 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 Master Data Management Integration 2.5" Note ID - 1086492.1 on My Oracle Support.

Viewing Publishing Status of Items

For more information about how to view publishing status of items, see the discussion of viewing the publishing history in the Oracle Product Information Management User's Guide.

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.

SyncPriceListListBRMProvABCSImpl

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 web service returns back to the BPEL with success notification, cross-reference values are updated with BRM identifiers. A response EBM is constructed and used to invoke PriceListResponseEBS.