Point-of-Sale Management

This chapter covers the following topics:

Overview

Point-of-Sale Management is the process by which a manufacturer validates requests, and manages and tracks funds when trade promotion activities are executed indirectly through retailers and wholesalers (or dealers and distributors). The Point-of-Sale Management functionality includes the following features:

Chargeback and Third Party Accrual data are managed in Oracle Trade Management whereas Special Pricing, Fund Requests, and Referrals are features that are available in Oracle Partner Management. When there are approved requests related to Special Pricing, Fund Requests, or Referrals, offers and claims are automatically generated in Oracle Trade Management; these claims are settled by the claims user.

Using Point-of-Sale Data for Volume Offers

When point-of-sale data is used for volume offers, identifying the seller and buyer are important for market eligibility rules. The following information applies to Point-of-Sale Management for Volume Offers:

Context Attribute Value
Channel Direct Indirect Sales
Distributor Name Distributor name
Distributor Segment Distributor Segment name
Distributor List Distributor List name
Distributor Territory Trade Management territory name

Org-Striping

In Oracle Trade Management the operating unit information is required when importing POS data. The operating unit can be derived from the system profile MO:Default Operating Unit or be selected by the particular used who plans to upload the data.

Claims are created in the background when indirect sales users initiate payments for batches. An indirect sales batch can contain transactions for only one operating unit and claims should be created in the same operating unit.

Impact of Org-Striping on Point-of-Sale Management

Org-striping has the following impact on various indirect sales management components:

Chargeback and Third Party Accruals

Retailers or end-customers may buy products directly from the manufacturer, or through wholesalers. Sometimes, to honor agreements that manufacturers have with individual customers or buying groups, the wholesalers sell products at a price that is lesser than their acquisition cost. Wholesalers submit claims to claim back the difference amount from the manufacturer. These claims are known as chargebacks.

Third Party Accruals are payments that must be made to the end-customer. The accrual may be a discount or incentive that the manufacturer wants to give to the end-customer, or it may be a result of the end-customer buying the products from a wholesaler who charges a price higher than the price agreement between the manufacturer and end-customer. This amount is accrued and paid to the end-customer.

Note: Chargebacks are claimed by wholesalers, whereas third party accruals are claimed either directly by the retailer or end-customer, or by the wholesaler on behalf of the retailer or end-customer.

Understanding Chargebacks

Manufacturing organizations face the challenge of handling rebates and chargeback claims for their customers and wholesaler networks. These organizations pay accruals to indirect and direct customers. Chargeback in Oracle Trade Management enables organizations to accurately create and report accruals, and efficiently validate and process the monthly chargeback claims that they receive from wholesalers.

the picture is described in the document text

In the scenario above, the manufacturer has different pricing agreements with the wholesaler and the retailer. If the manufacturer sells products to the retailer through a wholesaler, then the wholesaler purchases products from the manufacturer at an agreed price. This price can be higher than the price agreement that the manufacturer has with the retailer. The wholesaler then resells the products to the retailer according to the pricing agreement that the manufacturer has with the retailer.

The manufacturer incurs a chargeback for this transaction as below:

  1. Manufacturer sells to the wholesaler at $100

  2. Wholesaler resells to end-customers at $60

  3. Wholesaler submits a chargeback of $40 to the manufacturer

Depending upon how Oracle Trade Management is implemented in your organization, the chargeback data may be used for third party accruals and indirect inventory tracking for wholesalers.

Information in this section explains:

Process Flow

The following figure illustrates the process flow for chargebacks, starting from chargeback submission to chargeback settlement.

the picture is described in the document text

Chargeback Submission

Wholesalers or distributors may send chargeback data and claims through the Oracle XML Gateway. Oracle Trade Management supports EDI 844 and EDI 867 formats. See the Oracle XML Gateway User's Guide for more information.

They may also send the data in the form of .xls files or paper documents that will need to be converted and uploaded to the system using Oracle's Web ADI Tools. You can upload this into Oracle Trade Management, and process it further. If wholesalers want to change certain information in the chargebacks that were originally submitted, they can resubmit them.

Chargeback Validation

The system checks whether the wholesaler is a valid party in Oracle Trading Community Architecture (TCA), and automatically performs inventory verification, item verification, and price agreement verification. If any of these validations fail, then the system will not process the chargebacks. Notifications are sent to the submitter.

Chargeback Reconciliation

If the chargeback is valid, then the chargeback amount for each chargeback line is posted against a budget. The Administrator specifies the budget source as a profile value for the Chargeback budget. The amount in the utilized and earned columns are updated based on the batch processing results.

Chargeback Settlement

A single chargeback claim is automatically created against the chargeback transaction. If there are any disputes regarding the chargeback transaction, then the Administrator can initiate the claim for the chargeback lines without disputes. All chargeback earnings are automatically associated to the claim.

Chargeback Submission

Wholesalers may submit chargebacks in one of the following ways:

The submitted chargeback might have one or more associated chargeback lines. Chargeback lines include transaction-related information such as Customer ID, Product ID, Sale price and wholesaler acquisition price, Quantity of the product purchased, Customer contract, Customer authorization, Order number and order date, and the Differential amount (the amount charged back).

For example, a wholesaler submits a chargeback as follows:

Customer ID Product ID Sale Price Acquisition Price Quantity Purchased Order No. Order Date Chargeback amount
A X $40 $50 100 123 Jan 1 $1000
A Y $25 $30 50 245 Jan 30 $250
B Y $20 $30 80 624 Jan 15 $800
C X $45 $50 100 254 Jan 25 $500

Here, the individual rows are the chargeback lines.

Chargeback Resubmission

After wholesalers submit chargebacks, if they wish to change information in chargebacks that were originally submitted, they can make changes and resubmit them. They may:

You can view chargeback lines and the associated errors, and make manual corrections to the claim in the Chargeback Transaction Data Management page. All the transaction data is maintained to ensure accuracy and resolve future disputes. End-customer sales information such as product number, and price is captured and stored for reporting and auditing capabilities. The Administrator in your organization can also implement an option whereby you can create relationships between the end-customer and the wholesaler.

Information regarding the end-customers such as sales, identification, product number and price is captured and stored for reporting and auditing capabilities. These indirect customers are created as parties and accounts in TCA. They can optionally have a "Customer of" relationship with the wholesaler. During chargeback submission, an API call is made to the Data Quality Management (DQM) application in TCA. Based on data checking rules that are set up in DQM, the chargeback system finds the corresponding party ID that has been set up in TCA. If the party does not exist, a new party will automatically be created in TCA.

The Administrator can configure different rules in DQM. The required options must be set in System Parameters for the chargeback system to pass to DQM different rules. See the Oracle Channel Revenue Management Implementation Guide for more information.

Chargeback Validation

When a wholesaler submits chargebacks, basic chargeback validations are done out of the box. Validation is automatically done to check if the end-customer (Bill To Party and / or Ship To Party) is a valid party in Oracle Trading Community Architecture (TCA). Depending upon how Oracle Trade Management is implemented in your organization, one or more of the following validations take place:

The wholesaler's chargeback volume is validated against the inventory level of your products that the wholesaler possesses. The wholesaler's inventory level may be automatically tracked in Oracle Trade Management. This tracks quantity of the products that a wholesaler purchases from your organization and quantity of products that the wholesaler has sold.

If the quantity of products that the wholesaler claims to have sold is more than the quantity of products in his inventory, then the chargeback transaction is not processed.

For example, a wholesaler submits chargeback for product X for different periods:

Order Order Date Quantity
1 March 1, 2004 10,000
2 April 20, 2004 20,000
3 May 15, 2004 10,000

Validation is done to ensure that the wholesaler had 10,000 or more in quantity for Product X on Mar 1, 2004. Chargeback is not paid for more than 10,000 units. This validation also ensures that the wholesaler does not charge back for a product that was bought from a different manufacturer. Admin users can override this validation by unchecking the 'inventory tracking' flag in the indirect sales section of system parameters.

Codes and IDs that a wholesaler uses for the chargeback data (whether coming through EDI, XML gateway or by flat files) may not correspond to the internal codes and IDs that are used by your organization. The Administrator in your organization can map reference information such as wholesaler's item numbers, unit of measurement, wholesaler's end-customer number, price agreement number, to the corresponding internal codes and IDs. These code, ID conversions can be setup at the system parameter at a generic level or at the wholesaler's trade profile level. After the information is mapped, whenever a wholesaler submits a chargeback transaction, the chargeback engine automatically looks up the corresponding internal information based on the code conversion mappings defined.

A wholesaler may buy products from the manufacturer at an agreed price, and sell it at a different price to the end-customer. When a wholesaler submits a chargeback to claim this difference amount, validation is done to check whether this difference amount is accurate. This is done by checking the price, which the wholesaler has originally paid for the products that he has purchased from the manufacturer. This can be through data in the order management System and corresponds to the last order price for the respective products. Validation is automatically done and the calculated chargeback is displayed. You may process the chargeback based on these calculations, or you may change the calculated chargeback and then process it further.

A price list specifies the price that must be offered to a customer. Chargeback lines refer to the price list that is used to calculate and offer the selling price to the customer. If the chargeback transaction does not quote any price list, then the chargeback is not processed. However, if the chargeback line includes a price list, verifications are automatically made to check whether the:

The market eligibility of the agreement lists all members who are eligible for the price. Price Lists can be directly linked to an end-customer or with a buying group to which the customer belongs.

Chargeback Tolerances

The Administrator can set thresholds limits for discrepancies in chargeback submissions. When a wholesaler submits a chargeback transaction, the Processing Engine checks whether the chargeback amount sent by the wholesaler matches the amount that is calculated by your organization. If the discrepancy is within the tolerance levels set, then the chargeback is paid. If the difference is more than the tolerance level, then the chargeback transaction is considered as a disputed one, and is not processed. Tolerances can be set up for individual wholesalers in their Trade Profiles. Tolerances can also be set in System Parameters whereby the same tolerance level will be applicable to all wholesalers who deal with your organization.

Tolerances can be set in terms of either a percentage or an amount for every chargeback transaction (header tolerance), and every chargeback line (line tolerance) in a chargeback transaction. Chargeback tolerances can be either:

Depending upon the implementation setups in your organization, you may override chargeback tolerances while processing the transaction. When you override a tolerance, the system tracks the action and keeps a record of the tolerance being overridden.

Tolerances are used as follows:

For example, in a manufacturing organization, tolerance levels are set as follows:

Header tolerance = $100 Line tolerance = $50

A wholesaler submits a chargeback transaction with three lines as shown below:

Wholesaler's claim Manufacturer's calculation Difference Amount
$300 $350 $50
$450 $550 $100
$400 $400 -NA-
$400 $600 $200

In this case, the first two lines are within line tolerance. In this case, the total of difference amount of the lines is calculated based on only those lines that are marked within line tolerance. This means that the wholesaler is claiming an amount less than the manufacturer's calculation (Negative tolerance). Therefore, the batch will be considered as disputed. However, if users in the manufacturing organization have an option to override the tolerance level, they can override header tolerance and make payment.

Chargeback Reconciliation

After a chargeback is validated, chargeback processing occurs based on the implementation setups in your organization.

Irrespective of the implementation setups, the budget posting contains the following information which can be used to refer back in case of disputes:

Chargeback Settlement

If chargeback validation is completed successfully, a single chargeback claim is automatically created against the chargeback transaction. In the Chargeback Claim page, you can view the claim that is created to settle the transaction. If there are any disputes, the Administrator can initiate a claim for lines that are without disputes. Chargeback earnings are automatically associated to the claim.

For example, a wholesaler submits the following chargeback claim:

Customer Product Requested Amount
A X $1,000
B X $800
A Y $200
B X $1,200

As the first step, the chargeback engine processes this transaction and posts adjustments against the budget as follows:

Customer Product Requested Amount Processed Amount Budget Utilization (Earned and Utilized)
A X $1,000 $1,000 $,000
B X $800 $800 $800
A Y $200 $200 $200
B X $1,200 $1,200 $1,200

As the next step, a chargeback claim is created and earnings shown in the above table are automatically associated to claim lines. A credit memo is raised to settle the claim.

The settled claim looks as shown below along with other details such as the Claim number, Name of the Wholesaler organization, and Credit Memo number.

Product Amount Associated Earnings
X $3,000 $1,000 $1,200 $800
Y $200 $200

If there are errors or disputed lines in the claim, they can be corrected, and the chargeback transactions can be reprocessed. If they are reprocessed after settlement, then a new claim is created and the previous budget adjustments are adjusted and accounted accordingly.

The claims, accruals, and adjustments that are created have references to chargeback transactions. This enables you to create reverse adjustments. The accrual adjustments that are created include references to the chargeback. Claim lines are automatically associated to the chargeback accruals. You can view details of the chargeback submission from the claim.

After the claim is settled, the system generates a message that includes information on adjusted lines, lines with errors, credit memo number, and claim number. Depending upon the System Parameters setting in your organization, one of the following occurs:

However, regardless of the System Parameters setting, automatic messages are sent to wholesalers when chargeback claims are created.

Transaction data is maintained to ensure accuracy and to resolve disputes in future.

Chargeback Statuses

The following table describes the various statuses that a chargeback transaction may go through during the chargeback processing cycle.

Chargeback Statuses
Status Description
Open The chargeback transaction has been imported and is ready to be processed.
Disputed After the chargeback transaction has been imported, if the information is not accurate in any of the chargeback lines, the chargeback status appears as Disputed. You can modify the data in the disputed lines and process them. After you modify the data. the chargeback status changes from Disputed to Open.
Processing and Processed After you initiate data processing, the chargeback status changes to Processing and then to Processed. This means that the chargeback submission has been processed successfully and the funding budget has been updated. You can initiate payment for the chargeback transaction only when it is in the Processed status.
Closed The chargeback status changes to Closed after you initiate payment for the chargeback. A claim will be automatically created, and the claims user will receive a notification so as to enable completion of the settlement process.

Understanding Third Party Accruals

Third party accruals supports indirect accruals for end-customers in cases of promotional accruals and price differences. Third Party Accruals refer to the amount that is claimed in the following situations:

the picture is described in the document text

In the scenario above, a retailer buys a product for $60 from a manufacturer through a wholesaler. The price agreement between the manufacturer and the retailer is $50 for every unit of the product. The price agreement between the manufacturer and the wholesaler is $100 for every unit of the product.

The manufacturer incurs a chargeback for this transaction as below:

  1. Wholesaler sells products at $60 to the retailer

  2. Retailer has a price agreement with the manufacturer for $50

  3. Pay back to retailer equals $10

Apart from these direct accruals, some of these purchases may be eligible for accruals if they had been directly purchased from the manufacturer. These accruals are posted against the customers. These indirect accruals are used against future deductions from end-customers.

Topics in this section include an overview of Third Party Accruals and the process flow.

Process Flow

The following figure illustrates the process flow for Third Party Accruals starting from request submission to request settlement.

Process Flow for Third Party Accruals

the picture is described in the document text

Note: The submission and reconciliation processes, and tolerances are the same for Third Party Accrual data and Chargeback data. This section highlights the differences in the data processing for Third Party Accruals. For more information on submission, validation, tolerances, and reconciliation see Understanding Chargebacks.

Submission

Retailers may submit third party accrual requests (reimbursement requests) in the form of delimited files such as .csv files. You can import this data to into Oracle Trade Management by using the tool provided by WebADI, and process it further. If retailers want to change certain information in the third party accrual requests that were originally submitted, they can resubmit them.

Information regarding the end-customers such as sales, identification, product number and price is captured and stored for reporting and auditing capabilities. These indirect customers are created as parties and accounts in TCA. They can optionally have a "Customer of" relationship with the wholesaler. During third party accrual request submission, an API call is made to the Data Quality Management (DQM) application in TCA. Based on data checking rules that are set up in DQM, the chargeback system finds the corresponding party ID that has been set up in TCA. If the party does not exist, a new party will automatically be created in TCA.

The Administrator can configure different rules in DQM. The required options must be set in System Parameters for the chargeback system to pass to DQM different rules. See the Oracle Channel Revenue Management Implementation Guide for more information.

Validation

After the third party accrual request submission is uploaded to Oracle Trade Management, the system checks whether the retailer is a valid party in Oracle Trading Community Architecture (TCA), and performs the following validations automatically:

If any of these validations fail, the system will not process the third party accrual requests. Notifications are sent to the submitter.

Reconciliation and Settlement

If third party accrual request validation is successful, then the offers against which the third party accruals are claimed, are picked up by the pricing simulations of the Third Party Accrual concurrent process, and created as accruals against their respective sourcing budgets. The chargeback amount for each line is posted against a budget. The Administrator specifies the budget source as a profile value. Chargebacks are posted to this budget. The utilized and earned amounts of the budget are increased.

A third party accrual claim is automatically created against the request transaction. If there are any disputes regarding the third party accrual request transaction, the Administrator can initiate a claim for lines that are without disputes. Third party accrual request earnings are automatically associated to the claim.

Working With Chargeback and Third Party Accrual Transactions

Throughout this section, the terms "submission", and "transaction" are used for representing both chargeback and third party accrual submissions.

Use the information in this section to:

Importing a Transaction Through WebADI

Wholesalers or retailers (in case of third party accruals) may send chargebacks or third party accrual transactions in the form of .csv files. They may also submit the transactions in the form of paper documents such as paper receipts. You can manually convert these paper documents into electronic format and upload the data by using the upload tool provided by WebADI.

Note: You cannot upload Third Party Accrual batch from WebADI as Third Party Accrual is not one of the options under Batch Type in WebADI. To create Third Party Accruals, you must first upload a tracing batch and then run the Oracle Trade Management concurrent program OZF-TM: Third Party Accrual from Resale Table. This program creates a third party accrual based on the resale data in the OZF_RELASE_LINES_ALL table>

To import a transaction through WebADI, log into Oracle Trade Management as Oracle Trade Management User.

As a prerequisite, customers must have submitted chargeback or third party accrual data.

Navigation: Indirect Sales Management > Chargeback > Import Batch.

  1. Select Trade Management: Resale Layout from the Layout drop-down list and click Next.

  2. Select None from the Content drop-down list and click Next.

  3. Review the details and click Create Document.

    Wait until the Excel document is created. The Excel document that is generated appears as a template. The document will have two regions--the header region to enter the header information for the chargeback or third party accrual transaction; and a region below the header region where you can enter information for the individual lines. A transaction can have any number of lines.

  4. In the header region, enter the Batch Number (this should default if you are online and the macros are enabled ) and select a Batch Type from the Batch Type drop-down list. Select Chargeback to create a chargeback transaction. The other options that are available are:

    Ship and Debit: To upload Special Pricing data.

    Tracing: If you select this option, the data will not be processed by the chargeback engine for validations, data conversions, or chargeback calculation. It will be used only for indirect inventory tracking purposes.

  5. Enter the other details as required in the header region.

  6. In the region below the header region, complete a row each for individual lines by entering the required details such as the end customer ( ship to party, bill to party ) details, item number, quantity, UOM, agreement name ( pricelist between the manufacturer and the end-customer) and order details ( the order # , order date and ship date for orders from the distributor to the end customer ). Note that the information required will vary based on business processes. POS data mappings and layouts need to be defined to meet specific implementation needs.

    In the case where code conversion mappings have been defined, POS data needs to include the external codes in the columns beginning with 'Orig'. In this case, internal codes should not be used in the POS feed.

  7. After entering all the information, in the Menubar, click Oracle > Upload.

    A confirmation message is displayed after the document gets uploaded successfully. If there are any errors in the document, the errors are listed at the line level and a the batch / line related information can be corrected in the .xls before you re upload the data

  8. Click Close.

  9. Navigate to Indirect Sales Management > Chargeback.

    You will see the transaction with the batch number that you had assigned to it while creating it. The transaction status appears as Open.

Batch Details

The Batch Details page displays all the essential details of a chargeback or third party accrual submission. :

What you can do

If the status of the submission is Open or Disputed, you can do the following:

If the status of the submission is Processed or Closed, you can view the lines, and view the details of the submission such as processed lines, claims, notes, and attachments, by clicking the respective sub tab.

Viewing and Updating Batch Lines

After uploading a transaction, you can view the associated lines, and modify them. You can also view the associated claims, and add notes and attachments to the transaction. Sometimes, the transaction information may not be accurate. For example, the order number may be missing, or you may have selected a wrong pricelist. In such cases, the lines with inaccurate information are automatically marked as disputed. The transaction status appears as disputed if any of the lines are disputed. You can modify the data in the disputed lines and process them.

To view and update lines in a chargeback or third party accrual transaction, log into Oracle Trade Management.

Prerequisites

Navigation: Indirect Sales Management > Chargeback.

  1. Click the batch number corresponding to the transaction.

  2. Click View Lines.

    All the chargeback lines are displayed. For each chargeback line, you can see details such as the Dispute Code, Transfer Type, Invoice Date, Invoice Number and so on.

    Note: You can personalize the chargeback batch lines view to display specific columns on the screen. Click Personalize to personalize the chargeback lines view.

  3. If any of the lines are disputed, you can optionally add dispute codes to them. You can also edit the other fields as required.

  4. Click Apply to save the changes that you have made.

  5. Optionally, to view only the processed lines or only the disputed links, click the Processed Lines or Disputed Lines sub tabs respectively.

  6. Optionally, click the Claims sub tab to view the claims that are associated with the chargeback transaction.

  7. Optionally, use the Notes sub tab to view existing notes, or to add new notes to the chargeback transaction.

  8. Optionally, use the Attachments sub tab to add attachments to the chargeback or third party accrual transaction.

Processing a Submission

After you have verified that all the lines are accurate, you can process a chargeback or third party accrual submission. If there are any disputed lines, you can accept them, and process the submission. The associated budget gets updated accordingly.

To process a chargeback or third party accrual transaction, log into Oracle Trade Management as Oracle Trade Management User.

As a prerequisite, existing submissions with the status of either Open or Disputed.

Navigation: Indirect Sales Management > Chargeback.

  1. Click the batch number corresponding to the transaction.

  2. If the transaction has any disputed lines, you must first accept the disputed lines:

    1. Click View Lines. All lines are displayed. The disputed lines are highlighted.

    2. Click either Accept Claimed Amount or Accept Calculated Amount.

      Claimed Amount is the amount that the customer has claimed. Calculated Amount is the amount that you owe the customer as calculated by the system based on the chargeback engine validations. After you accept either amount, the chargeback lines will no longer be considered as disputed. The chargeback status changes from Disputed to Open. Note that you need to select the specific lines for which you plan to accept the calculated or the claimed amounts for processing.

      Note: The Process button will not appear after you accept the disputed lines. To process the transaction after accepting the disputed lines, you must navigate back to the Chargeback Summary page and reselect the transaction.

  3. If a transaction does not have any disputed lines, click Process to process the transaction.

    The transaction status first changes to Processing and then to Processed. The Utilized column in the associated budget gets updated accordingly. You can review the budget by navigating to Budget > Budgets, and selecting the associated Budget.

Initiating Payment for a Transaction

You can initiate payment for a chargeback or third party accrual transaction after it has been processed successfully.

To initiate payment for a chargeback or third party accrual transaction, log into Oracle Trade Management as Oracle Trade Management Super User.

As a prerequisite, a transaction in the Processed status should exist.

Navigation: Indirect Sales Management > Chargeback.

Notes:

Click the batch number corresponding to the transaction, and click Initiate Payment. The transaction status changes to Closed, and a notification is sent to the claims user.

Indirect Inventory Tracking

Wholesalers may buy a number of products from your organization and store it as inventory. Wholesalers' inventory levels can be automatically tracked in Oracle Trade Management. This information is displayed at the Account Level in the User Interface. You can track the quantity of products that wholesalers have purchased from your organization and the quantity of products that they have sold.

Note: The inventory changes are reflected in the UI based on the concurrent job 'Refresh Materialized Views for Inventory Summary' . Note that the Time Structures need to be defined prior to running the refresh programs.

The inventory level (in quantity) for a wholesaler is tracked as follows:

Adjusting Indirect Inventory

To view and adjust indirect inventory, log into Oracle Trade Management as Oracle Trade Management Super User.

Navigation: Indirect Sales Management > Inventory Tracking > Adjust.

Notes:

Inventory Summary

The Inventory Summary page displays all the essential inventory information of the selected customer organization. You can view details such as the customer number, start period, the products in the customer’s inventory, and so on. See About Indirect Inventory Tracking for more information on the columns that are displayed. You can also adjust the customer’s inventory level by clicking Adjust.

Special Pricing Requests and Soft Funds

Special Pricing and Fund Requests are features in Oracle Trade Management that are also available in Oracle Partner Management. Special pricing enables partners (wholesaler organizations) to request the vendor organization (manufacturers) for a special price or discount to sell products that they have not been able to move, or to win a deal for a specific end customer, or to meet a competitor's price. Fund Requests enables partners to request the vendor for a budget to execute sales activities such as campaigns to promote the manufacturer's products. In other words the vendor requests for funds to execute trade promotion activities on behalf of the partner or the manufacturer.

Information in this section will enable you to understand and work with Special Pricing and Funds Request. For more information on these concepts, see the Oracle Partner Management Vendor User Guide.

Understanding Special Pricing

Special Pricing enables manufacturers (vendors) to streamline and automate the process by which retailers (partners) request discounts on high-volume, competitive sales deals. When a partner requires assistance to complete a sale in terms of pricing, they request you for a discount or a special price. A partner may also face competition from a competitor and can request you for a discount to win the customer. Information in this section will enable you to understand the Special Pricing process flow, and work with Special Pricing requests.

Process Flow

The following figure illustrates the special pricing process flow, starting from special pricing request submission to claim settlement.

Process Flow for Special Pricing

the picture is described in the document text

Special Pricing Request Submission

Partners or wholesalers request for a special price or discounts on competitive sales deals, specific end-customer deals, and on inventory that they have not been able to sell.

Approval

After an approver is notified of a special pricing request, the approver logs into the system, checks information on the request and either approves or declines the request. The status of the request changes accordingly. If any information is missing, the approver can decline the request. The partner may provide the missing information and resubmit the request.

Offer Creation

After the special pricing request is approved, an Accrual offer, an Off-invoice or Scan Data offer is generated and the system creates a budget request to source funds to reimburse the partner.

The type of offers created and whether resultant accruals are created upfront and then adjusted against point-of-sale data or created as point-of-sale data is received is based on the following criteria.

If you enable the Ship from Stock check box when creating the special pricing request and set the OZF: Create Accrual on POS Receipt profile to No or to the default blank value, the system creates a scan data offer with accruals upfront and adjusts accrual earnings against point-of-sale data as the data is received, validated, and processed.

If you enable the Ship from Stock check box when creating the special pricing request and you set the OZF: Create Accrual on POS Receipt profile to Yes, the system creates an accrual offer and creates accrual earnings against point-of-sale data as the data is received, validated, and processed.

If you disable the Ship from Stock check box when creating the special pricing request, the system creates an off-invoice offer and applies this to direct sales.

Offer Sourcing

The offer sources funds from a budget in Oracle Trade Management after the budget request is approved, a notification is sent to the submitter notifying them of the approval.

Claim Creation and Settlement

After a sale is completed at the discounted price, the partner can submit a claim to collect payment. They can provide you the proof of sale and when you approve the request, an offer is generated.

Partners can submit claims either manually, online or through a POS file (Point-of-Sale file). Your settings for the OZF: Create Accrual on POS Receipt and the OZF: Auto Claim creation for POS profile options, as well as whether you choose to ship from the existing inventory or from new inventory for the offer determines if claim creation and settlement is automatic or manual.

The claim is processed in Oracle Accounts Receivable Deductions and Settlement and the partner gets paid through check or on-account credit.

Special Pricing Request Submission

Partners can submit special pricing requests in two scenarios.

Partners can make the following types of requests:

Special Pricing Request Approval

After the approver in Oracle Partner Management receives notifications of the special pricing request, the approver checks information on the request and approves or declines the request. If it is a Meet Competitor Quote or Bid Request, the approver checks if there are existing requests from the same customer. If a request exists, then the new requests (incoming request with the existing request) are linked.

After a special pricing request has been approved, budget requests are routed to the appropriate budget approvers (as defined in the approval process associated with the request). Before a special pricing request is approved, a default budget request is generated. If you are the approver, you can source the budget from one or many budgets. You can also drill into the budget tab and change the source of the budget.

If the Special Pricing Request approver does not specify the budget sourcing options during approval, the system automatically generates a default budget request. The approver can decide whether to use it or change it. This streamlines the approval process. If the approver specifies the budget sourcing options, the system generates budget requests based on the approver's changes.

The budgets can be approved manually or automatically. If the Auto-approval feature is set in Oracle Trade Management, budgets can be approved automatically.

Offer Creation and Sourcing

After the special pricing request is approved, one of the following offers is created. The type of offer that is created and how accruals are created depend on the following criteria.

When a budget request is approved,an Accrual offer is generated and applied when the partner makes a sale from new inventory.

When the partner makes a sale from new inventory, a unique offer number will be generated and displayed in the user interface. When requests are approved with Off-invoice offers, this offer number can be used while placing orders. When the partner makes a sale from existing inventory, the offer number is the same as the agreement number displayed in the user interface.

Special Pricing Request Settlement

After a sale is completed at a discounted price, the partner may claim the amount either by submitting a claim, or by short paying an invoice. These claims and deductions are settled through Oracle Accounts Receivable Deductions Settlement. To settle these claims automatically without any manual intervention, set the OZF: Auto Claim Creation For POS profile to Yes. If you set this profile to No, you must manually create the claim and settle it. Note that the Special Pricing requests are now striped by Org.

When partners submit claims, they can provide the proof of sale. Partners can submit claims either manually, online or through a POS file (Point of Sale file) in one of the following ways:

If the claim request is approved, a claim is automatically created in Oracle Accounts Receivable Deductions Settlement. If the partner short pays an invoice, then it is treated as a deduction. If you set the OZF: Auto Claim Creation For POS profile to Yes , claims are settled automatically. You can make payments either in the form of a cheque or an on-account credit. For more details on claims and claim settlement methods, see the Oracle Accounts Receivable Deductions Settlement Implementation Guide.

After the claim requests are settled, the committed, utilized, and earned columns in the budget get updated accordingly. Budget checkbook view gives you the exact status of the funds at any point of time. This also depends on the execution of the Funds Accrual Engine. You can view all the special pricing offers that are associated with the budget by drilling down the paid columns in the budget. See the Budgets chapter for more details.

Special Pricing Request Statuses

Special pricing request statuses enable you to know the exact status of a special pricing request. The following table describes the various statuses that a special pricing request may go through.

Special Pricing Request Statuses
Status Description
Draft A request has been created but has not yet been submitted for approval. A request in the Draft status can be edited.
Pending Approval The request has been submitted for approval. From Pending Approval, the status may change to either Declined or Approved. You cannot modify the information in the request after you submit it for approval.
Approved The status changes to Approved if all the approvers approve the request.
Declined The status changes to Declined if either the special pricing approver or the budget approver declines the request.
Archived This means that the request has been archived.
Cancelled The status appears as Cancelled if the request has been cancelled.

Understanding Soft Funds

The Funds Request functionality enables vendors to set aside funds to support the trade promotion activities of a partner. By assisting partners financially, a partner remains motivated and this also helps in building loyalty. The vendor can provide funds for specific time periods and base it on fiscal periods of their organization. Information in this section will enable you to understand the funds request process flow. It also describes the various statuses that a soft fund request can go through.

The following figure illustrates the soft fund process flow, starting from soft fund request submission to claim settlement.

Process Flow for Funds Request

the picture is described in the document text

Funds Request Submission

A partner requests for funds request to execute certain trade promotion activities on behalf of the vendor.

Fund Request Approval

When partners submit soft fund requests, they must first be approved by the vendor approver. Approvers are internal employees or vendors that are defined in AME. They are notified based on rules defined in AME. When the approver receives a fund request notification, they review the request and check for duplicate requests. The approver may either accept or decline the request.

If it is a valid request, the vendor approver checks whether the requested fund amount is feasible or not. If it is not feasible, or if the approver requires extra information to be able to approve the request, the approver returns the request and asks the partner to provide additional information. When the partner resubmits the request after providing the additional information required by the vendor, the request is routed to the first level approver defined in Oracle Approval Management. If the fund request is approved, a budget request is submitted to source funds from a budget in Oracle Trade Management.

Budget Sourcing

After the vendor approver approves the fund request, the soft fund sources funds from a budget in Oracle Trade Management. The budget source is specified as a profile value and the system creates a budget request to source funds from this budget. If the Auto-approval option is set, then the budget request is automatically approved. If the Auto-approval option is not set, then the request is routed to the budget approver.

The budget approver reviews the budget request and may approve or decline the request. If the budget approver approves the request, a notification is sent to submitter notifying them of the approval.

Claim Creation and Settlement

After the budget request is approved and the partner has executed the desired activity, they can submit a claim to redeem the funds. They can specify the actual amount spent on the activity and the amount claimed for the activity. When the vendors submit claims, the system notifies the claim approver in Oracle Trade Management. The claims approval flow begins and the claims approver verifies the claim information and approves the request. If Autopay has been implemented, then the partner or the wholesaler will be paid automatically; otherwise, you, the claims user can manually settle the claims by associating earnings and choosing a payment method. You can pay the partner either through on-account credit memo, or by check.

After the claims are settled, the committed, utilized, and earned columns in the budget get updated accordingly. The budget checkbook view gives you the exact status of the funds at any point of time. You can view all the soft fund requests that are associated with the budget by drilling down the paid columns in the budget. See the Budgets chapter for more details.

Process Flow

The following figure illustrates the soft fund process flow, starting from soft fund request submission to claim settlement.

Process Flow for Funds Request

the picture is described in the document text

Funds Request Submission

A partner requests for funds request to execute certain trade promotion activities on behalf of the vendor.

Fund Request Approval

When partners submit soft fund requests, they must first be approved by the vendor approver. Approvers are internal employees or vendors that are defined in AME. They are notified based on rules defined in AME. When the approver receives a fund request notification, they review the request and check for duplicate requests. The approver may either accept or decline the request.

If it is a valid request, the vendor approver checks whether the requested fund amount is feasible or not. If it is not feasible, or if the approver requires extra information to be able to approve the request, the approver returns the request and asks the partner to provide additional information. When the partner resubmits the request after providing the additional information required by the vendor, the request is routed to the first level approver defined in Oracle Approval Management. If the fund request is approved, a budget request is submitted to source funds from a budget in Oracle Trade Management.

Budget Sourcing

After the vendor approver approves the fund request, the soft fund sources funds from a budget in Oracle Trade Management. The budget source is specified as a profile value and the system creates a budget request to source funds from this budget. If the Auto-approval option is set, then the budget request is automatically approved. If the Auto-approval option is not set, then the request is routed to the budget approver.

The budget approver reviews the budget request and may approve or decline the request. If the budget approver approves the request, a notification is sent to submitter notifying them of the approval.

Claim Creation and Settlement

After the budget request is approved and the partner has executed the desired activity, they can submit a claim to redeem the funds. They can specify the actual amount spent on the activity and the amount claimed for the activity. When the vendors submit claims, the system notifies the claim approver in Oracle Trade Management. The claims approval flow begins and the claims approver verifies the claim information and approves the request. If you set the OZF: Auto Claim Creation For POS profile to Yes, then the partner or the wholesaler will be paid automatically; else, you, the claims user can manually settle the claims by associating earnings and choosing a payment method. You can pay the partner either through on-account credit memo, or by check.

After the claims are settled, the committed, utilized, and earned columns in the budget get updated accordingly. The budget checkbook view gives you the exact status of the funds at any point of time. You can view all the soft fund requests that are associated with the budget by drilling down the paid columns in the budget. See the Budgets chapter for more details.

Fund Requests Statuses

Fund Request statuses enable you to know the exact status of a soft fund request. The following table describes the various statuses that a soft fund request may go through.

Fund Request Statuses
Status Description
Draft A request has been created but has not yet been submitted for approval. A request in the Draft status can be edited.
Pending Approval The request has been submitted for approval. From Pending Approval, the status may change to either Declined or Approved. You cannot modify the information in the request after you submit it for approval.
Returned The request has been returned by approver asking for additional information.
Return Request Request has been returned when information or collateral is missing and the return reason is Collateral Submission Required.
Approved The status changes to Approved if all the approvers approve the request.
Declined The status changes to Declined if either the special pricing approver or the budget approver declines the request.
Archived This means that the request has been archived.
Closed The status appears as Closed if the request has been archived after "x" days. The date is greater that the waiting period that is specified in the system profile. The status gets changed to Closed after "x" days by running a concurrent program.
Deleted The status appears as Cancelled if the request has been cancelled.
Void The status appears as Void if the request has been cancelled by a vendor super user in the vendor or wholesaler organization.
Cancelled The status changes to Cancelled if a super user cancels the request when it is invalid.

Working with Special Pricing Requests and Soft Funds

Use the information in this section to:

Creating and Submitting a Special Pricing Request

Special Pricing requests can be created in Oracle Partner Management and also from Oracle Channel Rebate and Point-of-Sale Management.

To create a special pricing request from Oracle Channel Rebate and Point-of-Sale Management, log into Oracle Trade Management as Oracle Trade Management User.

Navigation: Indirect Sales Management > Special Pricing Request > Create.

Notes:

After you submit the request for approval, the status changes to Pending Approval. The special pricing request approver receives a workflow notification.

Note: The special pricing request does not require approval if you are the creator and approver according to the special pricing request approval rules.

Viewing and Editing Special Pricing Request Details

After creating or uploading a special pricing request, you can view the information associated with the request and modify the data.

To view and update special pricing request details, Log into Oracle Trade Management as Oracle Trade Management User.

As a prerequisite, a special pricing request in the Draft status should exist.

Navigation: Indirect Sales Management > Special Pricing Request.

Notes:

Click the Details icon corresponding to the special pricing request and modify the data as required. You can also add new notes or attachments by using the respective sub tabs.

Creating and Submitting a Fund Request

Special Pricing requests can be created in Oracle Partner Management and also from Oracle Trade Management.

To create a funds request on behalf of a partner or a wholesaler, log into Oracle Trade Management as Oracle Trade Management User.

Navigation: Trade Planning > Soft Fund Requests > Create Request.

Notes:

After you submit the request for approval, the status changes to Pending Approval. The special pricing request approver receives a workflow notification.

Note: The soft fund request status does not require approval if you are the creator and approver according to the approval rules.

Viewing and Editing Fund Request Details

After creating or uploading a special pricing request, you can view the information associated with the request and modify the data.

To view and update special pricing request details, log into Oracle Trade Management as Oracle Trade Management User.

As a prerequisite, a special pricing request in the Draft status should exist.

Navigation: Trade Planning > Soft Fund Requests.

Notes:

Click the Details icon corresponding to the soft fund request, and make the required changes.

Approving or Reassigning Special Pricing or Fund Requests

If you are the approver for a special pricing request or a soft fund request, then you will receive workflow notifications whenever a request is submitted for approval.

Use the following high-level procedure to accept, reject, or reassign a request.

Log into Oracle Trade Management as Oracle Trade Management User.

Navigation:

Notes:

Click the Details icon corresponding to the special pricing request or soft fund request, and approve, decline, or reassign the request as appropriate.

Approving Requested Special Pricing or Soft Fund Budget

After a special pricing request has been approved by the special pricing request approver, an off-invoice offer or an accrual offer is generated in the background. These offers must source funds from a budget to offer the discounts or the special price. Even in case of soft fund requests, funds must be sourced from an existing budget. The budget sourcing options for special pricing requests and soft fund requests are specified in System Parameters. If you are the owner of the budget that will fund these requests, then you will receive notifications if the Auto-approval feature is not set.

To approve a budget request for a special pricing or a funds request, Oracle Trade Management as Oracle Trade Management Super User.

As a prerequisite, an approved special pricing request or a funds request must exist.

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

Notes:

From the list of open notifications, select the appropriate notification, and click Approve.

Submitting a Special Pricing Request or Fund Request Claim

If you have appropriate permissions you can submit claims on behalf of partners, to get reimbursed for the discounted amount.

To submit a special pricing or soft fund request claim, log into Oracle Trade Management as Oracle Trade Management User.

As a prerequisite, approved special pricing or soft fund requests should exist.

Navigation:

Click the Submit Claim icon corresponding to the special pricing or soft fund request for which you would like to submit the claim.

Notes: Soft Fund Requests

Settling a Special Pricing or a Fund Request Claim

After special pricing or soft fund claims are submitted, these claims are treated as all the other claims in Oracle Trade Management. If you are the claims user who is responsible for settling claims that are related to special pricing or funds request, then you must settle these claims from the Claims tab. Check and On-account credit memo are the two settlement methods that are available for special pricing and soft fund claims.

For the detailed procedures on how to settle claims with a check or a credit memo, see the Claims chapter.

Viewing Claims and Budgets Associated With a Special Pricing or a Funds Request

To view claims and budgets that are associated with a special pricing request or a soft fund request, log into Oracle Trade Management as Oracle Trade Management User.

Prerequisites:

Navigation:

Click the Details icon corresponding to the special pricing request or soft fund request you would like to access.

Notes:

Deduplicating Customer Data

DQM approval is not required to happen during the approval of a special pricing request. It can happen at any time after approval of the special pricing request. The DQM approver can complete the DQM process by linking into the Special Pricing Requests area and performing a search on all requests that have not had DQM run. The DQM approver can choose to create a new end-customer or reseller account or use an existing account.

When a request is created, the end-customer name and reseller entered can be matched to an existing record in TCA.

If a duplicate record exists, the approver selects the existing end-customer or reseller or creates a new record and the system links the selected or newly created end-customer or reseller with the request. If a duplicate record does not exist, the approver creates a new record.

Use this procedure to check for existing end-customer or reseller records in TCA and to link the special pricing request to an existing TCA record or create a new one.

Prerequisites

None.

Steps

  1. Log in as the vendor DQM Approver and navigate to Message Center Link > Message Center page. To be a DQM approver, you need to have the appropriate permission.

  2. Click the hyperlink for a special pricing request. Potential duplicates are displayed.

  3. If you find a duplicate end-customer or reseller, select the record and click Merge.

  4. If you do not find a duplicate end-customer or reseller, click Create New Organization. The system will create a new record using the information hat you enter in the customer fields.

Referrals

Referral Management is a feature that is available in Oracle Partner Management whereby the partner (retailer or wholesaler) refers a business prospect, lead, or an opportunity to a vendor (manufacturer). If the referral results in an order, the partner can claim incentive for the referral. Wfhen partners claim incentives, offers and claims are automatically generated in Oracle Trade Management, and these claims are settled by the claims user. For more information on Referral Management, see Oracle Partner Management Vendor User Guide.

Process Flow

The following figure illustrates the process flow for referrals, starting from referral submission to claim settlement.

Process Flow for Referrals

the picture is described in the document text

Submission

A partner submits a referral. Alternately, the vendor can also submit referrals on behalf of a partner. After a referral is submitted, it has to be approved by the appropriate person. If it is approved, a lead is created in the system. If it is rejected, the partner is notified accordingly.

Referral Validation and Approval

The approver reviews the referral, searches for duplicate referrals, and approves or declines the referral. Before approving the referral, the approver checks if the referral matches any existing referral, lead, opportunity, and contact.

Lead-Opportunity Conversion and Offer Creation

If the lead is converted to an opportunity and the opportunity results in an order, an offer is generated in Oracle Trade Management.

Claim Creation and Settlement

If a partner's referral results in orders in the system, they have to be compensated for the same. Whenever a referral results in a successful order, the partner accrues incentives accordingly. These accruals are accumulated in the partner's account. This offer sources funds from a budget. The Administrator specifies the budget source as a profile value. Accruals that are claimed by the partner are posted for orders that are placed and shipped. A claim is automatically created in Oracle Trade Management after shipments for the order are complete. The claim is routed to the claims user who views the claim and adjusts the claim amount if necessary. The compensation is posted to the partner for acceptance. If the partner accepts the claim, the claim is processed further and settled.