Claim and Deduction Management

This chapter covers the following topics:

• Claims Overview
• Process Flow
• Claim Creation
• Claim Assignment
• Claim Approval
• Claim Research
• Claim Settlement
• Reports

Claims Overview

Business-to-Business operations (B2B operations) involve complex business activities and relationships between manufacturers and retailers. Claims and deductions form an important aspect of B2B operations. Customers raise claims or take deductions for many reasons such as to claim compensation for damaged goods and to claim promotional accruals that they are eligible to receive.

Settling claims and deductions involves determining whether a claim is valid, validating proof of performance conditions have been met, and tracking them. Sometimes, valid claims and deductions may not have the requisite proofs. Even in such cases, it is essential to settle these claims. These activities require resources, time, and effort. Customers may also submit invalid claims and deductions. While the claims remain unresolved, shipping and invoicing continue, thus giving interest-free credit to the retailers. Some of the challenges that organizations face today are those of settling deductions on time, and recognizing and preventing unauthorized claims and deductions.

Claims in Oracle Trade Management enables organizations to shorten the claims-processing cycle, and reduce claims and the associated costs. Information related to all the claims is stored in a centralized manner. This makes it possible for you to access accurate views of promotional spending and other variable costs. You can research, validate, and settle deductions, charge backs, and claims. You can also identify invalid and duplicate claims and prevent unauthorized claims and deductions.

Process Flow

The following figure illustrates the process flow for claims, starting from claim creation to claim research and settlement.

Process Flow for Claims

Claim Creation

Customers may submit a claim or deduct/overpay for many reasons such as OS and D- over, shorts and damages. If a customer makes any over payments or short payments a resulting deduction or overpayment transaction is created by AR into Oracle Trade Management. You can view, investigate and settle these claims.

Claim Assignment

After a claim has been created in Trade Management it must be assigned to an owner. Claim owners are responsible for claim settlement and resolution of any related issues. Ownership can be assigned either to individuals or a team. This assignment can be done manually or utilize our automated assignment engine based on a claim hierarchy established in Oracle Trade Management Territories.

Claim Approval

A claim must be approved before you settle it. After you submit the claim for approval, the approver receives a notification. The approval rules determine the approval flow. The approver may approve or reject the claim. After research has been done it must be submitted for approvals before settlement is complete.

Claim Research

Before settling a claim, you can:

• Determine whether a claim or deduction is valid or invalid.

• Determine the various reasons for which a claim is submitted, split the claim accordingly, and specify different settlement methods for each portion of the claim

  Find duplicate claims and remove such claims from the system.

Claim history enables you to record various changes made to a claim during the course of investigation. You can also use Oracle Discoverer to extract customer information, and use it for research purposes.

Claim Settlement

The claim settlement methods that are available in Oracle Trade Management are check, on-account credit memo, previous on-account credit memo, debit memo, Return Materials Authorization (RMA), automatic write-off, invoice credit memo, and contra charge. The settlement method that you can use depends upon the claim type. You can settle claims for individual customers and buying groups You can also settle via a user defined customized settlement flow You can also pay to third parties.

Reports

The following reports enable you to view the claim details during and after settlement:

• Claim Report: summary of essential claim details such as customer details, claim lines, payment details, and settlement methods.

• Claim Aging View: summary of claims and deductions by customer and by days due. Claim Aging View enables you to determine which customer has had outstanding claims for the longest period time and work on those claims.

• Claim Settlement History: summary of all information that is related to the settlement of a claim. Best practices would be to resolve all claims within a 30 day period. The older claims get the harder it will be to get invalid deductions repaid.

• Customer 360 Degree View: summary of all transactions of the selected customer including all the orders, invoices, debit memos and charge backs.

Claim Creation

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. Information in this section will enable you to:

• Understand claim classes

• Understand claim types and reasons

• Understand buying groups and related customer accounts

• Understand claim lines

• Understand associated earnings

• Understand third party accruals and pricing simulations

• Understand lockbox integration

• Create claims and debit claims

• Create deductions and overpayments

• Create overpayments

• View claim source

• Create claim lines and associate earnings

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 Detail Page

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

Modifying Details of a Claim Type

Use the following procedure to modify the details of a claim type.

Prerequisites

An existing claim type.

Steps

1. Log into Oracle Trade Management as Oracle Trade Management Super User and navigate to Administration > Claim side navigation link > Claim Types.

2. Click the hyperlink of the claim type.

3. Make the required changes, and click Update.

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.

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.

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, you can see all the offers 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. 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.

About Proportionately Associating 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.

About 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:

1. Review invoices for shipped products and amounts.

2. Contact shipping department for verification.

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

Creating an Action

Actions are predefined templates that contain a series of tasks intended to guide the research and resolution of claims. They are organization-specific, and provide the claims department with a project management tool. A set of actions can be designated as default actions for a specific claim reason. Follow these steps to create an Action.

Prerequisites

None.

Steps

1. Log in to Oracle Trade Management and navigate to Administration > Trade Management > Claim > Actions.

2. Select Create.

3. On the Create Action page, enter the following information: Source Object: Defaults to Marketing Claim.

   Name: Enter a name for the action.

   Start Date: The date from which the action can be used.

   End Date: The date upon which the action can no longer be used.

   Description: Enter a description for the action.

4. In the Task Templates section, enter the appropriate information in each field.

   Priority: The urgency of the task.

   Duration and Duration Type: Indicates how much time should be spent on the task. For example, enter 2 and select week if the time spent should be 2 weeks.

   Task Type: Select General or Approval.

5. Select Create.

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.

About Lockbox Integration

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.

Org-Striping in Claims

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.

Impact of Org-Striping on Claims

Org-striping has the following impact on claims:

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.

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.

Creating Claims in Open 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 or a Debit 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

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

Mass Creating Claims and Debit 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 a Transaction Related or a Non Transaction Related 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.

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

Creating an Overpayment

When customers may 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.

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

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.

• 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 Detail Information for Claim Lines

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.

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.

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.

Claim Assignment

Claim assignment involves assigning the right owners to claims. Claim owners are responsible for settling claims and resolving claim-related issues.

Information in this section will enable you to:

• Understand the concepts of claim ownership and auto assign owner

• Reassign owners by using claim assignment owner

About Claim Ownership and Auto Assign Owner

Every claim must have an owner. Owners are assigned either manually or automatically during claim creation. Automatic assignment occurs if Auto Assign Owner has been implemented in your organization.

A claim owner can be either an individual or a team. Teams can consist of multiple individuals and pre-defined groups of individuals. When a claim is owned by a team, one individual is always designated as the primary owner. The name of the primary owner appears in the Owner field on the Claim Detail page. The primary owner can add and remove team members, and also reassign claim ownership to another individual.

Team ownership enables you to manage scenarios where a specific claim owner is not easily determined during claim creation. In such cases, collective ownership and collaborative investigation may be required. See the Oracle Channel Revenue Management Implementation Guide for information on setting up teams.

Assigning a team to such claims enable you to:

• Avoid settlement delays that may occur if you assign a wrong owner.

  For example, a claim that is assigned to a wrong owner may remain in a pending state for a lengthy period of time before it is reassigned to the proper owner.

• Avoid creating many complex territories to handle every business scenario.

  For example, based on the customer's address, an organization knows that Claim #1020 should be assigned to a team member in the California territory. However, there is not enough information available to select a specific team member. The claim is therefore assigned to a team in the California territory. One of the team members recognizes that it is their responsibility and takes ownership of the claim.

If the Auto Assign Owner feature has been implemented in your organization, a claim owner is assigned automatically whenever a claim is created in Oracle Trade Management or in Oracle Receivables. You can initiate owner reassignment by selecting the Auto Assign check box on the Claim Detail page.

For example, a claim with the reason--Shipping was initially assigned to John. Upon investigation, John determines that the claim is a pricing error. John changes the claim reason to Pricing Error. Because he is not sure who should be working on this claim, he checks the Auto Assign Owner box and clicks Update. The system assigns a new owner based on the new claim reason.

As a prerequisite to enable assignment of owners, the Administrator must perform the following:

• Set up pre-defined groups in Oracle Resource Manager.

• Set up automatic assignment of an individual or a team in Oracle Territory Manager.

Claims supports the use of Oracle Territory Management to define territories and assign claim owners based on multiple customer, product, and geographical attributes, and claim type and reason.

Reassigning Claim Owners By Using Auto Assign Owner

If the Auto Assign Owner feature has been implemented, a claim owner is assigned automatically whenever a claim is created in Oracle Trade Management or in Oracle Receivables. Owner reassignment is triggered by selecting the Auto Assign check box on the Claim Detail page.

To reassign claims by using auto assign owner, log into Oracle Trade Management as Oracle Trade Management User.

Prerequisites:

• Assignment Manager must be implemented. See the Oracle Marketing Implementation Guide for instructions on implementing this feature.

• Territories must have been set up for assignment purposes.

Navigation: Claim > Claims > Claim Name.

Notes:

Select the Auto Assign Owner check box, and click Update.

Claim Approval

After creating and assigning a claim, you must submit the claim for approval. A claim can be settled only after it is approved by the designated approvers.

Information in this section will enable you to:

• Understand the claim approval process

• Initiate claim approval

• Approve claims

Understanding the Claim Approval Process

The claim settlement process begins after you submit a claim for approval. Claim approval rules determine the approval flow, and the submitted claim is routed to the designated approvers. Claim approvers may approve or reject a claim.

The claim status changes along with the approval flow. Claim statuses enable you to know the exact status of the claim at any point of time.

The following table describes the various statuses that a claim may go through.

Claim Statuses

Claim Status	Description
New	The claim status appears as New when it is created in Oracle Trade Management, but has not yet been researched upon. When a claim is created in Oracle Receivables, by default the claim status appears as Open.
Open	The claim status appears as Open when a you start the claim research process. The claim status may change to Complete, Pending Approval, or Pending Close.
Complete	You may manually change the claim status from Open to Complete. No approval is required to change the claim status from Open to Complete. It means that you have completed most of the research, but do not want to settle the claim immediately. When the claim status is Complete, you can request approval for the claim and initiate the settlement process. The claim status may change to either Pending Approval or Pending Close.
Pending Approval	You may request approval when the claim status is either Open or Complete. After you submit the claim for approval, if the approvers do not respond to the request, the claim status appears as Pending Approval. Depending on whether the approvers approve or reject the request, the claim status may change to either Approved, or Rejected. You cannot change this status to any other status.
Approved	The claim status changes to Approved after all the approvers approve the claim. This is a temporary status because the settlement process begins immediately after the claim is approved. The claim status may change to either Closed or Pending Close.
Rejected	The claim status changes to Rejected if the approvers reject the claim. You may manually change the status to Open and resubmit it for approval.
Pending Close	After a claim is approved, the claim status appears as Pending Close if the settlement process is not automated real time, but requires some concurrent process such as the Claim Settlement Fetcher to finish the claim processing. After the processing is complete, the claim status changes to Closed.
Closed	The claim status appears as Closed after the claim is settled.
Cancelled	The claim status can be updated to Cancelled only from Oracle Receivables and not from Oracle Trade Management. A claim cannot be settled when it is in the Cancelled status.

Submitting a Claim for Approval

To submit a claim for approval, log into Oracle Trade Management as Oracle Trade Management User.

As a prerequisite, an existing open claim should exist.

Navigation: Claim > Claims > Claim Name > Request Approval > Confirm.

After you submit the claim for approval, the claim approval rules determine the approval flow, and the submitted claim is routed to the designated approvers and they will receive a workflow notification.

Previewing Approval

The Preview Approval page enables you to review the information before you submit it for approval. You can see the list of approvers from the Preview Approval page.

• Click Confirm to submit the object (budget, offer, or claim) for approval. The request is routed to the designated approvers and they receive a workflow notification. The status of the object changes to Active after they approve the request.

• If you are the creator and approver of the object according to the approval rules, change the status of the object to Active and click Confirm.

Approving a Claim

When claims are submitted for approval, you will receive workflow notifications if you are the claim approver according to the approval rules.

To approve a claim, log into Oracle Trade Management as Oracle Trade Management Super User.

As a prerequisite, a claim must have been submitted for approval.

Navigation: Workflow > Worklist or Home > Tools > View Notification Work List.

Notes:

Select the notification that corresponds to the claim that must be approved, and click Approve.

Types of Approval Rules

You can set approval rules for:

• Earnings - Earnings approval rules are checked only if earning associated are over the threshold. The override threshold must be set to true in the Associate Earnings page.

• Performance - The Performance approval flag must be checked in Custom Setup. The profile OZF: Override Offer Performance Requirement must be set to No. Claims must have earnings associated and the associated offer must have a performance requirement.

• Claims - Claim must be checked in System Parameters.

Claim Research

Oracle Trade Management provides claim research tools, which you can use to obtain information about customers, transactions, and accruals that are associated with claims. You can view claim details, identify duplicate claims, split a claim and find the cause for the claim.

Information in this section will enable you to:

• View claim details

• Split claims

• Understand duplicate claims and related documents

• Understand the integration of the claims module with Oracle Discoverer

• Understand claim history and history rules

Viewing Claim Details

The claim details page includes the following information:

• Basic information including the claim number, date, type, reason, action, owner and status.

• Customer information including the customer name, account number, bill-to and ship-to addresses, contact, broker, sales representative, reference (customer debit memo) and reference date.

• Amount information including the claim amount, in both functional currency and transaction currency, and exchange rate information.

• Duplicate claim information that consists of a list of claims that might be duplicates of the claim that you are researching. If duplicate claims are discovered, then you can mark them as duplicate. Claims marked as duplicates are automatically closed.

• Auto assign owner information that includes details of owners who were automatically assigned to the claim based on the modifications made to the claim information.

Reverting Claim Status

For the check settlement method, Oracle Trade Management issues an invoice into the Payables system against which a check is issued to the vendor. When the check is created the claim is closed. Occasionally, a Payables invoice may be cancelled before it creates a check. For example, if the claim contains errors and the approver did not notice. In order to handle these type of exceptions:

• The Claim Settlement Fetcher concurrent program will find any cancellation on the AP invoice so that the claim status is changed back to open.

• In case of promotional claims, if the invoice is cancelled, the system will revert the status of the claim back to open.

• Any time an AP invoice is cancelled in Payables and the claim status reverts back to open, the system l records the activity on the claim’s history. This will provide you with an orientation on all actions performed on the claim.

• During check settlement, the claim number becomes the invoice number in Payables. Since this invoice number must be unique, if the invoice is cancelled and the same claim is settled once again with a check, the AP interface will send out an error message and append the invoice number with a suffix of “-1”.

  • For example, if claim CLA123 is settled with the check settlement method, it creates an invoice CLA123 in AP. If, for some reason, the invoice is cancelled in AP, the claim status reverts back to open in Trade Management. If the same claim is settled once again with a check settlement method, the system will add an invoice number of CLA123-1 in AP..

About Claim Split

Claim split enables you to split a claim into multiple smaller claims and facilitates the process of research and settlement. Split claims share the same master claim number, with the addition of a suffix as an identifier. When a claim is split, you can see the balance and the running total of the amount that is assigned to the new claims. If the entire amount of the claim is not allocated to the split claims, then the unassigned balance remains on the original claim. Splitting a claim enables you to:

• Settle only a part of a claim

  For example, a customer submits a claim for $10,000, but you can validate only $5,000. You split this claim into two claims, validate and settle one of them, and keep the remaining claim open for further investigation.

• Facilitate the investigation of a claim caused by multiple reasons

  For example, a customer submits a claim for $100,000 that is based on an audit of their records. After the initial investigation, you determine that it comprises of three earlier claims that the customer believes they never received payment for. To further investigate the claim, you split it into three claims to investigate each reason separately.

• Settle only the valid portion a claim

  Sometimes, customers may submit claims where only a part of the claim is valid. You can split such claims, verify, and settle the part you have verified. The other part of the claim may be left open for further investigation, or it may be charged back to the customer.

  For example, a customer submits a claim for a short shipment and to claim promotional discount. The promotional discount part is valid, but the short shipment part requires further investigation. You can split the claim into two claims, settle the one for the promotional discount, and leave the other claim open for further investigation.

The following example shows in more detail how a claim with multiple reasons might be split.

You send an invoice to a customer for $100,000. You receive a check for $20,000 that includes an $80,000 deduction. Because the customer does not give any reason for the deduction, you create a deduction in Oracle Receivables by using the default reason--Unknown.

After some investigation, you determine that the customer has deducted $30,000 for promotions, $40,000 due to shipping errors, and $10,000 due to pricing errors. You can split the claim one of two ways:

Deduction Number	Status	Amount	Reason
DED1	Cancelled	$0	Unknown
DED1_1	Open	$30,000	Promotions
DED1_2	Open	$40,000	Shipping Errors
DED1_3	Open	$10,000	Pricing Errors

Deduction Number	Status	Amount	Reason
DED1	Open	$30,000	Promotions
DED1_1	Open	$40,000	Shipping Errors
DED1_2	Open	$10,000	Pricing Errors

Notice that each claim number includes the original number of DED1. This number is used in Oracle Receivables for tracking purposes. All the outstanding balances and amounts that are processed for the root claim and each of the split claims are tracked in Oracle Trade Management.

Note: After a claim is split, the parent and the child claim are treated as separate claims during claim research. The fund balances in a child claim cannot be modified.

Rules for Splitting Claims With Claim Lines

The following guidelines and examples will help you split claims with claim lines. For the application to automatically split a line, the line amount must be for the full amount of the claim. In this example, the line is for less than the full amount; therefore, you must manually assign the line amount to the split claims.

For example, assume the total amount of a claim is $400.

• If there are no claim lines, then the claim can be split any way as long as the amounts still total $400.

• If there is a claim line for $300, then you can split the claim as follows:

  • Split it into two claims where Claim 1 = $350 and includes the claim line for $300, and Claim 2 = $50 with no claim line.

  • Split it into two claims where Claim 1 = $60 and has no claim line, and Claim 2 = $340 and includes the claim line for $300.

• If there is a Claim line for $400 (the claim total), then you can split claim line automatically as follows:

  • Split it into two claims where Claim 1 = $300 with a claim line of amount $300, and Claim 2 = $100 with a claim line of amount $100. You can do this by just giving the split claim amount $300 and $100 from the UI. You cannot use this functionality if the claim line has already been associated with earnings. If there are any associated earnings, you must manually adjust the association and split claim line first.

  • Split it into two claims where Claim 1 = $0 and has no claim line, and Claim 2 = $400 and includes the claim line for $400.

• If you have multiple claim lines whose sum is less than the total claim amount (for example Line 1 = $300 and Line 2 = $40), then you can split the claim as follows:

  • Split it into two claims where Claim 1 = $380 and includes Line 1 for $300 and Line 2 for $40, and Claim 2 = $20 with no claim lines.

  • Split it into two claims where Claim 1 = $350 and includes Line 1 for $300, and Claim 2 = $50 and includes Line 2 for $40.

  • Split it into two claims where Claim 1 = $30 and has no claim line, and Claim 2 = $370 and includes Line 1 for $300 and Line 2 for $40.

• If you have multiple claim lines whose sum equals the total claim amount (for example Line 1 = $300 and Line 2 = $100), then you can split the claim into two claims where Claim 1 = $100 and includes Line 2, and Claim 2 = $300 and includes Line 1.

Splitting a Claim

Splitting a claim into multiple smaller claims facilitates the process of research and settlement. You can split claims to settle only a portion of a claim, and to facilitate the investigation of a claim caused by multiple reasons. Split claims share the same master claim number, with the addition of a suffix as an identifier.

To split a claim, log into Oracle Trade Management as Oracle Trade Management User.

As a prerequisite, an open claim should exist.

Navigation: Claim > Claims > Claim Name > Split.

Notes:

• Claim Type and Reason: If you leave these fields blank, then the type and reason of the parent claim is defaulted.

• Amount: Enter the amount for the split claim.

• Line: Select a line if the claim has:

  • Multiple line amounts

  • A single line that is for less than the total claim amount

    You must explicitly assign line amounts to be split along with the claim. For information on rules for splitting claims with claim lines, see About Claim Split.

The new claims are generated after you click Update.

About Duplicate Claims and Related Documents

Sometimes, customers may raise multiple claims for the same transaction. There may also be multiple deductions referring to the same offer or invoice. These claims and deductions are termed as duplicate claims. Before settling a claim, you can search for duplicate claims and deductions based on the reference numbers or names. After you identify a duplicate claim, you can mark it as duplicate after which the duplicate claim is removed. You can also mark multiple claims as duplicate. Both the deduction and claim serve as a reference to each other for future audits.

The Related Documents side navigation link enables you to automatically search for related claims and gives you a summary view of all claims with similar or same customer debit memo numbers or invoice numbers, thus allowing you to identify duplicate or invalid customer claims more quickly.

For example, a customer deducts, and references the debit memo number as DM0123. Due to an error, the customer again deducts using the same debit memo but this time the number is read as DMO123 (the letter O instead of the number zero). When you access the Related Documents function, you can automatically see a listing all the claims with similar customer debit memo numbers. You can drill down into each of them and determine further if they are really duplicates.

Marking a Claim as Duplicate

Duplicate claims are multiple claims and deductions, which the customers raise against the same transactions and invoices.

To mark a claim as duplicate, log into Oracle Trade Management as Oracle Trade Management User.

As a prerequisite, an existing claim with duplicates should exist.

Navigation: Claim > Claims > Claim Name > Related Documents.

If any duplicate claims exist, they are displayed here.

Notes:

Verify if the information is duplicate and make a note of the claim numbers that have duplicate information. Click Main, and select the duplicate claim number in the Duplicate LOV, and Click Update.

Integration With Oracle Discoverer

Oracle Discoverer is a tool that you can access from Oracle Trade Management. Depending upon how Discoverer is implemented in your organization, it can be used as either:

• A query tool that enables you to create and view user workbooks to extract all the customer information from the database.

• A page with pre-defined reports that you select to run and refresh whenever reports must be updated.

The Oracle Workbook formats include:

• Simple table: data is displayed in columns

• Cross tab: data is displayed in rows and columns

• Page-detail table: data is displayed in columns and is grouped by items on the page axis

• Page-detail cross tab formats: data is displayed in both rows and columns and is grouped by items on page axis

You can view information from Oracle Discoverer only from the business areas and folders for which you have access. Claims users can typically access information from the Oracle Trade Management business area and the Claim Research folder. The seeded folder includes information such as Returns, Order Headers, Order Line Details, Checks, Invoice Payments, Deductions, Receivable Transactions, and Payables Invoices.

Discoverer supports many functions that enable you to manipulate your reports. These functions include filtering by conditions, sorting, calculations and functions such as sum, average, count, minimum and maximum, standard deviation and variance. The advanced features include graphing and scheduling. You can save a workbook in the database or export it as an HTML report or an Excel file.

About Claim History and History Rules

Claim history enables you to record various changes made to a claim during the course of investigation. The Administrator sets up history rules to define the fields and information that must be captured in Claim history.

After the history rules are set up, the system records all the changes that are made to the selected fields, and enables you to trace back all the changes that have been made to the claim. This provides every claim with a complete audit trail. If a customer conducts post-audit activities and disputes the resolution of different claims, the organization can produce complete documentation of all the changes that were made to the claim resulting in resolution for the disputes.

For example, History Rules may be created for a customer contact point. Every time the customer contact is changed, it is captured in Claim history. You are assigned to the claim and you interact with the customer contact--John during research and obtain certain information. Later on, John leaves the customer organization, and the new customer contact is Mary. You change the Contact field on the claim from John to Mary. Because this field is set up with History Rules, the change is automatically captured in the History of a claim. In future, if any disagreement arises over the information supplied by the customer, you can trace back that the information had come from the original contact person John.

Claim Settlement

Claim settlement is the process by which claims, deductions, and overpayments are settled. The claim settlement functions automate a majority of claim and deduction scenarios. For a claim created in Oracle Trade Management, checks and credit memos can be automatically created in the Oracle Payables and Oracle Receivables respectively for settlement.

With Auto-Resolution, organizations can automatically close out deductions, create corresponding Receivables transactions, apply the transactions, and enter accurate accounting entries as soon as the claim is settled in Oracle Trade Management. If the currency of the claim differs from the currency used by your organization to post accounting entries, then Oracle Trade Management can convert the claim amount to the proper currency. You can settle claims for Buying Groups and Related Customer Accounts

Note: If payout methods have been specified for an offer during offer creation, then you need not create a claim manually and specify the payment method. Such offers are settled automatically by the Autopay program.

Information in this section will enable you to:

• Understand Scan Data offer adjustments

• Understand promotional payments and work with the promotional payments view

• Understand the concept of paying earnings over thresholds

• Approve requests for unearned payments

• Understand the concept of mass settlement

• Net overpayments and deductions with debit items

• Understand and work with Autopay

• Understand Automatic Write-off

• Understand the concept of updating deductions based on subsequent receipts

• Understand claim settlement methods

• Understand standard memo lines

• Settle claims, debit claims, deductions, and overpayments

Understanding Scan Data Offer Adjustments

The Claims module is critical in managing the payment of Scan Data offers because the actual scan data is entered through claims. When the actual values of Scan Data offers exceed the committed amount or forecast values, the claim automatically adjusts the Scan Data accruals as required, including the committed and earned funds.

The committed and earned amounts in Scan Data offers are adjusted depending upon the fund utilization. The different types of automatic adjustments are discussed in the following sections.

Adjustments to Committed and Earned

Funds are committed to offers during offer creation. However, the amount that is earned from the offer may be more than the committed amount. When the actual data is submitted, you create a claim with at least one claim line. You associate the earnings from the claim line to the Scan Data offer, and enter the actual data in the appropriate Scan Data offer field. For the increase in the earned amount, the GL entries--Debit Sales, and Credit Liabilities are created and the committed and earned amounts are updated to show the new values.

For example, assume that a Scan Data offer was created for an organization as follows:

Product	Forecast Total Scan Value
Product A	$100,000
Product B	$80,000

The committed amount for this offer was $180,000. At the time the offer is created, the following accounting entries are made:

Debit Sales or Expense (Product A) $100,000 Credit Liabilities (Product A) $100,000

Debit Sales or Expense (Product B) $80,000 Credit Liabilities (Product B) $80,000

The Offer Checkbook appears as follows:

Committed	Earned	Paid
$180,000	$180,000	0

When the actual data is submitted, you create a claim with at least one claim line. You associate the earnings from the claim line to the scan data offer, and enter the actual data in the appropriate scan data offer field.

For this claim, the calculated actual units and values are as follows:

Product	Forecast Total Scan Value	Actual Total Scan Value
Product A	$100,000	$120,000
Product B	$80,000	$90,000

These numbers represent a $30,000 increase to both the committed and earned amounts. The following GL entries are created to account for the increase in the earned amount:

Debit Sales or Expenses (Product A) $20,000 Credit Liabilities (Product A) $20,000

Debit Sales or Expenses (Product B) $10,000 Credit Liabilities (Product B) $10,000

When the claim is settled, automatic adjustments are made to the committed and earned amounts. The Offer Checkbook looks as follows:

Committed	Earned	Paid
$210,000	$210,000	$210,000

Adjustments to Earned Only

The forecasted values for Scan Data offers may be less than the committed values. When the actual fund utilization of a Scan Data offer exceeds the forecasted values, the claim automatically adjusts earned funds.

For example, assume that the following Scan Data offer has been created:

Product	Forecast Total Scan Value
Product A	$100,000
Product B	$80,000

The committed amount for this offer was $200,000, whereas the forecasted total us $180,000. The Offer Checkbook looks as follows:

Committed	Earned	Paid
$200,000	$180,000	0

When the actual data is submitted, you enter the data in a claim. The calculated actual units and values are as follows:

Product	Forecast Total Scan Value	Actual Total Scan Value
Product A	$100,000	$110,000
Product B	$80,000	$85,000

This data represents no change in the committed amount, and an increase of the earned amount by $15,000. GL postings are created for the $15,000. When the claim is settled, an automatic adjustment is made to the earned amount, and the Offer Checkbook looks as follows:

Committed	Earned	Paid
$200,000	$195,000	$195,000

Scan Data Offer With No Adjustments

The fund earnings in a Scan Data offer may be less than the committed and forecasted amount. In such cases, when you create a claim, no adjustments are made to the committed and earned amounts. More data for the offer can be submitted at a later date. In cases where there is true under earnings, adjustments are made only if the Sales Management determines that no more actual data is expected and closes the offer. If this occurs, then you can reconcile the budget.

For example, assume that the following scan data offer has been created:

Product	Forecast Total Scan Value
Product A	$100,000
Product B	$80,000

The committed amount for this offer is $200,000. The Offer Checkbook appears as follows:

Committed	Earned	Paid
$200,000	$180,000	0

When actual data is submitted, you enter the data in a claim. The calculated actual units and values are:

Product	Forecast Total Scan Value	Actual Total Scan Value
Product A	$100,000	$70,000
Product B	$80,000	$40,000

This data represents no change to the committed and earned amounts. No GL entries are created because no adjustments are required. When the claim is settled, the Offer Checkbook looks as follows:

Committed	Earned	Paid
$200,000	$180,000	$110,000

Integration with E-Business Tax

Oracle Trade Management integrates with the E-Business Tax engine to get a tax quote. This provides information to claim analysts about the tax calculated by either AR/AP. Tax quote is asked before the claim is submitted for settlement.

Oracle Trade Management integrates with the E-Business Tax Engine to facilitate the claim settlement process by providing tax estimates to claim users. When a claim user researches or settles a claim, the E-Business Tax engine fetches the estimated tax amount. The claim user can use this information to validate the accuracy of the claim.

The Oracle E-Business Tax engine call enables you to estimate the tax amount of your claim. The estimate enables you to validate your research and look for the right information knowing the tax impact of the resulting resolutions.

In Oracle Trade Management instead of the existing tax codes on the claim lines screen, there are tax classification codes defined in the Oracle E-Business Tax application. The tax classification code values are determined by whether a settlement method integrates with Accounts Receivable or Accounts Payable. Based on the business process of an organization, the claims submitted by customers may be either inclusive or exclusive of taxes. Deductions and overpayments are generally inclusive of taxes.

Note: The tax quote provided by the E-Business Tax engine is only an estimate, which the claim user can use to validate a claim. The actual tax amount is calculated from Oracle Receivables, Oracle Payables, or Order Management, depending on the settlement method.

About Tax Classification Codes

Tax classification codes vary depending on their purpose, either Accounts Receivable or Accounts Payable. Tax codes are used for either:

• Oracle Receivables: a tax classification code known as "Output" is derived from the "ZX_OUTPUT_TAX_CLASSIFICATION" (Order to Cash O2C) lookup type.

• Oracle Payables: a tax classification code known as "Input" is derived from the "ZX_INPUT_TAX_CLASSIFICATION" Payment Flow (P2P) lookup type.

Tax Classification code varies depending on whether this settlement will go into an O2C flow or a P2P flow. Oracle Trade Management supports tax quote requests only for some settlement methods.

In Oracle Trade Management you can select whether you want to use the settlement method O2C or P2P to display either output or input taxes.

E-Business Tax Error Messages

The following E-Business Tax error messages are displayed in Oracle Trade Management:

• If you click the search icon for the tax classification code without selecting a settlement method or if you select an unsupported settlement method, the system displays the following error message:

  • “Tax Classification Code and Tax Actions are not available for this settlement method."

• If you select an Action and click Go without selecting a settlement method, select an unsupported settlement method or if you do not select a tax classification code:

  • " Tax Action not applicable."

About Paying Over Earnings by Thresholds

Promotional accruals are paid to customers through claims or deductions. When the payments are authorized, GL entries are created to reduce the accumulated promotional liabilities. Depending on the nature of the business, some customers may get paid more what they have accrued. The extra funds that are paid are know as unearned funds. This happens in cases where customers have long-term ongoing business deals with the manufacturer.

Depending on how Oracle Trade Management is implemented in your organization, and the Trade Profile settings for individual customers, you can pay customers more than what they have earned. You can track such payments so that customer balances are reflected accurately.

For example, a manufacturer creates a budget and gives an offer to a customer. The customer and the manufacturer have a long-term business relationship. The customer performs according to the offer terms and conditions, and accrues some earnings. The budget appears as follows:

Available	Committed	Utilized	Earned	Paid
$100,000	$10,000	$9,000	$9,000	0

The customer knows that the offer is ending in a few days, and plans to book some more orders in the next few days before the offer ends, and anticipates to earn another $1,000. In the meantime, the customer sends payments to the manufacturer, and deducts a total of $10,000.

The claims user in the manufacturing organization gets this deduction of $10,000. Because of the long-term business relationship that the customer and the manufacturer have, the user decides to pay the customer. The budget looks as follows:

Available	Committed	Utilized	Earned	Paid
$100,000	$10,000	$9,000	$9,000	$10,000

The Administrator can set up thresholds for such payments. Thresholds may be in terms of amounts based on various factors including the customer's last year same period sales performance, earnings on a similar offer on similar products, or the current year-to-date sales. Thresholds may also be a percentage of payments above the earned funds. If claims are within the thresholds, then you can settle them like any other regular promotional claims.

If unearned payments exceed the threshold amount or percentage, then depending upon the implementation setups, they may require approval. If approval is required, then you cannot settle a claim until the approvers approve the request for unearned payments.

Approving Requests for Unearned Payments

Requests for unearned payments may require approval when the amount exceeds the threshold amount or percentage. If you are the approver according to the approval rules, then you will receive a workflow notification when there are requests for unearned payments. The claims user cannot settle the claim until you approve the request.

To approve requests for unearned payments, log into Oracle Trade Management as Oracle Trade Management Super User.

As a prerequisite, a request for unearned payments must have been submitted for approval.

Navigation: Workflow > Worklist or Home > Tools > View Notification Work List.

Notes: Select the notification that corresponds to the unearned payments that must be approved, and click Approve.

About Autopay

Autopay enables you to automate payments for promotional accruals. When autopay is set up, it automatically creates claims, associates claims with the customer's accruals, and settles the claims as designated (credit memo or check).

For example, you request your Administrator to set up autopay to issue a credit memo for promotional accruals to a customer every two weeks. Every two weeks, autopay checks the customer's accrual balance. The balance for this period is $100, 000 earned and $80,000 paid, leaving an outstanding balance of $20,000.

Autopay automatically creates a claim for the customer, associates it with the $20,000 balance, selects credit memo as the settlement method, and initiates the settlement process. The settlement process begins with claim approval and ends with the generation of a credit memo for $20,000 and closure of the claim. Because the customer knows that the organization issues a credit memo every two weeks, it is less likely that the customer will deduct from payments to your organization.

If Autopay is setup, before creating claims and making payments, it checks whether payments must be made according to the payout dates specified in the offer, or according to the dates and frequency set up in the regular Autopay schedule. It also checks if any payment methods and payment preference in terms of time have been specified in the offer, and makes payments accordingly.

If performance requirements have been specified for offers, Autopay creates and processes claims only for those offers for which performance has been verified. Performance proof may be in the form of electronic files, images or based on physical inspection of the retailer's premises. Upon verifying performance, you can update the performance flags in an offer. Where there are multiple performance criteria, Autopay processes payments for the offer only after you verify all the performance requirements.

Customers will be eligible for autopay depending if the Autopay option is checked in the individual Trade Profiles.

Running and Scheduling Autopay

When you run autopay, claims are automatically created and associated with the customer's accruals. The claims are settled as designated (credit memo or check).

To run Autopay, log into Oracle Trade Management as Oracle Trade Management Super User.

Prerequisites

• Claims with the status of Open or Completed must exist.

• Autopay must be implemented.

Navigation: Claim > Autopay > Submit Request.

Notes:

• Request Name: Enter a name for the request. You will use this name to identify this request at a later point of time.

• Run Mode: The values available are:

  • All Offers: All the offers will be settled.

  • Offers with Autopay: Only those offers for which Autopay has been marked will be settled.

  • Offers without Autopay: Only those offers for which Autopay has not been marked will be settled.

• Activity Type: The Activity Type that you select determines the reason for which the claim is being settled.

• Start Date: To manually specify the schedule for running the request, select one of the following options in the Start Date field:

  Important: Skip this step if you wish to run the request based on a preset schedule.

  • As soon as possible: the request runs immediately.

  • Start at specific date: the request runs on the specified date.

  • In the Recurrence region, choose either Repeat or Never Repeat. If you select Repeat, then the request will be run based on the frequency that you specify

• Schedule Name Region: To run the request based on a preset schedule, select the schedule in the Schedule Name region. The request will be run based on the settings that have been made in the schedule

• Increment Date Parameters check box: If you check this option, then the recurring date parameters will be incremented by the repeat interval.

Viewing Autopay Request and Autopay Log

After running Autopay, you can view the Autopay Request and the Autopay Log to know if there were any errors encountered in the process.

To view Autopay Request and Autopay Log, log into Oracle Trade Management as Oracle Trade Management User.

As a prerequisite, an Autopay request must have been submitted.

Navigation: Claim > Autopay > View Request.

Notes:

• Details: Displays the details or log of the request. The Request Details page gives you a summary of the request including the parameters that were set while running the request, notifications if any, and other details.

• View Log: Displays the Autopay Log.

Understanding Automatic Write-off

When customers submit claims or take deductions, they may charge more than what they are supposed to claim or deduct. But the differences in the amount may be so small that it may not be worth spending time and resources to research them. You can decide not to spend time on researching the claim, and settle it with a write-off. When you settle claims with a write-off, it means that your organization is absorbing these costs as expenses.

Automatic write-off enables you to automatically identify claims, deductions, or overpayments that are eligible for write-off. The Administrator sets threshold limits for deductions as well as overpayments. Whenever a customer deducts or overpays, if the claim amount falls within the threshold limits, then the claims are automatically checked for automatic write-off. If required, you can manually uncheck these claims and investigate them, or settle them later.

For example, a manufacturer creates an automatic write-off threshold for $200. Claims with differences of less than $200 are checked automatically for write-off. The claims manager reviews these claims and notices that a particular customer has massive deductions slightly below the threshold, and unchecks these claims for automatic write-off to investigate them.

Claims that are originally over the threshold limit, but for various reasons have their amounts reduced, will not be automatically checked for write-off. Even if you manually check such claims, they are still treated as claims over the thresholds, and they require approval. Claims that are originally over the threshold limit, but have been split later on to smaller pieces, are still treated as claims over the threshold limit.

For example, in an organization, the write-off threshold for deduction is $200. A deduction comes in for $300. This deduction is then split into $100, $150 and $50. These split deductions are still treated as over the threshold limit. You can manually check these claims for automatic write-off, but they require approval.

The process of settling claims through write-off depends upon the type of claim or deduction.

• Transaction related deductions

  A write-off adjustment is created in Oracle Receivables. The disputed amount on the transaction is reduced and the claim is closed.

• Non-transaction related deductions

  A negative write-off line is created in Oracle Receivables. The claim is closed in Oracle Trade Management.

• Overpayments

  A positive write-off line is created in Oracle Receivables. The claim is closed in Oracle Trade Management After the claim is settled, the auto write-off check box will be read-only.

• Special cases

  After you uncheck claims that are under the thresholds, they will not be automatically checked again. You may however manually recheck these claims for automatic write-off as long as the claim status is Open. These claims are treated as claims that are under the threshold limits. After investigation, if you wish to still settle the claim with a write-off, then you must settle the claim through the claim settlement page.

When a claim is settled through a write-off, the expenses may need to be absorbed by different departments. On the claim settlement page, you can select the department to which a claim belongs to and the write-off amount is posted to the specified GL account.

Viewing Claims Eligible for Automatic Write-off

To view claims that are eligible for automatic write-off, and manually update the write-off flag against these claims, log into Oracle Trade Management as Oracle Trade Management User.

As a prerequisite, claims must exist.

Navigation: Claim > Claims > Personalize.

Notes:

• Available Column: Move the Write-off Flag to the Displayed Column.

• Save Search As: Enter a name for the search.

After you save the search, the Claims page appears. Claims that are eligible for automatic write-off, are marked. Optionally, to update the write-off flags for claims, manually check or uncheck the corresponding check boxes.

Note: You can update the write-off flags only for Claims that are in the Open status. The write-off check box will be disabled for claims that are in the other statuses; you cannot update these.

About Updating Deductions Based on Subsequent Receipts

When customers make subsequent payments for a single invoice, then the original deduction is updated based on the subsequent payments received. However, the manner in which the deduction gets updated depends on whether the deduction is transaction-related or non-transaction related, and the status of the previous deduction.

Transaction Related Deduction Without Splits

Transaction-related deductions can be traced back to an invoice, order, or an offer. If a previous deduction exists for the transaction and is not split, then the process will be different depending on the status of the previous deduction. The manner in which subsequent payments are processed during different statuses of the original claim is as follows:

• Open

  When the claim or deduction status is open, the remaining amount in the deduction is reduced by the subsequent receipt amount. The corresponding disputed amount on the transaction is also reduced.

  For example, an invoice is created for $500. The customer initially pays $350. This creates a deduction for $150 in Oracle Trade Management. The customer then pays $100 towards the same invoice, and the status of the original deduction is Open. Now, the original deduction that was created for $150 gets updated accordingly and shows $50 ($150 - $100) as the deduction amount. This means that the customer owes only $50.

  When the remaining amount in the deduction is reduced to zero, the status changes to Cancelled. Even if the subsequent payments made by the customer sum up to more than the invoice amount, the deduction will not be converted into an overpayment because the status changes to Cancelled as soon as the deduction amount is reduced to zero.

• Complete

  If subsequent payments are received when the status of the original deduction is Complete, then the status of the deduction changes from Complete to Open. After the status changes to Open, the remaining amount in the deduction is reduced by the subsequent receipt amount. The corresponding disputed amount on the transaction is also reduced. When the remaining amount in the deduction is reduced to zero, the status changes to Cancelled.

• Rejected

  If subsequent payments are received when the status of the original deduction is Rejected, then the status of the deduction changes from Rejected to Open. After the status changes to Open, the remaining amount in the deduction is reduced by the subsequent receipt amount. The corresponding disputed amount on the transaction is also reduced. When the remaining amount in the deduction is reduced to zero, the status changes to Cancelled.

  When the claim is resubmitted for approval and the settlement is restarted, the current amount and details of the claim are used to find the appropriate approvers.

  For example, the original deduction was for $10,000. It was sent to the Director for approval, and was rejected. The claim status changes to Rejected. A subsequent receipt amount is later applied to the deduction. The claim status changes from Rejected to Open, and the deduction amount reduces to $8000. The claims user restarts the approval and settlement process. Based on the fact that the deduction is now only $8000, it requires a lower level of approval and is only sent to the Manager for approval instead of the Director.

• Pending Approval or Approved

  If subsequent payments are received when the status of the original deduction is Pending Approval, then the status of the deduction changes from Pending Approval to Open. If the payments are received when the status is Approved, the status changes from Approved to Open. After the status changes to Open, the remaining amount in the deduction is reduced by the subsequent receipt amount. The corresponding disputed amount on the transaction is also reduced. When the remaining amount in the deduction is reduced to zero, the status changes to Cancelled.

  When the claim is resubmitted for approval and the settlement is restarted, the current amount and details of the claim are used to find the appropriate approvers.

  If any approver has already approved the deduction before this happens, these approvers receive notifications.

• Pending Close

  The original deduction is not updated when the status of the deduction is Pending Approval. This is because when the claim status is Pending Close, it means that the deduction has already been approved, and is currently undergoing the settlement process

  For example, a credit memo may already have been generated through the AutoInvoice program. In such cases, if a subsequent receipt is applied to the original transaction, the customer will be over credited.

• Closed or Cancelled

  The original deduction is not updated when the status of the deduction is Closed or Cancelled.

  When the status of the original claim changes to Open (in cases where the status is Complete, Rejected, Pending Approval, or Approved), the re-open flag is checked to inform users that due to some changes to the transaction and deduction balance, the claim status has been modified. This enables users to know that the claim details have changed since the last time they worked on it.

Every time a customer makes subsequent payments, the claim owner receives a workflow notification. You can drill down back to the Claim Details page by clicking the claim number in the notification. The deduction keeps an audit trail of all receipts affecting it at any point of time.

Transaction-Related Deduction With Splits

If a previous deduction exists for a transaction and has been split, the original deduction or root deduction, which is still referenced in Oracle Receivables and the child deductions, which are not referenced in Oracle Receivables but maintained in Trade Management) may be at various statuses. Therefore, when subsequent receipts are received for a deduction that has been split, the balances of multiple deductions may need to be reduced. The manner in which these child deductions get processed will be determined by their statuses. However, the sequence in which the amount will be reduced will be prioritized based on status as follows:

1. Open

2. Complete

3. Rejected

4. Pending Approval

5. Approved

In the following example, the root deduction has not been completely split out and is still in Open status.

Receipt 1. A root deduction DED1 of $10,000 is created, originally of unknown reason, was found to be due to different causes upon investigations, and was therefore split into multiple child deductions.

Deduction	Claim Reason	Remaining Amount	Status
DED 1	Unknown	$2,000	Open
DED 1_1	Shipping	$5,000	Pending Close
DED 1_2	Promotions	$2,500	Pending Approval
DED 1_3	Pricing Errors	$500	Open

Receipt 2. After the deduction was created and split, subsequently, another receipt is applied on the transaction for $3,000. Based on the status prioritization, therefore, it will only reduce the balances for the following deductions in the following order:

1. DED1

2. DED 1_3

3. DED 1_2

The balances in each of the deductions is reduced as follows. The claim status changes accordingly.

Deduction	Claim Reason	Remaining Amount	Status
DED 1	Unknown	$0	Cancelled
DED 1_1	Shipping	$5,000	Pending Close
DED 1_2	Promotions	$2,000	Open
DED 1_3	Pricing Errors	$0	Cancelled

Receipt 3. Another receipt for $1,000 comes in and is applied on the transaction. Now only DED1_2 will be updated.

Deduction	Claim Reason	Remaining Amount	Status
DED 1	Unknown	$0	Cancelled
DED 1_1	Shipping	$5,000	Pending Close
DED 1_2	Promotions	$1,000	Open
DED 1_3	Pricing Errors	$0	Cancelled

If there are no more subsequent receipts, DED 1_2 will be processed further and will be submitted for approval. The status changes along with the approval flow. No subsequent receipts can be applied after the status changes to Pending Close.

Creating a Non-transaction Related Deduction

Non-transaction related deductions are those which cannot be traced back to a transaction. Non-transaction related deductions occur when instead of submitting claims, customers deduct money from their payments to manufacturers. In case of a non-transaction related deduction, all the information such as the receipt number, receipt date, receipt amount, customer information and transaction information is captured from Oracle Receivables and passed to Oracle Trade Management. Customer debit memo numbers and claim reasons may also be passed to Oracle Trade Management. Deductions support related customer accounts and buying group promotions. Non-transaction related deductions are created in Oracle Receivables.

Prerequisites

A deduction that can be traced back to a specific transaction.

Steps

Note: As part of the cash application process, the Oracle Receivables user may need to perform additional data entry tasks. These steps present only one way to enter a non-transaction related deduction. See the Oracle Receivables User Guide for information on the different ways of entering non-transaction deductions.

1. Log in to Oracle Receivables as Oracle Receivables user and navigate to Receipts > Receipts.

2. Enter a Receipt Number. If necessary, change the Receipt Type to Cash, and change the Currency Code.

   The receipt number can be the customer check number or other reference number.

3. Enter a Receipt Amount. If necessary, change the Receipt Date and the GL date.

   Receipt amount is the amount the customer has paid.

4. Select a Payment Method.

5. Enter the Customer Name, and optionally enter a Reference and enter Comments.

   This information is passed to Oracle Trade Management when the deduction is created.

6. Click Applications.

7. Select Claim Investigation in the Apply To field.

   The available values are open transactions and some seeded Oracle Receivables activities. Claim Investigation is seeded specifically to create non-transaction related deductions (or overpayments) in Oracle 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.

8. Enter the deduction amount as a negative number in the Amount Applied field.

9. If necessary, select Oracle Trade Management Claim in the Reference Type field.

10. Select a reason in the Reference Reason field.

    The values available here are the same values that are available in Oracle Trade Management. If a customer indicates the reason for which they have made the deduction, this information can be captured when the cash application is created in Oracle Receivables, and be passed to Oracle Trade Management.

11. Enter a Customer Reference.

    If the customer indicates an internal debit memo number, it can be captured here and passed to Oracle Trade Management.

12. Select an Activity.

    The activity selected here drives the GL entries to account for the discrepancy between the cash received and the receivables amount. For example, Receipt = $10,000; Total balance of multiple invoices that the customer is paying for is $15,000.

    A non-transaction related deduction is created for $5,000. The following accounting entries are created:

    Debit Cash $10,000.

    Debit Claim Investigation Activity $5,000.

    Credit Receivables $15,000.

13. Click Save.

    Notice that a deduction number appears in the Reference Number field.

About Promotional Payments

The Promotional Payments tab gives a summary of the accumulated promotional accruals for all the customers that your organization deals with. Promotional accruals are the accruals that are created when customers place orders against offers. These are the discounts that the customers are eligible to receive. Customers may claim these accruals either by submitting claims or taking deductions.

By using the Promotional Payments tab, you can:

• Search for accruals that are related to a particular offer type.

• Search for accruals that are related to direct sales or indirect sales.

• Search for accruals by customer name, product category, and for a given date range.

• Compare the current earned, paid, and balance amounts with the respective amounts in the previous year.

• Create claims and initiate payment for selected customers.

The following table describes the columns that are displayed in the Promotional Payments page. All this information is displayed for each customer.

Promotional Payment Views

Column	Description
Earned	Total amount that the customer has earned.
Paid	Total amount corresponding to the customer's claims that have been settled and paid.
Balance	This is the amount that is payable to the customer. Balance = Earned - Paid.
Open Claims	Total amount corresponding to the customer's claims that are still in the process of settlement.
Last Year Same Period Earned	Total amount that the customer has earned in the same period in the previous year.
Last Year Total Earned	Total amount that the customer has earned during the previous year.

Searching for Accruals from the Promotional Payments Tab

From the Promotional Payments tab, you can search for the total promotional accruals for all customers for specific criteria such as Offer Type, Activity Type, Channel of Sales, Product Category, Customer, Start Date, and End Date.

To search for accruals, log into Oracle Trade Management as Oracle Trade Management User.

As a prerequisite, customers and business transactions should exist.

Navigation: Claim > Promotional Payments.

Notes:

• Search Region: Select values for the fields depending upon what you wish to search for. For example, to search for all the accruals related to all offers of a specific offer type, say Lump sum offers, select Lump sum from the Offer Type drop-down list. Click Go to display the list of claims that match the specified criteria.

• Search Query to Filter Data in the Table Region: Enter a query to filter the search results and display them.

Creating and Settling Claims from the Promotional Payments Tab

To create and settle claims from the Promotional Payments tab, log into Oracle trade Management as Oracle Trade Management User.

You can create claims from the promotional payments tab in the following two ways:

• By drilling down the Open Claims link against the customer for whom you would like to create the claim.

• By clicking the Pay button.

As a prerequisite, existing customers and transactions should exist.

Navigation: Claim > Promotional Payments.

Notes:

• Creating Claims:

  • Single Customer: To create claims for a single customer, click the link in the corresponding Open Claims column against the respective customer.

  • Multiple Customers: To create claims and initiate payments on a single screen for multiple customers, select the customers by checking the respective check boxes.

• Initiating Payment

  • Pay: Click Pay. In the Earnings Payment page, you can find out from here details such as the payment frequency (Annual, Quarterly, monthly, and so on), Last Paid Date, and also find out whether the customers are eligible to receive payments or not.

  • Initiate Payment and Create Claim: Select the Initiate Payment option and Create Claim option to create claims and initiate payment.

Claims are created and workflow notifications are sent to the designated approvers. Payments are made after the requests are approved.

To view the claims that have been created, drill down the Open Claims link against the customer for whom you have created claims. All the existing claims and the new claims that you have created are listed here.

Understanding Mass Settlement (Netting of Overpayments)

In B2B businesses, manufacturers and retailers have complex ongoing business transactions. Sometimes when the customers make payments, it may be difficult to know the exact reason for which they are making the payment. In some cases, such as when the transaction number is wrong, overpayments may be created.

When these overpayments are investigated, you may find that the overpaid amounts were meant to pay back for some transactions (debit items). The Mass Settlement function enables you to apply the overpaid amounts to such debit items.

For example, a customer receives an Invoice with the number 100080. However, the remittance amount refers to the invoice as 10008O (letter o instead of number 0). When your organization receives this payment, this invoice number will not be identified in Oracle Receivables, and therefore an overpayment will be created. You then realize that the invoice has been incorrectly entered as 10008O instead of 100080. You can settle the overpayment claim by applying the "overpaid" amount to the debit item 100080.

• During netting, the overpayments can be applied only up to the balance of the item.

• You cannot use the Mass Settlement function to settle deductions with associated earnings.

The Mass Settlement functionality enables you to create groups out of overpayments and deductions related to a customer, apply them to the customer's open transactions, and settle the overpayments and deductions on one screen. You can also specify multiple payment methods.

After netting a claim with the debit items, transactions, or other Oracle Receivables items, there may still be some remaining amount that must be settled.

For example, a customer may deduct for returns. During investigation, you may find that multiple credit memos have already been issued as a result of the RMAs that have been entered in Order Management. You can close the deduction by netting the credit memos to the deduction. However, there may still be some balance amount.

If the balance is an overpayment balance, then you can settle it through credit- on account, or write-off. If the balance is a deduction balance, then you can settle it through chargeback, or write-off.

You can perform netting and settling of balances at different times depending on how you investigate or how long it takes you to investigate the claim. The netted amount must however be approved by the designated approvers, according to the setups in your organization.

Netting Overpayments and Deductions With Debit Items

To net overpayments and log into Oracle Trade Management as Oracle Trade Management User, and use the following high-level procedure.

Navigation: Claim > Mass Settlement > Create.

Notes:

• Search Region: In the Search region, select the customer for whom you would like to net the overpayments. Search for Open Claims by selecting the Claim Type, Reason, Source Object Number, Receipt Number, or the Claim Number.

• Open Transactions: Search for Open Transactions by selecting the Batch Source, Transaction Class, Transaction Type, and Transaction Number.

  All the open transactions that match with the selected attributes are listed in the Open Transactions region. Sometimes, when you search for open transactions, the list of invoices may appear. You can display open transactions such as debit memos by further conducting a search.

• Open Claims Region: Select the transactions that you would like to settle.

  When you select an open claim, the amount field gets populated with the amount that must be settled. You can also enter a partial amount from the transaction. For example, the remaining amount from a deduction may be $1000, but you can choose to settle only $600.

• Calculate: Select this option:

  • After selecting the transaction lines and amounts that must be settled, select this option to calculate the sub total of the open claims that you have selected for settlement.

  • After selecting the transaction or debit item in the Open Transactions field. These are the debit items with which you will settle the claims. This calculates the sub total for the open transactions as well as the net amount of the settlement group. It is the sub total of open claims minus the sub total of open transactions. If there is any remaining amount, the amount must be split during settlement.

• Settlement Region: In the Settlement region, you can either settle the entire amount, or split the amount and choose different settlement methods.

Claim Settlement Methods

There are various claim settlement methods that are available in Oracle Trade Management. The settlement method that you can use depends upon the claim type. The following table describes the various settlement methods that are available in Oracle Trade Management.

Note: When a claim is not related to any promotions, and you wish to settle the claim with a credit memo or a debit memo, you can use memo lines to settle the claim. See About Standard Memo Lines for more information.

Navigation: Trade Management: Administration > Trade Management > Claim > Claim Source Setup > Available Settlements Methods

Claim Settlement Methods

Settlement Method	Description
Check	Claim is settled by issuing a check to the customer.
Invoice credit memo	Invoice credit memos reduce a customer's invoice balance to settle a valid deduction.
On-account credit memo	On-account credit memos reduce a customer's account balance to settle a valid deduction.
Previous on-account credit memo	Previous on-account credit memo is an on-account credit memo that exists in Oracle Receivables, and is still open. If there is an existing credit memo, then you need not create a new credit memo. You can instead select the existing credit memo to reduce a customer's balance and settle a valid deduction.
Write-off	Write-off enables you to settle valid deductions and overpayments. You can write off deductions if they are so small that it is not worth to spend time and resources to research them. When you settle a deduction with a write-off, it means that your organization is absorbing the claim amount or deduction as an expense. On the other hand, you can settle an overpayment with a write-off, when the overpayment is significantly small. In this case, customers will lose the amount that they have overpaid.
Return Material Authorization (RMA)	RMA is issued to handle valid product returns (damaged goods, faulty equipment, and so on). When you create an RMA, a credit memo is generated to settle the deduction.
AR-AP Netting (formerly Contra Charge)	The AR-AP Netting settlement method is available for deduction and overpayment. When selected for settlement, it sends out a workflow notification to users with a Netting responsibility to notify them to manually run the netting batch process.
Previous Open Credit Memo Settlement	This settlement method is available on claims and deductions When you use this settlement method, the previous open credit memo field will become mandatory. Although the field itself is not indicated as a mandatory field (marked with ‘*’) on the screen, the validation is triggered when you settle the claim with the previous open credit memo settlement method.
Previous Open Debit Memo Settlement	This settlement method is available on debit claims and overpayments. When you use this settlement method, the previous open credit memo field will become mandatory. Although the field itself is not indicated as a mandatory field (marked with ‘*’) on the screen, the validation is triggered when you settle the claim with the previous open credit memo settlement method.
Configurable Settlement Method for Autopay	Autopay enables automatic payments for accruals. When autopay is set up and runs, the system automatically creates claims, associates with accruals, and settles them with the payment method set up in Trade Profile. In Trade Profile, companies can set up a custom settlement for autopay claims. This function is useful when Trade Management is implemented stand-alone and payments need to be routed to third party systems.
Wire Transfer	When a claim is settled with a wire transfer settlement method, the invoice generated in Payables displays payment method of ‘Wire’.
Electronic Transfer	Electronic transfer refers to electronic fund transfer and is a payment method used in Payables to compensate suppliers/vendors. This new settlement method is similar to the existing check settlement method. When a claim is settled with an electronic transfer settlement method, the invoice generated in Payables displays a payment method of ‘Electronic’
Accounts Default Payment	A payment method can be associated with every supplier site. The payment method specified on the supplier site suggests the payment preference and can be used to default a payment method on the invoices generated for the supplier. The payment method associated with the supplier can be check, clearing, electronic, or wire. The accounts default payment allows the system to decide, based on the payment preferences setup on supplier site, what the default payment method for invoices interfaced in Accounts Payable should be. Details include : When a claim is settled with Accounts Payable default payment settlement method, the invoice interfaced into Payables will have no value for the payment method field and instead will allow Payables to default the supplier site’s payment method.

Custom Settlement Methods

Configurable Settlement Enhancements - Configurable settlement workflow allows companies to create custom settlement methods in addition to the seeded methods. You can settle promotional claims with the custom settlement method.

About Standard Memo Lines

When a claim or deduction is not related to any promotions, and upon validations, you wish to settle it with a credit memo or debit memo, Oracle Trade Management integrates with Oracle Receivables to account these transactions. The Autoinvoice program in Oracle Receivables depends on the autoaccounting setups to find the correct GL accounts.

Standard memo lines are commonly used by companies in auto-accounting setups for items which are not part of their normal inventory. You can pass a memo line to Oracle Receivables, thereby enabling the auto accounting setups. Memo lines can be used when you settle claims with either a credit memo or a debit memo. Standard Memo Lines can be an input into autoaccounting in Oracle Receivables to account for freight, revenue, autoinvoice clearing, tax, unbilled receivable, and unearned revenue.

To settle claim or a deduction with a standard memo line, you must select "Memo Lines" from the setup type drop-down list in the Claim Creation page. You can view the list of all the active memo lines that have been created for the operating unit of the claim. After you select a particular memo line, the other fields on the same claim line will be affected:

• If the memo line was set up with any Unit List Price, the price will default into the Price field on the claim line. You can override this.

• The "Line/Product" LOV becomes blank.

You can still access Associate Earnings from this claim line, but if earnings have been associated, then the memo line information is replaced by the associated earnings information. For example, the claim line may show the inventory item number instead of the memo line.

Validation

The validation process for standard memo lines includes the following:

• Validation of Associate Earnings

  Where standard lines are used in Autoaccounting setups for the revenue account the following may occur:

  • If the "Post to GL" flag is checked in System Parameters, and a claim line has associated earnings, then the Oracle Receivables Clearing account from the Claim Type or System Parameters will be passed to Oracle Receivables as the "Revenue" account when the credit memo and debit memo are created through Autoinvoice. Memo lines are not used or passed in such cases.

  • If the "Post to GL" flag is not checked in System Parameters, but a claim line has associated earnings, then the claim line references an inventory item. If not, the system gives an error message.

• Validation of Autoaccounting Setup

  From Auto accounting setups, if the memo line is used to derive the revenue account, then when you initiate claim settlement by submitting it for approval, each of the claim lines are validated to check if either an inventory item or a memo line has been selected. If any of the claim lines does not contain either of these, the system gives an error message.

Settling Claims for Related Customer Accounts

Sometimes you may want to settle claims for accounts that are related to the customer. Related Customer accounts are set up with relationships; common relationships include bill-to and ship-to.

To settle claims for related customer accounts, log into Oracle Trade Management as Oracle Trade Management User.

As a prerequisite, a claim with a status of Open or Complete should exist.

Navigation: Claim > Claims > Claim Name > Settlement.

Notes:

• Pay Related Customer: Select this check box. Select the Relationship Type (parent, reciprocal, or all), the Related Customer, and the Related Site.

Submit the claim for approval.

Settling Promotional Claims for Buying Groups

Buying groups are formed when organizations group themselves to leverage their buying power. During claim settlement, you can view the buying group member accruals and decide whether to issue payment to the buying group, or directly to one of its members.

To settle promotional claims for buying groups, log into Oracle Trade Management as Oracle Trade Management User.

Prerequisites:

• Buying groups and members must be set up.

• A promotional claim for a buying group with a status of Open or Complete.

Navigation: Claim > Claims > Claim Name > Lines.

Notes:

• Claim Lines: Create claim lines as necessary, and click Update. See Creating Claim Lines for information on creating claim lines.

• Associate Earnings: In the Associate Earnings icon corresponding to the required claim line, select the following:

  • Buying Group: the values that are available depend upon where the customer is in the buying group hierarchy.

  • Display Children: the accruals for the buying group members are displayed.

    After associating earnings, navigate to Settlement.

• Settlement Method: Select Credit Memo - On Account as settlement method.

Submit the claim for approval.

Settling Claims, Debit Claims, Deductions, and Overpayments

Use the following high level procedure to settle claims, deductions, and overpayments.

Prerequisites:

• An existing claim or deduction with a status of Open or Complete.

• Oracle Receivables should be set up.

• Oracle Payables should be set up for settlement with contra charge

Navigation: Claim > Claims > Claim Name > Lines.

1. Navigate to Claim Lines and verify if the claim has lines. The claim should have at least one claim line with a positive value. If a claim line does not exist, create one now. See Creating Claim Lines for information on creating claim lines. The sum of the claim lines can be less than the total claim amount, as taxes will be added.

2. Optionally, verify if earnings have been associated to the claim line. You will see a check mark in the Associate Earnings column if earnings are associated.

3. Navigate to the Settlement page, and complete any additional fields as required.

4. Submit the claim for approval.

The following table describes the settlement methods and certain specific steps that you may need to complete based on the settlement method that you select.

Claim Settlement Methods and Additional Notes for Settlement

Settlement Method	Claim Class	Additional Notes
On-account credit memo	Used to settle claims and deductions.	-NA-
Check	Used to settle claims.	Post-approval: The claim information is interfaced to Oracle Payables. The Payables Invoice Import Program transfers the interface information into Oracle Payables to create an invoice. The Payables clerk issues checks against the invoice. The Claim Settlement Fetcher program updates the settlement documents with the check payment details. The claim is closed after the invoice is paid.
Invoice-credit	Used to settle claims.	Notes: Verify that an invoice number is entered in a claim line. The tax code used is the one used on the invoice. Post-approval: The invoice credit memo is created and claim is closed under the following conditions: Multiple invoices are credited. Individual claim lines credit in different manners. For example one claim line credits a specific Line Number, whereas another claim line gives credit to specific type or gives credit to Total Amount, and so on. A notification is sent to Receivable role. The Receivables clerk credits the invoice and enters the credit memo transaction number in the notification. The claim is closed if the transaction number is valid.
Debit Memo	Used to settle debit claims and overpayments.	Post-approval: The claim details are interfaced to Oracle Receivables as debit memos. The Autoinvoice Import program transfers this information into Oracle Receivables. The Claims Settlement Fetcher program updates the settlement documents with the debit memo details and closes the claim.
Previous Credit Memo	Used to settle transaction-related and non-transaction related deductions.	Notes: As an additional prerequisite, a credit memo, which can be used to settle the deduction should exist. In the settlement page, from the Previous Open Credit Memo LOV, select a credit memo with a large enough balance to offset the deduction. Use the transaction number, transaction type, location, source, or reference to search for the credit memo. Notice that you can see the balance due, GL date, and transaction dates for the credit memos. Post-approval: The deduction is unapplied, and the previous open credit memo is applied to the receipt. The overpayment is closed online.
Invoice Credit or Invoice Line Credit	Invoice credit is used for settling transaction-related and non-transaction related deductions. It cannot be used to settle promotion-related deductions. Invoice line credit is used to settle transaction-related deductions that occurred because of reasons that can be traced back to specific invoice line items. The deductions cannot be promotion-related.	Notes: If this is an invoice credit, then verify that an invoice number is entered in a claim line, the invoice line is selected, and the line amount is a positive value. If this is not an invoice credit, then create a claim line. For a transaction-related deduction, this invoice number must be the same as the one on which the deduction was created. For a non-transaction-related deduction, this invoice number must be on the same receipt as the deduction. If the invoice numbers do not match, then the settlement is not automated. Instead, a manual settlement workflow is initiated and notification is sent to any Oracle Receivables user with the Receivables Role responsibility. If this is an invoice line credit, then verify that an invoice number is entered in a claim line, Multiple invoice lines can be entered, each as a separate claim line. The sum of the claim line amounts must equal the total claim amount. Post-approval: The invoice credit memo is created and deduction is closed under the following conditions: For transaction related deductions, credit is to a non-source invoice. For non transaction related deductions, credit is to an invoice not on the source receipt. The Receivables clerk receives a notification, credits the invoice and enters the credit memo transaction on the notification. The claim is closed if the transaction number is a valid.
Invoice Tax Only Credit	Used to settle deductions that occurred because of tax calculation errors. The deductions can be transaction-related; they cannot be related to a promotion.	Notes: Verify that an invoice number is entered in a claim line. If not, select an invoice number now. For a transaction-related deduction, this invoice number must be the same as the one on which the deduction was created. Else, the settlement process is not automated. A manual settlement workflow is initiated and notification is sent to any Oracle Receivables user with the Receivables Role responsibility. From the Previous Open Credit Memo LOV, select a credit memo with a large enough balance to offset the deduction. Use the transaction number, transaction type, location, source, or reference to search for the credit memo. Post-approval: The invoice credit memo is created and deduction is closed under the following conditions: For transaction related deductions, credit is to a non-source invoice. For non transaction related deductions, credit is to an invoice not on the source receipt. The Receivables clerk receives a notification, credits the invoice and enters the credit memo transaction on the notification. The claim is closed if the transaction number is a valid.
Chargeback	Used to settle deductions by charging back the customer in case you determine that the deductions are invalid.	Notes: The tax code is not used or passed by Oracle Trade Management. For a transaction-related deduction, the customer on the original transaction is charged. For non-transaction related deductions, the customer on the receipt is charged back. Post-approval: The chargeback is created online and the deduction is closed.
Write-off	Used to settle a transaction-related deductions.	Notes: In the deduction is non transaction-related, a settlement workflow notification is sent to Oracle Receivables. The Oracle Receivables individual must create an adjustment. When complete, the Oracle Receivables individual updates the notification with the adjustment record, and the deduction is closed in Oracle Trade Management. The tax code is not used or passed by Oracle Trade Management. Post-approval: The write-off is created online and the deduction is closed.
Return Materials Authorization	When a customer returns a product, you can use the RMA settlement method in Oracle Trade Management to settle the deduction. When the return is processed and a credit memo is generated, Oracle Trade Management automatically tracks the credit memo and uses it to close the deduction.	Notes: As an additional prerequisite, Order Management must be set up. The RMA transaction types are set up with return order workflows which drive all the processes that the return order must go through. Post-approval: The RMA is created online. You must ensure return is interfaced to Oracle Receivables as a credit memo. The Claims Settlement Fetcher program updates the settlement documents with the credit memo details and closes the claim.
Previous Debit Memo	Used to settle overpayments.	Notes: Verify that at least one claim line with a negative value exists. If a claim line does not exist, create one now. The sum of the claim lines must equal the total claim amount. In the Previous Open Debit Memo field, select a debit memo with a large enough balance to offset the overpayment. Use the transaction number, transaction type, location, source, or reference to search for the debit memo. Post-approval: The claim investigation for the overpayment is closed. The previous open debit memo is applied to the receipt and the overpayment is closed.
Receipt Write-Off	Used to settle overpayments.	Notes: Verify that at least one claim line with a negative value exists. If a claim line does not exist, create one now. The sum of the claim lines must equal the total claim amount. Post-approval: The write-off is created online and the overpayment is closed.
On-account Cash Application	Used to settle overpayments. When a customer has overpaid for various reasons, the overpayment can be placed on account. The overpayment amount can be applied to the customer's transactions.	Notes: Verify that at least one claim line with a negative value exists. If a claim line does not exist, create one now. The sum of the claim lines must equal the total claim amount. Post-approval: The on account cash application is made online and the overpayment is closed.

Reports

Information in this section will enable you to:

• Understand and view claim reports

• Understand and view claim aging report

• View claim settlement history

Claim Report

Claim Report is a summary of essential claim details that can be printed without having to navigate to different screens. The claim report includes the Customer Details, information on the Adjusted amount, settled amount, and the currency type, Settlement method, Payment details, Vendor details, and Claim lines.

To view a claim report of an existing claim, log into Oracle Trade Management as Oracle Trade Management User.

Navigation: Claim > Claims > Claim Name > Report.

Claim Aging View

Claim Aging View gives a summary of claims and deductions by customer and by days due. It adheres to the bucket definitions in Oracle Receivables, but centralizes all claims and deductions by customer for easy viewing. From this view, you can determine which customer has had outstanding claims for the longest period time and work on those claims. You can optionally create claims, update write-off flags, and settle claims from the Claims Aging View. Aging buckets can also be configured in Oracle Receivables for claim and deduction purposes.

To view claims aging of open claims, log into Oracle Trade Management as Oracle Trade Management User.

Navigation: Claim > Claims Aging.

Notes:

To view the outstanding claims for a customer, drill down the amount in the corresponding columns. For example, to view all claims that have been outstanding for 31-60 days, drill down the amount in the corresponding column.

Claim Settlement History

The Claim Settlement History report enables you to view all the information that is related to the settlement of a claim.

The Claim History Settlement page displays the following information:

• Claim number, date, class, type, amount, status

• Customer Name

• Effective Date of the settlement

• Settlement Method

• GL Date

• Related Customer

If this field is empty when a claim is closed, then it is not displayed on the Claim History Settlement page.

• Relationship Type with the Related Customer.

• Related Site (the Related Customer's bill-to site)

• Vendor and vendor site (Vendor's physical location)

• Comments

To view the claim history of an existing claim, log into Oracle Trade Management as Oracle Trade Management User.

Navigation: Claim > Claims > Claim Name > History.