Implementing Claims

This chapter covers the following topics:

• Basic Setups for Implementing Claims
• Prerequisites for Creating a Claim
• Setting Up Claim Ownership and Assignment
• Implementing Claim Research and Approval
• Implementing Claim Settlement

Basic Setups for Implementing Claims

The information in the following sections describes the basic setups for implementing claims for Oracle Channel Revenue Management.

Setting System Parameter Defaults

On the System Parameters page you can define:

• Accounting preferences

• Price Protection accounting preferences

• Claim Source Setup (Claim defaults), such as a default claim type, reason, claim owner, and so on

• Claim settlement defaults, such as a default RMA transaction type, debit memo type, credit memo type, write off adjustment type, chargeback type, and transaction type.

• Autopay frequency and preferences

• Pay Over Earnings thresholds

• Indirect Sales and Trade Planning preferences

• Price Protection Process Execution preferences

As a prerequisite, you must define claim types and reasons, and created operating units and basic accounting preferences.

Log into Oracle Trade Management.

Navigation: Administration > Trade Management > Setup > System Parameters.

Enter information in each of the following regions of the System Parameters page.

Accounting

• Receivable clearing account: When a claim or deduction is created and associated to promotional accruals, and if the settlement method is a credit memo, Oracle Trade Management creates the GL entries, Debit Liabilities and Credit Receivables Clearing.

• Vendor clearing account: When a promotional claim is settled by a check, GL entries, including Debit Liabilities and Credit Vendor Clearing are created. The Liabilities account used is the same one used when accruals occurred. The Oracle Payables Clearing accounts used during claim settlement are taken from the following setups:

  • As defined on claim type and any Account Derivation Rules updates.

  • As defined here in system parameters and any Account Derivation Rules updates

• When the Post to GL flag is checked in system parameters, the GL entries are created for the budget utilizations and for claim lines utilizations.

• Create GL entries for Off-invoice discounts: Select to create General Ledger accounting for all off invoice discounts.

• GL balancing segment: Select an Oracle General Ledger balancing segment to filter receivable write-off activity based on an Oracle General Ledger balancing segment. These segments refer to the balancing segment values in the A/C flexfield. This field is visible only if the profile option OZF: Select Write-Off Activities Based on GL Balancing Segments is enabled.

Claim

• Claim type and Claim reason: These values are assigned to deductions and overpayments created and passed to Oracle Trade Management from Oracle Receivables. However the claim source setup (previously referred to as claim defaults) takes precedence over the system parameters setup.

• Exchange type: Claims can be created in a transaction currency different from the functional currency used by the overall set of books. When the exchange type is unclear, the default selected here is used.

• Default owner: Owner assignment is based on various criteria such as claim type or reason. If the assignment manager has not been implemented or fails to assign an owner, the default owner specified here is used.

• Days due: Specific due dates for customers are designated in their trade profiles. If there is no due date in a trade profile, the default specified here is used.

• Territory Manager: Select if Territory Manager is implemented for Claims.

For information on price protection claims, see the Oracle Price Protection Implementation Guide.

Settlement Section Notes:

Settlement

• Receivables batch source: This is used for transferring entries from Oracle Trade Management into Oracle Receivables. The LOV contains all imported transaction sources defined in Oracle Receivables.

• RMA transaction source: This is used as a default for claims settled with RMAs. The list of values contains all return order types defined in Oracle Order Management. Oracle Trade Management provides a seeded source called Trade Management Claims.

• Debit memo, Credit memo, and Chargeback: These are the default values for claims settled with the respective settlement methods. The LOV contains all debit memos, credit memos, and chargebacks that are defined in Oracle Receivables.

• Payables batch source: This is used for transferring entries from Oracle Trade Management into Oracle Payables. The LOV contains all imported transaction sources defined in Oracle Payables.

• Payables payment term: This is the default Payables term used on invoices created in Oracle Payables for claim settlement. The list of values for this field contains all payment terms defined in Oracle Payables.

• Write-off threshold (Deduction): Enter a minimum value. For example, you enter 200 as the threshold. If you receive a deduction for $190, it is under the threshold and is eligible for automatic write off and will be automatically flagged for auto write off. The value entered here should always be a positive number.

• Write-off threshold (Overpayment): Enter a minimum value. For example, you enter $150 as the threshold. If you receive an overpayment for $140, it is under the threshold and is eligible for automatic write off.

• Write-off adjustment: The Receivable activities are defined in Oracle Receivables.

• Receipt write-off (Deductions): This is the Receivables Activity that is passed to Oracle Receivables. Use this while settling non transaction-related deductions.

• Receipt write-off (Overpayments): This is the Receivables Activity that is passed to Oracle Receivables. Use this while settling overpayments.

The profile option OZF: Defaulting Legal Entity for Claim is used for claims and debit claims created in Trade Management or for any claim (of any claim class) created from the Trade Management API or interface that has no legal entity. The values for this profile option include all available legal entities within the system.

Optionally, check the Route Mass Settlement Approval Based on Net Amount box to enable mass settlement approval based on the net amount rather than the open amount. See Setting Up Mass Settlement of Claims for more information.

Autopay

• Autopay: Select to turn on the Autopay functionality.

• Default claim type and reason: Select for Autopay claims.

• Frequency and frequency unit:These values define the frequency by which the customer is paid. You can select how often you want Autopay to run. For example, if you enter 1 and select Monthly, autopay will run once a month.

• Sales credit: This determines the default salesperson used for Autopay and claims created manually. You can select either Default Sales Rep or No Sales Credit.

Earnings Payments

Enter values in the fields to allow the early payment of unearned accruals for offers for some or all of your customers.

• Unearned payments: Determines who is eligible for unearned payments.

  • Allow for All: Unearned payments are allowed for all customers unless specifically disallowed in a customer's trade profile.

  • Allow for Selected: Unearned payments are not allowed unless specifically allowed in a customer's trade profile.

The customer trade profile set up always takes precedence. For example, you select Allow for All on the System Parameters page, whereas the customer X's trade profile is set to Disallow. As such, customer X is not eligible for unearned payments on offers.

• Threshold type and Threshold value: These values restrict the amount of unearned payments. For example, an offer has a committed amount of $10,000. The offer is ending soon and the customer has earned only $3,000 to date. You established a threshold of 20% (threshold type = percent; threshold = 20). If a claims processor receives a claim equal to or less than $3,000, up to $3,600 can be paid (3,000 x 1.2).

• Override threshold: Select to permit threshold overrides. If selected, settlement can still be initiated if the unearned payment amount exceeds the threshold amount. However, the claim must go through a special approval process before payment can be made. If not selected, the claim settlement process cannot be initiated. Corresponding settings in trade profiles take precedence.

• Prorate associate earnings by products: Check to have the system automatically break up earnings on offers proportionately by product or product category. If not selected, the first-in first-out approach is used. For more information, refer to the Oracle Channel Revenue Management User Guide.

Rule Based Settlement

Enter values in the fields to define rules for the automatic matching of claims and deductions with open AR credits and unpaid accruals due to customers.

• Enable Rule Based Settlement: Select to automate the research and settlement process for claims and deductions.

• Customer Name Matching: Select to include or exclude related customers from the matching process.

• Credit Matching Threshold: Select if you want to enter the threshold value as a percent of the credit amount or as a direct threshold amount.

• Threshold: Based on your selection for Credit Matching Threshold, enter the threshold value. For example, if you enter a threshold value of 5%, the difference in credit and deduction amounts should not be greater than 5% of the credit amount.

• Approval for New Credits: Enable this if deductions that are matched to open accruals resulting in new Accounts Receivables credits need to be routed through the approval workflow

• Approval for Matched Credits: Enable this if deductions that are matched to open Accounts Receivables credits need to be routed through the approval workflow

Setting up Trade Profiles

You set up trade profiles to capture customer or supplier preferences for various Oracle Channel Revenue Management activities such as communication methods for seeking approval, product and rejection code mapping, claim amount thresholds, claim frequency, and payment methods and frequency.

Setting Up Customer Trade Profiles

Customer trade profiles are used to:

• Link customers to vendors.

• On a single customer account, define customer trade profiles for each bill-to customer site.

• Define Autopay parameters for accrual reimbursements including payment frequency, threshold, and method for each bill-to site qualified on the offer for a particular customer account.

• Define customized parameters for claim payments including days due and write off thresholds for deductions and overpayments.

• Define earning payment parameters for unearned offer accruals including various threshold settings.

• Define indirect sales parameters including batch and line tolerances.

• Define code mapping for automatic code conversion of internal code to customer code and vice versa for all communications between customer and vendor. Code mapping can be for a product, agreement, party, party site, rejection reason, and unit of measurement.

To set up customer trade profiles, log in to Oracle Trade Management.

Navigation: Trade Management: Administration > Trade Management > Customer Trade Profiles > Create.

Basic Customer Information

• Operating Unit: Enter the Operating Unit for Trade Profile.

• Sites: Sites are org-striped and can be used within an operating unit.

• Supplier information: If the customer is also a supplier, enter the supplier information in the Supplier, Sendor Site, and Address fields.

  • A supplier is a person or company that sells to your company. To settle claims using a check, you must set up that customer as a supplier in Oracle Payables.

  • The trade profile provides a link between the two setups in the two systems. Supplier information on claims is completed automatically; therefore, claim processors do not need to determine this. Suppliers are not org-striped. They can be seen and used across operating units.

    If not set up in the customer trade profile, the claim owner must enter the supplier information on the first claim to be settled by check for this account. When this occurs, the customer trade profile information for the account is updated automatically.

Autopay Parameters

If you choose to use Autopay, it evaluates the accruals for this customer and automates payments as required. Otherwise, automatic payments are not made though accruals exist.

• Payment method:

  • Check: If selected, the vendor and vendor sites fields must be filled in.

  • On Account Credit Memo: If selected, accrual earnings are grouped by the bill-to sites on the customer account and a claim created for each site. In addition, if a customer account has accruals for with no specified bill-to site, this payment method creates a single claim for the total amount of these accruals.

  • AP Settlement, AP Debit, AP Default Payment,

  • Electronic Transfer, Trade Management Settlement, Wire Transfer

Claim Parameters

• Days due: Claim managers may require that claims for this account be resolved within a certain number of days. Enter that number here.

  For example, your company may require that all claims for an important customer account be resolved with 15 days of creation. In the customer trade profile, you can assign 15 as the default days due. If a claim for this customer account is created on January 1, the due date defaults to January 16.

Earnings Payments Parameters

The values selected here determine customer eligibility and the threshold for unearned payments for offers. This affects all promotional claims and deductions except for those related to Scan Data offers (whether settled by credit memo or check.) If a customer does not have a trade profile, the system behaves as if the trade profile setting is Null.

If no explicit threshold is set either on the System Parameters page or on the trade profile, but unearned payments are allowed, then the threshold is zero. Claim payment within the thresholds can be settled like any other promotional claim and go through the regular claim approval process.

• Unearned payments for offers:

  • Null: The customer may or may not be eligible for unearned payments depending on the System Parameter settings. If set to Allow for All, then this customer is eligible for unearned payments. If set to Allow for Selected, then this customer is not eligible for unearned payments.

  • Allow: Unearned payments are always allowed for this customer. This setting overrides the System Parameter setting.

  • Disallow: The customer is not eligible for unearned payments for offers regardless of the System Parameter setting.

• Threshold type:

  • Amount: Threshold is a currency amount. If 50 is entered in the threshold field, then the threshold is $50. (Assuming the currency being used is U.S. dollars.)

  • Percent: Threshold is a percentage. If 90 is enter in the threshold field, then the threshold is 90% of the earnings.

  • Unconditional: The threshold is infinity. Special approval for overriding the unearned payments threshold is never required. Claims simply go through the regular claim approval process.

• Threshold: This value can be greater than 100 if the threshold type is Percent.

  • Example for Percent: The threshold is 20%. Customer Y's earnings total $10,000 for an offer. Claim payments up to $12,000 can be made.

  • Example for Amount: The value is 2,000, and the functional currency is dollars ($). Customer Y's earnings total $10,000 for an offer. Claim payments up to $12,000 can be made.

• Override threshold: Select to allow the initiation of settlements for unearned payments where the amount is greater than the threshold.

  These claims are subject to a special approval process, and the regular approval process. This setting overrides the setting on the System Parameters page.

Point-of-Sale Parameters

The values defined in a customer's trade profile override the values set in System Parameters. For examples of setting these values, see the Oracle Channel Rebate and Point-of-Sale Management Implementation Guide.

Setting Up Supplier Trade Profiles

Supplier trade profiles are used in Ship and Debit and in Price Protection to:

• Link suppliers to customer accounts.

• Define parameters for accrual reimbursements including payment frequency, offer limits, and approval considerations.

• Define preferences for approval communication methods.

• Define thresholds for claim amounts including batch and line tolerances.

• Define code mapping for automatic item code conversion of internal item to supplier item for inbound and outbound transactions.

To set up trade profiles, log in to Oracle Trade Management.

Navigation: Trade Management: Administration > Trade Management > Supplier Trade Profile > Create

Basic Supplier Information

• Operating Unit: Select the operating unit for the supplier trade profile.

• Customer information: To settle claims, you must set up this supplier as a customer in TCA. In addition, perform the following steps to map supplier and customer information on the supplier trade profile.

  • Select the name of the supplier.

  • Select a supplier site. Supplier sites are not organization-specific and can be used across operating units.

  • Select the customer account that you want to map to the supplier site.

  • Select the bill-to site of the customer that you want to map to the supplier site.

Price Protection and Supplier Ship and Debit Parameters

The values defined in a supplier’s trade profile override the default values set for system parameters.

For information on setting parameters for price protection, see the Oracle Price Protection Implementation Guide.

For information on setting supplier ship and debit parameters, see the Oracle Supplier Ship and Debit Implementation Guide.

Implementing Org-Striping

Org-striping involves segregating areas based on operating units. In real-time scenarios, companies set up different operating units (OU) or business entities for different reasons. These operating units have their own business rules and they function independently. This means that the business transactions of one OU may or may not be accessed by another OU.

The Oracle MOAC security model enables you to use a single responsibility to access multiple operating units. Details of the default operating unit are derived from the MOAC profile option, MO: Default Operating Unit. Enabling multiple organization access, enables you to select the operating unit to access the respective views, claims, and mass settlement groups without switching responsibility.

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, Claim Reason, and so on 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.

Prerequisites for Creating a Claim

The information in the following sections explains how to set up:

• Claim Types

• Claim Actions

• Claim Reasons

• Claim Sources

Defining Claim Types

Claims are categorized by type and reason. This categorization allows users to group claims for easier analysis and resolution of claim problems.

For example, a claim type, non-promotional, could be repetitively paired with the claim reason, shipping. Based on this and other information, the organization might decide to improve its shipping processes to reduce this type of claim.

In addition, information derived from claim types can act as the business driver for various integration points by defaulting transaction types on the claims (for example, with Account Receivables and Order Management). Transaction types can be specified for credit memos, chargebacks, debit memos and return materials authorizations (RMAs). Vendor and Receivable clearing accounts can be specified at the claim type level.

Claim and transaction types are org-striped (specific to a particular operating unit.) Therefore, they are visible only within the operating unit in which they are created.

To set up claim types, log into Oracle Trade Management.

Navigation: Trade Management: Administration > Trade Management > Claim > Claim Types.

Notes:

• Credit memo: Select a negative transaction type. The transaction types are created in Oracle Receivables for claims and deductions settled with credit memos. Oracle Trade Management passes it to Oracle Receivables during settlement. In Oracle Receivables, this parameter helps drive accounting for the credit memo.

• Operating Unit An operating unit field is displayed on claim type summary, claim type create and as read only on the claim type detail screen

• Debit memo and Chargeback: Select a positive transaction type. The transaction types are created in Oracle Receivables for claims and deductions settled with debit memos or chargebacks. Trade Management passes it to Oracle Receivables during settlement. In Oracle Receivables, this parameter helps drive accounting for the debit memo.

• RMA transaction type: Select a transaction type. These transaction types are created in Order Management. They drive the default price list, line type, and workflows that ultimately determine return order processing in Order Management.

• Write-off adjustment: Select a Receivable activity. These activities are created in Oracle Receivables for adjustments. The activity selected here determines the accounting adjustment used when transaction-related deductions are settled by write-off.

• Receipt write-off (Deduction): Select a negative Receivable activity. Receivable activities are created in Oracle Receivables for receipt write-offs. The activity selected here determines the accounting for deductions when settled by receipt write-off.

• Receipt write-off (Overpayment): Select a positive receivable activity. Receivable activities are created in Oracle Receivables for receipt write-offs. The activity selected here determines the accounting for overpayments when settled by receipt write off.

• GL balancing segment: This field is visible only if the profile option OZF: Select Write-Off Activities Based on GL Balancing Segments is enabled. These segments refer to the balancing segment values in the A/C flexfield. This profile option allows users to filter Receivable write-off activity based on the Oracle General Ledger balancing segment selected here. It enables the filtering of transaction types and receivable activity defined in Oracle Receivables before making them available for a particular claim type in Trade Management. The filtering is done based on the balancing segment in the account code combinations used to set up the various receivables-related accounts on the transaction types and receivables activities in Oracle Receivables. Enabling this option causes the field GL Balancing Segment to display on the Create Claim Type page. This field is mandatory if the option is set to Yes.

• Receivable clearing account: When promotional claims or deductions are being settled with a credit memo, a debit entry for a liability account is created. Further, a credit entry is created for this Receivable clearing account. This is passed to Oracle Receivables as the revenue account for the credit memo. The list of Oracle General Ledger accounts displayed for this field is determined by the set of books selected in System Parameters.

• Vendor clearing account: When promotional claims or deductions are being settled with a check, a debit entry for a liability account is created. Further, a credit entry is created for the vendor clearing account. It is passed to Oracle Receivables as the distribution account on the Payables invoice. The list of Oracle General Ledger accounts displayed for this field is determined by the set of books selected in System Parameters.

Defining Claim Actions

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.

Log into Oracle Trade Management.

Navigation: Administration > Trade Management > Claim > Actions.

Notes:

• Task templates:

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

When creating claims reasons, you can designate default actions. See Set Up Claim Reasons. For more information on tasks, refer to the Oracle Common Application Components Implementation Guide .

Defining Claim Reasons

Claims are categorized by type and reason. This categorization allows users to group claims, and makes it easier to analyze claims, identify areas of inefficiency, and make improvements that will resolve or prevent further claims.

Claim reasons are used:

• For classification purposes

• When creating claim action defaults

• For integration point setups

Claim reasons are org-striped (specific to a particular operating unit.) Therefore, they are visible only within the operating unit in which they are created.

As a prerequisite, claim actions must be created before setting up claim reasons.

Log into Oracle Trade Management.

Navigation: Administration > Trade Management > Claim > Reasons.

Notes:

• Partner access: Select to enable partner access in Oracle Partner Management.

• Credit memo reason: These reasons are created in Oracle Receivables (CREDIT_MEMO_REASON QuickCode). Credit memo reasons are passed to Oracle Receivables when claims or deductions using this reason are settled by credit memo.

• Adjustment reason: These reasons are created in Oracle Receivables (ADJUST_REASON QuickCode). This reason is passed to Oracle Receivables when transaction-related deductions are settled by write-off or chargeback.

• RMA transaction type: Displays a list of transaction types created in Order Management (created with a Transaction Category of RETURN or MIXED and with a default return line populated.) They drive the default price list, line type, and workflows that ultimately determine return order processing in Order Management.

• Actions: Select the Active check box to make the action available for each claim with this particular reason. Select the Default check box to make one of the actions the default for claims with this reason. .

Defining Claim Sources

When creating claims, you must specify a claim type and reason. Deductions and overpayments created in Oracle Receivables and passed to Oracle Trade Management may not have a claim reason or type. Because these fields are required for claim creation, default values for claims from Oracle Receivables must be set up. These values are specified on the System Parameters page or on the Claim Source Setup page or both. Values set on the Claim Source Setup page override the defaults set on the System Parameters page. sources:

You can define a default claim type and reason for each claim source. Claim sources are predefined based on possible claim generation sources

These defaults override the default claim type and reason set on the system parameters page.

Users can setup available settlement methods for a claim source, based on the following table. For each claim source, administrators can select to enable the settlement methods available to be used for that particular claim source. This includes all seeded and non-seeded settlement methods.

Settlement methods are usually related to claim class. For all the seeded settlement methods currently supported in Oracle Trade Management, the system automatically filters the settlement methods based on the claim class. For example the check settlement method is available only on claims and not on deductions. You can control whether certain settlement methods should be available for a user to select.

This setup screen is available from the Claim Source Setup screen (previously referred to as Claim Defaults).

To access Claim Source Setup , log into Oracle Trade Management with Oracle Trade Management User Responsibility.

Navigation: Administration > Trade Management > Claim > Claim Source Setup.

Claim Source	Settlement Methods
Indirect Sales Claim	This icon is disabled (greyed out) for this claim source because the settlement method used is the one selected when setting up Trade Profiles for the customer of the indirect sales batch.
Indirect Sales Debit Claim	This icon is disabled (greyed out) for this claim source because the settlement method used is always debit memo.
Price Protection Customer Claim	Used by distributors to credit customers for price protection agreements when vendors decrease prices. Claims with this source type are settled with AR credit memos.
Price Protection Vendor Claim	Used by distributors to debit suppliers on price protection agreements when vendors decrease prices. Claims with this source type are settled with AP debit memos.
Price Protection Increase Supplier Claim	Used by distributors on price protection agreements to debit suppliers when vendors increase prices. Claims with this source type are settled with AP invoices.
Supplier Ship and Debit Internal Claim	Used for claims on internal ship and debit requests. For these claims, liability relieved directly and accruals posted to the GL account associated with the cost center on the internal request.
Supplier Ship and Debit Supplier Claim	Used when claiming supplier ship and debit accruals from supplier. Claims with this source type are settled with AP debit memos.
Manual Claim	Check / EFT/ Wire / AP Default Payment Credit Memo On Account, Return Material Authorization (RMA) AR-AP Netting Credit Memo Invoice Payables Debit (unlike the other settlement methods, this is not enabled out of the box)
Referral Claim	Check / EFT/ Wire / AP Default Payment Credit Memo On Account RMA AR-AP Netting Credit Memo Invoice Previous Open Credit Memo
Soft Fund Claim	Check / EFT/ Wire / AP Default Payment Credit Memo On Account RMA AR-AP Netting Credit Memo Invoice Previous Open Credit Memo
Special Pricing Claim	Check / EFT/ Wire / AP Default Payment Credit Memo On Account RMA AR-AP Netting Credit Memo Invoice Previous Open Credit Memo
Promotional Claim (for example, trade profiles, promotional payments and offer’s advanced options screen)	Check / EFT/ Wire / AP Default Payment Credit Memo On Account Payables Debit
Manual Claim Group	Chargeback Write Off On Account
Manual Debit Claim	Debit Memo Payables Debit Previous Open Debit Item
Chargeback Deduction	Credit Memo On Account Credit Memo Invoice RMA Write Off Chargeback Previous Open Credit Memo
Claim Investigation Deduction	Credit Memo On Account Credit Memo Invoice RMA Write Off Chargeback Previous Open Credit Memo
Invoice – Deduction	Credit Memo On Account Credit Memo Invoice RMA Write Off Chargeback Previous Open Credit Memo
Claim Investigation Overpayment	Write Off On Account RMA Debit Memo Previous Open Debit Memo

Note: All seeded settlement methods are flagged as seeded, as shown in the seeded column. This is a view only field to make it easier for an administrator to view whether seeded or custom settlement methods are selected.

Configuring Claim Source Setup

In Oracle Trade Management, configuring a Claim source is completed by a migration script which runs in the background. This migration script moves any saved or existing date on claim defaults to the Claim Source Setup screen (previously referred to as the Claim Defaults screen).

Implementing the Claim Creation API

Use the Claim Creation API to import claims into Oracle Trade Management from outside sources. For more information, log into Oracle Applications with the Integrated SOA Gateway responsibility. Access the Integration Repository and navigate to Oracle Trade Management under the Marketing and Sales product family.

Implementing the Promotional Payment View

To set up of the promotional payment view run the concurrent program OZF-TM : Refresh Materialized Views for Promotional Payment, regularly.

This program updates the materialized view for promotional payments with the most recent earnings information.

Implementing Lockbox Integration

In Oracle Trade Management the claim creation functionality includes a lockbox.

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 the section titled Settling Claims, Debit Claims, Deductions, and Overpayments in the Oracle Channel Revenue Management User Guide for information on how to settle claims.

The lockbox receives payments and automatically creates a claim for any differences between the payments received and invoices. Oracle Receivables interprets the lockbox entries based on settings in its' System Option and Lockbox setup windows.

The claim preferences are configurable. Customers can communicate the reasons for the difference between their payment and the invoice. The reason codes are captured in the lockbox file and they travel through the flow with the remittance line to Trade Management, where they are translated into your company's reason code. You can map Customer reason codes to internal reason codes.

The lockbox must be set up in Oracle Receivables. See Set Up Lockbox Integration, Oracle Channel Revenue Management Implementation Guide for this procedure.

See the Oracle Receivables Implementation Guide for more information. Lockbox integration requires Oracle Receivables Family Pack E or Oracle version 11.5.10 or higher.

Defining Claim Import

Use the Import Interface tables to import claims. When using this feature, the following process occurs:

1. First you must write a program to move the data into the interface tables.

2. The Claims import program, then takes the claim details from the interface table and creates claims in Oracle Trade Management.

3. To implement Claim Import, see the following:

   • Understanding the Claim Concurrent Program,

   • Understanding Claim Interface Tables.

Understanding the Claim Concurrent Program

The concurrent program, Import Claim , takes data from the interface tables, and creates claims and their associated claim lines. There are no parameters for this program.

First the claim is imported, then its corresponding claim lines are imported. When an error occurs, the program writes an error message. This message contains the id of the current record in the interface table. After writing the message, the concurrent program continues.

Understanding Claim Interface Tables

After the claim and claim lines are created successfully, the claim_id is recorded in the claim_id column of the claim interface table.

Two tables are used:

Table Name	Description
OZF_CLAIMS_INT_ALL	All claim information. Stores the data that must be imported to the ozf_claims_all table by the OZF-TM: Import Claim concurrent program.
OZF_CLAIM_LINES_INT_ALL	All claim information. Stores data that needs to be imported to ozf_claim_lines_all table using OZF-TM: Import Claim program.

Importing and Mapping Customer Reason Codes

Claims are created for a variety of reasons related to promotions, shipping problems, invoice errors, or quality issues. The reason for a claim can drive the claim research and resolution process. Claim reasons can also help a company analyze its claim problems.

Manufacturers and their customers have different claim reasons. During research, a claim processor might call a customer and refer to the customer's reason code. Capturing a customer's original reason code and automatically converting it to an internal reason code can make claim research easier.

Example

The retailer Bigmart uses more than 3,500 reason codes for deductions against its manufacturers. To make sense out of its deduction patterns and route them to the appropriate departments for investigation, the manufacturer Toy House maintains only 30 reason codes.

Bigmart electronically remits payments to Toy House (either indirectly via bank and then through a lockbox, or directly via an EDI file coming through a lockbox.) On their remittances, Bigmart includes a reason code for every line in every deduction.

During the Post Batch process in Oracle Receivables, all deductions taken by Bigmart are passed to Trade Management as deductions. If Bigmart's reason codes have been mapped to Toy House's internal codes, conversion will take place during this process.

During claim creation (both in Oracle Receivables and in Trade Management), customer reason code mapping works as follows:

• If the customer reason only is entered, the corresponding internal reason is displayed automatically. If no mapping has been done for a particular customer, then the internal reason will default to the reason specified on the Claim Defaults page or the System Parameters page (in that order.)

• If a customer reason and an internal reason are entered, the customer reason takes precedence. The internal reason will be converted to the one specified during mapping.

• If an internal reason only is entered, the customer reason field is left blank.

Note: Customer reason code mapping is operating unit specific. It is based on the login of the individual performing this task. Therefore, customer reasons can differ by operating unit even though customer accounts are not org-stripped.

As a prerequisite, a trade profile for the customer must exist. WebADI must be implemented.

Mapping Customer Reason Codes

Use the following procedure to map customer reason codes.

Log into Oracle Trade Management with Oracle Trade Management User Responsibility.

Navigation: Administration: Trade Management > Trade Management > Customer > Trade Profiles.

1. Enter the batch number which appears on the spreadsheet, and click Upload.

   The Code Conversions page appears. Code conversion type should be Reason, and the table should be populated with the customer reasons you have imported.

2. Convert the customer codes as follows:

   • Select an internal code for each customer reason

   • As an option, you can enter map start and end dates.

     Map start date defaults to the system import date. Map end date is left blank by default. Claim users can add an end date to the code mapping.

Maintaining Customer Reason Mapping

As ongoing maintenance, you can:

• Create additional mappings importing more files from the customer

  When you import more files, new mappings are added and updated mappings overwrite old ones.

• Create additional mappings on an individual basis

  Map start date defaults to the system date; map end date is left blank.

• Change the internal reason, and the map start and end dates.

• Delete individual mappings.

Setting Up Claim Ownership and Assignment

The following information explains how to set up claim ownership assignment and how to route claims to a team leader.

Owning and Assigning Claims

Three methods are available for claim assignment:

• Claim Territories: Using the CRM Foundation Module Territory Manager, Trade Management can assign claims based on customer, geographical, and claim attributes. If you use this method, no API is required. For more information, see Set Up Territory Manager for Oracle Trade Management.

• Assignment API: Use this API only if you want to assign a customize claim ownership.

• System Parameters: If territories or the API are not used, the default owner in specified in System Parameters is used.

Routing Claims to Team Leader

Routing for Claims to Team Leader uses team leads to assign claim ownership. On team definitions, you can identify a member as a lead for the team. In scenarios where a territory resource is a team, assign the team leader as the claim owner.

The following structure is used to determine a claim owner.

• When there is a single resource on the territory definition, that resource becomes the owner of the claim. If the resource is a team, the team lead becomes the owner of the claim. If a team lead is not specified, the system randomly selects a team member for claim assignment.

• When there are multiple resources on the territory definition, the resource identified as the primary contact will become the claim owner. If a team is identified as a primary resource, the team lead becomes the owner of the claim. If a team lead is not specified, system randomly selects a team member for claim assignment

• If there are multiple resources on the territory definition, and no single resource is identified as primary contact the system will first look for any team and assign the claim to the team lead. If a team lead is not specified, the system randomly selects a team member for claim assignment

Implementing Claim Research and Approval

The following information describes set up procedures for setting up claim research and approval.

Defining the History Rule

Use the History Rule option to record the changes made to a claim while it is being researched and processed.

Log in to Oracle Trade Management.

Navigation: Administration > Trade Management > Claim > History Rules.

Notes:

• Object attribute: These are different pages that can comprise a claim: Main, Lines, Line Detail, Associate Earnings, Split, Settlement.

Implementing the Claim Aging View

Provides a summary of claim and deduction amounts by customer and days due. To implement the Claims Aging View, you must:

• Define the aging bucket in Oracle Receivables.

• Run the Change Aging Populating concurrent process.

Implementing Oracle Discoverer

Discoverer is a tool used for querying, reporting, analysis, and web publishing. With the appropriate security access, users can view information stored in their database for various activities. They can build reports and graphs to dissect the information.

For Oracle Accounts Receivable Deductions Settlement, follow the procedures in these sections to set up Discoverer.

• Set Up User Security and Privileges.

• Customize Business Areas.

Setting Up User Security and Privileges

The steps below incorporate an example where the Oracle Trade Management user is added so that these individuals can view the Inventory Business Area. For this example, the user name is MKTMGR and the responsibility is Oracle Trade Management User.

As a prerequisite, Oracle Discoverer should be properly implemented.

Log in to Discoverer Administration version.

Select business area:

1. Click Open.

2. Select the business areas you want to edit. In this example, check Inventory and Inventory Value Added.

3. Click Finish.

Set Up User Security:

1. From the Tools menu, select Security to set up user security. This setup gives your user access to the User Edition of Discoverer for certain business areas.

2. Select a Business Area. In this example, select the User > Business Area tab. You can use either the Business Area > User tab, or the User > Business Area tab.

3. Open the User/Resp drop-down list, and select a user.

4. From the Available Business Area, select the business areas that you want to grant access to.

   In this example, select Inventory and Inventory Value Added.

5. Select the > button.

   Your selections display in the selected business areas on the left.

6. Click Apply .

Select a User Responsibility

1. From the User/Resp drop-down, select a user responsibility.

   In this example, select Oracle Trade Management User.

2. From the Available Business Area, select the same business areas for the user responsibility that you selected for the user.

   In this example, select Inventory and Inventory Value Added.

3. Click the > button.

   Your selections display in the selected business areas on the left.

4. Click Apply.

Give User Access to Admin Edition

1. From the Tools menu, select Privileges.

   You will now give your user access to the Admin Edition. You can use either the Privileges tab, or the User/Role tab. In this example, use the Privileges tab.

2. Make sure that all boxes for Show privileges for User and Show privileges for Responsibility are checked

3. Open the drop-down list and select MKTMGR.

   This user already has privileges for User Editing. The Schedule Workbook option is not checked, and no demos are currently planned for this function for this user. Select the check box if you would like to schedule a demo.

4. Check Administration.

5. Select all five boxes under Administration.

6. Click Apply.

   Check that the boxes for Show privileges for User and Show privileges for Responsibility are checked.

7. Open the drop-down list and select Oracle Trade Management User.

8. Select all boxes for Administration and User Edition. Exit the Discoverer Administration Edition for these changes to take effect.

To customize business areas, follow the steps below.

As a prerequisite, Oracle Discoverer should be properly implemented.

Log in to the Discoverer Administration version. Navigation: Oracle Marketing business area.

Steps:

1. From the Insert menu, select Folder From Database.

2. Assuming data needed is in APPS, check APPS user.

3. Click the plus sign (+) to expand APPS.

   All the tables and views for this user are loaded.

4. Highlight the views you want.

5. Select the > button to display the views in the Selected window.

6. Change the Default aggregate on datapoints to Details.

Defining Approval Rules for Claims

Approval rules can be configured using multiple parameters such as amount, claim type, claim reason, organization and custom setup.

The rules are evaluated based on the following parameters:

• Organization = 5

• Claim Reason = 4

• Claim Type = 3

• Custom Setup = 1

The lower the number, the more important the parameter in determining which rule will apply to a particular claim.

To set up approval rules for claims, log in to Oracle Trade Management.

Navigation: Administration > Trade Management > Setup > Approval Rule.

Notes

• Claim type:

  • Claim: select if this approval rule is for the normal claim approval process

  • Earnings: select if this approval rule is for use when the threshold for unearned payments for offers is overridden

  • Performance: select if this approval rule is for offer performance validation.

• Minimum amount and maximum amount: For unearned payment threshold overrides, this sets a minimum and a maximum amount for the difference between the earned amount and associated earnings.

• Order: Enter integers in ascending order.

• Type: Can be Function (for example, budget owner), Role (for example, Manager, Senior Manager), or User (a specific individual).

Defining Statuses

System statuses drive behavior for specific Oracle Channel Revenue Management objects. User statuses are used in conjunction with system statuses for classification purposes.

The following table describes the claim statuses used in Oracle Accounts Receivable Deductions Settlement:

Claim Statuses

Status	Description
New	The claim status appears as New when it has been created in Oracle Trade Management but has not yet been researched. 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 can manually change the claim status from Open to Complete. No approval is required to change the claim status from Open to Complete. Complete status 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 changes 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 in 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. 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.

Claim System Status

Status	Description
New	Used for claims entered in Trade Management using Create, Mass Create, Autopay, Import Interface or API. Not used for claims created from Accounts Receivable. Claims created in Accounts Receivable have a default status of open.
Open	Claim is being researched and is not yet resolved. Open claims may be changed to various statuses: Complete, Pending Approval (if approval is turned on), Pending Close (if approval is turned off).
Complete	Indicates most of the research is complete, but claim settlement is pending. No approval is required for this, the user manually changes the status from Open to Complete. From Complete, the user can request approval for the claim and initiate the settlement process. The claim status is changed to Pending Approval or Pending Close.
Pending Approval	A user has requested approval to settle an Open or Complete claim. Approval rules determine who approves the claim and under what circumstances. Users cannot change the status once a claim is Pending Approval. Depending upon the outcome of the approval, the claim status can be changed to Approved or Rejected.
Approved	Once all approvers have approved a claim, the claim status changes to Approved. This status is temporary. Immediately after approval, the settlement process is initiated and the claim status changes to Closed or Pending Close.
Rejected	If a claim is not approved, the status is Rejected. From this status, a user can manually change the status to Open, make changes, and resubmit the claim for approval.
Pending Close	Once approved, a claim remains in Pending Close status. If the settlement process is not automated and requires a concurrent process to finish, it will indicate this status. Once the process finishes, the claim changes from Pending Close to Closed.
Pending Close	When the claim settlement process finishes, the status is Closed.
Cancelled	Deductions status can be changed to Cancelled from Accounts Receivable only, not directly from Trade Management. Cancelled claims cannot be settled.

Implementing Claim Settlement

The following information describes the processes and setups required for claim settlement and security.

Defining Autopay

Autopay is a concurrent program that can be scheduled to run periodically to pay customers by credit memo or check. It sums up customer accruals, automatically creates claims, associates earnings for claims, and settles claims based on the Autopay parameters in customer trade profiles.

Oracle recommends that you schedule the Autopay concurrent program to run at least as often as the frequency for your most frequently paid customer (defined in the customer’s trade profile).

Example 1: Autopay Runs More Frequently Than Customer’s Trade Profile Autopay Frequency

The Autopay concurrent program is set to run daily at 4:00 PM. The autopay frequency set up in the trade profile for customer, Business World, is every two days. Their threshold is $100.

• Day 1: The Autopay program runs, looks up all of the accruals for Business World, creates one claim for them, and pays it.

• Day 2: The Autopay program runs. Although the frequency condition for Business World is not met, Autopay checks its threshold condition. If Business World has accrued $101 before 4 PM, then it will be paid. Otherwise it will not.

• Day 3: The Autopay program runs. The frequency condition for Business World is met. They are paid for all of their unpaid accruals since the last pay date, which may have been Day 1 or Day 2.

The following implementation steps are recommended for Autopay.

1. Set up trade profiles and the Autopay parameters on the System Parameters page. See Set Up Trade Profiles and Set Up Autopay in System Parameters.

2. Schedule Autopay either from the Trade Management user interface or from Oracle Forms. See Autopay Parameter Notes for additional information. Also see the concurrent program OZF: Claims Autopay.

Getting a Tax Quote

When promotional accruals are created based on sales orders, taxes may have been charged to customers, and tax liability may have been accrued. When claims are paid, some of the tax liability may be recovered, so the total claim amount may consist of payment for promotional accruals and also as a tax recovery amount.

The tax engine supplies an estimate of taxes before transactions are interfaced into the Financial or Order Management systems. Trade Management calls the tax engine to get a quote of the estimated tax amount. This reduces the changes of errors during interfaces with Accounts Receivable and Accounts Payable.

No action is required to set up the tax engine. We do recommend, however, that you verify that it is working.

Defining Pay Over Earnings Threshold Rules

Use the Pay Over Earnings feature if you want a customer to be paid more than what he actually has earned. The pay over earnings threshold rules determine the circumstances under which the pay over earnings can be paid. You can specify an amount or percent over the committed amount for which you will allow pay over earnings.

The set up is performed on the System Parameters page. See the Earnings Payments section of Set System Parameter Defaults for details and an example.

Defining Automatic Write Off Thresholds

When companies experience high claim volumes, they may prefer not to have their claim processors spend time investigating claims under a certain amount. With Oracle Trade Management, you can set up threshold rules that allow you to automatically write off claims with amounts that are under a specific threshold.

To enable automatic threshold write off functionality, perform the following procedure.

1. Set the profile option OZF: Claim Write Off Threshold.

2. Set threshold rules either on the system parameters page or individually by customer in each customer's trade profile.

   • For instructions, see Setting System Parameter Defaults.

3. Periodically run the concurrent program, Claim Auto Write-offs Program, to settle and close claims marked for automatic write off. This batch process can be:

   • Scheduled to run at specific intervals in Oracle Forms.

   • Run for a specific claim class (deductions or overpayments), customer, claim type, reason or claim date period.

Implementing Mass Settlement

Mass settlement functionality allows claims processors to:

• Offset overpayments with deductions

• Net overpayments with all debit items

• Net multiple deductions against multiple credit memos

• Specify multiple settlement methods per claim

Once a claims processor performs a mass settlement, the settlement must be approved. Approval rules are based on the claim type and reason associated with the mass settlement. As part of this set up, you can specify a default claim type and reason for mass settlement groups. This set up is done via the profile options listed in the procedure below.

To set up mass settlement, log into Oracle Trade Management.

Navigation: Administration > Trade Management > Setup > System Parameters.

Notes:

• Route mass settlement approval based on net amount: Selecting this check box is optional. If selected, the mass settlement amount is based on the net amount (post-netting). If not selected, the mass settlement approval amount is based on the open claims amount (pre-netting), in other words the sum of deductions and overpayments. For example, if five deductions totalling $100 and two overpayments totalling $80 are selected for netting, the open claims amount will be $20.

• Profile options: Log in to Oracle Forms and set the following profile options:

  • OZF: LOV for claim type and reason on mass settlement

  • OZF: Select Write-Off Activities Based On GL Balancing Segments

  For a description of these profile options see Setting Claim Profile Options.

Implementing Rule-Based Settlement

Rule Based Settlement enables claims processors to automate the process of claim research and settlement for claims that are raised by distributors against promotions or price protection agreements.

If you enable Rule Based Settlement when setting up system parameter defaults, you can also define rules that the Rule Based Settlement Engine concurrent program uses to

• match deductions with open AR credits

• match claims and deductions with unpaid distributor accruals

• set thresholds to find possible matches of deduction and claims with open credits and unpaid accruals

In addition, you can directly set up approval rules on the System Parameters page separately for credit matches and accrual matches that the Rule Based Settlement Engine concurrent program finds. If you enable one or both of the approval options for New Credits and Matched Credits, then you can use the report that the Rule Based Settlement Engine concurrent program produces to manually review, approve, and settle each of the matches found. Alternatively, to review and approve all of these claims at one go, navigate to the Mass Approvals sub tab of the Claims page, search for all claims in Pending Approval status, drill down on the claim number to review claim details, and select the approve check boxes against the ones that clear the review.

On claims against offers and price protection agreements, distributors cite a promotion ID or a pre-authorized (PAD) debit memo number on the claims. When matching, the Rule Based Settlement Engine concurrent program first looks to match deductions with a Accounts Receivables credit and if unable to find a credit match, then looks to match deductions with unpaid accruals based on the PAD number provided by the distributor on the claim.

The Matching Process

The promotion ID or PAD number is just one of the attributes in the matching process. Other matching attributes that the program uses are listed below in order of precedence. The program uses each matching attribute to find an exact or possible match before moving on to the next attribute in the order of precedence.

• Customer reference ID on the deduction - If one exists then the program looks to match the customer reference ID to that on an open credit for the customer in the system.

  • If an exact match exists, then the program offsets the deduction with the credit and closes the claim.

  • If an exact match does not exist, but the match is within the thresholds you specified on the System Parameters page, then the program lists the deduction as a possible match to the credit on the report for your review.

• Pre-Authorized Debit Memo (PAD) number on the deduction - If one exists then the program looks to match the PAD# to an offer code.

  • If an exact match exists, then the program associates the accruals on the offer to the deduction, settles the deduction with a credit memo and closes the claim.

  • If an exact match does not exist, then the program moves to the next matching attribute.

  Note: To add a PAD number when manually creating a deduction, set up the Receipt Application Information flexfield in Oracle Receivables to include PAD number in the segment and map it to a claim attribute. Then, set this attribute value for the OZF: RBS Receipt PAD Attribute profile option. For more information, see the Setting Profile Options section. You can update the offer code of an open deduction.

• Amount on the deduction - The program looks to match the deduction amount with credit amount or the unpaid accrual amount.

  • If an exact match exists, then the program offsets the deduction with the credit and closes the claim.

  • For a credit memo, if an exact match does not exist, but the difference in deduction and credit amount is within the threshold of 5 or 10 percent of the credit amount, then the program lists the deduction as a possible match to the credit on the report for your review and approval before closing it.

  • For accruals, if an exact match does not exist, but the difference in is within the pay over earnings threshold for the distributor, then the program lists the deduction as a possible match to the accrual on the report for your review and approval before closing it.

The following diagram illustrates the matching process.

The process above includes the following steps that the Rule Based Settlement Engine concurrent program uses to find matches for claims and deductions.

1. Deductions are generated.

2. The Rule Based Settlement Engine concurrent program is initiated.

3. The program first looks to match deductions with open credits.

   • If a match is found, the engine offsets the deduction with the credit.

   • If a match is not found, the engine looks to match deductions with open accruals with the same PAD number or offer code.

     • If a match is found, the engine associates the accrual with the deduction and closes out the deduction.

     • If a match is not found, the engine terminates the match process.

Implementing Auto Write Off

Claims can also be mass settled by write off — either manually or automatically. The process reduces time and resources required for writing off claims.

The Write Off Adjustment field is a place holder for the activity that is used for writing off invoice related deductions. The LOV for this field comes from Oracle Receivables, and it exposes all receivable activities of type Adjustment. Oracle General Ledger accounts associated with these activities are used for creating accounting entries for invoice related deduction write offs.

Use Auto Writeoff for small amount deductions and overpayments. You can set different thresholds for deductions and overpayments. Writing off claims below the threshold amount are completely automated. Optionally, you can manually select and deselect claims for auto write off and set approvals.

In Oracle Accounts Receivable Deductions Settlement you can complete write-off in the following ways:

• Manually during individual claim settlement.

• By running auto write off program Claim Auto Write-offs Program described below.

• During settlement fetcher program run.

To implement auto write off, log into Oracle Trade Management.

Navigation: Administration > Trade Management > Setup > System Parameters.

Follow these steps:

1. In the Settlement section, select or enter values for the Writeoff parameters.

   Parameter	Description/Example
   Writeoff Threshold (Deduction)	example: You enter $200 as the threshold. If you receive a deduction for $190, it is under the threshold and is eligible for automatic write off. The value entered here should always be a positive number.
   Writeoff Threshold (Overpayment)	example: You enter $150 as the threshold. If you receive an overpayment for $140, it is under the threshold and is eligible for automatic write off.
   Writeoff Adjustment	: These are receivable activities defined in Accounts Receivable.
   Receipt Writeoff (Deductions)	Select the appropriate Receivables Activity that will be passed to Oracle Receivables and used during settlement for non transaction-related deductions.
   Receipt Writeoff (Overpayments)	Select the appropriate Receivables Activity that will be passed to Oracle Receivables and used during settlement for non transaction-related overpayments.

2. Run the profile option OZF : Under Write Off Threshold Approval Required.

3. Run the concurrent program Claim Auto Write-offs Program a batch process provided to write off claims that have been selected for automatic write off.

   The OZF : Under Write Off Threshold Approval Required profile is used by the settlement fetcher program. Claims settled by credit memo/debit memo/RMA/AP methods can be settled for partial amounts. When the settlement fetcher program Claim Auto Write-offs Program is run to close these claims, the balance on the claims can be either split or written off depending on the value of this profile.

   The process settles claims for:

   • Transaction-related deductions by creating a write off adjustment against the transaction (for example, an invoice.) It reduces the disputed amount on the transaction by the claim settlement amount, and closes the claim.

   • Non transaction-related deductions by creating a negative write off line in Oracle Receivables.

   • Overpayments the process creates a positive write off line in Oracle Receivables.

   • For both non transaction-related deductions and overpayments, it:

     • Reverts the claim investigation line

     • Applies the amount to the receipt write off

     • Reapplies any remaining amount to the claim

     • Creates the accounting entries

     • Closes the claim

Claims settled by this process are identified by the Settled By field. Post settlement, the auto write off check box is read-only and cannot be changed.

Claims are flagged when they fall below the thresholds that were set up in System Parameters. When the OZF-TM: Claim Auto Write-offs Program is run, the claims are automatically closed by write-off settlement. You can include claims that are over the write-off thresholds in the automatic write-off; these claims require approval.

Special Cases

• Claims under thresholds that have been deselected for autopay by a claim processor will not be flagged again automatically. They can be selected again manually as long as the claim status is Open.

• Claims that were deselected for settlement can still be written off on a one-off basis from the Claim Settlement page. Approval may or may not be required based on the profile option OZF : Under Write Off Threshold Approval Required.

• Claims that are over threshold amounts can be written off with this concurrent program if approval dictates by the custom set up is granted.

• Claims originally over thresholds whose amounts have been reduced are not flagged automatically for write off. Claim processors can manually flag them for write off. Approval dictated by the custom set up.

• Claims originally over thresholds but later split into sub claims are still treated as claims over the threshold. They can be flagged for automatic write off with approval dictated by the custom set up.

Implementing the Claim Settlement Workflow

Oracle Accounts Receivable Deductions Settlement uses Oracle Workflow to control the sequence of events and notifications that occur when settling claims. The following sections provide:

• Detailed information about Overview of the Claim Settlement Workflow Process that is seeded with Oracle Trade Management.

• Instructions on configuring the OZF: Claim Settlement workflow process to extend the settlement process for any non-seeded payment methods your organization requires. For details see:

  • Claim Generic Settlement Process

  • Claim Settlement Seeded and Non-Seeded Processes.

  • Claim Settlement Process Definitions.

  • Receivable Settlement Actions Definition.

  • Receivables Document Correction Process.

  • Non-seeded Settlement Process Definitions.

For information on the implementation and setup of Oracle Workflow, refer to the Oracle Workflow Administrator's Guide.

Overview of the Claim Settlement Workflow Process

In Oracle Accounts Receivable Deductions Settlement, the settlement process is initiated when a user changes the following claim attributes:

• Settlement method: Select applicable settlement methods for a claim.

• Status: Change claim status to closed.

The claim settlement workflow process is invoked as follows:

• If the OZF : Automate Deduction/Overpayment Settlement profile option is set to No, the claim settlement workflow process is invoked if the user tries to settle deductions or overpayments by a settlement method related to Oracle Receivables.

• If the OZF: Automate RMA Settlement profile options is set to Yes, settlement automation is enabled between Oracle Receivables and Oracle Trade Management.

• For credit memo invoice settlements, the claim settlement workflow is invoked in the following cases:

  • For both transaction-related and non-transaction-related deductions, if the invoice defined in the claim line was not applied on the receipt for which the deduction was created, the claim settlement workflow is invoked. The user must verify the claim information and create a credit memo in Oracle Receivables to close the claim.

• If the OZF: Derive Accrual Account during Claims Settlement profile option is set to Yes, when you settle a claim by changing the claim status to Closed, the claim status becomes Pending Close immediately and the claim settlement workflow is invoked. The Oracle General Ledger entries and payment creation process are put into background processing. The user must run the Workflow Background Engine concurrent program to proceed with the settlement workflow.

• The Claim Settlement Workflow process is called in any of the following scenarios:

  • If post to GL is set to Yes and the OZF: Derive Accrual Account during Claims Settlement profile option is set to Yes, the creation of GL entries are deferred to the background. This is because the applicable GL account is derived based on the account derivation rules that you defined.

  • The Automate Deduction/RMA profiles is set to No.

  • Claim is settled by a credit memo invoice and:

    For an invoice deduction, the invoice is not the source invoice.

    For non invoice deduction, the invoice is not on the source receipt.

    When crediting an invoice, different types of credits are mixed. An invoice can be credited as credit to total amount, credit to type where type is tax/freight/line amounts or credit to individual invoice line number.

Claim Generic Settlement Process

Claim Generic Settlement Process verifies if a settlement method is seeded. It is associated with the following sub-processes:

• Start: This activity marks the start of a process and does not perform any action.

• Promotional Claim Payment: This activity verifies if the activity is a Promotional Claim Payment. If not, it generate an error. If is successful, if goes to Seeded Settlement Method.

• Seeded Settlement Method: This activity is used to verify whether or not the settlement method is seeded. It also sets the item attribute Settlement Type to ADHOC if the settlement method is not seeded. The resulting type for this activity can be Yes or No. If Yes, it goes to the Claims Settlement Process and if No, it goes to the Non-seeded Settlement Process.

• Claim Settlement Process : If this activity is successful, the process ends. If the activity generated an error, it Reverts Entries and ends.

• Non-seeded Settlement Process:If this activity is successful, it ends. If it is not successful, it generates an error, Reverts Entries and ends.

Generic Claims Settlement

Claim Settlement New

The Claim Settlement New diagram is associated with the following sub-processes:

• Start: This activity marks the start of a process and does not perform any action.

• Automated Settlement Process: This activity verifies if the activity is an Automated Settlement Process. The resulting type for this activity can be Yes or No. If yes, , the activity ends. If no, it goes to Prepare Receivables Instructions.

• Prepare Receivables Instructions: This activity is used to Prepare Receivables Instructions. The resulting type for this activity can be Yes or No. If yes, it goes to Receivables Settlement Action. If no, it goes to Claims Settlement Rejection/Cancellation, Resets the Claims Status, and Ends.

• Receivables Settlement Action: If this activity is successful, a request is processed, the settlements documents are updated, and the claim settlement is closed. If there is an error during the updating settlement documents process, an incomplete claim is generated and a Receivables Document Correction is generated which in turns goes back to the Update Settlement Documents process.

  If the Receivables Settlement Action process requires more information, additional information is requested from Claims, the claim status is reset, and the process ends.

• Non-seeded Settlement Process:If this activity is successful, it ends. If it is not successful, it generates an error, Reverts Entries and ends.

Claim Settlement New

Non-Seeded Settlement New

The Non-Seeded New diagram is associated with the following sub-processes:

• Start: This activity marks the start of a process and does not perform any action.

• Complete Settlement Documents Process: This activity verifies if the activity is a Complete Settlement Documents Process. The resulting type for this activity can be Error or Success. If there is an error, the claims owner is notified of an error, the process reverts entries, and ends.

  If successful, the Settlement Process is automated.

• Is Settlement Process Automated: The resulting type for this activity can be Yes or No. If no, it continues to wait to verify that the settlement document was received and completed. If the Settlement Process is Automated, it creates a settlement document. .

• Create Settlement Document: If this activity is successful, it goes to a loop counter where it either closes the settlement process and ends or goes back to the Complete Settlement Documents step.

  If the Create Settlement Document process generates an error, it notifies the claims owner of the error, reverts entries, and ends the process.

  If the Receivables Settlement Action process requires more information, additional information is requested from Claims, the claim status is reset, and the process ends.

Non Seeded Settlement New

Promotional Claim Payment

The following diagram shows the flow for Promotional Claim Payment.

The Promotional Claim Payment diagram is associated with the following sub-processes:

• Start: This activity marks the start of a process and does not perform any action.

• OZF_CHECK_PROMO_CLAIM: This activity verifies if the activity is a promotional claim. The resulting type for this activity can be Yes or No. If No, it continues the flow. If yes, it defers to OZF_CREATE_PAYMENT.

• OZF_CREATE_PAYMENT: The resulting type for this activity can be Success or Error. If it is successful it continues the flow. If the process generates an error, it goes to OZF_NTF_CSETL_ERR, resets the status and ends the process.

Promotional Claim Payment

Create a New Function

The following diagram shows the flow for creating a new function to reset the claims status to open in case of exception. This function checks if the claim has associated earnings. If yes, it calls the function to reverse GL entries (ozf_gl_interface_pvt.reverse_gl_entry). This would be called for non-seeded settlement methods.

Create a New Function

Revert GL Entries

The following diagram shows the flow to revert entries.

The Revert Entries diagram is associated with the following sub-processes:

• Start: This activity marks the start of a process and does not perform any action.

• Promotional Claim: This activity verifies if the activity is a promotional claim. The resulting type for this activity can be Yes or No. If No, it ends the process because it is successful. If yes, it goes to Revert GL Entry.

• Revert GL Entry:: The resulting type for this activity can be Success or Error. If it is successful it ends the process. If the process generates an error, it ends the process with an error.

Revert Entries

Non-Seeded Settlement Process Definitions

The purpose of the Claim Non-Seeded Settlement process is to provide a general settlement workflow process definition for users. It can be customized to meet your business needs.

You can customize the package for OZF_CLAIM_SETTLEMENT_WF_PVT to customize the non seeded settlement flow.

1. Use the lookup code CUSTOM_METHOD to OZF_PAYMENT_METHOD

2. Add the method to the manual claim source in the claim source setup screen.

3. Submit the claim for settlement. The claim will go into pending close status.

4. Create a transaction in Accounts Receivable. Enter the Transaction Flexfield information and choose context as Claim. Enter the claim number in the appropriate field.

5. Every ten minutes the workflow process checks to see if the transaction was created. If the transaction was created, the workflow creates settlement documentation and closes the claim.

Maintaining Team Access and Security

To control claim access to account for all levels of security use the OZF: Claim Access Security profile option. The three values in this profile option include:

• Full Access – View and Update

• Restricted Access - View Only

• No Access

If the “Full Access” flag for a team member is checked on the claim territory, this member’s “Edit Metrics” flag on the claim itself is also checked.

The following table summarizes claim security:

Person	Access to Individual Claim
AMS: Admin Group member	Can update all claims
Claim Owner	Can update any claims they own
Team Member with Edit Metrics	Can update a claim
Team Member without Edit Metrics flag checked	Can only view a claim. However, if the team member's OZF: Claim Security Access profile value is set to Update, the profile overrides the claim setting and the team member can also update a claim. The team member's claims designated as view only cannot be included in the mass settlement group the team member creates but the claims which the team member can update can be included in this group.
All other users who neither own nor belong to the claim's team.	Dependant on the OZF: Claim Security Access profile option: If the value is Full Access – View & Update: You can update claims which don't belong to the team or which you don’t own. If the value is Restricted Access - View Only: You can only view those claims. If the Value is No Access: You cannot view any claims. The claims you can view only cannot be included in the mass settlement group you create however the claims you can update can be included.

If you add a team or person as a collaborator on the claim run the AMS: Group Access Refresh Program to ensure that the added users can see the claim.

Every claim must be assigned to a team or group created in the CRM Foundation Resource Manager module. After the team or group is created, they can be added to a claim.

• Groups: Every time a change is made, run the AMS - Group Access Refresh Program to update the group information.

• Teams: Every time a change is made, run the Team Access Refresh Program to update the team definitions.

If teams or groups are frequently changed, you can schedule these two programs to run on a regular basis.

Team Access and Security

#	Team Member	Access
1	Members in the Group specified in the profile option AMS: Admin Group	Update all fields: Excluding fields locked by the system out-of-the-box. Including fields locked by locking rules.
2	Claim owner and team members	Update all fields: Excluding fields locked by system out-of-the-box Excluding fields locked by locking rules.
3	Task assignees	Update tasks from calendar or task list; view report of a claim.
4	All other users in the same operating unit as the claim	Access level is determined by the profile option AMS: Update Claim Access. The two levels allowed are: Update access excluding ability to update owner fields, fields locked by the system out-of-the-box, and fields locked by locking rules. View access of claims only.
5	All other users in different operating units from claim.	No access and no view. Claims are org-striped