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:

1. Setup Revenue Recognition
2. Revenue Scheduling Rules
3. Define Revenue Policies
4. 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:

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

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

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

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

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

1. 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)

Create a Party Hierarchy in Oracle Fusion Applications

This article will discuss Party Hierarchies and demonstrate how to create a Party Hierarchy in Oracle Fusion Applications.

Hierarchical structures of an enterprise are defined in and maintained in special tables. And one of those tables is the FND_HIER. There are three predefined hierarchies:

1. The customer hierarchy
2. Thee trading community party hierarchy
3. Dun and Bradstreet hierarchy. 

As a prerequisite, you need to have the role "Customer Data Steward" assigned to the desired user. For a demonstration on how to assign the role, check out the video below:

Once assigned, proceed to the Navigator, look for Customer Data Management > Hierarchies 

Select Hierarchies and click on the Create button. 

Give the hierarchy a name and go with the option: "Trading Community Party hierarchy" and with the status of "Active" and then click on Next:

In the Hierarchy Members section, Click on the "Add" icon to add a Parent Party:

To add a child Party, select the Parent Party and click on the "Add" icon again:

Look for the child Party ("ABC Consulting") and proceed to click OK.

If you expand the hierarchy, you can see that ABC Corporation sits at the top and then ABC Consulting sits below, underneath. 

You can further add child Parties if necessary. Once done, click on Next to confirm the hierarchy and click on Finish to effectively create the Party hierarchy.

Below is a quick video demonstration on how to create a Party Hierarchy 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)

Creating a Customer Paying Relationship Assignment in Oracle Fusion Applications

This article will demonstrate how to create a Customer Paying Relationship Assignment in Oracle Fusion Applications. As a prerequisite, you need to have the role "Customer Data Steward" assigned to the desired user. For a demonstration on how to assign the role, check out the video below:

What is a paying relationship? 

A paying relationship is a configuration that enables customers to apply receipts to the transactions of related customers.So For example, you have two customer entites that are related. Maybe they roll up to the same corporate parent. A paying relationship enables the parent company to pay the bills for its subsidiaries, or a subsidiary wants to pay for the bills of the other subsidiaries. So this means the paying relationship allows you to manage these types of scenarios in the receivables obligation where a customer wants to pay the bills of a related entity.

The idea with party relationships is to model your customer records according to the way you conduct your business. A party relationship represents the way in which two entities interact with each other based on the role that each entity takes with respect to the other. 

There are two different types of paying relationships: party paying relationships (we'll call it PPR), and customer account relationships (CAR). 

What is the difference between the two?

In the simplest terms, PPR is at the Party Level (including the Accounts, Sites and Transactions) while CAR is only at the Account Level. 

Party paying relationships provide one party with access to another party's accounts and transactions. You may have a party with five accounts underneath and another party with three accounts underneath. And those eight accounts are going to be related to each other because the parties at the top are related.

Meanwhile, Customer Account Relationship is a flat relationship between two customer accounts only. A relationship at the customer account level is flat in the sense that it only involves one account on one side and another account on the other side. 

How do I Create a Party Paying Relationship?

To create a Customer Paying Relationship Assignment, go to the Functional Setup Manager > choose the "Financials" Offering > Search for the task "Manage Customer Paying Relationship Assignment".

From the Manage Customer Paying Relationship Assignment page, View the seeded Paying Relationship Assignment set or add a new one by clicking on the  "+" Icon. 

Add the preferred Hierarchy Type and the preferred Paying Relationship.

The Pay Below Paying Relationship consists of parties paying for their own transactions and the transactions of all parties that are lower in the hierarchy. What this means here is that we are going to have to build a hierarchy as a requirement, as a prerequisite, to a party paying relationship. For more information on creating party hierarchies, check out a separate article: Create a Party Hierarchy in Oracle Fusion Applications.

The Pay Any Paying Relationship means that any party in the hierarchy can pay for each other's receivable bills, regardless of where they are in the sequence. Any party within the relationship can pay for the accounts of any other party within the relationship.

Below is a quick video demonstration on how to Create a Customer Paying Relationship Assignment 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)

Configuring Payment Relationships for Customers in Oracle Fusion Applications

What is a paying relationship? 

It is a configuration that enables customers to apply receipts to the transactions of a related customer. 

To give an example, two or more customers can be related to each other, (i.e. a subsidiary of a corporate parent). This allows a parent company to pay for the transactions of the subsidiary, or vice 

versa, depending on the configuration.

There are two different types of party paying relationships: Party-Paying relationships, and we have customer account relationships.

What is the difference between Party-Paying and Customer Account relationships?

Customer Account Relationships is a flat relationship between two customer accounts only. A relationship at the customer account level is flat in the sense that it only involves one account on one side and another account on the other side. And therefore, we use the terminology flat. Customer account relationships go beyond payment activities. You can also define customer account relationships to share billing and shipping services between two accounts.

Party Paying Relationships orders the related parties in a hierarchy. It provides one party with access to another party's accounts and transactions. If you think about a party paying relationship, you may have a party with five accounts underneath and another party with three accounts underneath. And those eight accounts are going to be related to each other because the parties at the top are related.

What are the components of a party-paying relationship? 

• Define a hierarchy
• Define a Paying Relationship Assignment - A Paying relationship is going to be assigned to a hierarchy to indicate how the parties in the structure are able to manage each other's customer payments. 

There are two types of party-paying relationships: Pay Below and Pay Any. 

What is the difference of Pay Below and Pay Any?

Pay below consists of parties paying for their own transactions and the transactions of all parties that are lower in the hierarchy. What this means here is that we are going to have to build a hierarchy as a prerequisite to a party-paying relationship.

Pay any means that any party within the relationship can pay for the accounts of any other party within the relationship, regardless of their position in the hierarchy.

Hierarchical structures of an enterprise are defined in and maintained in special tables. And one of those tables is the FND_HIER. There are three predefined hierarchies, the customer hierarchy, the trading community party hierarchy, and the Dun and Bradstreet hierarchy. 

Below is an example of a party hierarchy: Green Corporation Worldwide has subsidiaries in USA, Singapore, and Nigeria.

Example 1: Pay Any Relationship

Green Corporation hierarchy is assigned to a Pay Any type of paying relationship. This means that Green Corporation Worldwide can pay for USA, Singapore, and Nigeria. In addition to that, because it is a Pay Any paying relationship, this that means that each party can also pay for the other transactions of any of the other parties, regardless of their position in the hierarchy.

Example 2: Pay Below Relationship

Green Corporation hierarchy is assigned to a Pay Below type of paying relationship. This means that Green Corporation Worldwide can pay for Green Corporation USA, Singapore, and Nigeria, as well as its own transactions. However, each subsidiary can only pay for its own transactions because there are no entities lower in the hierarchy.

How do we create a Hierarchy?

Check this step-by-step demonstration: Create a Party Hierarchy in Oracle Fusion Applications

How do we create a Customer Paying Relationship Assignment?

Check this step-by-step demonstration: Creating a Customer Paying Relationship Assignment in Oracle Fusion Applications

Applying a Receipt

So I'm going to click down here, and I'm going to go to Receivables in the Accounts Receivable work area. I'm going to go to the Tasks panel and select Create a Receipt. So what I'm going to do here is create a receipt for one of the parties in the hierarchy and try to apply it to the other party in the hierarchy. So here I am when I go with the Receipt Method check, and I need a customer payment, or Receipt Amount, here.

And then I'm going to assign the customer to this customer payment, or Receipt. So I'm going to look for Purple Iguana, which is part of the hierarchy that I defined. And at this point, I'm going to go with the option Submit and Apply Manually.

Now, before I proceed, I do want to show you an important receivable system option. So I'll return here in a moment, but I want to go to the Functional Setup Manager-- Financials being the offering, Receivables being the functional area. I want to go to Manage Receivable System Options.

So I'm looking at the system options for this business unit, US1. If I go to Cash Processing, I want to highlight the fact that this system option is not turned on, it's not selected, Allow Payment of Unrelated Transactions. We'll discuss that later in the course, but I wanted to come here and show you that this particular system option is not enabled. So what that means is that to pay for related customers, I would have to define a relationship. So I'm going to go ahead and close that for now and go back to the receipt.

So I'm going to go with the option Submit and Apply Manually. You need a receipt number here, so I'm just putting a receipt number. So here I am going to go with the option to Add Open Receivables. That will allow me to search.

And remember this receipt that I'm working with is for the customer Purple Iguana. I'm going to look for transactions of the related customer. So here I'm going to go to Transaction Customer Name and look for Punta Cana Corporation. I'm going to try looking for the customer again. OK, there I have it. So I'm going to select Punta Cana Corporation here and hit OK.

Now that I have the related customer, I'm going to run a search. And what we're trying to do here is apply a customer payment for Purple Iguana to transactions for this related customer, Punta Cana Corporation. So I'm going to go ahead and search. And here I see four potential invoices that I can apply this payment to. So I'm going to pick this one at the top, click on that and then Done.

And then here we see that I'm applying a payment to a related customer's transaction. OK. So the payment is for Purple Iguana. The invoice belongs to Punta Cana Corporation. So here I'm going to go ahead and click on Save and Close. And we successfully demoed the party paying relationship, so I'm going to go back to the slides now.

And so we want to talk about customer account relationships at this point. There are two types of account relationships. We have the One Way relationship, and then we have the Reciprocal.

So One Way means that you have a parent account that can apply receipts to open debit items of the related account, but receipts in the related account can't be applied to open debit items of the parent account. So you have a parent-child relationship. And what we mean by debit items are transactions such as invoices and debit memos. So the name gives us a good idea of what that type of relationship does.

Then we have Reciprocal. In that scenario, the two accounts involved in the relationship can pay for each other's open debit items. So customer A can pay for transactions belonging to customer B and vise versa.

So what's needed to define a consumer account relationship? We need to first determine which are the two customer accounts that will participate in the relationship. And as we have explained, this is a flat relationship, account to account. And then number two, we need to decide on the type of relationship it's going to be. Is it going to be One Way? Is it going to be Reciprocal?

And then there's another consideration for customer account relationships, and that has to do with billing and shipping implications. We have to decide whether there are going to be billing and shipping services shared. Now, to enable these billing and shipping services, there are going to be Bill To and Ship To options, and you can enable those when you define the account relationship.

So what we want to do now is demo the customer account relationships. And so I'm going to define a customer account relationship and then test it by creating a receipt and applying that receipt to the related customer account. So I'm going to go through the application now.

From the Account Receivable work area, I'm going to select Manage Customers. Now, here I'm looking for two sample customers, and I'm going to use this customer Fox Stores. And here we can see the party level information in the middle-- the customer account information and then the sites.

So I'm going to click on the account number link, and here I'm looking at the customer account information for Fox Stores. And I'm going to go to Relationships. So there's different tabs, Payment Details, Communication, Profile History, and the third tab from left to right is Relationships.

So here what I'll do is click on the Create icon, and I have to pick their related customer account. So here we can see the options for billing and shipping services. I'm going to uncheck those, and I'm going to go with the option Reciprocal. If I don't check Reciprocal, then it would be a One Way relationship. In other words, Fox Stores would be the parent, and the account that I'm going to select now would be the child.

So I'm going to select reciprocal. And then the related account I'm looking for is account 16080, Business World. So I'm going to hit OK, and I'm going to backdate the start date here. And of course, I have to associate these to a reference data set. Then I'm going to go ahead and hit OK here.

So I can see the relationship here. I'm going to hit Save and Close and then proceed to test. So I navigate back to the Accounts Receivable work area. And here I'm going to go with the option Create Receipt. So here I create a receipt with the Receipt Method check. And of course we have to assign a receipt number and an amount. So I'm going to put in an amount of $500. The amount doesn't really matter, I just want to make sure that this works.

The customer associated with the payment would be see Fox Stores, and that's the account number 80030. OK. I'm going to attempt to apply this payment to an invoice belonging to Business World. So I'm going to go with the option here Submit and Apply Manually.

And so here I am. I'm going to click on Add Open Receivables. And the customer account number of the related customer account would be 16080. So here we go. I can see Business World, and I hit OK. And then I'm going to search again and see what transactions come up.

And so here I see a number of transactions, and I'm going to pick the first one here, invoice 10000. I click Add and Done. And so here I have been able to apply this customer payment from Fox Stores to a transaction belonging to Business World. So I'm going to go ahead and hit Save and Close, and I'm going to return to the PowerPoint.

So the demo basically took me through creating a customer account relationship, and then I was able to apply the receipt to test that relationship. Now, there is one more saying that we would like to discuss, and that would be Allow Payment of Unrelated Transactions. It is a receivable system option, and so for these receivables system some options, there are two potential settings you can enable or you can disable.

If you enable these system options, any customer account can pay for the open debit items of any other customer account. So defining paying relationships is not required if you enable these system options. However, if the system option is disabled, receipt application is restricted to related customers only. So defining paying relationships at the party or customer account level is indeed required if this system option is disabled.

So that takes us here to the end of this course, and we've discussed a number of topics, including the TCM, the trading community model, what a party is, what a customer is, a customer account, and of course, a customer account site. We've discussed what paying relationships are. We have also explored the different types of paying relationships, party paying relate relationships versus customer account relationships.

In terms of party relationships, we know that there are options there. You do have to create a hierarchy, and there are options to define a Pay Below versus a Pay Any relationship. After building the hierarchy, you do have to define a paying relationship assignment, and you do that in the Functional Setup Manager.

Creating a Manual Refund in Oracle Fusion Applications

This article demonstrates the steps involved in creating a Manual Refund via an On-Account Credit Memo.

1. Navigate to the Receivables Application > Billing Work Area 





2. Click on the Task Panel and create an On-Account Credit Memo:





3. On Create Transaction screen, fill up the necessary details to create a Credit Memo. Make sure the Transaction Class selected is a Credit Memo:



4. Fill up the Bill-To Name and the Ship-To Name, including the Amount and Quantity of the Credit Memo. Also note to use the negative sign for Credit Memos:





5. Once complete, click on Complete and Close to complete the transaction.





6. A confirmation message confirms that the Credit Memo has been created.







7. Next, login as a User with enough privilege credentials in Payables then Go to Accounts Receivables Work Area and click on the task Panel and select Apply Credit Memos










8. Search and Select for the On-Account Credit Memo you created and click on "Issue Refund":





9. On the Issue Refunds screen, populate the required fields and click on "OK". This populates the Payables Open Interface Tables and creates a Payment Request in the form of a Payables Invoice.





10. To verify if the Credit Memo has been applied, go back and search for the Credit Memo in the "Manage Credit Memo Applications" screen. Notice that the Unapplied amount has been reduced to Zero:





11. Next, navigate to the Payables Work Area and check on the Invoice created for the Customer for the refund.










On the Payables Work Area, search for the recently-created Invoice and select it. You can either Account for the transaction or refund the Customer in full.








On the actual Invoice, click on "Actions" and select "Pay in Full":

The Payment Details screen will appear and fill up the necessary details to complete the Payment:








Once done, click on "OK" and a confirmation message will appear:








To confirm if the Payment has been initiated, re-search the invoice and check the Payment Status:

Below is a quick video demonstration of Issuing Manual Refunds 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)