Managing Customer Bankruptcy in Oracle Fusion Applications

What is Bankruptcy?

Bankruptcy is a legal process by which a person or organization declares inability to pay outstanding debts.

How do we handle this process in the Collections application? 

A bankruptcy request is initiated on behalf of the customer. So the customer would let a collector know that they have started this legal process. And then the collector would go in to the application and initiate this process to make sure that collection activities are suspended.

How do I initiate a bankruptcy request?

The bankruptcy request are basically sent to an appropriate person for approval. There is a workflow process that will route that approval to a collections manager so that they can look at the request and approve or reject. 

After a bankruptcy request has been submitted and potentially approved, that bankruptcy request can be withdrawn. A notification is sent to the collections manager to approve that withdrawal request.  Once that bankruptcy withdrawal request is approved, the customer status switches from bankrupt to delinquent.

What configurations are necessary to use these bankruptcy requests functionality?

Enable Bankruptcy

There is an important setting in Global Preferences that needs to be turned on for your organization to use these functionalities. The setting is "Enable Bankruptcy". If this option is set to Yes, the Bankruptcy subtab appears under their Profile tab in the Collections work area.

Go to the Functional Setup Manager, under the Financials Offering, Collections Functional Area, go to the task "Manage Collections Preferences". At the top we have Global Preferences. Locate the Enable Bankruptcy option right at the bottom of the Global Preferences and set it to Yes. 

Note that this is not a setting that can be enabled for one business unit only or for a group of business units. It's something that's going to be available for all business units.

Bankruptcy Reasons

Bankruptcy Reasons allow you to report and track different types of bankruptcy requests. These are very useful for reporting and tracking purposes.

To add more Bankruptcy Reasons, Go to the Functional Setup Manager, under the Financials Offering, Collections Functional Area, go to the task "Manage Collection Lookups". Look for the Lookup type of "Bankruptcy_Disposition_Reason". These are all associated with a common set ID. There are already seeded reasons (Entered in Error, File for Bankruptcy, and Reorganized) but you have the option to add more to the list. 

How do we process a bankruptcy request? 

To actually initiate the bankruptcy request, navigate to the Collections work area and you select the customer in question and simply click on the "Request" button under the bankruptcy sub-tab. The approval workflow kicks in and routes a notification to the appropriate person, that Collections manager or supervisor that's supposed to review their request and approve or reject.

What is the impact of Bankruptcy?

All accounts and sites under that customer and all transactions will be suspended. Collection activities are also suspended and delinquent transactions no longer appear in the Collections work area. In addition, the customer will show a status of bankrupt.

A collector can still find the customer and view the transactions associated with the customer. But they won't be able to perform any Collections activities, such as receiving a payment, or even putting in a payment promise, or dispute a transaction because, again, the customer has filed for bankruptcy. They'll be unable to make payments.

What Type of Information do I need to store for Bankrupt Customers?

There may not be a field in the Collections application to capture information specific to your organization such as claims, attorneys involved, filing locations. This can be handled by Descriptive Flexfields. Descriptive Flexfields are fields that you can use to store information unique to your organization, your industry, or for special circumstances or scenarios like this one.

Below is a step-by-step video on how to Manage Customer Bankruptcy 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)

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)

Overview of Receipt Write-Offs in Oracle Fusion Applications

What is a receipt write-off in Receivables? 

A receipt write-off is a receipt activity that cancels a small unapplied amount remaining on a receipt which your organization considers to be immaterial. 

There are two methods available to create these receipt write-offs:

1. Manual - a write-off is created from the Accounts Receivables Work Area
2. Automatic - A write-off would be automatically created by running the Create Automatic Receipt Write-offs Program. It would look at the approval limits that are assigned to the user of running the process. 

Does Receipt Write-Off support multi-currency processing?

The receipt write-off functionality in Receivables supports multi-currency processing. This means when you write off a foreign currency receipt, Receivables uses the conversion rate information from the original receipt for the write-off record. For scenarios when you adjust the conversion rate of a foreign currency receipt, Receivables will reverse the write-off with the original conversion rate, and then apply the new conversion rate to the write-off.

Receipt Write-off Configurations 

The following are required to configure Receipt Write Offs:

Manage Receivables Activities

Receivables would need to define a Receivables Activity with the type of "Receipt write-off" and identify the accounting distributions to be used.

1. Go to Functional Setup Manager > look for the Financials offering > Manage Receivables Activities
2. Select a Business Unit and look for the activity type "Receipt Write-off" and click on Search
3. Observe the GL account that Receivables is going to use to credit the receipt write-off amount. 

For more information on Manage Receivables Activities, check out the article: "Overview of Managing Receivables Activities in Oracle Fusion Applications"

Approval limits Configuration

Users are going to be assigned approval limits in order to process receipt write-offs. This means is that there's a minimum and maximum approval amount that users can be provisioned with, so that they can process receipt write-offs accordingly. Now, these limits are going to be as specific to a currency as well.

1. Go to Functional Setup Manager > Look for the Financials offering > Receivables Functional Area > Manage Approval Limits
2. Search for the desired user and see that there are two different document types: Adjustment and then Receipt Write-off.

The below video shows how to set Receivables Approval Limits:

Receivables System Options

In the Receivables System Options, there are settings that that will be specific to a business unit. We would need to define write-off limit ranges per receipt, and receipt balances that are less or greater than this range will not be written off. 

1. Go to Functional Setup Manager > Look for the Financials offering > Receivables Functional Area > Manage Receivable System Options
2. Select the Appropriate Business Unit and Go to the Cash Processing tab
3. Take a look to the right towards the top, we see a range from write-off limit per receipt to write-off limit per receipt.

For more information on Managing Receivable System Options, check out the article: Overview of Managing Receivable System Options in Oracle Fusion Applications

Application Exception Rule Set

There are additional considerations regarding Lockbox functionality. After Lockbox processes and applies receipts, the AutoApply process uses the Application Exception Rule Set to determine how to manage over and underpayments. This configuration is used to manage remaining amounts after Lockbox has run. 

If there is an overpayment, the Application Exception Rule indicates whether to refund the amount to the customer, place the amount on account, write off the amount, or leave the amount unapplied. 

To View the "Application Exception Rule Set", Navigate to the  Functional Setup Manager > Customer Billing > Manage Receipt Application Exception Rules.

There is an option there to require a user review. Perhaps there are certain overpayments that your organization considers to be immaterial, and you decide that you want to review their write-off before it is final. 

Create Automatic Receipt Write-offs Program

This program will write off unapplied amounts and closed receipts. This program will still look at the approval limits of the user who is running the process. In addition to that, this program will look at the write-off limit ranges that have been established in the system options configuration. This process can be scheduled periodically to adjust for small remaining balances. The is also an option to create write-offs only for specific currencies and customers and an option to generate a report after the process has completed.

This process can be executed in Draft mode ("Generate Report Only") to see what the adjustments would before running the process in Final mode. It generates a report that allows you to review, and once confirmed, run the process again in Final mode. A Receivable activity needs to be specified to generate accounting distributions and credit the write-off amounts when running in Final Mode.

How do we create a Manual Receipt Write-Off?

The below video demonstrates how to create a Manual Receipt Write-Off:

1. Navigate to Receivables > Accounts Receivables
2. In the Accounts Receivables work area, click on the Task panel and select Manage Receipts
3. Search and Select for a receipt with a small, unapplied amount. 
4. Go down to the Receipt Details section and select the receipt application
5. Click on Actions > More > Create Write-Off and specify the amount you want to Write-Off and click OK and proceed to Save.
6. Verify that the unapplied amount is now $0.

How do I run the Automatic Receipt Write-Off Process?

1. Go to Tools > Scheduled Processes > Schedule New Process
2. Search and Select the process "Create Automatic Receipt Write-Off"
3. Fill up the Mandatory Parameters such as Business Unit and Receipt Currency
4. You can also fill up optional parameters, such as the Unapplied Amount or Percentage Receipt Date

Below is a quick demonstration of Running the Automatic Receipt Write-Off Process 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.

Create Accounting for Receivables in Oracle Fusion Applications

From the Springboard, navigate to:

Create Accounting Execution Report

Confirm the created Journal in the Manage Journals screen

Below is a quick demonstration of Create Accounting for Receivables 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)

Defining a Transaction Source in Oracle Fusion Applications

A Transaction Source is a mandatory attribute on a transaction (i.e. credit memo, invoice, debit memo, etc.). It tells where the transaction came from.

There are two types of transaction sources:

• Manual - Transactions that are created from the application screen.
• Imported - sources that are used by AutoInvoice. 

To create a custom Transaction Source, from the Homepage, navigate to Setup and Maintenance > Financials > Customer Billing > Manage Transaction Sources:

From the Manage Transaction Sources screen, you can search for an existing Transaction source or create a new custom transaction Source:

In the Create Transaction Source screen, fill up the required fields and click on "Save and Close" once done:

Some Important fields are:

1. Name - Transaction Source Name
2. Description - Transaction Source Description
3. Type - Choose Manual if this will be used from the Application and Import when used by AutoInvoice.
4. From Date - It's recommended to use a back date of 6 months
5. Transaction Source Set - Identifies the Set ID associated with this Transaction Source.
6. Legal Entity - Associates this Transaction Source with a Legal Entity
7. Last Transaction Number - Identify where the Transaction Numbering will start
8. Automatic transaction numbering - Tick this checkbox if the transactions will be sequential based on the Last Transaction Number.
9. Allow duplicate transaction numbers - Tick this checkbox if your organization allows duplicate transaction numbers (not recommended).

Below is a quick video demonstration of Defining a Transaction Source 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)

Overview of Processing Late Charges for Receivables in Oracle Fusion Applications

What is a late charge? 

It's a fee and/or penalty assessed against overdue customer transactions (Invoice or a debit memo).

What options do you have in the receivables applications to present late charges to your customers?

You have three options called late charge types. These are as follows:

1. Adjustment. And so if you record late charges as adjustments, then Receivables combines all the interest charges relating to an overdue transaction, and creates a single Late Charge adjustment against the transaction. In other words, that adjustment is going to increase the balance of that transaction.So if you pick adjustments, and you are assessing fees as well as penalties, then Receivables will create two adjustments-- one for the fee, and one for the penalty.
2. Debit memos. If you record late charges as debit memos, then Receivables will create one debit memo per overdue transaction. Additionally, if you also assess penalty charges, then Receivables includes a separate line for penalty charges on the debit memo.
3. Interest invoice. if you record late charges as interest invoices, then Receivables will create a single interest invoice per customer site and currency. So think of this interest invoice as a way to consolidate charges so that the customer receives one single document. So they'll receive one single interest invoice that will detail charges for all the invoices that were overdue, and therefore are being assessed a charge. 

What's needed to implement the late charges feature?

Defining a late charge policy is required  to implement the late charges feature. A late charge policy is basically a configuration required for your late charge documents. Below are some configurations required to implement the late charges feature:

1. Define Receivable Activities. Defining Receivables activities is needed for Interest charges, as well as Penalty charges. For Example when Receivables is creating an adjustment, it will need to know which GL accounts to use. The Receivables activity setup will provide the information how to generate accounting distributions. To know how to define a Receivables activity, check out a separate article: Overview of Managing Receivables Activities in Oracle Fusion Applications.
2. Define Transaction Types. If the late charge document is going to be a debit memo or an interest invoice, you would need to define the transaction types for those debit memos or interest invoices.
3. Turn on the Late Charges Option in Receivable System Options. Make sure that the Late Charges feature is enabled in Receivable System Options for the system to assess late charges on overdue transactions. This is an option defined per business unit. To know more about the configurations available in the Receivable System Options check out a separate article: Overview of Managing Receivable System Options in Oracle Fusion Applications.
4. Customer Profile Classes. When you go the a customer profile class setup, there are two tabs. One of them is specific to the late charge feature. There's an option to enable late charge for any customers associated with the said profile class. Two Important fields here is the "Late Charge Calculation Method" and "Late Charge Type". For "Late Charge Calculation Method", this identifies if you are going to assess late charges on overdue invoices only, on late payments, or both. For "Late Charge Type", this identifies the document to be used for late charges.

Late Charge Calculation Method

When you set up a late charge profile for your customers, you must decide the method to use to calculate late charges.

You select the calculation method in the Late Charge Calculation Method field in the Credit Limits and Late Charges tab of the Customer Profile Class pages, or on the applicable customer or customer site profile.

The interest calculation methods are:

• Average Daily Balance: Calculate late charges based on the average daily balance of overdue invoices. This method is for balance forward bills only.
• Late Payments Only: Calculate late charges based on the number of days between the payment due date and the actual payment date. This method uses the paid amount as the overdue invoice amount when calculating the late charge.
• Overdue Transactions Only: Calculate late charges for transactions based on the number of days a payment is late when you submit the Create Late Charges program.
• Overdue Transactions and Late Payments: Calculate late charges on both overdue transactions and late payments. This option levies the largest late charge amount on a customer.
  For example, your enterprise calculates late charges on the 15th and 30th of each month. Your customer has an overdue invoice of $100 that falls due on November 16:
  • On November 30, you run the Create Late Charges program. The program calculates late charges for this overdue invoice.
  • On December 10, your customer pays the invoice.
  • On December 15, you run the Create Late Charges program again. The program assesses further charges for the additional 10 days that the payment was overdue.

There are three different interest calculation formulas that Oracle delivers out-of-the-box:

1. Flat rate - Receivables will ignore the number of days that a payment is overdue.
2. Simple
3. Compound

1. Interest Tiers and Charge Schedules. - The concept of Interest tiers are interest rates that's increasing as time goes on. So the longer that transaction is overdue, the higher the interest rate will be. The below table is an example. A charge schedule is shown with four interest tier periods, along with interest rates assigned to those interest periods.

Days Overdue Tiers	Interest Rate
1-30 Days	2%
31-45	3%
46-60	4%
Over 60 Days	5%

If the transaction is overdue between 1 and 30 days, you are charging 2%. If the transaction is overdue between 31 and 45 days, you are charging 3%, and so on or so forth.

To use Interest Tiers and Charge Schedules, enable the option "Use Multiple Interest rates" in the Customer Profile Class, inside the "Late Charges" tab.

To review the Interest Tiers and Charge Schedules, go to the Functional Setup Manager and select the "Manage Interest Tiers" and "Manage Charge Schedules" Task, respectively.

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 Receivables Adjustments in Oracle Fusion Applications

What are Receivables Adjustments?

An adjustment is a manual or automatic billing update that increases or decreases the balance on a transactions such as an invoice, debit memo, chargeback or a credit memo.

Which types of Adjustments can be processed in Receivables?

1. Invoice - This means that the adjustment amount will be applied to the entire invoice.
2. Line - The adjusted amount is prorated across all lines. If the adjustment includes tax, then the amount is prorated across lines and tax.
3. Charges - the adjusted amount is applied to the charges amount on the invoice. Again, if the adjustment includes tax, the amount is prorated across charges and tax. 
4. Tax - the adjusted amount is applied to the tax amount
5. Freight - The adjusted amount will be applied to the freight amount

Adjustment Configurations

1. Approval limits - Approval limits are going to determine whether a user can approve adjustments. These are defined by document type, amount and currency. 
• A document type - can be adjustment, or it can be something like credit memo refund or receipt write off. 
• Amount - Amount can be part of a defined range. the range can go from a negative number to a positive number.
• Currency - Approval limits are going to be specific by currency. There will be different limits for the US dollar, for the Euro, for the Mexican Peso, etc.

To know how to setup Approval limits, check out this step-by-step video: Managing Approval Limits in Oracle Fusion Applications.

1. Receivable activities - this configuration in the Receivables application will allow Receivables to generate accounting distributions. More on Managing Receivable Activities in a separate article: "Overview of Managing Receivables Activities in Oracle Fusion Applications".
2. Adjustment Reasons -  important for tracking and classifying adjustments. Adjustment reasons is optional by default. but you can make it mandatory. M

To know how to setup additional Adjustment Reasons, check out this step-by-step video: Managing Adjustment Reasons in Oracle Fusion Applications

Adjustment Statuses

1. Approved
2. Pending Approval
3. More Research
4. Rejected

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 Receivables Credit and Debit Memo in Oracle Fusion Applications

What is a Credit Memo or a Debit Memo?

In Receivables, a Credit Memo decreases the value of a transaction while a Debit Memo Increases the value of a transaction. Both of these are linked to the original Invoice.

What's the difference of an Adjustment as compared to Credit/Debit Memos? 

In an adjustment, the amounts are updated for the original transaction whereas a Debit Memo or Credit Memo is a new transaction that is linked to the Original Invoice like an addendum. Although note that we can create a separate Credit/Debit Memo that is not linked to an Invoice. These are called on-account Credit/Debit Memos.

When is it preferred to use Adjustments or Credit/Debit Memos?

It depends on the organization requirement as well as statutory requirements that prevails in a country to decide which approach should be followed. But Adjustments are more commonly used when there is an error in the original amount stated in the Invoice, whereas Credit/Debit Memos are used when there is an amendment in the actual invoice.

Steps in creating a Credit Memo

So navigation is step one. Once we're logged in terms of starts us in the Billing work area. And we're looking for the Task Credit Transactions.

A window will prompt the user to search and select the original invoice the Credit Memo will be linked to. Once selected, click "OK".

On the "Credit Memo" screen, fill up the required fields. For the Credit Memo Amount, the user may either put in the exact amount or a percentage from the Original amount. Once done, click on "Save and Close". This will effectively create a Credit Memo linked to the Original Invoice.

You may search and verify for the newly created Credit Memo by navigating to Billing Work Area > Task Panel > Manage Transactions screen:

View the Credit Memo's report by selecting the Transaction and clicking on the "View PDF" button:

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 Receivables Invoicing Rules in Oracle Fusion Applications

Invoicing Rules are used to determine when to recognize your receivable for invoices that span more than one accounting period. You can only assign one invoicing rule to an invoice. Receivables provides the following invoicing rules:

Bill In Advance: Use this rule to recognize your receivable immediately.

Bill In Arrears: Use this rule if you want to record the receivable at the end of the revenue recognition schedule.

To use Invoicing Rules create an Invoice with the field populated:

After creating your Invoice and assigning an Invoicing Rule, Run Recognize Revenue Program from the Scheduled Processes page. This will create Invoices dated in a future date depending on the Invoicing Rule you have specified.

Also, ensure that the Invoicing Rule setup in Import Information section of "Manage Transaction Sources" task is correctly configured.

For more full-detailed Tutorials and Tips, check out #TheOracleProdigy at https://lifeofanoracleprodigy.blogspot.com/

Follow my other Social Media sites:

Like my Page The Oracle Prodigy on Facebook (https://www.facebook.com/theOracleProdigy/)

Follow me on Twitter (https://twitter.com/D_OracleProdigy)

Subcribe to my YouTube Channel (https://www.youtube.com/c/OracleNerd)