Overview of Pricing Dimension Structure in Revenue Management Cloud

This article gives an overview about Pricing Dimension Structure in Revenue Management Cloud, including its components and importance. The diagram below shows the components of a Pricing Dimension Structure:

Pricing Dimension Structure Instance is the management structure of Pricing Dimensions. It provides additional settings here at the instance level of the Pricing Dimensions, such as enabling of the Creation of Dynamic Combinations. The relationship between the Pricing Dimension Structure and the instance is 1 to 1.

When the Creation of Dynamic Combinations is enabled, this means that combinations can be added dynamically, You don't have to pre-define the combinations because we are saying that they can be dynamically added when you are defining the Standalone Selling Price.

Pricing Dimension Structure acts like a Key Flexfield (KFF) and will allow your organization to depict its current pricing policies. Each structure is composed of segments, and a structure can have up to 30 segments. Each of these segments need a value set for each segment in your structure.  

Value Sets

A value set determines the data type that will be used by the segment and will validates and control the values and that are acceptable for that segment. Also, a Value Set dictates the Size and Numerical Precision of a Segment.

Each Value Set can have different types of validation such as Independent, Format Only, Table, Dependent, etc. It is the best practice to always use independent. More information can be found from the Oracle Official Documentation. 

In the example above, the Pricing Dimension "Hardware Products Discount Policy" is composed of three Pricing Dimension Segments (Geographical Region, Deal Size, Customer Type). 

The Segment "Customer Type" has the data type "Character" and the acceptable values are only "Government" and "Commercial". As for the segment "Deal Size", you can define the ranges of amounts that will be acceptable. 

Below is a quick video demonstration on how to create Pricing Dimension Instances, Structures and Value Sets in Revenue Management Cloud:

Pricing Bands

Price Bands are optional pricing configurations. Each segment in Pricing Dimension Structure can have a label. Price Bands Type can be Set, Quantity or Amount:

In the Example below, Quantity Band defines the price if the customer is purchasing between a certain number of units.  

We are looking at volume of the units purchased. The more units we sell, the lower the price is going to be for the customer. You want to give them a favorable price.

As for the Amount band, it is saying if the deal size is between a certain amount, it will correspond to a certain unit price. 

So you have the values high, medium, and low. And then these are the dollar ranges there. This means the more the customer buys, the lower the price will be.

The Set Band, on the other hand, uses criteria other than volume and deal size. This means that you can drive your pricing without looking at the size or volume of the deal. If you look at this example below, it uses the geographical information. 

We see here North America. And then we see here the countries within North America, the United States. Countries that belong to the European Union. And that might be a criteria that you want to use in your Pricing Dimension Structure.

The implementation task of creating Price Bands is "Manage Pricing Dimension Bands for Revenue Management".

Deploying the Pricing Dimension Structure

Once the structure has been finalized, you need to run a Deployment process for your structure to validate the structure and make it available to be used.

Below is a quick video demonstration on how to create Pricing Dimension Assignments in Revenue Management Cloud:

For more full-detailed Tutorials and Tips, check out #TheOracleProdigy at https://lifeofanoracleprodigy.blogspot.com/
Follow The Oracle Prodigy on Facebook (https://www.facebook.com/theOracleProdigy/) and Twitter (https://twitter.com/D_OracleProdigy)

Revenue Management Cloud Implementation Considerations

Below are some questions that you may have to answer before implementing Revenue Management Cloud for your organization:

1. Contract Identification Rules. What are the common links or attributes across all contract lines?

The keyword here is "common link". What is the attribute that is going to allow your organization to take transactional lines and group them into a customer contract? Is that a sales order number? Is that a purchase order number? These will allow you to define these rules and allow your organization to meet that first step of the new revenue recognition standard: Identify contracts with customers. Check out a separate article for more information on Contract Identification Rules.

2. Performance Obligation identification rules. Once you've identified the customer contract, then you need to identify performance obligation. Performance Obligations are the promises that you have made to the customer. Similar to Contract identification Rules, think about the common elements of the obligation. What are those attributes that I can use to identify the promises that I have made to the customer? It can be some inventory ID, or a product description, or things of that nature. That will clearly identify what is the promise that has been made to the customer. Check out a separate article for more information on Performance Obligation Identification Rules.

For Items 1 and 2, The goal is to have minimal manual intervention in the creation of these contracts. Oracle has predefined three Performance obligation identification rules and contract identification rules but you can define your own. You would need to understand your transactional data, your revenue data, so that you can then define these rules in a way that you will get to that minimum manual intervention that we are looking for.

3. Revenue Price effective periods or Standalone Selling Price (SSP) effective periods. The term "revenue prices" has been outdated and the latest and most updated terminology we use is "standalone selling price".

One of the five steps to revenue recognition involves allocating transaction price, with standalone selling price as a basis. So the question here is, how often are your pricing policies being updated? You would need to observer how frequently you need to update your pricing. Depending on how you answer that question, you're going to appropriately define those effective periods. Is it monthly? Is it quarterly?

4. Threshold Amounts. Another question would be, do you want to subject price changes to manual review? There's some threshold attributes there, and one of those has to do with manual review. Subject is customer contracts based on their amounts to manual review. That can be set in system options. What is the proper amount? Are contracts over $5,000 be subjected to manual review? It all depends on your organization or industry. You're going to come up with a threshold amount, and then any contracts exceeding that threshold amount are going to be reviewed by a human being.

5. Integrations. With regards to Integration with third-Party Applications (EBS and Non-Oracle Systems), below are some additional key implementation decisions:

1. Evaluate if you will continue using EBS or any other ERP versus implementing Financials Cloud. Although we allow that integration with E-Business Suite and other third-party non-Oracle systems, but this is something you might want to think about in terms of maintenance and complexity of the integrations.
2. If you continue to use EBS, you want to make sure you determine which document sources and receivables transactions need to integrate with Revenue Management. 
3. Determine the method that you will use to bring over customers and items to Revenue Management.

For more full-detailed Tutorials and Tips, check out #TheOracleProdigy at https://lifeofanoracleprodigy.blogspot.com/
Follow The Oracle Prodigy on Facebook (https://www.facebook.com/theOracleProdigy/) and Twitter (https://twitter.com/D_OracleProdigy)