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)

Overview of Revenue Management Configurations in Oracle Fusion Applications

This article shows an overview of Revenue Management Configurations in Oracle Fusion Applications. This article shares some components from another article: Configuring Revenue for Receivables in Oracle Fusion Applications, as that article configures the Revenue Management application to be used by Receivables.

Revenue Management Setups Mapped to the Five Steps to Revenue Recognition

Below are some of the common Revenue Management Configurations shared among other modules:

1. System Options
2. Source Document Type
3. Performance Satisfaction Plans

Below are some the configurations for Revenue Contract with Customers:

1. Contract Identification Rules
2. Performance Obligation Identification Rules
3. Performance Obligation and Implied Performance Obligation Templates (optional)

The Diagram below shows the different Configurations for Revenue Management:

Performance Satisfaction Plan Types. Performance Satisfaction Plan Types (also called Revenue Scheduling Type) indicate how the Revenue will be split. It can be a fixed or variable schedule, or depending on the periods. Performance Satisfaction Plan Types are attached to Performance Satisfaction Plans.

Performance Satisfaction Plans. (also called Revenue Scheduling Rules) dictate if we're going to recognize the revenue at a point in time at once, one period, or over time, multiple periods, etc. We'll be thinking about quantities, percentages, or maybe we'll be thinking in terms of an accounting period on how to recognize the revenue. For more information on Revenue Scheduling Rules and Scheduling Types, check out a separate article: Manage Revenue Scheduling Rules in Oracle Fusion Applications. Performance Satisfaction Plans are attached to a Source Document Type.

Source Document Types. Source Document Type are needed for integrations. Source Document Types are already predefined for integrations with Oracle E-Business Suite and for Oracle Cloud applications. If you are bringing data or integrating to third party applications, you're going to have to define those. Examples of Source Documents are Sales orders, Service contract, Warranty contract, etc. For more information on Source Document Types and Type Codes, check out a separate detailed article about it: Source Document Types and Type Codes in Revenue Management Cloud

System Options. Revenue Management System Options is where you'll be attaching a Source Document Type. You would need to specify revenue clearing account for each Source Document Type to identify the default accounting combination.

This setup can be found in the "Manage System Options for Revenue Management" task.

Aside from Source Document Types, there are different sections in System Options because these are settings for the whole Revenue Management as a product module. Each section is highlighted in detail below:

1. Currency Conversion Section - Here you can specify a Conversion Rate Type for Multicurrency Processing.
2. Integration - here is where we populate Source Document Types and the default Revenue Clearing Account. We also specify the Extraction Start Date. That's when the first extraction is going to take place and going forward, you're going to continue to extract data from that specific source. The data will be extracted from the applications and into the interface tables to creating customer contracts.
3. Oracle Fusion Receivables Transaction Sources - This is a section exclusively for Fusion Receivables. Here, you would have to populate Receivable Transaction Sources. Receivable Transaction Sources pertain to Invoices, credit memos, debit memo that's created in the Cloud Receivables module. When you populate the relevant transaction sources from Cloud Receivables, that indicates that we want to transfer data associated with these transactions to Revenue Management so that we can comply with the Revenue standard. Similar to the Integration section, it also has the  Extraction Start Date field.
4. Revenue Accounting and Thresholds - Here, we can specify the GL accounts for contract liability, contract asset, etc. All the way to the right, we can specify Thresholds Amounts. Thresholds for Transaction Price Exemptions, Discount Exemptions, and then Transaction Price Review. If you populate a threshold amount, what that means is if the customer contract exceeds that amount, then you're going to subject that customer contract to manual review. A human being is going to review the contract and validate it and make sure everything is correct.

To Identify contracts with customers, you need to setup the following (click on each link for a detailed article):

1. Contract Identification Rules
2. Performance Obligation Identification Rules
3. Performance Obligation and Implied Performance Obligation Templates (optional)

The summary of each setup is provided below:

1. Contract Identification Rules. Contract identification Rules will to determine which transaction lines are included in a contract. The idea here is to use Source Document Type Codes (DFFs) to match lines so that you can group them into a contract. Examples of those can be quote numbers, purchase order numbers, etc. 

2. Performance Obligation Identification Rules. Performance Obligation Identification Rule are rules used to group source document lines into performance obligations. The idea here is to look for the common link between source document lines and identify what are the performance obligations of the contract.

A key concept for Contract Identification Rules is the Creation of Contracts while the concept for Performance Obligation Identification Rules is Identify the contract's obligation.

3. Performance Obligation and Implied Performance Obligation Templates. Performance obligation templates are used to define bundles that are routinely sold to customers. An example of this would be where a customer is purchasing a phone. With that phone, they're getting a free car charger. Both the phone and the car charger is a performance obligation and are commonly sold together. The difference between Implied and Non-Implied is with the Implied Performance Obligation, the bundled item isn't from the Source System. Unlike in the Implied Performance Obligation, it comes from the source system.

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)