Creating Claims
Overview
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.
Understanding Claim Components
To create claims, you must understand the different claim types, classes, reasons, claim lines, and customer-reason code mapping.
Claim Classes
Claim, Debit claim, Deduction, and Overpayment are the four different claim classes that are available in Oracle Trade 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 Trade 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 Associate Earnings page. The settlement methods for claims include check, credit memo, or Return Materials Authorization (RMA).
-
Debit Claim
Debit claims are created in Oracle Trade 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 Trade 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 Trade 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 Trade 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 Trade 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 Trade Management. All the transaction and receipt information from Oracle Receivables is carried over to Oracle Trade 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 Trade Management as a result of the integration between Oracle Trade 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 Trade 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.
Claim Types and Reasons
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:
Integration Setups 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 Trade 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 Trade 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 Trade Management to Oracle Receivables for integration purposes. Optionally, credit memo reasons can also be passed from claims in Oracle Trade 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.
Claim Actions
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.
Third Party Accruals and Pricing Simulations
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 Trade 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 Trade 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 Trade 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 Reason
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 Trade 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 Trade 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 Trade 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.
Processing Methods
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 and Related Customer Accounts
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.
Enabling AutoLockbox
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 Trade 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 Trade Management. These claims can be settled through Oracle Trade Management. See Settling Claims, Deductions, and Overpayments for information on how to settle claims.
Enabling Multi-Org Processing
In Oracle Trade 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.
-
Claim Details
The Claim Detail page in Oracle Trade Management displays detailed information about any type of a claim. You can modify this information by making changes to the editable fields and clicking update. You can access the following information from the Claim Detail page:
| Function | Description |
|---|---|
| Main | The claim detail page displays detail information about any type of a claim. You can modify this information by making changes to the editable fields and clicking update. |
| Line | This page displays information about the lines associated with the claim. You can create a line by entering information in the table below and clicking update. You can associate a line with promotional earnings by clicking Associate Earnings icon on that row. |
| Related Documents | Use to access relevant documents pertaining to this claim. |
| Team | Use to assign access to Team members |
| Task | 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. The line amount should be greater than the sum of all the lines that are selected for split claim. |
| Attachments | Use this screen 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. |
| Notes | Use this screen 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. |
| Settlement | Displays information/details related to the settlement of a claim. To settle a claim, fill in the required fields and select the Update button. On a manually created claim, if no settlement method is selected, then the settlement method is taken from that specified on the customer’s trade profile. Because a customer can have more than one trade profile, the system looks first for the default settlement method defined for the customer site and account, and then at the party level. |
| History | This page displays all history records of a claim. A recording is triggered by an event happened to the claim. You can specify the events that can trigger a history recording in history rule. To see history detail, click on the hyperlink in the event column |
| Report | Displays a report containing information about this claim. The information includes items such as Operating Unit, Claim Number and Customer Information. |
Claim Advanced Search
The Personalize option on the Claim page enables you to search for a claims based on specific criteria. You can choose to filter the search by a particular set of records and select which columns you want to display.
To modify the search criteria select the Modify criteria button.
Claim Lines and Associated Earnings
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 Associate Earnings 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 Associate Earnings 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 view the Associate Earnings 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.
Proportionate Association of Earnings by Products
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 earnings flag is checked, Oracle Trade Management will prorate the earnings across accruals against the offer. It will also perform the following actions:
-
In the case of over utilization, the excess amount will be prorated over all of the products. An adjustment record is created containing all of the product information.
-
The original claim line will be split and earnings will be redistributed so that each claim line will be associated with earnings for only one offer-product combination.
Claims Status
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.
Creating a Claim
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 into Oracle Trade 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.
Creating Multiple Claims
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 into Oracle Trade 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.
Creating Claim Lines
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 into Oracle Trade Management as Oracle Trade Management User.
As a prerequisite, a claim should exist.
Navigation: Claim > Claims > Claim Name > Lines.
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.
Entering Claim Line Details
Claim line details are used to associate promotional activities and documentation to the specified claim.
To enter claim line details, log into Oracle Trade Management as Oracle Trade Management User.
As a prerequisite, a claim with completed claim lines should exist.
Navigation: Claim > Claims > Claim Number > Lines. 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 checkboxes 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 checkboxes are added as notes to the claim and they have no functional impact.
-
Number: This is the reference number of the document.
-
Product Name: The Part Number field is populated automatically if a Product Name is selected.
-
Quantity, UOM, Price, and Tax Code: 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 Code: Tax Code is populated automatically if a Tax Code was selected on the Lines page.
Associating Earnings With Claim Lines
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 into Oracle Trade Management as Oracle Trade Management User.
As a prerequisite, a claim with completed claim lines should exist.
Navigation: Claim > Claims > Claim Name > Lines.
Notes: Searching for promotional accrual information
-
Associate Earnings: Search for the appropriate line.
-
Associate Earnings Summary: Enter search criteria in one or more of the following fields in the Accruals Search Criteria 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.
-
Activity Type, Activity, and Schedule: to search for a particular offer and its accruals. Alternatively, you can search by campaign schedule to find its related offers and accruals.
-
Document Class and Document Number: to search for accrual records for specific document types, such as orders and invoices.
-
Product: to search for the accrual records for a specific product.
-
Summary View: to specify an Activity, Document Class or Product view.
-
-
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.
Notes: Associating earnings
-
Scan Promotions Accruals: If you have a Scan Data promotion, then enter the actual scan data units and values in the Scan Promotion Accruals table.
Note: You can only associate earnings to a claim if it has no existing associations.
After you save your work and return to the Lines Summary page, you will notice that the Associate Earnings icon has changed to a check mark.
Creating Deductions or Overpayments
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.
Creating an Overpayment
When customers make overpayments, Oracle Receivables creates overpayment claims in Oracle Trade 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 Trade 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 Trade 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.
Creating a Deduction
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 Trade 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 Trade 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 Trade 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 Trade 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 Trade Management.
-
Customer Reference: If the customer indicates an internal debit memo number, it can be captured here and passed to Oracle Trade 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.
Viewing the Source
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 into Oracle Trade Management as Oracle Trade Management User.
As a prerequisite, a deduction or overpayment should exist.
Navigation: Claim > Claims > Claim Name > Source.
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.