This chapter covers the following topics:
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
The manufacturer may have different pricing agreements with some end-customers who buy products indirectly through distributors. Sometimes, distributors may have to sell products to these end-customers at a price that is less than their acquisition cost. In such cases, they may chargeback the differential amount back to the manufacturer. Claims need to be created and settled based on the chargeback information
Third Party Accruals
Third party accruals include discounts and accruals that are applicable to retailers, or other channel partners. Wholesalers may track this data and submit requests on behalf of the retailers to claim these accruals.
Special Pricing
Retailers or wholesalers request the manufacturer for a special price or discount to dispose existing inventory, meet a competitor's price, or to win a deal for an existing customer.
Fund Requests
Retailers or wholesalers execute trade promotion activities on behalf of the manufacturer, and request for a budget to execute these activities.
Referral Management
Retailers or wholesalers refer a business prospect, lead, or an opportunity to a manufacturer. If the referral results in an order, they can claim incentive for the referral.
Chargeback and Third Party Accrual data are managed in Oracle Channel Revenue 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 Channel Revenue Management; these claims are settled by the claims user.
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:
Seeded qualifiers are required to support the ability to identify indirect sellers and buyers
A seller/buyer can be an account or an account site but both need to be seeded as Quoting (QP) qualifiers.
A seller account is an actual valid account site defined in Accounts Receivable. Although the seller is a seller from the indirect sales transaction's perspective, it is still a customer from the company's perspective. For example, a distributor that a company sells to, is a customer from the company's perspective. However, if this distributor submits its sales transactions to the company, these transactions become indirect sales transactions.
Additionally, indirect seller and buyer account sites are valid customer account sites defined in Oracle Trading Community Architecture.
The “Sold By” IDSM (indirect Sales Modifier) qualifier supports the following contexts and values :
Context Attribute | Value |
---|---|
Channel Direct | Indirect Sales |
Distributor Name | Distributor name |
Distributor Segment | Distributor Segment name |
Distributor List | Distributor List name |
Distributor Territory | Channel Revenue Management territory name |
In Oracle Channel Revenue 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.
Org-striping has the following impact on various indirect sales management components:
Chargeback: The profile option, QP: Security Control, determines whether the operating unit details in indirect sales orders should be matched with the operating unit details specified in the pricelist. If the profile option is set to:
On: If On, and if the price list was created without the global flag checked, the indirect sales order's operating unit is checked against that of the price list. If it does not match, then it results in a dispute of invalid price list.
Additionally, if the QP profile option is set to On with the global flag on the pricelist checked or set to Off, , the pricelist validation does not take place.
Third Party Accruals: The validation that takes place is similar to that of offers applied to direct sales orders.
Org-Striping validation on price lists and offers rely on the Advanced Pricing Engine.
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.
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 Channel Revenue Management enables organizations to accurately create and report accruals, and efficiently validate and process the monthly chargeback claims that they receive from wholesalers.
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:
Manufacturer sells to the wholesaler at $100
Wholesaler resells to end-customers at $60
Wholesaler submits a chargeback of $40 to the manufacturer
Depending upon how Oracle Channel Revenue 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:
The following figure illustrates the process flow for chargebacks, starting from chargeback submission to chargeback settlement.
Chargeback Submission
Wholesalers or distributors may send chargeback data and claims through the Oracle XML Gateway. Oracle Channel Revenue 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 Channel Revenue 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.
Wholesalers may submit chargebacks in one of the following ways:
Flat Files (.csv files)
Wholesalers may send chargebacks in the form of .csv files. You can import these files into Oracle Channel Revenue Management by using the upload tool provided by WebADI.
Paper documents
Wholesalers may submit chargebacks 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.
XML Gateway
Wholesalers or distributors may send chargeback data and claims through the Oracle XML Gateway. Oracle Channel Revenue Management supports EDI 844 and EDI 867 formats. See the Oracle XML Gateway User's Guide for more information. The chargeback process automatically runs, and in the meantime, you can see the status as "Processing".
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:
Resubmit a transaction multiple times
A wholesaler may try to resubmit a chargeback repeatedly. If a wholesaler tries to submit the same chargeback twice, the transaction is rejected because the transaction lines will be duplicates. The submitter gets notified accordingly.
Resubmit a transaction to handle corrections and disputes
Disputes may occur if wholesalers submit erroneous or incorrect chargebacks. In such cases, the manufacturer can inform the wholesaler about the errors and disputes, and the wholesaler can resend the transaction with corrections. During resubmission, if the original submission has been paid, then the chargeback engine reprocesses these lines and reverses the old accruals. The system creates new accruals, but associates only the difference amount to the claim.
For example, Goodway submits a chargeback a transaction for $1000. You, the manufacturer find that Goodway is eligible to chargeback only $500, and you make a payment for $500. The chargeback engine creates accruals for $500. However, Goodway feels that it is eligible to receive $1000 and not $500, and resubmits the chargeback transaction with the corrected data. You accept that Goodway is eligible to receive $1000, and make another payment for $500. The chargeback engine now reverses the $500 accruals that were created during the first submission, and creates new accruals for $1,000.
If the original submission has not been paid, then the submission is treated as a new one, and amount for the corrected lines is paid.
Resubmit the same transaction with additional chargeback lines
A wholesaler may resubmit a chargeback with added chargeback lines. In these cases the chargeback engine processes only the new lines. If wholesalers resubmit the same transaction with additional chargeback lines, they must explicitly flag the lines that must be reprocessed. A combination of the wholesaler number, customer number, order number, order or invoice date, product number, and transaction code is used to determine whether the transaction has been processed before, and to identify duplicate chargeback lines.
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.
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 Channel Revenue Management is implemented in your organization, one or more of the following validations take place:
Wholesaler inventory verification
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 Channel Revenue 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:
Price list is valid on the invoice date indicated on the chargeback data
Customer is specified in the chargeback, and that the sale price is valid
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.
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:
Positive: amount claimed by the wholesaler is more than the manufacturer's calculation
Negative: amount claimed by the wholesaler is less than the manufacturer's calculation
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:
After a wholesaler submits a chargeback transaction, chargeback lines are checked against line tolerance.
After all the lines are checked, the amount for all those lines which are marked as within tolerance, are added. This amount is again checked against header tolerance.
If the total amount is still within header tolerance, all lines that are marked as below header tolerance will be processed. If the total amount is greater than header tolerance, you must uncheck some of the chargeback lines to be processed even though the lines may fall within line tolerance.
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.
After a chargeback is validated, chargeback processing occurs based on the implementation setups in your organization.
The Administrator can set the option in System Parameters to accrue funds for chargebacks. This option determines whether chargebacks will debit up front accruals (created by offers or fully accrued budgets), or will simply calculate payment during chargeback processing. This option enables you to forecast the chargeback amount and accrue for it up front when sales orders are shipped to a wholesaler.
For example, the previous year total sales of an organization was $10 million. The organization finds that for a particular wholesaler, the chargeback total was $1 million in the previous year. It therefore estimates that about 10% of this year's sales will again be claimed by the same wholesaler as chargebacks. To do this, the organization creates an accrual offer, or a fully accrued budget with a rate of 10% that gets calculated and accrued every time the wholesaler makes purchases in the current year. This pool of accruals will be used to make payments to the wholesaler.
If this option is implemented, then:
The Utilized and Earned columns in the Budget increase whenever automatic adjustments are made.
The Paid column increases for the amount of the chargeback claim after approval.
To accrue funds for chargeback, you can create either of the following:
Accrual offers (Accrual offers, Volume offers, Lump sum offers, or Scan Data offers).
Fully Accrued Budget. While creating the budget, you must set the fully accrued budget to "Accrue to Customers" and check the Liability flag.
After the chargeback process, when payment is initiated for the chargeback submission, based on this option being checked, the following occur:
The system checks for existing accruals for these offers or fully accrued budgets.
If it finds chargeback accruals, then the market and product eligibility of the submitted chargeback transactions are matched with those of the offer. Payment is initiated only if these conditions match.
If there are multiple accrual records, then the oldest accruals are paid first.
For example, the system tracks the following accrual records for a wholesaler:
Order Number | Order Date | Product | Amount |
---|---|---|---|
1 | September 1, 2003 | Product A | $100 |
2 | September 2, 2003 | Product A Product B | $200 $500 |
3 | September 3, 2003 | Product B | $300 |
If the wholesaler submits a chargeback transaction for $250 for Product A, then $100 is paid against Order 1, and $150 is paid against Order 2. If the wholesaler submits a chargeback transaction for $400 for Product B, then $400 is paid against Order 2 only.
Automatic adjustments are made if funds in the accrual offer or the fully accrued budget are not sufficient to pay the chargeback amount. In the above example, if the wholesaler submits a second chargeback transaction for $500 for Product A, then because the balance accruals available for Product A is $50, an automatic adjustment up of $450 is made before creating the chargeback payment claim record.
However, if accruals are created by Lump sum offers with spread, then adjustments are made only if the chargeback amount is above the total lump sum amount.
For example, a Lump sum offer with spread is created for $100 for 100 days. Therefore an amount of $1 is accrued on a daily basis. The amount accrued on the 50th day will be $50. A wholesaler submits a claim for $100 on the 50th day of the offer, and the payment is made even though the amount is more than what has been accrued on the 50th day. However, if on the 60th day the wholesaler submits another chargeback transaction for $20, then because that total payment has already exceeded the total lump sum amount, an adjustment of $20 is made automatically.
However, if the amount claimed in the form of chargeback claims is lesser than the amount in the accrual offer or fully accrued budget, no automatic adjustments are made to decrease the amount in the offer or budget because additional chargeback claims may come in the future.
For example, if the available accruals for a product are $500 and a chargeback claim comes in for $200, no adjustments are made to decrease the available accruals.
All the claims, accruals, and adjustments that are created will have references to the chargeback transaction and lines to enable you to make reverse adjustments if required.
If the option to accrue funds for chargebacks is not implemented, then the Administrator can specify the budget source as a profile value. Accruals for the chargebacks are created and associated on the claim payment record. The amount for each chargeback line is posted against the budget. The Utilized and Earned columns are increased accordingly. The Paid column gets updated after the claim is approved.
Irrespective of the implementation setups, the budget posting contains the following information which can be used to refer back in case of disputes:
Wholesaler number (internal account number in TCA)
Order number and order date
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:
The message is automatically sent to the wholesaler
You can manually send the message to the wholesaler by clicking Send Outbound Messages
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.
The following table describes the various statuses that a chargeback transaction may go through during the chargeback processing cycle.
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. |
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:
Manufacturers deal indirectly with the retailers, who are the end-customers. Manufacturers may use third party accruals to offer incentives to promote sales to these indirect customers.
Manufacturers may sometimes sell directly to the retailers (end-customers). But sometimes, when the manufacturer is out of stock, the retailers may have to buy products from a wholesaler. As a result of this, the end-customers must be compensated for the promotions they would have qualified for had they bought directly from the manufacturer.
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:
Wholesaler sells products at $60 to the retailer
Retailer has a price agreement with the manufacturer for $50
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.
The following figure illustrates the process flow for Third Party Accruals starting from request submission to request settlement.
Process Flow for Third Party Accruals
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 Channel Revenue 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 Channel Revenue Management, the system checks whether the retailer is a valid party in Oracle Trading Community Architecture (TCA), and performs the following validations automatically:
Item verification - The codes and IDs that a retailer uses for the third party accrual request may not correspond to the internal codes and IDs that are used by your organization. If reference information is mapped, then whenever a wholesaler or end-customer submits a third party accrual request, the chargeback engine automatically looks up the corresponding internal information.
Price list verification - Verifications are automatically made to check whether the price list is valid on the invoice date indicated on the transaction data, and the buying price is valid.
Offer verification - Third party accruals are created when the customers are eligible to receive accruals or incentives as specified in the offers that they are eligible for. If the retailer or end-customer has submitted the request, then validation is done to check if the end-customer is included in the market eligibility of the offer. If wholesalers have submitted the request on behalf of the retailer, then validation is done to check if the end-customers have been included in the market eligibility of an offer, and the wholesaler is the payout party. An indirect sales qualifier is available in the Market Eligibility section in offers, which restricts offers so that they apply only to indirect sales from the POS data that is received.
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.
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:
Import a transaction through Web ADI
Batch Details
View and update lines
Accept disputed lines and process a submission
Initiate payment for a transaction
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. You can save and reuse the WEB ADI templates.
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 Channel Revenue 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 Channel Revenue 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.
Select Channel Revenue Management: Resale Layout from the Layout drop-down list and click Next.
Select None from the Content drop-down list and click Next.
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.
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.
Enter the other details as required in the header region.
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.
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
Click Close.
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.
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:
View and Update Lines
Accept Disputed Lines and Process a Submission
Initiate Payment for a Transaction
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.
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 Channel Revenue Management.
Prerequisites
Existing chargeback or third party accrual submissions with the status of either Open or Disputed.
The submissions must have associated lines.
Navigation: Indirect Sales Management > Chargeback.
Click the batch number corresponding to the transaction.
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.
If any of the lines are disputed, you can optionally add dispute codes to them. You can also edit the other fields as required.
Click Apply to save the changes that you have made.
Optionally, to view only the processed lines or only the disputed links, click the Processed Lines or Disputed Lines sub tabs respectively.
Optionally, click the Claims sub tab to view the claims that are associated with the chargeback transaction.
Optionally, use the Notes sub tab to view existing notes, or to add new notes to the chargeback transaction.
Optionally, use the Attachments sub tab to add attachments to the chargeback or third party accrual transaction.
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 Channel Revenue Management as Oracle Trade Management User.
As a prerequisite, existing submissions with the status of either Open or Disputed.
Navigation: Indirect Sales Management > Chargeback.
Click the batch number corresponding to the transaction.
If the transaction has any disputed lines, you must first accept the disputed lines:
Click View Lines. All lines are displayed. The disputed lines are highlighted.
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.
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.
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 Channel Revenue 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.
Wholesalers may buy a number of products from your organization and store it as inventory. Wholesalers' inventory levels can be automatically tracked in Oracle Channel Revenue 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:
Beginning Inventory
The Administrator in your organization can set the period starting from when it would like to track the wholesalers' inventory levels. The starting period can be set only once for each wholesaler. Thereafter, the system automatically calculates the beginning inventory levels for the next period.
Inventory In
Inventory In stores information of all sales data and orders placed by the wholesaler. It includes details of all products that the wholesaler purchases from the manufacturer. This data is extracted from Oracle Order Management and gets automatically updated. Based on the setups in your organization, the sales data can be converted to a common unit of measurement for products.
Inventory Out
Inventory Out stores information of all the indirect sales data that the wholesaler submits as a part of chargeback submission. It also stores information of sales orders with the source code of OM that are returned to the wholesaler.
Adjustments
You can manually and periodically adjust inventory levels based on validations from the wholesaler. You can adjust inventory levels only if you have the required access and responsibility. Adjustments can be either positive or negative. Adjustments are tracked and stored with information on the adjusted quantity, adjusted period, adjusted user, adjusted date, adjustment reason.
Ending Inventory
Ending Inventory provides information on a wholesaler's existing inventory levels at any point of time.
Ending Inventory = Beginning Inventory + Inventory In - Inventory Out + Adjustments
To view and adjust indirect inventory, log into Oracle Channel Revenue Management as Oracle Trade Management Super User.
Navigation: Indirect Sales Management > Inventory Tracking > Adjust.
Notes:
Adjustment Date: This is the date from which the adjustment will be effective.
Adjustment Quantity: Enter a positive value to increase the inventory levels, or a negative value to decrease the inventory levels.
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.
The Saved Search drop-down list on the Inventory Tracking page contains saved searches and the following predefined options: All Years, Current Year, Current Year + 1 Prior Year, Current Year + 2 Prior Years, and Prior Year.
Use the Inventory Tracking page to perform simple and advanced searches for inventory. From this page you can save and name your search for later use. Click Simple Search to search for a customer, product category, product, start period, or end period. Click Advanced Search to enhance your search criteria. Click Adjust to adjust the customer's inventory level.
For numeric fields, the default search operator is equal to. For text fields, the default search operator is starts with. For example, if you enter ABC in the Customer field and then you perform a search, the results include all customer names that start with ABC, such as ABC, ABC Corporation, ABC International, and so on.
If you specify multiple criteria, the search engine uses the and condition and displays results for which all the criteria are met. For example:
If you enter Audio in the Product Category field and select 10-Mar-2017 in the Start Period field, the search results include all customers that have products in the Audio product category, and the corresponding quantity of items present in their inventory from 10-Mar-2017 to the current date.
If you select Hardware, Computer, and Laptop in the Item Category field, the search results include any item that is present in all three item categories.
For the Start Period and End Period fields in the Inventory Tracking page or the Personalize page, the search operator is always is. You can set Start Period and End Period as search fields multiple times. However, only the values you specify for the last selected Start Period and End Period are used in the search.
Special Pricing and Fund Requests are features in Oracle Channel Revenue 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.
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.
The following figure illustrates the special pricing process flow, starting from special pricing request submission to claim settlement.
Process Flow for Special Pricing
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.
Your setting for the OZF: Create Accrual on POS Receipt profile option
If you choose to use existing inventory (ship from stock) or new inventory to ship the offer order.
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 Channel Revenue 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.
Automatic claim creation and settlement – In this case, accruals are created as point of sales data is received and validated and claims on these accruals created and submitted for approval and settlement.
Enable Ship from Stock check box when creating the special pricing request
Set the OZF: Create Accrual on POS Receipt profile to Yes
Set the OZF: Auto Claim creation for POS profile to Yes
Manual claim creation and settlement as needed – In this case, you can manually create claims and associate earnings or initiate payments for approved special pricing request batches
Enable Ship from Stock check box when creating the special pricing request
Set the OZF: Create Accrual on POS Receipt profile to Yes
Set the OZF: Auto Claim creation for POS profile to No
The claim is processed in Oracle Accounts Receivable Deductions and Settlement and the partner gets paid through check or on-account credit.
Partners can submit special pricing requests in two scenarios.
Existing inventory: When a partner has already bought products and wants a discount for previous purchases. When they request for a special price or discount, and you approve it, they can proceed to make the sale to end-customers and claim the discounted amount by providing you the proof of sale.
New inventory: When a partner requests a special price or discount for a new purchase and you approve it, they must book an order with you and further proceed to make the sale to the end-customer. After they complete the sale, they can provide the proof of sale to you and claim the discounted amount. You can either let the amount accrue or give it off the invoice.
Partners can make the following types of requests:
Blanket Request: When partners have inventory in the warehouse and have not been able to sell it, they can ask for a discount to clear the unsold inventory.
Bid Request: When partners want to win a deal for specific customers. In this case the end customer needs to be specified.
Meet Competitor Quote: When partners want to match a competitor's price, they can ask you to reduce the price to complete a sale. In this case competitor information can be tracked.
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 Channel Revenue Management, budgets can be approved automatically.
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.
For Scan Data offer creation and upfront accruals,
Enable the Ship from Stock check box when creating the special pricing request. This means that existing inventory is used for the offer order.
Set the OZF: Create Accrual on POS Receipt profile to No or the default blank value. This ensures that accrual earnings that are created based on forecast are adjusted against the point of sales data as the data is received, validated, and processed.
For Accrual offer creation and accruals on receipt of POS data,
Enable the Ship from Stock check box when creating the special pricing request
Set the OZF: Create Accrual on POS Receipt profile to Yes. This ensures that accrual earnings are created against the point of sales data as the data is received, validated, and processed.
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.
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:
E-mail or fax: When partner submits a claim through e-mail or fax, the special pricing user can look up the request and approve or decline the claim. This is a manual process and data will need to be uploaded into the system to enable data processing.
Online: When the claim is submitted online, the system notifies the claim approver who reviews the claim and approves or declines the claim.
As a POS file: Each POS file has a type of either Chargeback or Special Pricing. If the POS file is of type Special Pricing, claims are automatically generated from the claim data included within the POS file.
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 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.
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. |
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
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 Channel Revenue Management.
Budget Sourcing
After the vendor approver approves the fund request, the soft fund sources funds from a budget in Oracle Channel Revenue 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 Channel Revenue 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.
The following figure illustrates the soft fund process flow, starting from soft fund request submission to claim settlement.
Process Flow for Funds Request
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 Channel Revenue Management.
Budget Sourcing
After the vendor approver approves the fund request, the soft fund sources funds from a budget in Oracle Channel Revenue 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 Channel Revenue 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 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.
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. |
Use the information in this section to:
Approve, reject, or reassign a Special Pricing or a Soft Fund request
Approve a budget request for Special Pricing or Funds request
View claims and budgets associated with a Special Pricing or a Funds 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 Channel Revenue Management as Oracle Trade Management User.
Navigation: Indirect Sales Management > Special Pricing Request > Create.
Notes:
Requester's Name: Enter the name of the contact person in the wholesaler organization.
Ship From Stock check box: This check box determines whether you will make the sale from new inventory or from the existing inventory.
End Customer: Enter the name of the customer to whom the wholesaler intends to sell the products.
Products: Enter the details of the products for which you would like to request for a special price or discount. Complete a row for each product.
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.
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 Channel Revenue 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.
Special Pricing requests can be created in Oracle Partner Management and also from Oracle Channel Revenue Management.
To create a funds request on behalf of a partner or a wholesaler, log into Oracle Channel Revenue Management as Oracle Trade Management User.
Navigation: Trade Planning > Soft Fund Requests > Create Request.
Notes:
Partner: Select the wholesaler or distributor organization for whom you are creating the special pricing request.
Requestor's Name: Select the contact person in the wholesaler organization.
Activity: This field determines the activity that will be carried out with the fund.
Partner Contribution: If the partner is contributing towards the fund, then enter the partner's contribution.
Ship From Stock: This check box determines whether you will make the sale from new inventory or from the existing inventory.
Expense Breakdown: This is the breakdown of expenses for the trade promotion activity. The 'Total' and 'Requested Amount' are amounts that will be utilized for an activity.
Performance Objectives: This is the outcome that is expected for an activity. This information will enable you to measure the success of your trade promotion expenditure.
Products: These are the products that will be promoted by the trade promotion activity.
Geography region: These are the geographical regions where the trade promotion activity will be executed.
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.
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 Channel Revenue 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.
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 Channel Revenue Management as Oracle Trade Management User.
Navigation:
Navigate to Indirect Sales Management > Special Pricing Request to approve, reject or resign a special pricing request.
Navigate to Trade Planning > Soft Fund Requests to approve, reject or resign a soft fund request.
Notes:
Click the Details icon corresponding to the special pricing request or soft fund request, and approve, decline, or reassign the request as appropriate.
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 Channel Revenue 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.
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 Channel Revenue Management as Oracle Trade Management User.
As a prerequisite, approved special pricing or soft fund requests should exist.
Navigation:
Navigate to Indirect Sales Management > Special Pricing Requests to submit a special pricing request claim.
Navigate to Trade Planning > Soft Fund Requests to submit a soft fund request claim
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
Expense Breakdown: Enter the amount spent for each activity. This gives a breakdown view of how and what exactly the funds have been spent for.
After special pricing or soft fund claims are submitted, these claims are treated as all the other claims in Oracle Channel Revenue 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.
To view claims and budgets that are associated with a special pricing request or a soft fund request, log into Oracle Channel Revenue Management as Oracle Trade Management User.
Prerequisites:
To view the associated budget, the special pricing request or funds request must have been submitted for approval.
To view the associated claims, claims must have been created for the special pricing request or the soft fund request.
Navigation:
Navigate to Indirect Sales Management > Special Pricing Request to view the view the budgets and claims that are associated with a special pricing request.
Navigate to Trade Planning > Soft Fund Requests to view the budgets and claims that are associated with a soft fund request.
Click the Details icon corresponding to the special pricing request or soft fund request you would like to access.
Notes:
Claims: Claims that have been created to settle the request are displayed here.
Budgets: Budgets from which funds have been sourced for the request are displayed.
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
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.
Click the hyperlink for a special pricing request. Potential duplicates are displayed.
If you find a duplicate end-customer or reseller, select the record and click Merge.
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.
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 Channel Revenue Management, and these claims are settled by the claims user. For more information on Referral Management, see Oracle Partner Management Vendor User Guide.
The following figure illustrates the process flow for referrals, starting from referral submission to claim settlement.
Process Flow for Referrals
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 Channel Revenue 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 Channel Revenue 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.