This chapter covers the following topics:
Customers may submit claims to submit overpayments, compensation for damaged goods, or promotional accruals. Other situations involve customers taking illegal deductions, or paying more than what they owe your organization. You can create different types of claims based on the nature of claims that must be settled.
When a claim is created, all the information necessary to process the claim is recorded. This information includes the claim type, reason for the claim, customer information, contact information, broker and sales representative details, the amount, and currency type.
The Mass Create functionality enables you to create multiple claims and debit claims on one screen. You can import claims based on data from legacy or third party systems by using Import Interface. You can also create claims and debit claims from any system by using a Public API. Claims can be imported from a legacy system either through claims import or through the claims API.
To create claims, you must understand the different claim types, classes, reasons, claim lines, and customer-reason code mapping.
Claim, Debit claim, Deduction, and Overpayment are the four different claim classes that are available in Oracle Channel Revenue Management. The settlement methods and processing is different for each claim class.
Claim
Customers may submit reimbursement requests for a number of reasons such as to claim compensation for damaged goods or payment for services. Claims are created in Oracle Channel Revenue Management to handle these reimbursement requests. Claims may or may not be promotion-related. Promotion-related claims have promotional earnings (accruals) associated with them. You can view this in the Promotional subtab of the Claim Main page. The settlement methods for claims include check, credit memo, or Return Materials Authorization (RMA).
Debit Claim
Debit claims are created in Oracle Channel Revenue Management to charge back customers who have been overpaid. Debit claims are settled through debit memos.
For example, a customer earns $10,000; you issue a check for that amount. Later on, the same customer returns $1,000 worth of merchandise from a previous order, thus decreasing the true accrual to $9,000. To handle this situation, you can create a debit claim for $1,000, and settle the claim by generating a debit memo.
Deduction
Deductions are created in Oracle Receivables and you can view and settle these deductions in Oracle Channel Revenue Management. Deductions are used to handle situations where customers short pay invoices for various reasons such as to claim compensation for shipping errors, pricing errors, and to claim promotional earnings.
When a deduction is created, all the pertinent information such as receipt numbers, dates and amounts, customer and transaction information, customer debit memo numbers and claim reasons, which is entered in Oracle Receivables, is available in Oracle Channel Revenue Management.
For example, you send an invoice for $10,000 to a customer. But the customer remits only $8,000 for this invoice, citing a deduction of $2,000 for promotional earnings that the customer has not received. A deduction for $2,000 is automatically created in Oracle Receivables. You can view and settle this deduction in Oracle Channel Revenue Management.
Deductions can be of one of the following types:
Transaction-related: deductions can be traced back to a specific transaction such as an invoice, a debit memo or a charge back.
Non transaction-related: deductions cannot be traced back to a specific transaction.
Promotion-related: deductions have associated promotional earnings. Customers make these deductions to claim discounts that have been given them for such activities as slotting fees or that are accrued when they place orders.
Settlement methods for deductions include invoice credit memo, on-account credit memo, previous on-account credit memo, write-off, charge back, RMA, and contra charge.
For more information on transaction types and adjustments for deductions, see the Oracle Receivables User Guide and the Oracle Order Management User's Guide.
Overpayment
Overpayments are created in Oracle Receivables when customers overpay what you have invoiced the for. This could be for an over shipment they have received or an inaccurately priced invoice. Settlement methods for overpayments include debit memo, write-off, and on-account credit.
Claims and Debit Claims are created in Oracle Channel Revenue Management. Deductions and Overpayments are created from Oracle Receivables. Oracle Receivables users can create deductions or overpayments when they find mismatches between the applied transaction amount and the receipt amount from the Receipt Application window.
If the payment is directly applied to a transaction and a short pay is recognized, then a deduction can be created based on the transaction, or a claim investigation can be created for the customer.
If Oracle Receivables users identify that a customer has overpaid, then a claim investigation can be created for the customer on receipt and is distinguished as an overpayment claim class in Oracle Channel Revenue Management. All the transaction and receipt information from Oracle Receivables is carried over to Oracle Channel Revenue Management as source information for claim research.
See Settling Claims, Deductions and Overpayments for procedures related to settling claims, debit claims, deductions, and overpayments.
Note: Throughout this document, the term "Claim" is used generically to encompass claims, debit claims, deductions, and overpayments.
Apart from regular claims, deductions, and overpayments, claims are also created automatically in Oracle Channel Revenue Management as a result of the integration between Oracle Channel Revenue Management and Oracle Partner Management.
Whenever any requests related to Special Pricing, Soft Funds, and Referrals are created and approved in Oracle Partner Management, offers and claims are automatically created in Oracle Channel Revenue Management.
These claims are settled by the claim users. For information on settling claims related to Special Pricing, Soft Funds, and Referrals, see the Indirect Sales Management chapter. See the Oracle Partner Management Vendor User Guide for more information on Special Pricing, Soft Funds, and Referrals.
Customers submit claims for various reasons such as to claim compensation from your organization for losses caused due to shipping problems, invoice errors, promotional payments, or quality issues.
Sometimes the reason for the claim may not be identified so thus is unknown. You can use internal claim types and reasons to identify the reason for which the claims have been raised and classify these claims.
Claim types and reasons also enable you to close the loop on claims processing and settlement, and to analyze claim problems. Depending on the claim type or reason, the process of claim research and resolution may be different. You can have any number of internal claim types and reasons. Your Claims Administrator can set up claim types and reasons based on your business needs.
Claim types and reasons together enable you to classify claims, and identify problem areas that need improvement. For example, you may have a large number of claims with the type--shipping and the reason--damaged goods. With this knowledge, you can improve your shipping methods and reduce the number of shipping claims arising due to damaged goods.
Claim Types
Claim types serve the following specific purposes:
Setups for integration purpose
Organizations can store setups required for creating transactions or adjustments in Oracle Receivables as well as in Order Management. The Oracle Receivables setups mainly drive the accounting, while the Order Management setups drive the workflow of a Return Material Authorization (RMA). These setups are as follows:
Transaction Type | Description |
---|---|
Credit Memo | Used when a claim or a deduction must be settled with a new credit memo. Must be set up in Oracle Receivables. |
Debit Memo | Used when a debit claim or an overpayment must be settled with new debit memo. Must be set up in Oracle Receivables. |
Chargeback | Used when a deduction must be settled with a chargeback. Must be set up in Oracle Receivables. |
RMA | Used when a claim or deduction must be settled with an RMA (return order). Must be set up in Order Management with a workflow tied to it. The workflow must have Invoicing Activity to generate a credit memo to close out the claim or deduction. |
Write-off Adjustment Receivable Activity | Used when a deduction must be settled with a write-off. Must be set up in Oracle Receivables as an adjustment type receivable activity. |
Receipt Write-off Receivable Activity | Used when an overpayment must be settled with a receipt write-off. Must be set up in Oracle Receivables as a receipt write-off type receivable activity. |
Default Receivable Clearing Accounts
When accruals are created either from a Lump sum, Accrual, Net Accrual, Scan data or Volume offer, such accruals may be treated as liabilities by some companies. These liabilities must be tracked in the General Ledger. Oracle Channel Revenue Management enables GL integration by creating Debit Sales or Expense, and Credit Liabilities accounting entries.
If a claim or deduction is associated to such accruals and the settlement method is a credit memo, then Oracle Channel Revenue Management creates entries for Debit Liabilities and Credit Receivables.
The debit entry for the liabilities account reverses the liabilities created when the accruals were created. Because the claim is being settled for such accruals, and the customer will be paid by a credit memo, these liabilities must be reduced. The credit entry for Oracle Receivables clearing account offsets the debit entry that the credit memo creates to reduce revenue of the customer account.
Default Vendor Clearing Accounts
If a promotional claim must be settled by a check instead of a credit memo, then accounting entries for Debit Liabilities and Credit Vendor Clearing will be created. The liabilities account used will be the same as the account used when accruals were created. The Oracle Receivables or Oracle Payables Clearing accounts that will be used during claim settlement are derived from the following setups:
As defined in the Claim Type, and the Account Generator workflow updates if any.
As defined in System Parameters, and Account Generator workflow updates if any.
Claim Reasons
Claim Reasons serve the following specific purposes:
Action Default
Action is a template of tasks. Based on the claim reason, certain repetitive tasks may need to be performed every time. Such tasks are defaulted automatically based on the claim reason. Therefore, you need not enter the tasks manually every time.
Setups for Integration Points
When a chargeback is created to settle a deduction, the chargeback reason must be passed from Oracle Channel Revenue Management to Oracle Receivables for integration purposes. Optionally, credit memo reasons can also be passed from claims in Oracle Channel Revenue Management to credit memos in Oracle Receivables.
For information on creating claim types and reasons, and application integration, see the Oracle Channel Revenue Management Implementation Guide.
As an option, you can select an action when creating a claim. Each action typically has a series of associated tasks. These tasks enable you to research and settle claims. For more information on tasks, see the Common Components chapter.
For example, a shipping claim may have an action called Shipping Claim Tasks. The series of tasks might include:
Review invoices for shipped products and amounts.
Contact shipping department for verification.
Obtain proof of delivery.
The Administrator sets up actions based on the business needs of your organization. For more information on actions, see the Oracle Channel Revenue Management Implementation Guide.
Manufacturers often deal with their customers directly or indirectly or both through distributors. If this is the case with your organization, you may want to offer promotions to customers both directly and through distributors who also sell to the same customers.
Oracle Channel Revenue Management can take indirect purchase data for direct customers, run a pricing simulation, and determine what promotions the customer is entitled to.
For example, an organization sells directly to Customer X. The organization also sells its products to a distributor who resells to Customer X as well as to other customers that you do not deal with directly. The distributor periodically sends in sales data to help you calculate accruals for all of the customers.
For this example, assume that the data consists of the following:
Customer | Relationship | Sales Amount |
---|---|---|
X | Direct and Indirect | $100,000 |
Y | Indirect | $80,000 |
Z | Indirect | $70,000 |
Based on the information provided from the distributor including the data, customer and product information, order number and date, quantity, price, shipment date, invoice number and date, and so on, Oracle Channel Revenue Management simulates the price and promotion that Customer X would have received had they dealt directly with you for a particular order.
If the pricing simulation indicates the customer would have received a better price or promotion dealing directly with you (say a $10K difference for this example), Oracle Channel Revenue Management automatically creates an accrual for this customer. The $10K is tracked in the customer budget, and can be paid later to the customer by a claim or deduction.
The data for Customers Y and Z will be saved and stored separately, so that you can offer promotions to these indirect customers in the future.
Customer reasons are the codes by which customers identify the claims that they submit. These customer reason codes may be different from the internal reason codes that your organization uses. The Administrator in your organization can create mappings for customer reason codes and the internal reason codes that are used by your organization. If these codes are mapped, then whenever a customer submits a claim, the customer's original reason is captured and automatically converted to the internal reason code. This simplifies the claim research process.
In the following Customer Reason Code Mapping diagram, Customer Reasons codes Shipment Errors and Invoice Errors are mapped to an Internal Reason named Processing Errors. Damaged Goods customer reason is mapped to an Internal Reason named Quality issues.
Customer Reason Code Mapping
For example, a retailer--Bigmart maintains more than 3,500 reason codes for deduction against its manufacturers. One of the manufacturers--Toy House maintains only 30 internal reason codes to analyze deduction patterns and route them to different departments for investigation.
Bigmart remits payments to Toy House. On those remittances Bigmart indicates on multiple lines their deductions and their reasons for deducting. The reason codes used by Bigmart are converted to internal reason codes. The amount that is deducted is adjusted and converted into deductions in Oracle Channel Revenue Management.
The processing of claims depends upon the manner in which the customers remit payments. Customers can make payments either through:
Electronic remittance (through bank or EDI file)
If it is an electronic remittance, then the information goes through the Quick Cash User Interface of Oracle Receivables. A Post Batch process then updates the customer balances and turns such information into receipts. During the Post Batch process, any amounts deducted or claimed will be adjusted in Oracle Channel Revenue Management and claims will be created. Customer reason codes are converted to internal reason codes during this process.
Manual remittance
If it is a manual remittance, then the Oracle Receivables user enters the relevant information. Customer reason codes are converted to internal reason codes during this process. Claims are created in Oracle Channel Revenue Management and receipts are issued.
During claim creation, you can enter one of the following:
Enter only the customer reason code
If you enter only the customer reason without entering the internal reason code, then based on the customer reason code, the system searches and changes the code to the corresponding internal claim reason. If customer reason codes have not been mapped, then the system takes the internal reason from System Parameters.
Enter customer reason code and internal reason code
If you enter the customer reason code and the internal claim reason code, then the customer reason code takes precedence and it is converted to the right internal claim reason.
Enter only the internal claim reason code
If you enter only the internal claim reason, then the customer reason field will be empty by default.
After a customer reason code is converted to the internal reason code, you may still make use of the customer reason code to refer to the claim.
When processing claims for settlement, payment methods depend on the origin of the claim, the claimant, and relationship between the claimant and the payee. In addition, processing is influenced by the following choices that you make.
Buying group or individual group member account
AutoLockbox
Multi-Org Access
Buying groups are formed when organizations group themselves to leverage their buying power.
For example, you create a promotion for a buying group. When buying group members place orders, accruals for each member are tracked individually, even though the buying group entity may be handling all the invoices and claims for the group. 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.
Related Customer accounts are set up with relationships. Common relationships include bill-to and ship-to.
For example, the headquarters of an organization may be set up as the bill-to account and location for multiple retail stores. Each retail store can be set up as a ship-to account and location. In addition, the headquarters office may be handling all the claims for retail stores, but these retail stores may receive their payment directly.
AutoLockbox (or Lockbox) is a service that commercial banks offer corporate customers to enable them to outsource their accounts receivable payment processing. An AutoLockbox operation can process millions of transactions a month.
AutoLockbox eliminates manual data entry by automatically processing receipts that are sent directly to your bank. The Oracle Receivables user can specify how this information must be transmitted and Oracle Receivables ensures that the data is valid before creating QuickCash receipt batches.
The customer who has remitted the receipt can be automatically identified, and the AutoCash rules may be optionally used to determine how to apply the receipts to your customer's outstanding debit items. See the Oracle Receivables User Guide for more information on AutoLockbox.
During AutoLockbox and Post QuickCash processing, Oracle Receivables can automatically prepare eligible remittance lines for claim creation in Oracle Channel Revenue Management. AutoLockbox can initiate claim creation for eligible remittances. Deductions and overpayments can be created from the PostBatch process when customers' remittances come from the Oracle Receivables Lockbox. All the relevant customer information including customer reason and reference number is passed to Oracle Channel Revenue Management. These claims can be settled through Oracle Channel Revenue Management. See Settling Claims, Deductions, and Overpayments for information on how to settle claims.
In Oracle Channel Revenue Management claim users can work on multiple operating units. Claim users can switch from one operating unit to another if they have access to multiple operating units. Details of the default operating unit are derived from the MOAC profile option, MO: Default Operating Unit. Users who have access to multiple operating units can select the operating unit to access the respective views, claims, and mass settlement groups.
If you implemented org striping for claims, the impact is described in the following table.
Feature | Description |
---|---|
Claim Creation | During claim creation, the default operating unit on the claim is derived from the MOAC profile option, MO: Default Operating Unit profile option. A user with access to multiple operating units can change this field. Operating unit details are required for Claim Interface Tables and the Claim Creation API. |
Promotional payments view and Claims aging view | The promotional payments and the claims aging views display details of claims that belong to the default operating unit. Users who have access to multiple operating units can select the operating unit to access the respective promotional payments view and the claims aging view. |
Claim display | Claim users can view all claims that they have access to. |
Mass settlement | Claim users can view all mass settlement groups that they have access to. When creating a mass settlement group, users should select an operating unit. If they do not select an operating unit, then LOVs such as Bill to, Claim Type, or Claim Reason, do not display values. |
Personalized search | For claim display and mass settlement purposes, the personalized search includes operating unit as a search criteria to enable claim users to sort claims and mass settlement groups by operating unit. |
Claim Settlement Methods | Settlement documents such as check and credit memo are created in the same operating unit as the claim that is being settled. Settlement methods are tied to Claim Source setup. You can disable settlement methods for a specific organization. |
Note: Org-striping has no impact on claim security or claim access.
In addition, org striping affects the following Claim related concurrent processes include the operating unit field. You can run these processes for all operating units that you can access. You can run concurrent processes with the following options:
All: enables you to run the following concurrent programs across all operating units:
Claims Import Purge
Import Claims
Transfer to General Ledger
All, but without parameters: enables you to run the following concurrent programs across all operating units, but without parameters:
Claims Auto Write-Offs Program
Claims Autopay
Claims Settlement Fetcher
You cannot use this option to run concurrent programs with any parameter other than operating unit. To run concurrent programs with other parameters, you must run it separately for each operating unit.
You cannot use this option to run concurrent programs with any parameter other than operating unit. To run concurrent programs with other parameters, you must run it separately for each operating unit.
The Claims summary page displays claims with My Claims as the default predefined view. From this summary page you can create claims and select multiple claims to write off or to update. You can click any claim number to go to the Claim Main page for that claim. The Personalize button on the Claims summary page enables you to create personalized views by selecting the columns you want to display.
Claim Main
The Claim Main page displays detailed information about any type of a claim. To modify this information, you can make changes to editable fields and then click Update. You can access the following information from the Claim Main page:
Function | Description |
---|---|
Promotional | Use to associate earnings of a claim with open accruals. To create a line from the Promotional tab, search accruals, enter the amount for the accrual of choice, and then click the Update button. Note: You can remove promotional claim lines by clicking the Remove All button. This action removes Line Amount for all claim lines. You can then enter the amount for the claim lines as required. |
Nonpromotional | Use to associate claim lines with RMA, invoice, or product information for nonpromotional settlements. To create a line from the Nonpromotional tab, click the Add Another Line button, enter details, and then click the Update button. |
Settlement | Displays information or details related to the settlement of a claim. To settle a claim, fill in the required fields and select the Update button. |
AR Source | For the Deduction and Overpayments claim classes, the AR Source subtab displays the claim source and subsequent receipt application details. |
Duplicates | Use to access duplicate claims and related documents pertaining to this claim. |
Tasks | Use to assign follow-up activities such as resolving problems related to the claim. |
Split | Displays a list of claims that were split from the current claim. The Line Amount list of values displays all the lines that are available in original claim. |
Notes and Attachments | Notes: Use to write Notes and record information that you would like to communicate to others regarding this claim. You can create any number of notes and edit and modify notes about this claim. Attachments: Use to review and edit Attachments. Attachments can be a Web address, file attachment or simple text. Click the Description text to review or edit the Attachment details. Click the Attachment text to view or download the Attachment. |
Team | Use to assign access to team members. |
Claim History
You can click the History button on the Claim Main page to view the complete history of a claim. An event is recorded in claim history every time a change is made to the claim. You can specify the events that can trigger a history recording in history rule.
Click the Simple Search button on the Claims summary page to search for claims based on specific criteria. You can then name your search and save it for later use. You can click the Advanced Search button on the Claims summary page or the Saved Searches page to add further search criteria.
For numeric fields, the default search operator is equal to. For text fields, the default search operator is starts with. For example, if you enter CLA024 in the Claim field and then you perform a search, the results include all claim numbers that start with CLA024.
If you specify multiple criteria, the search engine uses the and condition and displays the results for which all the conditions are met. For example, if you select Vision Operations in the Operating Unit field and Closed in the Status field, the search results contain all closed claims in the Vision Operations operating unit.
Claim lines serve the purposes of recording the details of a claim. Claim lines contain transaction details such as the product details, price, unit of measurement, and so on. Claim lines are used for associating offers or campaigns with a specific claim. For example, if a claim or deduction is promotion-related, it may be tied to multiple offers resulting in multiple Claim lines.
When you associate one or more offers to a claim, it means that you are settling the claim to pay the accruals that are created from these offers. From the claim lines page, you can access the Associate Earnings Summary. Here, if you created the claim manually, then you can see all global offers and all offers available for the claim's operating unit that are applicable to the customer or buying group on the claim and its related accounts, including any outstanding (unpaid) promotional accruals. You can search for accruals by offer, customer, order, invoice and products, and so on.
The Earnings Association diagram below Offer 1 and Offer 2 are associated to Claim A.
Earnings Association
The Promotional subtab on the Claim Main page includes all outstanding (unpaid) promotional offer accruals that are related to a specific customer and claim. For a customer budget, it displays the total utilized and remaining unutilized amounts as of date, in both transactional and functional currencies. However, actual association of earnings happens in either the transaction or the functional currency based on the claim currency. The system calculates the current association amount, existing association amount and net association amount (the difference between the current and existing association amounts).
By using the search function, you can view all offers that are applicable to each claim for customers and related accounts, and buying groups and buying group members. You can use associated earnings for claim research and settlement.
Some examples of how you can use associated earnings for claim research and settlement are given below. For each example, you can assume that the following has already occurred:
A claim has been created.
At least one claim line was created, and earnings were associated with it.
Example 1: Accruals
A customer submits a deduction for $20,000. You first look at the customer checkbook and see the following:
Offer | Earned | Paid |
---|---|---|
Offer 1 | $100,000 | $40,000 |
Offer 2 | $15,000 | $9,000 |
Offer 3 | $8,000 | $5,000 |
Next, you look at the customer's associated earnings information for this claim and see the following.
Offer | Amount | Available |
---|---|---|
Offer 1 | $100,000 | $60,000 |
Offer 2 | $15,000 | $9,000 |
Offer 3 | $8,000 | $5,000 |
Let us assume that you have determined that the deduction is related to all three offers, and you have selected credit memo as the settlement method. In the Line Amount field in the Promotional subtab of the Claim Main page, you enter the values in the Line Amount column as shown below:
Offer | Amount | Amount Available | Line Amount |
---|---|---|---|
Offer 1 | $100,000 | $40,000 | $9,000 |
Offer 2 | $15,000 | $9,000 | $6,000 |
Offer 3 | $8,000 | $3,000 | $5,000 |
When the credit memo is issued, $9,000 is withdrawn from the accruals for Offer 1, $6,000 from Offer 2, and $5,000 from Offer 3. The following GL accounting entries are created:
GL Entry | Offer 1 | Offer 2 | Offer 3 |
---|---|---|---|
Debit Liabilities | $9,000 | $6,000 | $5,000 |
Credit Receivables Clearing | $9,000 | $6,000 | $5,000 |
The customer's budget checkbook is updated automatically to:
Offer | Earned | Paid |
---|---|---|
Offer 1 | $100,000 | $49,000 |
Offer 2 | $15,000 | $15,000 |
Offer 3 | $8,000 | $8,000 |
When the next claim for this customer is created, the associated earnings page will show the following details:
Offer | Amount | Amount available |
---|---|---|
Offer 1 | $100,000 | $51,000 |
Example 2: Buying Group
A Buying Group offers its members a deal whereby each unit of product that they purchase is eligible for a 10% accrual. Member A places an order and accrues $10,000. The $10,000 is tracked in the earned column of the budget for Member A.
The Buying Group handles the invoicing and claim processing for all its members. It submits a claim on behalf of Member A for $10,000. Being the claim owner, you create a claim with at least one claim line, and associate earnings with that claim line.
When you navigate to the Promotional subtab on the Claim Main page, you do not at first see the $10,000 in accruals because the Buying Group did not place the order directly. To research this claim further, you use the search function to view all of the accruals for all the buying group members. You can then associate the $10,000 in accruals to the claim and either pay Member A directly or pay the Buying Group, who will disburse the payment to Member A.
In general, when you associate earnings to an offer on the claim line, the claim amount gets associated to the entire offer on a first-in-first-out basis irrespective of the item or product categorization on the offer. This means that the earliest order line with accrual is cleared first.
However, some organizations may have a policy of clearing their claims periodically, say on a monthly basis, and they may not necessarily clear the oldest liability first. Alternately, because of the many product lines involved in one single offer, when a claim comes in that partially relieves the offer's accruals, they may prefer to proportionately pay the accruals for the offer lines.
For example, the total accrual for an offer is $1,000, out of which $200 has been paid out for previous claims. The outstanding accrual balance of $800 is broken up by products, and when a claim is created for $500, and the user associates the whole $500 to this offer, the system automatically splits the associated earnings by product as follows:
Product A for $500 * (500 / 800) = $312.50
Product B for $500 * (200 / 800) = $125.00
Product C for $500 * (100 / 800) = $62.50
If the offer sources funds from multiple budgets, the accruals are proportionately relieved from the budgets. For example, in the above scenario, if the offer sources funds from two different budgets--Budget A and Budget B, then due to product eligibility validation, each budget may track the accruals for some of the products or all. Assume that the accruals for Product A, Product B, and Product C are tracked as shown in the following table.
Product | Budget A | Budget B | Total |
---|---|---|---|
Product A | $300 | $200 | $500 |
Product B | $200 | -NA- | $200 |
Product C | -NA- | $100 | $100 |
When the claim is created for $500, and the associated earnings are split proportionately by product. The funding budgets are also split proportionately and the associated earnings for the products will be sourced as below:
The associated earnings for Product A ($312.50) is split between Budget A and B as shown below:
Budget A: $312.50 x (300 / 500) = $187.50
Budget B: $312.50 x (200 / 500) = $125.00
The associated earnings for Product B ($125.00) is sourced entirely from Budget A.
The associated earnings for Product C ($62.50) is sourced entirely from Budget B.
An option in the System Parameters determines whether the system will prorate the earnings based on product or not.
When the Prorate Associated Earnings by Products check box is selected, Oracle Channel Revenue Management prorates the earnings across accruals against the offer. It also performs the following actions:
In the case of over utilization, based on the positive amount that is remaining, the excess amount is prorated over all of the products. An adjustment record is created containing all of the product information.
In the case of a complete pay over, the total amount is prorated over all the products that have nonzero accrual amounts.
The original claim line is split and earnings are redistributed so that each claim line will be associated with earnings for only one offer-product combination.
Important: For an offer where the Ignore Payment Validations check box is selected and the offer has a null available amount, the system cannot prorate the amount.
An example of the offer prorate feature for pay over scenarios is given in the following tables.
Partial Pay Over
Amount to be associated with the offer: $90
Search for: Order O1
Total available amount in the offer: $50
Prorate logic: Based on Available Amount (Before Association)
The pay over amount of $40 is distributed for products P1 and P2 as shown in the table below.
Offer | Order | Product | Amount | Available Amount (Before Association) | Associated Amount | Available Amount (After Association) |
---|---|---|---|---|---|---|
Offer A | O1 | P1 | 70 | 40 | Accrual = 40 Pay Over = 40 × (40/50) = 32 Total = 72 |
40-72 = (-32) |
Offer A | O1 | P2 | 50 | 10 | Association = 10 Pay Over = 40 × (10/50) = 8 Total = 18 |
10-18 = (-8) |
Partial Pay Over With Negative Available Amount
Amount to be associated with the offer: $55
Search for: Order O2
Total available amount in the offer: $10
Prorate logic: Based on Available Amount (Before Association)
The pay over amount of $45 is distributed for products P3 and P4 as shown in the table below.
Offer | Order | Product | Amount | Available Amount (Before Association) | Associated Amount | Available Amount (After Association) |
---|---|---|---|---|---|---|
Offer A | O2 | P3 | 0 | -10 | Accrual = (-10) | 0 |
Offer A | O2 | P4 | 40 | 20 | Accrual = 20 Pay Over = 20 × (45/20) = 45 Total = 65 |
20-65 = (-45) |
Complete Pay Over
Amount to be associated with the offer: $65
Search for: Order O3
Total available amount in the offer: $0
Prorate logic: Based on Amount
The pay over amount of $65 is distributed for products P5 and P6 as shown in the table below.
Offer | Order | Product | Amount | Available Amount (Before Association) | Associated Amount | Available Amount (After Association) |
---|---|---|---|---|---|---|
Offer A | O3 | P5 | 30 | -20 | Pay Over = 65 × (30/50) = 39 | (-20)-39 = (-59) |
Offer A | O3 | P6 | 20 | 20 | Pay Over = 65 × (20/50) = 26(-20)-39 = (-59) | 20-26 = (-6) |
You can create claims in either New or Open status using the profile option OZF: Default Status When Creating Claims.
New Status - If a claim is created in New status, you must manually change the status to open before you can settle the claim. In New status you can delete the claim but not settle it.
Open Status Oracle recommends setting the value of this profile option to Open. This means that when you create a claim or use Mass Create to create a large number of claims they will be set to Open status and you will not have to open each claim individually to cancel it. the default for this profile option is Open.
Customers may submit reimbursement requests for a number of reasons such as to claim compensation for damaged goods, payment for services, and so on. Debit claims can be used to charge back customers who have been overpaid.
To create a claim or a debit claim, log in to Oracle Channel Revenue Management as Oracle Trade Management User.
Navigation: Claim > Claims > Create.
Notes:
Claim Number: If left blank, a unique claim number is automatically generated.
Customer Name: Determines the claiming customer. The available customer names and bill-to locations are customer accounts set up in the TCA
Currency Code: Select a code for the currency in which claims are to be created
Offer Code: Search and select the code of the offer for which you are creating this claim. This is used by the Rule Based Settlement Engine concurrent program which automates the process of matching claims and deductions to open credits and accruals.
Amount: Enter a positive value for a claim, or a negative value for a debit claim.
Exchange Type: If a claim comes in with a currency that is different from the functional currency, the currency must be converted. Exchange Type defines the type of exchange rate. For example, a Corporate exchange type may have a set of rates determined after every month-end market close.
Note: The Exchange Type, Rate, Currency and Amount fields are used only when the transaction and accounted currencies are different. The value for this field must be used to perform an exchange rate conversion.
Exchange Date/ Exchange Rate: Rates may differ based on the exchange date that you enter. Based on the Exchange Type and Exchange Date entered, an exchange rate may populate this field. If it is a user-defined exchange type, you can enter a different rate. For example, if Sterling Pound is the currency type and 2 is the exchange rate, then the value for Amount is converted at a rate of 2 Sterling Pounds:1 US dollar.
The Mass Create function enables you to create multiple claims and debit claims on one screen. All the basic information for claims can be captured quickly so that they can be routed to the proper owners in a timely fashion. This functionality enables you to handle the massive volume of claims data that your company has to deal with, and enables you to expedite the claims process.
To mass create claims and debit claims, log in to Oracle Channel Revenue Management as Oracle Trade Management User.
Navigation: Claim > Claims > Mass Create.
Notes:
Claim Number: If left blank, a unique claim number is automatically generated.
Claim Amount: If the amount is greater than zero, a claim is created; otherwise, a debit claim is created.
Exchange Type, Exchange Rate, and Exchange Date: If the currency for the claim is different than the functional currency, select an Exchange Type, Exchange Date, and Exchange Rate.
If an error occurs, the row with the problem is highlighted. All the other claims that you entered in the table are created.
The Mass Update feature enables you to update multiple claims from the Claims summary page. All of the basic information for claims can be updated from the Mass Update Claims page. This functionality enables you to update various fields for the selected claims, such as Owner, Broker, Sales Person, Claim Attachments, and so on.
To perform mass update for claims:
Log in to Oracle Channel Revenue Management as Oracle Trade Management User.
Navigate to the Claims summary page and perform one of the following:
Select the claims you want to update.
Click Simple Search, then search for and select the claims you want to update.
Click Simple Search and then Advanced Search, then search for and select the claims you want to update.
Select Mass Update from the Actions drop-down list.
Click Go. The Mass Update Claims page opens.
Claim Lines enable you to associate the claim amount to chargeback, debit memo, credit memo, offer, order, invoice, or third party accruals. For example, you can select the type as order to settle a claim that is associated with a particular order. A claim can have multiple claim lines.
To create claim lines, log in to Oracle Channel Revenue Management as Oracle Trade Management User.
As a prerequisite, a claim should exist.
Navigation: For nonpromotional claims, from the Claim tab, click the Claims subtab, then the claim. In the Claim Main page, click the Nonpromotional subtab, and then click the Add Another Line button.
Navigation: For promotional claims, from the Claim tab, click the Claims subtab, then the claim. In the Claim Main page, click the Promotional subtab, and then expand the Accruals Search link. Specify the search criteria and click the Go button.
Notes:
Settlement Method: The settlement method that you select will determine the tax codes that are displayed. If you selected Check or Contra Charge, you will see Oracle Payables Tax Codes. For all the other methods, you will see Oracle Receivables Tax Codes. The Tax Code selected here is the default for all claim line items, unless it is overridden for an individual line. On a manually created claim, if you do not select a settlement method, it is derived from the customer's trade profile.
Line Type: Line Type is used to associate a claim to a chargeback, debit memo, credit memo, offer, order, invoice, or third party accrual data. The Line Type determines the transaction to which the claim amount is related.
Transaction LOV: The values that are displayed in the list depend upon the Line Type that you selected. For example, if you select the Line Type as Order, then all the order numbers are listed here.
Claim line details are used to associate promotional activities and documentation to the specified claim.
To enter claim line details, log in to Oracle Channel Revenue Management as Oracle Trade Management User.
As a prerequisite, a claim with completed claim lines should exist.
Navigation: From the Claim tab, click the Claims subtab, then the claim. In the Claim Main page, click the Promotional subtab. Locate the line you want to add details for, and click the icon in the Detail column.
Notes:
Valid: Select to indicate that the claim is valid. This check box has no functional impact.
Performance Verified and Proof of Performance: Select these check boxes to indicate that performance on the part of the customer has been verified, and to indicate that the proof of performance has been attached to the claim. These check boxes are added as notes to the claim and they have no functional impact.
Number: This is the reference number of the document.
Name: Select a name for the type of chargeback, credit memo, debit memo, invoice, or order.
Item Type: Item or item category acts as a filter for the line or product LOV.
Line or Product: Provides the item number and name.
Quantity, UOM, and Price: These fields are automatically entered if values were entered on the Lines page.
Amount: Verify the amount. Claim Currency Amount is the amount shown in the Claim currency regardless of the promotional activity currency.
Tax Classification Code: Specifies the rate at which tax is applied to the claim.
Use Associate Earnings to associate a claim line with earnings accrued in the checkbook. Associating earnings is mandatory for promotional claim types. On the Associate Earnings page, you can view available earnings for a customer in both transactional and functional currencies.
To associate earnings with claim lines, you should first search for promotional accrual information, and then associate earnings.
Log in to Oracle Channel Revenue Management as Oracle Trade Management User.
As a prerequisite, a claim should exist.
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: Searching for promotional accrual information
Enter search criteria in one or more of the following fields in the Accruals Search section:
Relationship and Related Customer: These are account relationships that are set up in TCA.
Buying Group and Display Children: To search for the accruals for that particular buying group and its members.
Budget: To search for accruals for a specific fund.
Activity Type and Activity: To search for a particular offer and its accruals.
Summary View: To specify an Activity, Order, Period, or Product view.
Period: To search for accruals for a specific year. This value is obtained from the OZF: Default Value for Associate Earnings Query profile option.
Performance Verified: Select this check box to indicate that you have verified the customer or buying group has met the performance criteria for a promotion.
Offer Type, Item, Item Type, Order Number, End Date: Search for accruals related to these fields.
Invoice Number: To search for invoice numbers based on the claim customer. If you select Relationship and Related Customer, the Invoice Number field displays invoices from related customers. If you select Buying Group, the Invoice Number field displays invoices from that buying group and its members.
Channel of Sales: Search for accruals by direct or indirect sales channel.
Prorate Associated Earnings by Products: Select this check box to view the associated earnings prorated by Products.
After you associate a line amount in the Accruals Search section, the Associated Accrual Details section displays the associated accrual details in the Promotional subtab. You can remove associated records individually by clicking the Remove icon in the Associated Accrual Details table. This action will either remove or update the related claim lines from the Nonpromotional subtab. The Remove icon is available when the claim is in open status and associated accruals region has records.
To set a view for the Associated Accrual Details section, set the profile option OZF: Default View for Associated Accrual Details Region. You can also view accrual details by activity, order, period, and offer.
When customers pay less than the invoice amount, you create a deduction for the unpaid, outstanding amount complete with references, reasons for the shortpayment, and details of the related transaction. You may then decide to write off this amount, adjust it against some other payment, or claim it.
Similarly, customers can pay more than the invoice amount. In such cases, you create an overpayment for the difference and then close them using an appropriate settlement method.
When customers make overpayments, Oracle Receivables creates overpayment claims in Oracle Channel Revenue Management.
To create an overpayment, log into Oracle Receivables as Oracle Receivables User.
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 an overpayment. See the Oracle Receivables User Guide for information on the different ways of entering overpayments.
Navigation: Receipts > Receipts.
Notes:
Receipt Number: Receipt number can be the customer check number or any other reference number. If necessary, change the Receipt Type to Cash, and change the Currency Code.
Receipt Amount: Receipt amount is the amount that the customer has paid. If necessary, change the Receipt Date, and the GL date.
Payment Method, Customer Name, Reference, and Reference: This information is passed to Oracle Channel Revenue Management when the deduction is created.
Applications: Navigate to the Applications screen.
Apply To: Select Claim Investigation. The available values are open transactions and some seeded receivables activities. Claim Investigation is seeded specifically to create non-transaction related overpayments (or deductions) in Oracle Channel Revenue Management.
Amount Applied: Enter a positive number.
Activity: The activity that you select here drives the GL entries to account for the overpayment.
After you save your work, an overpayment number appears in the Reference Number field.
Transaction related deductions can be traced back to a transaction (invoice, chargeback, or debit memo). Non-transaction related deductions cannot be traced back to a transaction.
Transaction related and non-transaction related deductions are created in Oracle Receivables. 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.
To create either a transaction-related or a non-transaction related deduction, log into Oracle Receivables as Oracle Receivables User.
As a prerequisite, a deduction that can be traced back to a specific transaction should exist.
Note: The Oracle Receivables user may need to perform additional data entry tasks. These notes present only a single way of creating non-transaction related deductions. See the Oracle Receivables User Guide for information on the different ways of entering non-transaction deductions.
Log into Oracle Receivables as Oracle Receivables User.
Navigation: Receipts > Receipts.
Notes:
Receipt Number: The receipt number can be the customer check number or any other reference number. If required, change the Receipt Type to Cash, and change the Currency Code.
Receipt Amount: This is the amount that the customer has paid. If required, change the Receipt Date, and the GL date.
Payment Method, Customer Name, Reference, and Comments: This information is passed to Oracle Channel Revenue Management when the deduction is created.
The default settlement method for a deduction is Credit Memo – On Account.
Offer Code: Select the offer code attached to this deduction.
You can update the offer code for a deduction in Open status. When you update the offer code, the PAD number is automatically updated. Select the offer code attached to this deduction. You can update the offer code for a deduction in Open status. When you update the offer code, the PAD number is automatically updated.
PAD: This is the Pre-Authorized Deduction number that is displayed for the offer code you selected.
Applications: Navigate to Applications.
If the deduction is transaction related, then enter the following specific information:
Apply To: This determines what the customer is paying for.
Balance Due: This is the balance of the transaction after the customer's payment. The balance due will be positive for deductions.
If the deduction is non-transaction related, then enter the following specific information:
Apply To: Select Claim Investigation. 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.
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
Reference Type: Select Oracle Trade Management Claim in the Reference Type field, and select a reason in the Reference Reason field. The values that are available here are the same as in Oracle Channel Revenue Management. If a customer indicates the reason for which they have made the deduction, then this information can be captured when the cash application is created in Oracle Receivables; this information can be passed to Oracle Channel Revenue Management.
Customer Reference: If the customer indicates an internal debit memo number, it can be captured here and passed to Oracle Channel Revenue Management.
After you save the deduction, a deduction number appears in the Reference Number field. At this point, the deduction is created.
If it is a transaction-related deduction, it may have a dispute on it. To verify the dispute, navigate to Transactions > Transactions > [transaction name] > More > Disputed Amount.
Source displays the Oracle Receivables receipt and transaction information that originally created a deduction or overpayment. Source enables you to refer back to the documents in Oracle Receivables.
To view the source of a deduction or an overpayment, log in to Oracle Channel Revenue Management as Oracle Trade Management User.
As a prerequisite, a deduction or overpayment should exist.
Navigation: From the Claim tab, click the Claims subtab, then the claim. In the Claim Main page, click the AR Source subtab.
Notes:
The following information is displayed:
Receipt: The record created in Oracle Receivables when a company receives a customer payment.
Receipt Date: The date when the payment was received.
Receipt Amount: The amount that the customer has paid.
Currency Code: The currency in which the customer has paid.
Receipt Comments: Comments that were entered by the Oracle Receivables clerk.
If the deduction is transaction-related, then the following fields appear in addition to the above fields:
Source Type: Values are invoice, debit memo and chargeback.
Source Number: The transaction number (invoice, debit memo or chargeback number).
Source Date and Source Amount: The transaction date.
Source Amount: The transaction amount.
In the Receipt Application region, click the hyperlink of the event to view more details about the subsequent receipt application.