Performance Obligation Templates in Revenue Management Cloud

A Performance Obligation is a promise to deliver goods and services to a Customer. An example of a Performance Obligation in a contract is providing for a telecommunications company is to Voice and Data Plan to a Customer, including a mobile phone.

A Performance Obligation template is used to define bundles that are routinely sold to customers. 

A similar example of a bundle would be a Voice, Data and Phone Plan. These are usually sold to customers together, and thus, can be included in one template. 

Another similar setup is the Implied Performance Obligation template. The keyword here is "implied." This means is that there might be performance obligations in a customer contract that are implied, but they're not captured anywhere in the source system.

In our Telecommunications contract, an example of this would be, a customer will get a free car charger included in his or her Voice, Data and Phone Plan. That free car chargers is not registered anywhere from the source system. So to be able to account revenue for the car charger, then you would need to define an implied performance obligation template like this one.

These performance obligations templates are business-specific. Therefore, oracle doesn't predefined any of them. You would have to create them according to the needs of your business or industry.

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)

Reference Information for Contracts and Performance Obligations Identification Rules

What is Reference Information?

Reference Information for Contracts and Performance Obligations can be used to populate important information from other systems (such as EBS, non-Oracle systems or other Fusion Cloud applications), into an extensible attribute. It can be the quote number, a Purchase Order number or any other information that may help end-users search for contracts.

Both Contract Identification Rules and Performance Obligation Identification Rules can use Reference information as shown below:

This is Reference information can then be used as a search criteria from the Revenue Management work area. Click on the Tasks icon, and from there, you go to "Manage Customer Contracts". There is a field named "Reference" where you can use to search for the said contract. If you copied that particular data point as a reference, then your users can use that to find specific contracts.

Note that the field might be hidden from the Basic View. Follow the steps below to display the field.

1. Click on the Advanced Button:

2. Click on the Add Fields Button:

3. Click on the "Reference" selection to display the field

4. The field "Reference" can then be used to search for transactions

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)

Managing Performance Obligation Identification Rules in Oracle Revenue Management Cloud

What is a Performance Obligation Identification Rule? 

Once we know what the contract is and it has been created, and we have to identify what are the obligations in the contract? What are the promises we have made to the customer? Performance Obligation Identification Rule are rules used to group source document lines into performance obligations. The idea here, is to look for a common link between source document lines. What is that common link that is going to be used for grouping purposes? These can be things like a product or service descriptions. That's a good way of identifying these promises that we have made to the customer, which are synonymous with these performance obligations.

Oracle pre-defines three Performance Obligation rules, and you can define your own. You can use up to 90 extensible attributes, called Source Document Types Codes. Note that these three predefined rules are not updateable.

For performance obligation identification rules, you are more than likely to use Line Attributes instead of Header Attributes. When you're bringing that data over to Revenue Management, some of it is going to be associated with the header of a document, like a sales order or a contract, and some of the data is going to be related to the lines of that document. So for the performance obligation identification rules, It's probably going to be associated with lines, because the Lines will identify the promises that needs to be fulfilled.

Similar to Contract Identification Rules, Performance Obligation Identification Rules uses prioritization as well. You specify a priority in terms of a Number and Revenue Management is going to execute these rules based on the order of the priority.

Below is a quick demonstration of creating Performance Obligation Identification Rules in Oracle Fusion applications:

You can also add Reference Information for Contracts and Performance Obligations Identification Rules. Reference Information for Contracts and Performance Obligations can be used to populate important information from other systems (such as EBS, non-Oracle systems or other Fusion Cloud applications), into an extensible attribute. It can be the quote number, a Purchase Order number or any other information that may help end-users search for contracts.

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)