This chapter covers the following topics:
Claim settlement is the process by which claims, deductions, and overpayments are settled. The claim settlement functions automate a majority of claim and deduction scenarios. For a claim created in Oracle Channel Revenue Management, checks and credit memos can be automatically created in the Oracle Payables and Oracle Receivables respectively for settlement.
With Auto-Resolution, organizations can automatically close out deductions, create corresponding Receivables transactions, apply the transactions, and enter accurate accounting entries as soon as the claim is settled in Oracle Channel Revenue Management. If the currency of the claim differs from the currency used by your organization to post accounting entries, then Oracle Channel Revenue Management can convert the claim amount to the proper currency. You can settle claims for Buying Groups and Related Customer Accounts
Note: If payout methods have been specified for an offer during offer creation, then you need not create a claim manually and specify the payment method. Such offers are settled automatically by the Autopay program. For a manually created claim too, if a settlement method is defined on the customer's trade profile and valid offer code having available earnings is updated on the claim, then the claim is automatically initiated for settlement and the status is updated to Pending Approval or Pending Close.
Information in this section will enable you to:
Understand Scan Data offer adjustments
Understand promotional payments and work with the promotional payments view
Understand the concept of paying earnings over thresholds
Approve requests for unearned payments
Understand the concept of mass settlement
Net overpayments and deductions with debit items
Understand and work with Autopay
Understand Automatic Write-off
Understand the concept of updating deductions based on subsequent receipts
Understand claim settlement methods
Understand standard memo lines
Settle claims, debit claims, deductions, and overpayments
Use the following high level procedure to settle claims, deductions, and overpayments.
Prerequisites:
An existing claim or deduction with a status of Open or Complete.
Oracle Receivables should be set up.
Oracle Payables should be set up for settlement with contra charge
Navigation: From the Claim tab, click the Claims subtab, then the claim. In the Claim Main page, click the Settlement subtab.
Navigate to Claim Lines and verify if the claim has lines. The claim should have at least one claim line with a positive value. If a claim line does not exist, create one now. See Creating Claim Lines for information on creating claim lines. The sum of the claim lines can be less than the total claim amount, as taxes will be added.
Optionally, verify if earnings have been associated to the claim line. You will see a check mark in the Associate Earnings column if earnings are associated.
Navigate to the Settlement page, and complete any additional fields as required.
Submit the claim for approval.
The following table describes the settlement methods and certain specific steps that you may need to complete based on the settlement method that you select.
Settlement Method | Claim Class | Additional Notes |
---|---|---|
On-account credit memo | Used to settle claims and deductions. | -NA- |
Check | Used to settle claims. | Post-approval: The claim information is interfaced to Oracle Payables. The Payables Invoice Import Program transfers the interface information into Oracle Payables to create an invoice. The Payables clerk issues checks against the invoice. The Claim Settlement Fetcher program updates the settlement documents with the check payment details. The claim is closed after the invoice is paid. |
Invoice-credit | Used to settle claims. | Notes:
Post-approval: The invoice credit memo is created and claim is closed under the following conditions:
|
Debit Memo | Used to settle debit claims and overpayments. | Post-approval: The claim details are interfaced to Oracle Receivables as debit memos. The Autoinvoice Import program transfers this information into Oracle Receivables. The Claims Settlement Fetcher program updates the settlement documents with the debit memo details and closes the claim. |
Previous Credit Memo | Used to settle transaction-related and non-transaction related deductions. | Notes:
Post-approval: The deduction is unapplied, and the previous open credit memo is applied to the receipt. The overpayment is closed online. |
Invoice Credit or Invoice Line Credit |
|
Notes:
Post-approval: The invoice credit memo is created and deduction is closed under the following conditions:
|
Invoice Tax Only Credit | Used to settle deductions that occurred because of tax calculation errors. The deductions can be transaction-related; they cannot be related to a promotion. | Notes:
Post-approval: The invoice credit memo is created and deduction is closed under the following conditions:
|
Chargeback | Used to settle deductions by charging back the customer in case you determine that the deductions are invalid. | Notes:
Post-approval: The chargeback is created online and the deduction is closed. |
Write-off | Used to settle a transaction-related deductions. | Notes:
Post-approval: The write-off is created online and the deduction is closed. |
Return Materials Authorization | When a customer returns a product, you can use the RMA settlement method in Oracle Channel Revenue Management to settle the deduction. When the return is processed and a credit memo is generated, Oracle Channel Revenue Management automatically tracks the credit memo and uses it to close the deduction. | Notes:
Post-approval: The RMA is created online. You must ensure return is interfaced to Oracle Receivables as a credit memo. The Claims Settlement Fetcher program updates the settlement documents with the credit memo details and closes the claim. |
Previous Debit Memo | Used to settle overpayments. | Notes:
Post-approval: The claim investigation for the overpayment is closed. The previous open debit memo is applied to the receipt and the overpayment is closed. |
Receipt Write-Off | Used to settle overpayments. | Notes:
Post-approval: The write-off is created online and the overpayment is closed. |
On-account Cash Application |
|
Notes:
Post-approval: The on account cash application is made online and the overpayment is closed. |
Oracle Channel Revenue Management integrates with the E-Business Tax engine to get a tax quote. This provides information to claim analysts about the tax calculated by either AR/AP. Tax quote is asked before the claim is submitted for settlement.
Oracle Channel Revenue Management integrates with the E-Business Tax Engine to facilitate the claim settlement process by providing tax estimates to claim users. When a claim user researches or settles a claim, the E-Business Tax engine fetches the estimated tax amount. The claim user can use this information to validate the accuracy of the claim.
The Oracle E-Business Tax engine call enables you to estimate the tax amount of your claim. The estimate enables you to validate your research and look for the right information knowing the tax impact of the resulting resolutions.
In Oracle Channel Revenue Management instead of the existing tax codes on the claim lines screen, there are tax classification codes defined in the Oracle E-Business Tax application. The tax classification code values are determined by whether a settlement method integrates with Accounts Receivable or Accounts Payable. Based on the business process of an organization, the claims submitted by customers may be either inclusive or exclusive of taxes. Deductions and overpayments are generally inclusive of taxes.
Note: The tax quote provided by the E-Business Tax engine is only an estimate, which the claim user can use to validate a claim. The actual tax amount is calculated from Oracle Receivables, Oracle Payables, or Order Management, depending on the settlement method.
Tax classification codes vary depending on their purpose, either Accounts Receivable or Accounts Payable. Tax codes are used for either:
Oracle Receivables: a tax classification code known as "Output" is derived from the "ZX_OUTPUT_TAX_CLASSIFICATION" (Order to Cash O2C) lookup type.
Oracle Payables: a tax classification code known as "Input" is derived from the "ZX_INPUT_TAX_CLASSIFICATION" Payment Flow (P2P) lookup type.
Tax Classification code varies depending on whether this settlement will go into an O2C flow or a P2P flow. Oracle Channel Revenue Management supports tax quote requests only for some settlement methods.
In Oracle Channel Revenue Management you can select whether you want to use the settlement method O2C or P2P to display either output or input taxes.
The following E-Business Tax error messages are displayed in Oracle Channel Revenue Management:
If you click the search icon for the tax classification code without selecting a settlement method or if you select an unsupported settlement method, the system displays the following error message:
“Tax Classification Code and Tax Actions are not available for this settlement method."
If you select an Action and click Go without selecting a settlement method, select an unsupported settlement method or if you do not select a tax classification code:
" Tax Action not applicable."
The Promotional Payments tab gives a summary of the accumulated promotional accruals for all the customers that your organization deals with. Promotional accruals are the accruals that are created when customers place orders against offers. These are the discounts that the customers are eligible to receive. Customers may claim these accruals either by submitting claims or taking deductions.
By using the Promotional Payments tab, you can:
Search for accruals that are related to a particular offer type.
Search for accruals that are related to direct sales or indirect sales.
Search for accruals by customer name, product category, and for a given date range.
Compare the current earned, paid, and balance amounts with the respective amounts in the previous year.
Create claims and initiate payment for selected customers.
The following table describes the columns that are displayed in the Promotional Payments page. All this information is displayed for each customer.
Column | Description |
---|---|
Earned | Total amount that the customer has earned. |
Paid | Total amount corresponding to the customer's claims that have been settled and paid. |
Balance | This is the amount that is payable to the customer. Balance = Earned - Paid. |
Open Claims | Total amount corresponding to the customer's claims that are still in the process of settlement. |
Last Year Same Period Earned | Total amount that the customer has earned in the same period in the previous year. |
Last Year Total Earned | Total amount that the customer has earned during the previous year. |
From the Promotional Payments tab, you can search for the total promotional accruals for all customers for specific criteria such as offer type, activity type, invoice number, channel of sales, product category, customer, start date, and end date.
To search for accruals, log in to Oracle Channel Revenue Management as Oracle Trade Management User.
As a prerequisite, customers and business transactions should exist.
Navigation: Claim > Promotional Payments.
Notes:
Search Region: Select values for the fields depending upon what you wish to search for. For example, to search for all the accruals related to all offers of a specific offer type, say Lump sum offers, select Lump sum from the Offer Type drop-down list. Click Go to display the list of claims that match the specified criteria.
Search Query to Filter Data in the Table Region: Enter a query to filter the search results and display them.
Promotional accruals are paid to customers through claims or deductions. When the payments are authorized, GL entries are created to reduce the accumulated promotional liabilities. Depending on the nature of the business, some customers may get paid more what they have accrued. The extra funds that are paid are know as unearned funds. This happens in cases where customers have long-term ongoing business deals with the manufacturer.
Depending on how Oracle Channel Revenue Management is implemented in your organization, and the Trade Profile settings for individual customers, you can pay customers more than what they have earned. You can track such payments so that customer balances are reflected accurately.
For example, a manufacturer creates a budget and gives an offer to a customer. The customer and the manufacturer have a long-term business relationship. The customer performs according to the offer terms and conditions, and accrues some earnings. The budget appears as follows:
Available | Committed | Utilized | Earned | Paid |
---|---|---|---|---|
$100,000 | $10,000 | $9,000 | $9,000 | 0 |
The customer knows that the offer is ending in a few days, and plans to book some more orders in the next few days before the offer ends, and anticipates to earn another $1,000. In the meantime, the customer sends payments to the manufacturer, and deducts a total of $10,000.
The claims user in the manufacturing organization gets this deduction of $10,000. Because of the long-term business relationship that the customer and the manufacturer have, the user decides to pay the customer. The budget looks as follows:
Available | Committed | Utilized | Earned | Paid |
---|---|---|---|---|
$100,000 | $10,000 | $9,000 | $9,000 | $10,000 |
The Administrator can set up thresholds for such payments. Thresholds may be in terms of amounts based on various factors including the customer's last year same period sales performance, earnings on a similar offer on similar products, or the current year-to-date sales. Thresholds may also be a percentage of payments above the earned funds. If claims are within the thresholds, then you can settle them like any other regular promotional claims.
If unearned payments exceed the threshold amount or percentage, then depending upon the implementation setups, they may require approval. If approval is required, then you cannot settle a claim until the approvers approve the request for unearned payments.
You can pay the customer for an offer that does not have any accruals by selecting the Ignore Payment Validations check box in the Create Offer page. All users can select this check box for draft offers. For an active offer, only an administrator can select or update this check box.
To claim an amount for an offer that has no earnings:
On the Create Offer page, create an offer and select the Ignore Payment Validations check box. You can also select this check box on the Update Offer page.
On the Claim Main page, create a claim:
In the Accrual Search region, search for an offer that has Yes in the Ignore Payment Validations column.
Click Go. A line is created in the Accruals and Adjustments for Customers region.
Enter the amount to associate with the offer.
To associate an amount with a product that does not have earnings, select Offer Type, select Item Type, and search for or enter Item in the Accrual Search region.
Click Request Approval to submit this claim.
Requests for unearned payments may require approval when the amount exceeds the threshold amount or percentage. If you are the approver according to the approval rules, then you will receive a workflow notification when there are requests for unearned payments. The claims user cannot settle the claim until you approve the request.
To approve requests for unearned payments, log into Oracle Channel Revenue Management as Oracle Trade Management Super User.
As a prerequisite, a request for unearned payments must have been submitted for approval.
Navigation: Workflow > Worklist or Home > Tools > View Notification Work List.
Notes: Select the notification that corresponds to the unearned payments that must be approved, and click Approve.
Autopay enables you to automate payments for promotional accruals. When autopay is set up, it automatically creates claims, associates claims with the customer's accruals, and settles the claims as designated (credit memo or check).
For example, you request your Administrator to set up autopay to issue a credit memo for promotional accruals to a customer every two weeks. Every two weeks, autopay checks the customer's accrual balance. The balance for this period is $100, 000 earned and $80,000 paid, leaving an outstanding balance of $20,000.
Autopay automatically creates a claim for the customer, associates it with the $20,000 balance, selects credit memo as the settlement method, and initiates the settlement process. The settlement process begins with claim approval and ends with the generation of a credit memo for $20,000 and closure of the claim. Because the customer knows that the organization issues a credit memo every two weeks, it is less likely that the customer will deduct from payments to your organization.
If Autopay is setup, before creating claims and making payments, it checks whether payments must be made according to the payout dates specified in the offer, or according to the dates and frequency set up in the regular Autopay schedule. It also checks if any payment methods and payment preference in terms of time have been specified in the offer, and makes payments accordingly.
If performance requirements have been specified for offers, Autopay creates and processes claims only for those offers for which performance has been verified. Performance proof may be in the form of electronic files, images or based on physical inspection of the retailer's premises. Upon verifying performance, you can update the performance flags in an offer. Where there are multiple performance criteria, Autopay processes payments for the offer only after you verify all the performance requirements.
Customers will be eligible for autopay depending if the Autopay option is checked in the individual Trade Profiles.
When you run autopay, claims are automatically created and associated with the customer's accruals. The claims are settled as designated (credit memo or check).
To run Autopay:
Log in with the Oracle Trade Management User responsibility.
Navigate to Claim, then Autopay.
Enter a request name.
Enter values for fields on the various subtabs.
Click Submit.
Prerequisites
Autopay must be implemented.
The Update Time Structure concurrent program must be run.
Parameters:
Operating Unit: This LOV contains all the operating units the user has access to.
Run Mode: The values available are:
All Offers: All the offers will be settled.
Offers with Autopay: Only those offers for which Autopay has been marked will be settled.
Offers without Autopay: Only those offers for which Autopay has not been marked will be settled.
Customer Name: Select a customer name for the autopay program to search for all the accruals for this customer account. Autopay creates a claim for unpaid funds and initiates the settlement process to pay the customer.
Relationship: The relationship type values are: All, Parent, and Reciprocal. Based on the relationship type a list of related customers and buying groups are displayed in the related customer and buying groups fields respectively. The relationship type is dependent on the customer name and is enabled after a customer name is specified.
Related Customer: Based on the relationship type select a related customer from the LOV. The related customer finds the accruals and pays them to the claiming customer.
Buying Group and Members: Based on the customer and the relationship, select a buying group. Though a relationship affects in finding the buying group, the buying group is not completely dependent on relationship. Buying group can be specified only for one customer. Since the accruals for a buying group is calculated, only one claim is created and paid.
Include All Member Earnings: The available values are Yes and No. If you select Yes, earnings of all the members of the buying group are considered for the claim.
Pay To: The available values are:
Customer: Claims are paid to the customer.
Related Customer: Claims are paid to the related customer.
Fund Name: Select a fund to search for all the accruals for this fund and group them by customer account that is, one claim per customer. This might result in creating multiple claims.
Activity Type: The Activity Type that you select determines the reason for which the claim is being settled. The available values are Offer and Price List.
Offer Type: Select the offer type to create claims.
Activity Name: Select an activity type that is either an offer or a price list.
Product Category: Select a product category and the corresponding accruals are considered to create claims.
Product: Select a product and the corresponding accruals are considered to create claims.
For Period: In the For Period field, specify the frequency to generate claims. The available values are Days, Months, Quarters, Weeks, and Year.
Value: The Value field is derived from the For Period field. For example, if the For Period parameter is selected as Weeks, all last dates of the week are displayed is the values LOV. Earnings for that week are selected for claim creation.
Start Date and End Date: Select the start and end dates to specify the date range for accrual payments.
Group By Offer: The available values are Yes and No. If you select Yes, the program creates one claim per offer.
The Autopay program can be set up at the System Parameters, Customer Trade Profile and Offer levels. For generating claims the autopay frequency is considered based on the selected parameter values, as follows:
If no parameters are specified or only the operating unit is specified, the System Parameter frequency is considered for creating claims.
If only customer name is specified, the Customer Trade Profile frequency is considered for creating claims.
If Activity Type is selected as Offer and Activity Name is selected as Offer Name, the offer frequency and frequency unit are considered for creating claims.
If Budget is selected, the offer frequency for offers funded from the budget is considered for creating claims.
If any of these parameters are selected: start date, end date, offer or activity name and product, offer and customer, or period type and period value, an off cycle claim for all open or unpaid accruals is created. A single claim is created for each period.
Every accrual with the GL date in the date range of a selected period is considered by the autopay program for payment.
After running Autopay, you can view the Autopay Request and the Autopay Log to know if there were any errors encountered in the process.
To view Autopay Request and Autopay Log, log in to Oracle Channel Revenue Management as Oracle Trade Management User.
As a prerequisite, an Autopay request must have been submitted.
Navigation: Claim > Autopay > View Request.
Notes:
Details: Displays the details or log of the request. The Request Details page gives you a summary of the request including the parameters that were set while running the request, notifications if any, and other details.
View Log: Displays the Autopay Log.
To create and settle claims from the Promotional Payments tab, log into Oracle Channel Revenue Management as Oracle Trade Management User.
You can create claims from the promotional payments tab in the following two ways:
By drilling down the Open Claims link against the customer for whom you would like to create the claim.
By clicking the Pay button.
As a prerequisite, existing customers and transactions should exist.
Navigation: Claim > Promotional Payments.
Notes:
Creating Claims:
Single Customer: To create claims for a single customer, click the link in the corresponding Open Claims column against the respective customer.
Multiple Customers: To create claims and initiate payments on a single screen for multiple customers, select the customers by checking the respective check boxes.
Initiating Payment
Pay: Click Pay. In the Earnings Payment page, you can find out from here details such as the payment frequency (Annual, Quarterly, monthly, and so on), Last Paid Date, and also find out whether the customers are eligible to receive payments or not.
Initiate Payment and Create Claim: Select the Initiate Payment option and Create Claim option to create claims and initiate payment.
Claims are created and workflow notifications are sent to the designated approvers. Payments are made after the requests are approved.
To view the claims that have been created, drill down the Open Claims link against the customer for whom you have created claims. All the existing claims and the new claims that you have created are listed here.
This business user flow describes how to use Oracle Channel Revenue Management to settle an offer-related claim with a check payment.
Oracle Channel Revenue Management must be fully implemented.
Integration with Oracle Payables must be set up.
The workflow background process with the parameter Claim Settlement must be running to close the claim.
The following concurrent programs must be running:
Payables Open Interface Import: to track the claim in Oracle Payables the same way all other payments through Oracle Payables are tracked
Claim Settlement Fetcher: to close the claim that you have prepared to settle
You, the manufacturer, wanted to promote a new shampoo. To do this, you created an accrual type offer for your customer, Goodway Stores. The offer stated that Goodway would receive 10% off all purchases of the new shampoo for a three month period. The 10% savings was accrued during that period. Goodway has now submitted a claim requesting payment for their accruals by check.
The following figure illustrates the Oracle Channel Revenue Management application process flow for settling a trade promotion claim by check payment.
Creating an Offer-related Claim and Settling it By Check Payment
Follow the steps in this section to complete this flow.
Step 1: Create a Claim
The claim you create for this flow will be related to an offer. However, customers can file claims for a variety of reasons including shipping errors or defective merchandise. In some cases, the reason may be unknown.
Procedure: create claims, create claim lines.
Step 2: Associate Earnings
In this step, the 10% accrual (also called "rebates" or "earnings") which you, the manufacturer, tracked for Goodway on its purchases of shampoo, will be associated to the claim. Associating the earnings to the claim means that the claim will be paying off these accruals. When you associate earnings, you associate an offer to a claim so that the claim is tied to the offer, and to the budget that is funding the offer. You can then view how much the customer has earned for the associated offer. In most cases, you will associate earnings for many offers rather than just one.
Step 3: Select the Check Payment Settlement Method
Now you will select a settlement method for the claim and submit it for approval.
Step 4: Import Invoices Into Oracle Payables
This is an interim stage for creating a check to Goodway for the 10% accrual it has earned. The purpose of this step is to track the claim in Oracle Payables the same way all other payments through Oracle Payables are tracked. You, the manufacturer, should have your Administrator automate this step. Log into Oracle Forms as ebusiness/welcome: Payables, Vision Operations (USA).
Navigation: Other > Requests > Run > Single Request.
Notes:
Name: Select Payables Open Interface Import
Source: CLAIMS
Navigate to View > Requests > All My Requests > View Output to view the output to confirm that the invoice was imported.
Step 5: Search Standard Invoice
This is a step performed by the manufacturer's accounts payable clerk. This is another interim stage for creating the check to Goodway. The purpose of this step is to validate the payment information before actually creating a check. The payables invoice created from the claim should indicate that the customer will be paid the amount you entered on the claim. You, the manufacturer, can ask your Administrator to automate this step.
Log into Oracle Payables as ebusiness/welcome. This user has Oracle Payables Super User responsibility.
Navigation: Invoices > Entry > Invoices.
Perform a query in the Invoice Number field using the claim number.
Press the F11 key.
Enter the claim number in the Invoice Number field.
Notice that additional information related to this claim is filled in automatically, for example supplier name, invoice amount, and invoice currency. Quickly check to make sure that the Distribution Total and the amount are the same. If they are not the same, you will not be able to complete this task.
Click Actions, and select Validate.
Click OK.
The invoice status changes from Never Validated to Validated. Changes are saved automatically.
Note: The concurrent program, Invoice Validation, can validate multiple invoices simultaneously.
Step 6: Create Check
This step shows how to create a check to pay the customer for the claim. The customer will be paid with the designated amount in Oracle Payables.
Navigation: Actions > Pay in Full.
Notes:
Bank Account: Select BofA.
Document: Select Check.
The Note window appears as the system reserves the check document. This prevents other users from generating duplicate checks.
Although the currency of this bank account is set to USD, by setting the Multiple Currency Payments flag to Yes, the system will allow you to create a check from this bank in another currency.
Save your work. Click Actions, select Format, and click OK to submit the Payment Process Manager.
Step 7: View Budget Utilization
The Claim Settlement Fetcher concurrent program imports the Oracle Payables information back into Oracle Channel Revenue Management, and closes the claim that you have prepared to settle. You can review the budget paid column to observe that the budget has been paid for the claim amount.
Log into Oracle HTML applications as trademgr/welcome.
Navigation: Budget > Budgets.
Notes:
Review the Budget you used to see that the claim has been paid. Optionally, click the Paid Amount link to verify that the Paid amount has been updated.
Step 8: View the Closed Claim
Review the claim that has been closed. This concludes the claim settlement process. The claim will be closed when the Claims Settlement Fetcher concurrent program is complete.
Navigation: Claim > Claims.
Notes:
Look for the claim you created and settled. Verify that the status has changed to Closed. The Claim Report shows the Receipt, Settlement, Vendor, Payment Detail, and other information.
Volume offers are created to encourage customers to buy high volumes of products. This business user flow describes how to create a Volume offer that has different discounts based on the amount of products purchased, and settle the related deduction through an on-account credit memo.
Oracle Channel Revenue Management must be fully implemented.
Integration with Oracle Receivables must be set up.
The workflow background process with the parameter AMS Marketing Generic Approvals must be running to initiate an approval notification to the Budget Approver to approve the budget.
The workflow background process with the parameter Claim Settlement must be running to close the claim.
The following concurrent programs must be running:
OM Order Line: to generate an invoice from an order that is created in Order Management
Pick Release Process: to pick and pack a sales order
Interface Trip Stop: to ship a sales order to the customer location
Funds Accrual Engine: to update the budget that is related to the offer and the order.
AutoInvoice: to validate and import records as completed transactions into Oracle Receivables
Claim Settlement Fetcher: to close the claim that you have prepared to settle
Important: The Administrator in your organization should automate these concurrent programs by scheduling them to run regularly.
Vision Industries wishes to encourage its customers to purchase a particular product in large quantities. The Sales Management assigns you the responsibility of working out a strategy to achieve this objective. You, the Sales Manager decide to create a Volume offer to encourage a particular customer--Goodway to buy the product in higher quantities. The discounts vary for a range of quantities of an item that is purchased. If Goodway purchases quantities in a higher range, they receive higher discounts. When Goodway reaches a higher sales level, they can get discounts even retroactive to the previous purchases.
You create a Volume offer to offer discounts to Goodway. You source funds for this offer from an existing budget. Goodway starts placing orders after the offer becomes active, and accrues discounts accordingly. Instead of submitting claims, Goodway takes a deduction for the amount that your organization owes them. You plan to settle these deductions by issuing on-account credit memos.
The following figure illustrates the process flow for creating a volume offer that has different discounts based on the amount of products purchased, and settling the related deduction through an on-account credit memo.
Volume Accrual Offer
Follow the steps in this section to complete this flow.
Step 1: Create Offer
As the first step, you create a Volume offer whereby Goodway receives discounts based on the quantity of products that they purchase. You can also enter the minimum quantity or amount within certain ranges that the customer must purchase to get the appropriate discount.
Step 2: Activate Offer
After creating the offer, you must activate it to make it available to be used. Discounts are applied each time the customer places an order.
Step 3: Create a Sales Order
After the offer is active, Goodway can start placing orders against the offer. Goodway places an order for three units of a product, and discounts are applied when orders are created in Order Management by the Order Management clerk.
Log into Order Management as ebusiness/welcome. This user has the Order Management Super User responsibility.
Navigation: Orders, Returns > Sales Orders > Order Information.
Notes:
Order Type: Select Mixed.
Line Items: Enter values as appropriate.
Adjustments: Use this option to create Promotion Pricing Attributes for Oracle Channel Revenue Management. Complete the following for a request only offer. For an automatic offer skip the step to view adjustments.
Click Adjustments, select Promotion/Pricing Attributes and click OK.
Select Promotion Number, click Apply, and click OK.
Navigate to Actions to view adjustments.
Save your work. Make a note of the Order Number, and click Book Order.
A message appears indicating that the order has been booked. The Order Header tab reappears and the status appears as Booked. The Pick Release Process picks and packs the sales order. The Interface Trip Stop program ships the sales order to the customer location. Shipping is mandatory for Volume offers.
Step 4: View Budget Utilization
The Funds Accrual Engine updates the budget related to the offer and the order. The utilized and the earned columns in the budget get updated according to the discounts that are offered against the orders that the customers have placed. The budget shows the utilized and earned amount based on the discount applied to the order, and the orders that are shipped. Optionally, click the amount under the Utilized column to view the order number.
Step 5: View Invoice for Order
The concurrent program OM Order Line automatically creates an invoice for the order. To view the invoice for the order, log into Oracle Receivables as ebusiness/welcome.
Navigation: Transactions > Transactions.
Notes:
Enter the Sales Order Number, and search for the invoice details. Note the invoice number. Click Line Items to verify the order lines.
Step 6: Create Receipt and a Non-invoice Related Deduction
Goodway takes a short payment (deduction) to claim the accrued discounts. You must create a receipt to record the payment and the short payment. The short payment creates a deduction claim. Based on the reason you select, the claim will be assigned to the appropriate person in Oracle Channel Revenue Management who owns the claim.
You must create a non-invoice related receipt and a short payment (receipt amount is less than the invoice amount). The short payment creates a deduction claim. Based on the reason you select, the claim will be assigned to the appropriate person in Oracle Channel Revenue Management who owns the claim.
Navigation: Receipts > Receipts Summary > New.
Notes:
Receipt: Enter a unique receipt number.
Receipt Amount: Enter an amount that is less than the invoice for which you wish to create a deduction.
Payment Method: Automatic Receipt.
Applications: Navigate to Applications and enter the following information:
Apply To: Select the required invoice number.
Amount Applied: Apply complete invoice balance.
Other information such as Trans Currency, Balance Due, Allocated Receipt Amount, Customer Number, GL Date, Apply Date, Class, and Type are automatically populated. Repeat this step for each invoice line that you have.
Create another line for Claim Investigation Activity by entering the following details:
Apply To: Claim Investigation.
Amount Applied: Apply amount of Invoice (Deduction Claim is created since receipt amount is less than invoice amount).
Activity: Claim Investigation Activity.
Reference Type: Oracle Trade Management Claim.
Save your work. Note down the Reference Number generated. This is the deduction number. The Deduction amount should be the sum of invoice amounts minus the Receipt Amount.
Step 7: View Claim or Deduction
Deductions are created in Oracle Receivables and can be viewed in Oracle Channel Revenue Management. To view the claim in Oracle Channel Revenue Management, log in to Oracle Channel Revenue Management.
Navigation: Claim > Claims.
Look for the claim or deduction generated in Receipts.
Step 8: Associate Earnings
Associate Earnings is used to associate an offer to the claim so that the claim can be tied to the offer and budget. After associating earnings, you can view how much Goodway has earned through the claims for the associated offer.
Step 9: Settle Claim
You wish to settle the claim with an on-account credit.
The following processes occur in the background:
The AutoInvoice program validates and imports records as completed transactions into Oracle Receivables. If there are any errors in the process, they are listed in the output report.
The Claims Settlement Fetcher concurrent program closes the claim that you have prepared to settle.
Step 10: View Closed Claim
You can review and check if the claim has been closed. This concludes the claim settlement process. The claim will be closed when the Claims Settlement Fetcher concurrent program is complete.
Navigation: Claim > Claims.
Notes:
Look for the claim that you created and settled. The Claim Report shows the Receipt, Settlement, Vendor, Payment Detail, and other information.
Step 11: View Paid Budget
You can optionally review the budget paid column to observe that the budget has been paid for the claim amount.
Log in to Oracle Channel Revenue Management.
Navigation: Budget > Budgets.
Notes:
Review the budget from which you have sourced funds for the offer and to settle the claim. Optionally, click Paid Amount to verify that the paid amount has been updated.
Step 12: Review Credit Memo
You can optionally review the generated credit memo. Make sure that the AutoInvoice Program running in the background for creating Credit Memos from claims has completed successfully before searching for the credit memo.
Log into Oracle Receivables as ebusiness/welcome.
Navigation: Transactions > Transactions.
Notes:
Search for the transaction number by entering the claim number. Click Line Items to review the lines.
The Claims module is critical in managing the payment of Scan Data offers because the actual scan data is entered through claims. When the actual values of Scan Data offers exceed the committed amount or forecast values, the claim automatically adjusts the Scan Data accruals as required, including the committed and earned funds.
The committed and earned amounts in Scan Data offers are adjusted depending upon the fund utilization. The different types of automatic adjustments are discussed in the following sections.
Funds are committed to offers during offer creation. However, the amount that is earned from the offer may be more than the committed amount. When the actual data is submitted, you create a claim with at least one claim line. You associate the earnings from the claim line to the Scan Data offer, and enter the actual data in the appropriate Scan Data offer field. For the increase in the earned amount, the GL entries--Debit Sales, and Credit Liabilities are created and the committed and earned amounts are updated to show the new values.
For example, assume that a Scan Data offer was created for an organization as follows:
Product | Forecast Total Scan Value |
---|---|
Product A | $100,000 |
Product B | $80,000 |
The committed amount for this offer was $180,000. At the time the offer is created, the following accounting entries are made:
Debit Sales or Expense (Product A) $100,000 Credit Liabilities (Product A) $100,000
Debit Sales or Expense (Product B) $80,000 Credit Liabilities (Product B) $80,000
The Offer Checkbook appears as follows:
Committed | Earned | Paid |
---|---|---|
$180,000 | $180,000 | 0 |
When the actual data is submitted, you create a claim with at least one claim line. You associate the earnings from the claim line to the scan data offer, and enter the actual data in the appropriate scan data offer field.
For this claim, the calculated actual units and values are as follows:
Product | Forecast Total Scan Value | Actual Total Scan Value |
---|---|---|
Product A | $100,000 | $120,000 |
Product B | $80,000 | $90,000 |
These numbers represent a $30,000 increase to both the committed and earned amounts. The following GL entries are created to account for the increase in the earned amount:
Debit Sales or Expenses (Product A) $20,000 Credit Liabilities (Product A) $20,000
Debit Sales or Expenses (Product B) $10,000 Credit Liabilities (Product B) $10,000
When the claim is settled, automatic adjustments are made to the committed and earned amounts. The Offer Checkbook looks as follows:
Committed | Earned | Paid |
---|---|---|
$210,000 | $210,000 | $210,000 |
The forecasted values for Scan Data offers may be less than the committed values. When the actual fund utilization of a Scan Data offer exceeds the forecasted values, the claim automatically adjusts earned funds.
For example, assume that the following Scan Data offer has been created:
Product | Forecast Total Scan Value |
---|---|
Product A | $100,000 |
Product B | $80,000 |
The committed amount for this offer was $200,000, whereas the forecasted total us $180,000. The Offer Checkbook looks as follows:
Committed | Earned | Paid |
---|---|---|
$200,000 | $180,000 | 0 |
When the actual data is submitted, you enter the data in a claim. The calculated actual units and values are as follows:
Product | Forecast Total Scan Value | Actual Total Scan Value |
---|---|---|
Product A | $100,000 | $110,000 |
Product B | $80,000 | $85,000 |
This data represents no change in the committed amount, and an increase of the earned amount by $15,000. GL postings are created for the $15,000. When the claim is settled, an automatic adjustment is made to the earned amount, and the Offer Checkbook looks as follows:
Committed | Earned | Paid |
---|---|---|
$200,000 | $195,000 | $195,000 |
The fund earnings in a Scan Data offer may be less than the committed and forecasted amount. In such cases, when you create a claim, no adjustments are made to the committed and earned amounts. More data for the offer can be submitted at a later date. In cases where there is true under earnings, adjustments are made only if the Sales Management determines that no more actual data is expected and closes the offer. If this occurs, then you can reconcile the budget.
For example, assume that the following scan data offer has been created:
Product | Forecast Total Scan Value |
---|---|
Product A | $100,000 |
Product B | $80,000 |
The committed amount for this offer is $200,000. The Offer Checkbook appears as follows:
Committed | Earned | Paid |
---|---|---|
$200,000 | $180,000 | 0 |
When actual data is submitted, you enter the data in a claim. The calculated actual units and values are:
Product | Forecast Total Scan Value | Actual Total Scan Value |
---|---|---|
Product A | $100,000 | $70,000 |
Product B | $80,000 | $40,000 |
This data represents no change to the committed and earned amounts. No GL entries are created because no adjustments are required. When the claim is settled, the Offer Checkbook looks as follows:
Committed | Earned | Paid |
---|---|---|
$200,000 | $180,000 | $110,000 |
Sometimes you may want to settle claims for accounts that are related to the customer. Related Customer accounts are set up with relationships; common relationships include bill-to and ship-to.
To settle claims for related customer accounts, log in to Oracle Channel Revenue Management as Oracle Trade Management User.
As a prerequisite, a claim with a status of Open or Complete should exist.
Navigation: From the Claim tab, click the Claims subtab, then the claim. In the Claim Main page, click the Additional Links subtab, and then click the Settlement link.
Notes:
Pay Related Customer: Select this check box. Select the Relationship Type (parent, reciprocal, or all), the Related Customer, and the Related Site.
Submit the claim for approval.
Buying groups are formed when organizations group themselves to leverage their buying power. During claim settlement, you can view the buying group member accruals and decide whether to issue payment to the buying group, or directly to one of its members.
To settle promotional claims for buying groups, log in to Oracle Channel Revenue Management as Oracle Trade Management User.
Prerequisites:
Buying groups and members must be set up.
A promotional claim for a buying group with a status of Open or Complete.
Navigation: From the Claim tab, click the Claims subtab, then the claim. In the Claim Main page, click the Promotional subtab, and then expand Accrual Search.
Notes:
Buying Group: The values that are available depend upon where the customer is in the buying group hierarchy.
Display Children: The accruals for the buying group members are displayed.
After associating earnings, navigate to Settlement.
Submit the claim for approval.
In B2B businesses, manufacturers and retailers have complex ongoing business transactions. Sometimes when the customers make payments, it may be difficult to know the exact reason for which they are making the payment. In some cases, such as when the transaction number is wrong, overpayments may be created.
When these overpayments are investigated, you may find that the overpaid amounts were meant to pay back for some transactions (debit items). The Mass Settlement function enables you to apply the overpaid amounts to such debit items.
For example, a customer receives an Invoice with the number 100080. However, the remittance amount refers to the invoice as 10008O (letter o instead of number 0). When your organization receives this payment, this invoice number will not be identified in Oracle Receivables, and therefore an overpayment will be created. You then realize that the invoice has been incorrectly entered as 10008O instead of 100080. You can settle the overpayment claim by applying the "overpaid" amount to the debit item 100080.
During netting, the overpayments can be applied only up to the balance of the item.
You cannot use the Mass Settlement function to settle deductions with associated earnings.
The Mass Settlement functionality enables you to create groups out of overpayments and deductions related to a customer, apply them to the customer's open transactions, and settle the overpayments and deductions on one screen. You can also specify multiple payment methods.
After netting a claim with the debit items, transactions, or other Oracle Receivables items, there may still be some remaining amount that must be settled.
For example, a customer may deduct for returns. During investigation, you may find that multiple credit memos have already been issued as a result of the RMAs that have been entered in Order Management. You can close the deduction by netting the credit memos to the deduction. However, there may still be some balance amount.
If the balance is an overpayment balance, then you can settle it through credit- on account, or write-off. If the balance is a deduction balance, then you can settle it through chargeback, or write-off.
You can perform netting and settling of balances at different times depending on how you investigate or how long it takes you to investigate the claim. The netted amount must however be approved by the designated approvers, according to the setups in your organization.
To net overpayments log in to Oracle Channel Revenue Management as Oracle Trade Management User, and use the following high-level procedure.
Navigation: Claim > Mass Settlement > Create.
Notes:
Search Region: In the Search region, select the customer for whom you would like to net the overpayments. Search for Open Claims by selecting the Claim Type, Reason, Source Object Number, Receipt Number, or the Claim Number.
Open Transactions: Search for Open Transactions by selecting the Batch Source, Transaction Class, Transaction Type, and Transaction Number.
All the open transactions that match with the selected attributes are listed in the Open Transactions region. Sometimes, when you search for open transactions, the list of invoices may appear. You can display open transactions such as debit memos by further conducting a search.
Open Claims Region: Select the transactions that you would like to settle.
When you select an open claim, the amount field gets populated with the amount that must be settled. You can also enter a partial amount from the transaction. For example, the remaining amount from a deduction may be $1000, but you can choose to settle only $600.
Calculate: Select this option:
After selecting the transaction lines and amounts that must be settled, select this option to calculate the sub total of the open claims that you have selected for settlement.
After selecting the transaction or debit item in the Open Transactions field. These are the debit items with which you will settle the claims. This calculates the sub total for the open transactions as well as the net amount of the settlement group. It is the sub total of open claims minus the sub total of open transactions. If there is any remaining amount, the amount must be split during settlement.
Settlement Region: In the Settlement region, you can either settle the entire amount, or split the amount and choose different settlement methods.
You can perform mass settlement of claims through asynchronous and synchronous methods from the Mass Settlement UI. Whether the mass settlement process proceeds synchronously or asynchronously is determined by the profile option OZF: Number of Claims for Asynchronous Mass Settlement. If the value of the profile option is null, then the mass settlement is processed synchronously. If the profile option value is a number, then:
If the number of claims to process is less than the value of the profile option, mass settlement is processed synchronously.
If the number of claims to process is greater than the value of the profile option, mass settlement is processed asynchronously.
When the Claims Mass Settlement program is submitted but the process is not yet complete, the Group Claim summary page shows group claim status as pending, individual claims status in the group as complete, and remaining amounts of the claims as zero.
If the concurrent program runs successfully, then the group and individual claims are closed. If partial claim amounts are selected for mass settlement, then split claims are created.
If the concurrent program ends in error, then the Group Claim summary page shows the group claim as rejected and the individual and split claims as open.
If you terminate the concurrent program, then the group claim remains pending and individual claims in the group claim are completed. You can then reinitiate the concurrent program from the Mass Settlement Detail page by clicking Reinitiate Mass Settlement.
To settle claims with debit or credit transactions that belong to unrelated customers, enable the Oracle Receivables system option Allow Payment of Unrelated Transaction and set the profile option OZF: Allow Netting of Unrelated Customer Transactions to Yes. Use the public API OZF_CLAIM_PUB.Settle_Mass_Settlement for mass settlement of unrelated customer transactions.
When customers make subsequent payments for a single invoice, then the original deduction is updated based on the subsequent payments received. However, the manner in which the deduction gets updated depends on the following criteria.
Whether the deduction is based on a claim and can be traced back to a transaction
If it is a direct deduction from a payment
If the original deduction was split or not split
The status of the deduction
Transaction-related deductions can be traced back to an invoice, order, or an offer. If a previous deduction exists for the transaction and is not split, then the process will be different depending on the status of the previous deduction. The manner in which subsequent payments are processed during different statuses of the original claim is as follows:
Open
When the claim or deduction status is open, the remaining amount in the deduction is reduced by the subsequent receipt amount. The corresponding disputed amount on the transaction is also reduced.
For example, an invoice is created for $500. The customer initially pays $350. This creates a deduction for $150 in Oracle Channel Revenue Management. The customer then pays $100 towards the same invoice, and the status of the original deduction is Open. Now, the original deduction that was created for $150 gets updated accordingly and shows $50 ($150 - $100) as the deduction amount. This means that the customer owes only $50.
When the remaining amount in the deduction is reduced to zero, the status changes to Cancelled. Even if the subsequent payments made by the customer sum up to more than the invoice amount, the deduction will not be converted into an overpayment because the status changes to Cancelled as soon as the deduction amount is reduced to zero.
Complete
If subsequent payments are received when the status of the original deduction is Complete, then the status of the deduction changes from Complete to Open. After the status changes to Open, the remaining amount in the deduction is reduced by the subsequent receipt amount. The corresponding disputed amount on the transaction is also reduced. When the remaining amount in the deduction is reduced to zero, the status changes to Cancelled.
Rejected
If subsequent payments are received when the status of the original deduction is Rejected, then the status of the deduction changes from Rejected to Open. After the status changes to Open, the remaining amount in the deduction is reduced by the subsequent receipt amount. The corresponding disputed amount on the transaction is also reduced. When the remaining amount in the deduction is reduced to zero, the status changes to Cancelled.
When the claim is resubmitted for approval and the settlement is restarted, the current amount and details of the claim are used to find the appropriate approvers.
For example, the original deduction was for $10,000. It was sent to the Director for approval, and was rejected. The claim status changes to Rejected. A subsequent receipt amount is later applied to the deduction. The claim status changes from Rejected to Open, and the deduction amount reduces to $8000. The claims user restarts the approval and settlement process. Based on the fact that the deduction is now only $8000, it requires a lower level of approval and is only sent to the Manager for approval instead of the Director.
Pending Approval or Approved
If subsequent payments are received when the status of the original deduction is Pending Approval, then the status of the deduction changes from Pending Approval to Open. If the payments are received when the status is Approved, the status changes from Approved to Open. After the status changes to Open, the remaining amount in the deduction is reduced by the subsequent receipt amount. The corresponding disputed amount on the transaction is also reduced. When the remaining amount in the deduction is reduced to zero, the status changes to Cancelled.
When the claim is resubmitted for approval and the settlement is restarted, the current amount and details of the claim are used to find the appropriate approvers.
If any approver has already approved the deduction before this happens, these approvers receive notifications.
Pending Close
The original deduction is not updated when the status of the deduction is Pending Approval. This is because when the claim status is Pending Close, it means that the deduction has already been approved, and is currently undergoing the settlement process
For example, a credit memo may already have been generated through the AutoInvoice program. In such cases, if a subsequent receipt is applied to the original transaction, the customer will be over credited.
Closed or Cancelled
The original deduction is not updated when the status of the deduction is Closed or Cancelled.
When the status of the original claim changes to Open (in cases where the status is Complete, Rejected, Pending Approval, or Approved), the re-open flag is checked to inform users that due to some changes to the transaction and deduction balance, the claim status has been modified. This enables users to know that the claim details have changed since the last time they worked on it.
Every time a customer makes subsequent payments, the claim owner receives a workflow notification. You can drill down back to the Claim Details page by clicking the claim number in the notification. The deduction keeps an audit trail of all receipts affecting it at any point of time.
If a previous deduction exists for a transaction and has been split, the original deduction or root deduction, which is still referenced in Oracle Receivables and the child deductions, which are not referenced in Oracle Receivables but maintained in Channel Revenue Management) may be at various statuses. Therefore, when subsequent receipts are received for a deduction that has been split, the balances of multiple deductions may need to be reduced. The manner in which these child deductions get processed will be determined by their statuses. However, the sequence in which the amount will be reduced will be prioritized based on status as follows:
Open
Complete
Rejected
Pending Approval
Approved
In the following example, the root deduction has not been completely split out and is still in Open status.
Receipt 1. A root deduction DED1 of $10,000 is created, originally of unknown reason, was found to be due to different causes upon investigations, and was therefore split into multiple child deductions.
Deduction | Claim Reason | Remaining Amount | Status |
---|---|---|---|
DED 1 | Unknown | $2,000 | Open |
DED 1_1 | Shipping | $5,000 | Pending Close |
DED 1_2 | Promotions | $2,500 | Pending Approval |
DED 1_3 | Pricing Errors | $500 | Open |
Receipt 2. After the deduction was created and split, subsequently, another receipt is applied on the transaction for $3,000. Based on the status prioritization, therefore, it will only reduce the balances for the following deductions in the following order:
DED1
DED 1_3
DED 1_2
The balances in each of the deductions is reduced as follows. The claim status changes accordingly.
Deduction | Claim Reason | Remaining Amount | Status |
---|---|---|---|
DED 1 | Unknown | $0 | Cancelled |
DED 1_1 | Shipping | $5,000 | Pending Close |
DED 1_2 | Promotions | $2,000 | Open |
DED 1_3 | Pricing Errors | $0 | Cancelled |
Receipt 3. Another receipt for $1,000 comes in and is applied on the transaction. Now only DED1_2 will be updated.
Deduction | Claim Reason | Remaining Amount | Status |
---|---|---|---|
DED 1 | Unknown | $0 | Cancelled |
DED 1_1 | Shipping | $5,000 | Pending Close |
DED 1_2 | Promotions | $1,000 | Open |
DED 1_3 | Pricing Errors | $0 | Cancelled |
If there are no more subsequent receipts, DED 1_2 will be processed further and will be submitted for approval. The status changes along with the approval flow. No subsequent receipts can be applied after the status changes to Pending Close.
Non-transaction related deductions are those which cannot be traced back to a transaction. Non-transaction related deductions occur when instead of submitting claims, customers deduct money from their payments to manufacturers. In case of a non-transaction related deduction, all the information such as the receipt number, receipt date, receipt amount, customer information and transaction information is captured from Oracle Receivables and passed to Oracle Channel Revenue Management. Customer debit memo numbers and claim reasons may also be passed to Oracle Channel Revenue Management. Deductions support related customer accounts and buying group promotions. Non-transaction related deductions are created in Oracle Receivables.
Prerequisites
A deduction that can be traced back to a specific transaction.
Steps
Note: As part of the cash application process, the Oracle Receivables user may need to perform additional data entry tasks. These steps present only one way to enter a non-transaction related deduction. See the Oracle Receivables User Guide for information on the different ways of entering non-transaction deductions.
Log in to Oracle Receivables as Oracle Receivables user and navigate to Receipts > Receipts.
Enter a Receipt Number. If necessary, change the Receipt Type to Cash, and change the Currency Code.
The receipt number can be the customer check number or other reference number.
Enter a Receipt Amount. If necessary, change the Receipt Date and the GL date.
Receipt amount is the amount the customer has paid.
Select a Payment Method.
Enter the Customer Name, and optionally enter a Reference and enter Comments.
This information is passed to Oracle Channel Revenue Management when the deduction is created.
Click Applications.
Select Claim Investigation in the Apply To field.
The available values are open transactions and some seeded Oracle Receivables activities. Claim Investigation is seeded specifically to create non-transaction related deductions (or overpayments) in Oracle Channel Revenue Management. If the customer has referenced an internal debit memo number, you can record this as a Claim Investigation line and enter the debit memo number in the customer reference field.
Enter the deduction amount as a negative number in the Amount Applied field.
If necessary, select Oracle Channel Revenue Management Claim in the Reference Type field.
Select a reason in the Reference Reason field.
The values available here are the same values that are available in Oracle Channel Revenue Management. If a customer indicates the reason for which they have made the deduction, this information can be captured when the cash application is created in Oracle Receivables, and be passed to Oracle Channel Revenue Management.
Enter a Customer Reference.
If the customer indicates an internal debit memo number, it can be captured here and passed to Oracle Channel Revenue Management.
Select an Activity.
The activity selected here drives the GL entries to account for the discrepancy between the cash received and the receivables amount. For example, Receipt = $10,000; Total balance of multiple invoices that the customer is paying for is $15,000.
A non-transaction related deduction is created for $5,000. The following accounting entries are created:
Debit Cash $10,000.
Debit Claim Investigation Activity $5,000.
Credit Receivables $15,000.
Click Save.
Notice that a deduction number appears in the Reference Number field.
This business user flow describes how to create a non-invoice deduction, close the claim through auto-resolution, and settle it by invoice credit.
Oracle Channel Revenue Management must be fully implemented.
Integration with Oracle Receivables must be set up.
Goodway had placed an order for a particular product. You, the manufacturer, had shipped the products, but the shipment got delayed by many days due to bad weather conditions. Because of the delay in shipment, Goodway was not able to honor the requirements of end customers and therefore suffered losses. To claim compensation for these losses, Goodway takes a deduction from the payments.
You now have to create a non-invoice deduction, ensure that the orders and invoices related to the claim are valid, and automatically settle the deduction claim.
The following figure illustrates the process flow for deduction to auto-resolution for a non-invoice deduction, starting from creating a receipt to reviewing the Oracle Receivables receipt.
Deduction to Auto-resolution for Non-invoice Deduction
Step 1: Create Receipt and Non-Invoice Related Deduction
You must create a non-invoice related receipt and a short payment (receipt amount is less than the invoice amount). The short payment creates a deduction claim. Based on the reason you select, the claim will be assigned to the appropriate person in Oracle Channel Revenue Management who owns the claim.
Navigation: Receipts > Receipts Summary > New.
Notes:
Receipt Amount: Enter an amount that is less than the invoice for which you wish to create a deduction.
Payment Method: Select Automatic Receipt.
Status: Select Confirmed.
Applications: Navigate to applications and enter the following details:
Apply To: Select invoice number.
Amount Applied: Apply complete invoice balance.
Other information such as Trans Currency, Balance Due, Allocated Receipt Amount, Customer Number, GL Date, Apply Date, Class, and Type are automatically populated. Repeat this step for each invoice line that you have.
Create another line for Claim Investigation Activity with the following details:
Apply To: Select Claim Investigation.
Amount Applied: Apply amount of Invoice (Deduction Claim is created since receipt amount is less than invoice amount).
Activity: Select Claim Investigation Activity.
Reference Type: Select Oracle Trade Management Claim.
An example of the Receipt applied to invoices is shown below:
A receipt of $800 has been received and this must be applied to 2 invoices in full. The invoice amount of the first invoice is $1062.50 and invoice amount for the second invoice is $531.25. So the claim investigation amount is $800 - $1062.50 - $531.25 = $793.75. The difference between the total amount of the invoice and the original receipt amount is the amount that is used for deduction (unresolved claim).
Apply To | Amount Applied | Balance | Deduction Amount | Activity | Reference Type | Reference Reason |
---|---|---|---|---|---|---|
Invoice 1 | $1,062.50 (Including Tax) | 0 | -NA- | -NA- | -NA- | -NA- |
Invoice 2 | $531.25 (Including Tax) | 0 | -NA- | -NA- | -NA- | -NA- |
Claim Investigation | $793.75 | -NA- | $793.75 Shows negative in Oracle Receivables Shows positive in Oracle Channel Revenue Management |
Claim Investigation Activity | Oracle Trade Management Claim | Unknown |
Save your work. Note down the Reference Number generated. This is the deduction number. The Deduction amount should be the sum of invoice amounts minus the Receipt Amount.
Step 2: View Deduction
Deductions are created in Oracle Receivables and can be viewed in Oracle Channel Revenue Management. To view a claim or deduction in Oracle Channel Revenue Management, log in to Oracle Channel Revenue Management.
Navigation: Claim > Claims.
Look for the claim or deduction generated in Receipts.
Step 3: Settle Claim with AutoResolution by Issuing a Credit Memo
You decide to choose autoresolution to automatically close the claim, and choose the settlement method as credit memo. After this step is complete, the claim gets closed automatically. Procedure: Settling a Claim with an On-account credit memo.
Step 4: View Closed Claim
You can review the claim that has been closed. This concludes the claim settlement process. For auto-resolution claims, you do not have to run the AMS-TM: Claims Settlement Fetcher concurrent program.
Navigation: Claim > Claims.
Notes:
Look for the Claim you created and settled. The Claim Report shows the Receipt, Settlement, Vendor, Payment Detail, and other information.
Step 5: Review Oracle Receivables Receipt
You can review the Oracle Receivables Receipt that has been created. Note that the Receipt On-account Credit line has replaced the Claim Investigation line earlier. The deduction amount or short payment that was recorded in Oracle Receivables will be updated with the amount that is issued in the form of on-account credit. Log into Oracle Receivables as ebusiness/welcome.
Navigation: Receipt > Receipts.
Notes:
Search for the receipt. Navigate to Applications. Note that the on-account credit has replaced the claim investigation line earlier because the overpayment is settled. The on-account credit is a cash application line that can be used for the customer later on.
When customers submit claims or take deductions, they may charge more than what they are supposed to claim or deduct. But the differences in the amount may be so small that it may not be worth spending time and resources to research them. You can decide not to spend time on researching the claim, and settle it with a write-off. When you settle claims with a write-off, it means that your organization is absorbing these costs as expenses.
Automatic write-off enables you to automatically identify claims, deductions, or overpayments that are eligible for write-off. The Administrator sets threshold limits for deductions as well as overpayments. Whenever a customer deducts or overpays, if the claim amount falls within the threshold limits, then the claims are automatically checked for automatic write-off. If required, you can manually uncheck these claims and investigate them, or settle them later.
For example, a manufacturer creates an automatic write-off threshold for $200. Claims with differences of less than $200 are checked automatically for write-off. The claims manager reviews these claims and notices that a particular customer has massive deductions slightly below the threshold, and unchecks these claims for automatic write-off to investigate them.
Claims that are originally over the threshold limit, but for various reasons have their amounts reduced, will not be automatically checked for write-off. Even if you manually check such claims, they are still treated as claims over the thresholds, and they require approval. Claims that are originally over the threshold limit, but have been split later on to smaller pieces, are still treated as claims over the threshold limit.
For example, in an organization, the write-off threshold for deduction is $200. A deduction comes in for $300. This deduction is then split into $100, $150 and $50. These split deductions are still treated as over the threshold limit. You can manually check these claims for automatic write-off, but they require approval.
The process of settling claims through write-off depends upon the type of claim or deduction.
Transaction related deductions
A write-off adjustment is created in Oracle Receivables. The disputed amount on the transaction is reduced and the claim is closed.
Non-transaction related deductions
A negative write-off line is created in Oracle Receivables. The claim is closed in Oracle Channel Revenue Management.
Overpayments
A positive write-off line is created in Oracle Receivables. The claim is closed in Oracle Channel Revenue Management After the claim is settled, the auto write-off check box will be read-only.
Special cases
After you uncheck claims that are under the thresholds, they will not be automatically checked again. You may however manually recheck these claims for automatic write-off as long as the claim status is Open. These claims are treated as claims that are under the threshold limits. After investigation, if you wish to still settle the claim with a write-off, then you must settle the claim through the claim settlement page.
When a claim is settled through a write-off, the expenses may need to be absorbed by different departments. On the claim settlement page, you can select the department to which a claim belongs to and the write-off amount is posted to the specified GL account.
To view claims that are eligible for automatic write-off, and manually update the write-off flag against these claims, log in to Oracle Channel Revenue Management as Oracle Trade Management User.
As a prerequisite, claims must exist.
Navigation: Claim > Claims > Personalize.
Notes:
Available Column: Move the Write-off Flag to the Displayed Column.
Save Search As: Enter a name for the search.
After you save the search, the Claims page appears. Claims that are eligible for automatic write-off are marked. Optionally, you can select claims and then select Write Off from the Actions drop-down list.
Note: You can update the write-off flags only for claims that are in the Open status.
There are various claim settlement methods that are available in Oracle Channel Revenue Management. The settlement method that you can use depends upon the claim type. The following table describes the various settlement methods that are available in Oracle Channel Revenue Management.
Note: When a claim is not related to any promotions, and you wish to settle the claim with a credit memo or a debit memo, you can use memo lines to settle the claim. See About Standard Memo Lines for more information.
Navigation: Channel Revenue Management: Administration > Claim > Claim Source Setup > Available Settlements Methods
Settlement Method | Description |
---|---|
Check | Claim is settled by issuing a check to the customer. |
Invoice credit memo | Invoice credit memos reduce a customer's invoice balance to settle a valid deduction. |
On-account credit memo | On-account credit memos reduce a customer's account balance to settle a valid deduction. |
Previous on-account credit memo | Previous on-account credit memo is an on-account credit memo that exists in Oracle Receivables, and is still open. If there is an existing credit memo, then you need not create a new credit memo. You can instead select the existing credit memo to reduce a customer's balance and settle a valid deduction. |
Write-off | Write-off enables you to settle valid deductions and overpayments. You can write off deductions if they are so small that it is not worth to spend time and resources to research them. When you settle a deduction with a write-off, it means that your organization is absorbing the claim amount or deduction as an expense. On the other hand, you can settle an overpayment with a write-off, when the overpayment is significantly small. In this case, customers will lose the amount that they have overpaid. |
Return Material Authorization (RMA) | RMA is issued to handle valid product returns (damaged goods, faulty equipment, and so on). When you create an RMA, a credit memo is generated to settle the deduction. |
AR-AP Netting (formerly Contra Charge) | The AR-AP Netting settlement method is available for deduction and overpayment. When selected for settlement, it sends out a workflow notification to users with a Netting responsibility to notify them to manually run the netting batch process. |
Previous Open Credit Memo Settlement | This settlement method is available on claims and deductions When you use this settlement method, the previous open credit memo field will become mandatory. Although the field itself is not indicated as a mandatory field (marked with '*') on the screen, the validation is triggered when you settle the claim with the previous open credit memo settlement method. |
Previous Open Debit Memo Settlement | This settlement method is available on debit claims and overpayments. When you use this settlement method, the previous open credit memo field will become mandatory. Although the field itself is not indicated as a mandatory field (marked with '*') on the screen, the validation is triggered when you settle the claim with the previous open credit memo settlement method. |
Configurable Settlement Method for Autopay | Autopay enables automatic payments for accruals. When autopay is set up and runs, the system automatically creates claims, associates with accruals, and settles them with the payment method set up in Trade Profile. In Trade Profile, companies can set up a custom settlement for autopay claims. This function is useful when Channel Revenue Management is implemented stand-alone and payments need to be routed to third party systems. |
Wire Transfer | When a claim is settled with a wire transfer settlement method, the invoice generated in Payables displays payment method of 'Wire'. |
Electronic Transfer | Electronic transfer refers to electronic fund transfer and is a payment method used in Payables to compensate suppliers/vendors. This new settlement method is similar to the existing check settlement method. When a claim is settled with an electronic transfer settlement method, the invoice generated in Payables displays a payment method of 'Electronic' |
Accounts Default Payment | A payment method can be associated with every supplier site. The payment method specified on the supplier site suggests the payment preference and can be used to default a payment method on the invoices generated for the supplier. The payment method associated with the supplier can be check, clearing, electronic, or wire. The accounts default payment allows the system to decide, based on the payment preferences setup on supplier site, what the default payment method for invoices interfaced in Accounts Payable should be. Details include :
|
Configurable Settlement Enhancements - Configurable settlement workflow allows companies to create custom settlement methods in addition to the seeded methods. You can settle promotional claims with the custom settlement method.
When a claim or deduction is not related to any promotions, and upon validations, you wish to settle it with a credit memo or debit memo, Oracle Channel Revenue Management integrates with Oracle Receivables to account these transactions. The Autoinvoice program in Oracle Receivables depends on the autoaccounting setups to find the correct GL accounts.
Standard memo lines are commonly used by companies in auto-accounting setups for items which are not part of their normal inventory. You can pass a memo line to Oracle Receivables, thereby enabling the auto accounting setups. Memo lines can be used when you settle claims with either a credit memo or a debit memo. Standard Memo Lines can be an input into autoaccounting in Oracle Receivables to account for freight, revenue, autoinvoice clearing, tax, unbilled receivable, and unearned revenue.
To settle claim or a deduction with a standard memo line, you must select "Memo Lines" from the setup type drop-down list in the Claim Creation page. You can view the list of all the active memo lines that have been created for the operating unit of the claim. After you select a particular memo line, the other fields on the same claim line will be affected:
If the memo line was set up with any Unit List Price, the price will default into the Price field on the claim line. You can override this.
The "Line/Product" LOV becomes blank.
You can still access Associate Earnings from this claim line, but if earnings have been associated, then the memo line information is replaced by the associated earnings information. For example, the claim line may show the inventory item number instead of the memo line.
Validation
The validation process for standard memo lines includes the following:
Validation of Associate Earnings
Where standard lines are used in Autoaccounting setups for the revenue account the following may occur:
If the "Post to GL" flag is checked in System Parameters, and a claim line has associated earnings, then the Oracle Receivables Clearing account from the Claim Type or System Parameters will be passed to Oracle Receivables as the "Revenue" account when the credit memo and debit memo are created through Autoinvoice. Memo lines are not used or passed in such cases.
If the "Post to GL" flag is not checked in System Parameters, but a claim line has associated earnings, then the claim line references an inventory item. If not, the system gives an error message.
Validation of Autoaccounting Setup
From Auto accounting setups, if the memo line is used to derive the revenue account, then when you initiate claim settlement by submitting it for approval, each of the claim lines are validated to check if either an inventory item or a memo line has been selected. If any of the claim lines does not contain either of these, the system gives an error message.