The Oracle Prodigy: May 2019

Managing Contract Identification Rules in Oracle Revenue Management Cloud

What is a Contract identification Rule?

Contract identification Rules is going to determine which transaction lines are included in a contract. The idea here is to use source document attributes to match the lines so that you can group them into a contract. Examples of those can be quote numbers, purchase order numbers, etc. If you have multiple transactional lines with the same quote number, then that can mean that these lines can be grouped into a customer contract. These rules are executed on a priority.

How do we create a Contract identification Rule?

To create a contract identification rule, navigate to the Functional Setup Manager, select the Financials offering and choose the Revenue Management functional area. And then the right, select All Tasks and navigate down to "Manage Contract Identification Rules".

Below is a quick video tutorial on creating Contract Identification Rules in Oracle Fusion applications:

A contract can include multiple source document types, so the relationship between a customer contract and a source document type does not have to be one-to-one.

Think about long and hard about defining Grouping Attributes. Grouping Attributes defines the attributes that you want the system to use for automatic customer contracts identification.

For example, we are saying that we're going to look at the customer name, the purchase order number and the quote number. If the system detects you have multiple transaction lines with the same customer, purchase order number and the quote number, it will group those together to form a customer contract.

Usually, Contract Identification Rules use Extensible Header attributes, while Performance Obligation Identification Rules use Extensible Line attributes. Extensible attributes can use up to 90 attributes each for header data and lines data.

There is an available FBDI template to upload Contract Identification Rules in bulk.

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:

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.
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.
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:

System Options
Source Document Type
Performance Satisfaction Plans

Below are some the configurations for Revenue Contract with Customers:

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:

Currency Conversion Section - Here you can specify a Conversion Rate Type for Multicurrency Processing.
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.
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.
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):

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.

Source Document Types and Type Codes in Revenue Management Cloud

What is a Source Document Type?

Source Document Types are used for integrating third-party applications and Revenue Management Cloud. Examples of Source Documents are Sales orders, Service contract, Warranty contract, etc. Source Document Types are attached to System Options and is a required and integral setup in Revenue Management

There are Source Document Types 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 create custom ones. If you are interested to know which of these Source Document Types were predefined or seeded, notice the "Created By" column. If see the value "Oracle" then that means that's something that was predefined.

Source Document Types brings together the Revenue Scheduling Rules (also known as Performance Satisfaction Plan), the Satisfaction Measurement Model (SMM) and the Document Type Code.

What is a Satisfaction Measurement Model?

A Satisfaction Measurement Model answers how you measure satisfaction such as Quantity, Period or Percentage, depending on how your organization measures satisfaction. For example, if it's a service that you provide over time, the SMM would probably be based on the accounting period.

What is a Source Document Type Code?

Source Document Type Codes are used to define the attributes that can be used in a number of setups in Revenue Management such as Contract Identification Rules, Performance Obligation Rules, Pricing Dimension Assignments and also for defining subledger accounting rules.

Document Type Codes are synonymous to Descriptive Flexfields (DFFs). DFFs are fields that allow you to track and capture data points that may be specific to your organization or industry. To define new Document Type Codes, The name of the implementation task is "Manage Revenue Management Descriptive Flexfields".

Source Document Type Codes are important aspects in identifying contracts with the customer (Contract Identification Rules), and also to identify performance obligations (Performance Obligation Identification Rules). Source Document Type Codes can contain two types of Data:

Source Document Header data - These are usually header-level data such as sales order number, a contract number, contract date or Customer information
Source Document Lines data - These are usually line-level data such as inventory item, numbers or IDs, product descriptions, line amounts, etc.

Both Header and Line data can contain up to 90 extensible attributes that you can populate.

Manage Revenue Scheduling Rules in Oracle Fusion Applications

What is a Revenue scheduling rule?

A Revenue scheduling rule (also known as "Performance Satisfaction Plan") is a rule that tells receivables how to allocate our revenue into the future. It can be that a revenue scheduling rule that tells receivables not to recognize revenue now, we are going to recognize the revenue manually in the future by processing a revenue adjustment.

To view or create a Revenue Scheduling Rule, Navigate to Functional Setup Manager, Pick on the “Financials” offering, search for the Task “Manage Revenue Scheduling Rule” or "Manage Performance Satisfaction Plans":

Provide a name of the rule, and a Revenue Scheduling Type. There is a checkbox to indicate if the Revenue Scheduling Rule will be Deferred or Non-Deferred. You would need to associate, the Scheduling Rule with a Reference Data Set. Reference Data Sets allow you to share configurations across multiple business units or keep them specific.

What is a Revenue Scheduling Type?

Revenue Scheduling Type (also called Performance Satisfaction Plan Types) indicate how the Revenue will be split. You can use four different performance Satisfaction Plan Types on Revenue Scheduling Rules:

Daily revenue rate, all periods - This means you are recognizing revenue on a daily basis. Use this type of Performance Satisfaction Plan if your organization has accounting rules with very strict revenue recognition requirements. This rule requires a start date and an end date.
Daily revenue rate, partial periods. Used if there's a revenue that needs to be recognized partially for a period, then you have to prorate. This type of rule also needs start date and end date.
Fixed schedule. This does not use days, instead it uses accounting periods. Now that accounting period can be a week, can be similar to a month, can be a quarter, depending on the Accounting calendar your organization uses. If you go with a fixed schedule, you would have to then provide percentages. For example if the period will be over three months, then you have to come in and specify how the revenue will be split, such as 30/30/40 or it can be 20/50/30. That's a mandatory attribute to populate how that revenue is going to be distributed across those periods, whatever the number of periods there are.
Variable schedule. The revenue is going to be prorated over a number of periods, but those periods are not going to be fixed. So these will also require a start date.

What is the difference between Deferred and Non-Deferred?

Deferred means that you will have to recognize the revenue manually through adjustments and Non-deferred means that the revenue recognition schedule will be created for the invoice. Note that for Non-deferred, you would have to run the Recognize Revenue Program to be automatically generated a revenue schedule for invoices.

Check out the video below for a step-by-step demonstration on Creating Revenue Scheduling Rules in Oracle Fusion Applications:

Creating Items and Their Spoke System Relationship in Oracle Fusion Applications

This practice will show how to create three inventory items that will be used in Revenue Management, a phone model, an unlimited talk and text plan and a data plan. We also have to associate these to a spoke system, a source system where these items reside. Note that the user you are going to sign in with should be provisioned with the "Data Steward" role.

Below is a quick video demonstrating how to assign the "Data Steward" role:

From the Welcome Springboard, Navigate to Product Information Management. Product Management in the Oracle Cloud is synonymous to Inventory.

Go to the Tasks icon. And what we want to see here is the option to create. If you don't see the option to create an item, then you don't have the necessary roles assigned to create an Item. Check your assigned Roles before proceeding. Once assigned, Click on Create Item.

Create inventory items by copying them from an existing items. Select the existing item and go to the Relationships tab. Move the item "Organizations",from the Available to the Selected list and click OK.

You will be redirected to the Create Item page, update the description to make it easier to find the item later on. Once done, Click on Save and Close. The Item ID is going to be automatically sequenced.

You will be shown a Summary of important information and proceed to Apply to confirm.

Click on the Task Panel and go to Manage Items. Search for the item you created based on the description to get the Item ID that was automatically numbered.

Take note of the Item ID (AS16907). Notice here the sequence. It has a prefix and then five digits, 16907. We will associate this item to a source system, called a "Spoke System". Click on the link, go to Relationships Tab and then Spoke System.

Click on "Create" and in the source system field, input where the item originally exists. In this example, is this "Legacy System 1". Input the Item ID (AS16907) that you took note of and we're going to put in a description. Go ahead and click OK, and Save and Close, and then I'm going to click on Done.

Confirm the Item was created by searching either using the Item ID or the Description

Repeat the steps to create two more items RM20002 or RM20003:

Repeat the steps to create a copy two more items RM20002 (unlimited talk and text) and RM20003 (Data Plan). Note that for the second item, You will have the ability to assign a sequence to it.

Below is a quick video demonstration of Creating Items and Their Spoke System Relationships in Oracle Fusion Applications:

Integrating E-Business Suite with Oracle Revenue Management Cloud

In this Article, you will gain an understanding of how Oracle E-Business Suite integrates with Revenue Management.

Before you can perform more work on these integrations, You need to have reference data in place such as enterprise structures, legal entities, ledgers, business units, Parties, Customers, customer accounts, customer account sites and inventory items in the Oracle Cloud. And you would need to read about Integrating with Revenue Management in Oracle Fusion Applications.

There are predefined programs in E-Business Suite called that extract data from EBS and bring it over to the Cloud. Below programs are run sequentially:

Extract Revenue Basis Data program
Create Billing Data program
Create Revenue Management Data export file

The file created by the "Create Revenue Management Data export" program gets into the Cloud via the Universal Content Manager, and from there data gets pushed into the Revenue Management interface tables. Data will be validated and create customer contracts in the Revenue Management base tables by running a process called "Identify Customer Contracts".

Identify Customer Contracts will create contracts based on rules. These rules can be predefined or defined by your organization. Once that has been completed, Revenue Management can now perform the five steps to revenue recognition.

There is out-of-the-box integration with the below E-Business Suite modules

Order Management
Service Contracts
Receivables

These E-Business Suite modules have pre-built integration because they contain information relevant to Revenue Management Cloud. Service Contracts would contain contract information, Sales orders in Order Management, and invoices and credit memos information in Receivables.

Required steps to configure E-Business Suite integration with Revenue Management:

Apply patches provided by Oracle (25505159 and
Configure system options in EBS Receivables to add a new tab.
Profile Option "AR: Source System Value for Revenue Management"
Configure business events using Fusion Web Services
Set up EBS Secure Socket Layer (SSL) for consuming Fusion services

For steps 1, 4 and 5, go to Oracle Metalink Support and download the appropriate patches and notes on how to implement these steps. The patches are applicable for releases 12.1.3 and 12.2.x.

After that patch is applied, as we can see here, you're going to see a new tab shown below:

In Setting the profile option, the name of the profile option is "AR: Source System Value for Revenue Management" and the value that you want to set the option is "EBIZ". This is a mandatory setting in order to extract revenue basis data from EBS and bring that over to Oracle Revenue Management Cloud.

Once everything has been configured and set, you may proceed to extract revenue data by running a process in EBS called Extract Revenue Basis Data. Extract Revenue Basis Data is a request set that will run three sub-processes that does the following:

Extract Revenue data
Extract Billing data.
Create a data export file that will be sent to the Universal Content Manager

After you have run an import process to transfer files into the UCM, the next process that needs to take place is Load Interface File for Import. This process transfers setup or transaction data files from a user-specified location to the interface tables. The interface tables we are discussing here are the Revenue Management interface tables.

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)

Integration with Revenue Management in Oracle Fusion Applications

This article discusses the Inbound Revenue data Integration with Revenue Management in Oracle Fusion Applications. Below are the Objectives of this Article:

Understanding inbound integration options with Revenue Management
Understanding how Oracle E-Business Suite integrates with Revenue Management
Understanding how third party applications integrate with Revenue Management
Understanding Outbound integrations with Revenue Management

Before you can perform more work on these integrations, You need to have reference data in place such as enterprise structures, legal entities, ledgers, business units, Parties, Customers, customer accounts, customer account sites and inventory items in the Oracle Cloud. Also, you would need to create a source system and item relationship called Spoke System Relationship.

Defining a Source System

This is part of the prerequisites for integration. Go to the task "Manage trading community source system" and click on "Create" and click on the option "Enable for Items" and also "Enable for Trading Community Members" because we're going to be loading inventory item information as well as customer information into the cloud.

Defining a Spoke System Relationship

A spoke system relationship is a relationship between items and a source system. This is required when integrating with third-party applications. To define a spoke system relationship, you would need to first Define Master Data.

To find out more about Defining a Spoke System Relationship, check out a separate article on Creating Items and Their Spoke System Relationship in Oracle Fusion Applications.

Defining Master Data means that you need customer and inventory item data loaded into Oracle Fusion before you can do integrations. There are predefined templates to upload customer information and import or update inventory items. Once done, you would need to register the source of the integration, called a Source System.

Prior to Performing a third-party or spreadsheet integration, you must register the source system so that you can then bring data into the Oracle Cloud and over to the Revenue Management interface tables. The Steps to Registering a Source System are:

Create a source system within the Trading Community Model
Import a source system reference file from a Spreadsheet

Inbound Integration to Revenue Management Cloud

There are multiple ways to bring data into Oracle Revenue Management Cloud. As mentioned, it can be through an FBDI template, or the pre-defined integration with E-Business Suite, or a custom program. The entry point for all solutions would be the Universal Content Manager (UCM).

Integration with E-Business Suite

There is out-of-the-box integration with the below E-Business Suite modules

Order Management
Service Contracts
Receivables

These E-Business Suite modules have prebuilt integration because they contain information relevant to Revenue Management Cloud. Service Contracts would contain contract information, Sales orders in Order Management, and invoices and credit memos information in Receivables.

There is a predefined program in E-Business Suite that extract data from EBS and brings it over to the Cloud via the Universal Content Manager. In turn, the UCM will populate the interface table and will create contracts in Revenue Management Cloud based on rules. Note that there are required steps to configure E-Business Suite integration with Revenue Management.

For more detailed information on Integrating E-Business Suite with Oracle Revenue Management Cloud, check out a separate article: Integrating E-Business Suite with Oracle Revenue Management Cloud

Integration with other Oracle Fusion Cloud Modules

Oracle Revenue Management also tightly integrates with other Oracle Cloud applications such as Fusion Receivables, Cloud Project Financial Management Contracts since both of these applications contain data that's going to be relevant to the new revenue recognition standard.

For Cloud Receivables, source documents such as invoices, credit memos will be relevant to Revenue Management, while for Project Financial Management, it would be documents like contracts, warranties, etc.

There is a pre-defined process called the Extract Revenue Basis Data from Oracle Fusion Applications that will extract data from the other modules and populate the interface tables. After the interface tables have been populated, a process called "Identify Customer Contracts" needs to be run to validate that data and identify customer contracts, the same process used for E-Business Suite.

Setups for Revenue Management Integration with Oracle Cloud applications

There are some required configuration in the page "Manage System Options for Revenue Management". You would need to configure Source Document Types for both Receivables and Project Financial Management. Source documents are documents such as warranty contracts, specific types of invoices, or credit memos, etc.

You would need to specify revenue clearing account for each Source Document Type to identify the default accounting combination. Also, we see extraction start date. This indicates that starting on this date, the data will to be extracted from the Fusion applications and into the interface tables to creating customer contracts.

Additionally for AR, you need to configure Oracle Fusion Receivables Transaction Sources because every single invoice, credit memo, debit memo that you create in Receivables is associated with a transaction source.

Processing Historical Data

It will be important to load historical revenue and billing data for iterative modeling and comparative analysis. In the Manage System Options page, you will need to provide the start date for that particular integration to indicate how far you are going to integrate that source data for modeling.

The revenue standard was effective January 1, 2018, but you might make a decision to go back two years, or three years for modeling and comparative analysis. You can bring that data on or after January 1, 2014 from the E-Business Suite ERP or Financials Cloud ERP. You can not really bring that data over prior to this date.

Spreadsheet Integration using File-Based Data Import

Oracle Fusion has a number of templates that can be used to bring data over into Revenue Management from third-party applications with the use of File-Based Data Import (FBDI) templates. They allow you to bring revenue basis and billing data into the Cloud and over to the Revenue Management interface tables.

If you decide to go with the FBDI template, there are separate FBDI templates you need to use for revenue data (Revenue Basis Data Import) and billing data (Billing Data Import). The template will contain source header data from the source document, sales order, the warranty contract, and sublines that impact satisfaction information. You can download the FBDI template from Oracle Documentation: File-Based Data Import for Financials.

The Revenue Basis Data Import template will have three tabs, each one for different types of data:

Header Data (VRM_SOURCE_DOCUMENTS)
Line Data (VRM_SOURCE_DOC_LINES)
Satisfaction event information (VRM_SOURCE_DOC_SUB_LINES)

While the Billing Data Import only has one tab (VRM_BILLING_LINE_DETAILS).

You need to run an import process to get that CSV data file into the Cloud, called "File Import and Export". After the import process takes the data into the UCM server, run the process "Load Interface File for Import" to populates the Revenue Management interface tables.

This will trigger the process "Validate Customer Contract Source Data" that will validate the data in the inteface. Next, you would need to run "Identify Customer Contracts" to create customer contracts from the Revenue Management base tables.

Custom Program using a SOAP Web Service

If you decide to go with a custom program, you will need two APIs for this integration, the Revenue Basis Data Import API and the Billing Import API.

You will have to utilize the Web Service API to place a file in the UCM server. After the file is in the UCM server, you run the same process to load the interface tables ("Load Interface File for Import") and proceed to run another process to automate the five steps to revenue recognition ("Identify Customer Contracts").

Error Correction for Integrations

There is a spreadsheet template that Oracle provide that allows you to not only correct import errors but check for errors. This function is called "Correct Contract Document Errors in Spreadsheet" and is found by navigating to the Revenue Management work area.

Outbound Integration

With the use of the subledger accounting engine, we are going to generate journals in Revenue Management. Those journals will end up either in a target General Ledger. If your target General Ledger is Fusion GL, We're not going to do any outbound transactions because the journals are going to stay within the cloud.

However, if you are using EBS, what will happen here is that you will run Create Accounting as you normally would do. A data file will be created and sent over to the Universal Content Manager, then you then run a process to import those journal entries from the cloud and into E-Business Suite. This data is going to go to the GL interface tables in EBS. You can then run an import process that takes the data to the EBS GL production tables. It creates the journals. After you create the journals, then you can post those journals in EBS GL.

There are certain setups you have to do in the cloud to allow for this outbound integration with EBS. And so here you see the name of the task, Manage Subledger Application. Pick the desired application ("Revenue Management") and choose the application you'll transfer the Ledgers to. There is an option to transfer to EBS. You have to go with this option here to transfer ledgers externally to EBS.

Configuring Revenue for Receivables in Oracle Fusion Applications

What is Revenue Management?

Oracle Revenue Management complies with accounting standards that tell the organization to recognize the revenue later after the invoice has been sent. A sample of this would be a multi-period Mobile contract for Voice and Data Subscription, or Streaming Subscription, or a Software Support Contract.

The concept of Revenue Management is that your organization sells a service or product to your customer, but have not fully delivered that service, we cannot fully recognize the whole revenue for that invoice at once because we have to follow an accounting standard. What Revenue Management does is we prorate our revenue from the start and end of the contract. For Example, the contract was for a 12-month period, that's the bill will be pro-rated for 12 months.

An example we can use for this whole article would be a support service provided by Oracle Corporation for a period of 12 months for $100,000.00. The Support fees would be pro-rated in a 12-month accounting period, instead of having it only at one accounting period.

Depending on your Requirements, you may need to configure or update the following setups related to revenue:

Setup Revenue Recognition
Revenue Scheduling Rules
Define Revenue Policies
Define Revenue Contingencies

Each of these setups will be discussed in detail below.

Setup Revenue Recognition - It's a collection of defaults, options, functionality features that is broken down into two areas, billing-related and cash-processing system options and customer payment system options. Below are the setups for Revenue Recognition:

Salesperson System Options - Allows an organization to require a Salesperson when you enter an invoice. The idea here is to assign sales credit to that person that sold the product or service so that they can receive commissions based on their sales.

It also has an implication in terms of revenue recognition, because if you make an adjustment to their revenue, the sales credit of that salesperson will be impacted. If the salesperson gets paid based on revenue, an adjustment will also be made to his or her commission.

In some cases, you compensate salespeople on revenue and non-revenue, so it doesn't have to equal 100%. You can strictly compensate a salesperson based on revenue. To do this, you can enter a value in the Sales Credit Percent Limit field.

Revenue Adjustment Reason Lookup Type – If you create an invoice with revenue recognition rule that has the deferral option turned on, then you need to make sure that you track the reasons for revenue recognition. This Lookup just means you can add reasons to the seeded reasons list so that users can pick the value they need when they are about to recognize revenue manually.

AutoAccounting based on a Standard Line - If AutoAccounting is based on standard line, the transaction line must either be an inventory item or a memo line, and not a user-entered line.

When you are entering lines for an invoice in receivables, those lines can be adhoc. If you enter an adhoc line, it's going to be difficult for receivables to generate the required revenue accounting information. It doesn't know how to generate the accounting distributions for that line.

However, if it's an inventory item that you are using in an invoice line, AutoAccounting can generate the accounting distribution. It can also can be a standard line, which means that you are defining products and services outside of the inventory module.

Revenue Scheduling Rules - You can create an invoice with revenue recognition rules. A scheduling rule is a rule that tells receivables how to allocate our revenue into the future. It can be that a revenue scheduling rule that tells receivables not to recognize revenue now, we are going to recognize the revenue manually in the future by processing a revenue adjustment. For more information about Managing Revenue Scheduling Rules, check out a separate article: Manage Revenue Scheduling Rules in Oracle Fusion Applications.

Revenue Policies - Revenue Policies allow your organization to make automatic revenue recognition decisions for manually entered and imported transactions. This works in connection with revenue contingencies.

To create Revenue Policies, go to the Functional Setup Manager, pick the Financials offering, select the Revenue Recognition functional area and choose the Task “Manage Revenue Policies”.

Revenue policies can be based on different criteria such as:

Credit classification- When you create a customer, you can assign that customer a credit classification in the customer profile class setup. It can be excellent, average or poor credit. For example, the customer has excellent credit classification, then you might decide to recognize their revenue right away because they are good payers. Or on the other hand, you may want to recognize the revenue later on if the customers have poor credit, as you don’t want to recognize the revenue now and reverse it later on if the customer fails to pay.

Refund Policy Threshold- You can use the refund policy threshold column to enter the standard refund period represented in days that you offer to your customers. When you enter or import the transaction, if a line is associated with a contract, receivables analyzes the contract and look at the refund period. And if the contract offers a refund period that exceeds their refund policy, then our contingency is going to be assigned to the line. This is commonly used when your organization might have a certain refund policy where you may allow an unhappy customer a refund within 30 or 45 days. If that's the case, you might want to wait after the refund period has passed to recognize your revenue.

Payment Terms Threshold– Based on the Business Unit, payment terms and the transactions, receivables will identify that these are non-standard payment terms and therefore we are going to defer their revenue. This will dictate that we are only going to recognize the revenue after the removal event has happened, such as a customer payment, or after 60 days has passed, etc. For example, if there's an invoice created with these a non-standard NET 45 payment terms, it will be subject to a contingency and revenue will not be recognized unless the customer has already paid.

Revenue Contingencies - provides certain restrictions that you apply on revenue recognition that are going to be removed by an event. For example, the event can be payment, or the event can be that 30 days have passed, and now I feel comfortable that I can recognize the revenue.

How Does Revenue Contingencies Work?

You enter and complete the receivable transactions, either manually or automatically. Receivables will analyze the invoice and look at the contingencies and assignment rules that you have defined. If the customer specified in that invoice and the Business Unit matches the contingencies and assignment rules, it will proceed to determine if are there any restrictions for this invoice.

If there are no restrictions, then it can go on and recognize the revenue. If it does find contingencies, it will defer the revenue and wait until a removal event takes place. The removal event in this example is a payment. The system will not recognize revenue until the customer pays. Once the customer pays, it will automatically recognize the revenue for that particular invoice.

Removal Event – Removes the restriction based on an event such as a Payment, number of days passed, etc. For example, if a customer was billed with a non-standard payment term (NET 45), they will be assigned a revenue contingency, in which a payment will be the removal event. Once the customer pays, the restriction will be removed on the revenue, and we will recognize the revenue and report it because there's no risk anymore.

Revenue Contingency Assignment Rules - Defines a rule on how to apply that contingency. You can apply the rule to a given customer or a set of customers.

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 Functional Setup Manager in Oracle Fusion Applications

What is the Functional Setup Manager?

the Functional Setup Manager provides an integrated end-to-end application for setups and administration processes. Functional Setup Manager is the application in the Oracle Cloud to perform configurations to define setups.

Everything starts with planning, gathering and discussing business requirements so that you can then model your enterprise. And then, once finalized, you're going to initiate the set up by opting into an offering. Opt-In means you want to enable an offering. You then proceed to define the setups, referred to as an implementation task. As the word task means, it is something that needs to be done, something that needs to be completed. An example of a task would be defining a source document type. You will then test your configurations in a development or a test environment, and migrate those to a production environment on Go Live.

You still have to use Functional Setup Manager after Go Live for ongoing maintenance, to editing existing setups, if they need to be edited, or add additional configurations, such as maintenance of payment terms, setups, periods, etc.

Also, there might be certain features that you did not enable, or certain configurations that you did not complete because they were optional but then later on, you decide that you want to implement certain features so you can do it using the Functional Setup Manager.

Benefits of using the Functional Setup Manager

Centralized Setup - A single interface for all Cloud applications. You can use the Functional Setup Manager for all setups for all Offerings.
Guided Process - Implementation tasks are Organized by using Task lists, which guide you through recommended setups. Task Lists are further broken down into required versus optional implementation tasks.
Configurable - Gives you the freedom to pick an offering and specify what is relevant to your organization. This means that just because you opt-in to the financials offering, doesn't mean you have to enable every single functional area under financials. You can choose which functional area you will implement. You might need GL, but not AR and AP, or all of them.
Easier Management of Setup Data - Clearly see dependencies as you look at the implementation tasks for a specific functional area, no need to guess what the prerequisites are.
Setup Data Migration - Supports the ability to move and migrate the configurations, from one environment to another.
Reporting - Provides the feature to generate reports to validate your setup data.

Key Concepts of the Functional Setup Manager

Offering - An offering is a collection of business processes that will be relevant to your enterprise. So for Financials, this means you have the General Ledger module and at least one subledger, Revenue Management, Receivables, etc. Click on the Navigator and look for "My Enterprise", select the offering you need to implement for your organization and Opt-In.

Functional Areas - Functional Areas are the applications within the Opt-In Offering that your organization might require, such as Receivables, Payables, Revenue Management. For Example, we have the financials offering. We have Revenue Management as a Functional Area. It groups together the Tasks List that you need to carry out for implementation and maintenance.

Implementation Tasks and Task Lists - An Implementation task is simply a configuration that you need to carry out for your implementation or maintenance. This could be like defining a source document type or it can be a pricing configuration, or system options for Revenue Management. Task Lists just simply groups together the Tasks for easier navigation.

Scoping - There's another concept called Scoping. Scoping provides the Business Unit you will use for an Implementation Task because a configuration Task can have different values for each Business Unit.

Shared Functional Area - shows you offerings that share the same functional area. For example, the Functional "Legal Structures" are shared between other offerings besides Financials.

How do I Opt-in to an Offering?

Click on the Navigator and look for "My Enterprise" > Offerings
Select the Offering you want to implement.
Read the detailed description of the Offering to find out if this is what your organization requires
Check the status to make sure that the offering is enabled
Use the opt-in feature
Use the related documents available in different formats (PDF, Excel, HTML) to learn more about implementation requirements, a list of implementation tasks, configurations that need to be completed, and new features.

There's also feature in the Opt-In that gives you the freedom to choose if you use the new features recently released by Oracle. For Example, the new features rolled out by the upgrade process is something your organization does not need, then you can simply not opt-in to that new feature.

Below is a Video Demonstration on Opting in to an Offering using the Functional Setup Manager in Oracle Fusion Applications:

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)