Implementing Claims

This chapter covers the following topics:

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:

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

Log into Oracle Channel Revenue Management.

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

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

Accounting

Claim

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

Settlement Section Notes:

Settlement

The profile option OZF: Defaulting Legal Entity for Claim is used for claims and debit claims created in Channel Revenue Management or for any claim (of any claim class) created from the Channel Revenue 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

Earnings Payments

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

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.

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.

Control Channel Revenue Periods

The Control Channel Revenue Periods page enables you to maintain periods, ensuring that all transactions are accounted and closed appropriately. The periods displayed on this page are predetermined based on operating unit and ledger. The periods are defined in the Accounting Calendar window in Oracle General Ledger.

Navigation: Oracle Trade Management User responsibility, Channel Revenue Management, Administration, Trade Management, Control Channel Periods.

On the Control Channel Revenue Periods page the future periods are displayed by default. You can search for periods with these attributes: Period Name, Fiscal Year, and Period Status.

The available values for Period Status are Closed, Never Opened, and Open. If you select Closed, accruals and settlement are not allowed for this period. For unprocessed transactions, exceptions are raised. A closed period can be reopened only if the corresponding GL period is not in the Permanently Closed status. For a transaction that is in a closed period when the Subledger program is run, the OZF: GL Date for Accounting Sweep profile option updates the transaction with a date in an open period.

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:

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

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

Basic Customer Information

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.

Claim Parameters

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.

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:

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

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

Basic Supplier Information

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.

Additional Information: 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:

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 Channel Revenue Management.

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

Notes:

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 Channel Revenue Management.

Navigation: Administration > Trade Management > Claim > Actions.

Notes:

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

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 in to Oracle Channel Revenue Management.

Navigation: Administration > Trade Management > Claim > Reasons.

Notes:

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 Channel Revenue 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 Channel Revenue 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 Channel Revenue Management with Oracle Trade Management User Responsibility.

Navigation: Administration > Channel Revenue 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 Channel Revenue 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 Channel Revenue 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 Channel Revenue 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 Channel Revenue 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 Channel Revenue Management. AutoLockbox can initiate claim creation for eligible remittances. Deductions and overpayments can be created from the PostBatch process when customers' remittances come from the Oracle Receivables Lockbox. All the relevant customer information including customer reason and reference number is passed to Oracle Channel Revenue Management. These claims can be settled through Oracle Channel Revenue Management. See 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 Channel Revenue 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 Setting Up Lockbox Integration, Oracle Channel Revenue Management Implementation and Administration 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 Channel Revenue Management.

  3. To implement Claim Import, see the following:

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 Channel Revenue 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 Channel Revenue Management), customer reason code mapping works as follows:

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 in to Oracle Channel Revenue Management with Oracle Trade Management User Responsibility.

Navigation: Administration: Channel Revenue 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:

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:

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.

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 Channel Revenue Management.

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

Notes:

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:

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:

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 Channel Revenue Management.

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

Notes

Multiple Currencies Support for Claim Approval Rules

You can create an approval rule for a single currency and apply that rule to claims in multiple currencies. The order of precedence for selecting currency for a claim approval rule is: Claim, Ledger, Null, and then the default approver.

The following example shows how you can use a single approval rule for claims having multiple currencies:

  1. On the Create Approval Rule page, select Claim from the Approval Rule For drop-down list.

  2. In the Currency drop-down list, select USD and enter the Minimum Amount as 100 and the Maximum Amount as 1000. USD is the ledger currency.

  3. A claim named CLA12 with currency worth 100 CAD is submitted for approval.

  4. The system checks for an approval rule for the claim in this order:

    • For the claim currency

    • For the ledger currency

    • For no currency

    • For the default approver

  5. Since USD is the ledger currency, the system converts CAD to USD and appropriately calculates the amount that must be sent for approval in USD.

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 Channel Revenue 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 Channel Revenue Management. A claim cannot be settled when it is in the Cancelled status.
Claim System Status
Status Description
New Used for claims entered in Channel Revenue 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 Channel Revenue 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.

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 Channel Revenue 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. Channel Revenue 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 Channel Revenue 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:

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 in to Oracle Channel Revenue Management.

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

Notes:

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

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.

The following diagram illustrates the matching process.

the picture is described in the document text

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:

To implement auto write off, log into Oracle Channel Revenue 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

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:

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:

The claim settlement workflow process is invoked as follows:

Claim Generic Settlement Process

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

Generic Claims Settlement

the picture is described in the document text

Claim Settlement New

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

Claim Settlement New

the picture is described in the document text

Non-Seeded Settlement New

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

Non Seeded Settlement New

the picture is described in the document text

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:

Promotional Claim Payment

the picture is described in the document text

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

the picture is described in the document text

Revert GL Entries

The following diagram shows the flow to revert entries.

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

Revert Entries

the picture is described in the document text

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:

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.

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

For more information, see About Notes, Team, and Product Options, Oracle Channel Rebate and Point-of-Sale Management User Guide.

Using Subledger Accounting for Defining Account Derivation Rules for Claims

If your business requirements call for the need to post promotional accruals (for accrual, lump sum offers) to Oracle General Ledger you can customize the derivation of this account in Oracle Subledger Accounting (SLA).

Customization defines the value of a certain segment of the whole account.

You can use the following attributes for customization:

For an accrual account the Account Deriving Rule in SLA obtains accounts in the following order of precedence:

For a claim settlement account the Account Deriving Rule in SLA obtains accounts in the following order of precedence:

Important: You must retain the predefined Account Derivation Rule (ADR) for Claim Clearing Account since the account information is used while interfacing claims to Oracle Receivables or Oracle Payables.

For more information on using the Account Derivation Rules, see the Oracle Subledger Accounting Implementation Guide.