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)