This chapter covers the following topics:
This chapter provides the information you need to set up the Point of Sales portion of Oracle Channel Revenue Management. How this module is implemented will vary depending on your business requirements.
Point of Sales Management enables a manufacturer to validate requests as well as manage and track funds when trade promotions are executed indirectly through retailers and wholesalers (or dealers and distributors). Point of Sales Management includes the following features:
Chargeback
When wholesalers sell products to retailers or end users, they sometimes sell the products at a price that was agreed upon between retailers and the manufacturer. If this price is lower than the price the wholesaler paid to purchase the products from the manufacturer, the wholesalers can claim the difference between their purchase price and selling price from the manufacturer through chargeback.
Third Party Accruals
When retailers buy products from wholesalers, they might not get the discounts that they are entitled to if they buy directly from the manufacturer. The manufacturer can accrue these discounts for the retailers based on the data that wholesalers send through Third Party Accrual.
Special Pricing
Retailers or wholesalers may request a special price or discount from a manufacturer in order to dispose of existing inventory, meet a competitor's price, or win a deal for an existing customer. The manufacturer can pay the retailers the discount based on these requests through Special Pricing.
Soft Funds
Retailers or wholesalers may request a budget in order to execute trade promotion activities on behalf of the manufacturer.
Inventory Tracking
The manufacturer can keep track of the inventory level of the wholesalers to verify the data that the wholesalers send. This ensures that the manufacturer does not overpay the wholesalers' claims.
Oracle Channel Rebate and Point of Sales Management and Oracle Partner Management work together in the following way:
Chargeback and Third Party Accrual data are managed in Oracle Channel Rebate and Point of Sales Management.
Special Pricing and Soft Funds, and Referral Management are features that are available in Oracle Partner Management.
Oracle Channel Rebate and Point of Sales Management integrates with Oracle Partner Management so that whenever there are any approved requests related to Special Pricing or Soft Funds, offers and claims are automatically generated in Oracle Channel Rebate and Point of Sales Management. These claims are settled by the claims user.
See the Oracle Channel Rebate and Point of Sales Management User Guide for more information on using this application.
See the Oracle Partner Management Partner User Guide for information on Partner Management.
An operating unit is a business entity with its own set of business rules. You set up entities to deal with geographical differences that affect product, customer, operational efficiency, and encourages inter division competition, If you implemented multiple operating unit access, you can view and track operations across operating units. You must also set the MO: Default Operating Unit profile option with your default operating unit before you can create an account site or an account relationship. For more information, see the Oracle Applications Multiple Organizations Implementation Guide.
Oracle Point of Sales Management uses operating units:
When importing Point of Sales data using WebADI, XML Gateway, or the interface table.The operating unit can be derived from the system profile MO:Default Operating Unit or be selected by the particular user who plans to upload the data.
When checking sales orders against the price list.
When performing batch import
When tracking each point of sales batch. This includes batch import and chargeback summary. Note: An Point of 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 Point of Sales management components:
Chargebacks: The profile option, QP: Security Control, determines whether the operating unit details in Point of 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 Point of 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.
The impact is on single organization concurrent programs where operating unit is a required parameter and the default value is derived if it cannot be found. The program processes data for only one operating unit. You must select an operating unit before you submit the following programs.
Third Party Accrual from Interface Table
Third Party Accrual from Resale Table
Oracle Channel Rebate and Point of Sales Management provides the ability to handle rebates and chargeback claims from customers and wholesaler networks for point of sales. Three types of gateways can be used to import customer information in batches: XML Gateway, EDI or WebADI. From this data, chargebacks and third party accruals are created automatically.
You can also create special pricing requests in this functionality. Point of Sales uses a price list to store the terms and conditions between the company (supplier) and its end customer for chargeback claims.
You can also use the Point of Sales Inventory Tracking feature to track distributor inventory levels. After the preliminary inventory level is established, the inventory is updated based on order management and POS [Point of Sales] data imports. All data coming from Order management is referred to as 'Inventory In' while POS data is referred to as 'Inventory Out'. This process ensures that your customers claim only the amount to which they are entitled. Adjustments to inventory can be made manually. Inventory data is updated on this screen based on a concurrent job.
To implement this functionality in Advanced Pricing, set the profile option QP: Return Manual Discounts to Yes, so that all adjustments (manual and automatic) are returned by the pricing engine.
This section describes profile options for the Point of Sales category, OZF_IDSM_SETIP. These profile options affect the processing of point of sales data through to the generation of claims.
You must set a value for a required profile option. Optional profile options provide default values, so you need to provide a value only if you want to change the default value. Your System Administrator needs to set up Supplier Ship and Debit profile options in the System Profile Values Window. See: Setting User Profile Options, Oracle E-Business Suite System Administrator's Guide.
Set the following profile options for Point of Sales.
| Profile Name | Required | Level | Setting | Default | Effect/Limitation |
|---|---|---|---|---|---|
| OZF: Auto Claim Creation For POS | No | Site | Yes/Np | No | Used to settle claims on offers created for special pricing requests. |
| OZF: Chargeback Budget | Yes | Appl Resp Site User |
List of active fixed budgets | Used with chargebacks. | |
| OZF: Common Currency for Trade Management | Yes | Site | Lists of currencies | USD (United States Dollar) | Sets a common currency for use in inventory tracking. |
| OZF: Common Unit of Measure for Trade Management | Yes | Site Appl |
List of Unit Of Measures | Each | Sets a common unit of measure for inventory tracking. |
| OZF: Create Accrual on POS Receipt | No | Site | Yes/No | Null | Used to record accruals on Special Pricing Request offers based on forecast or POS data. When used with the Ship from Stock check box for Special Pricing Request creation, determines offer types. |
| OZF: Currency Conversion Type | Yes | Site | Default = Corporate | Corporate | Sets the type of currency conversion. It is used in inventory tracking. |
| OZF: Default benefit for soft funds | No | Appl Resp Site User |
List of soft fund benefits | Default fund benefit | Used to set up the default benefit for soft fund requests. |
| OZF: Default budget for special pricing | No | Appl Resp Site User |
List of active fixed budgets | Partner Budget | Budget from this profile is used to create the budget request on submission of a special price request. |
| OZF: Default Soft Fund Request Approver | No | Appl Resp Site User |
List of internal employees | Valid employee name | Request is sent to this default approver when Oracle Approval Management does not find any rule that matches the special pricing request criteria. |
| OZF: Default Special Pricing Request Approver | No | Appl Resp Site User |
List of internal employees | Valid employee name | Request is sent to this default approver when Oracle Approvals Manager does not find any rule that matches the special pricing request criteria. |
| OZF: Enable Product Security in Special Pricing Old Name: OZF: SP_ENABLE _PROD_SECURITY (OZF: IDSM Setup) |
Appl Resp Site User |
||||
| OZF: Event for Pricing Simulation | No | Appl Resp Site User |
BATCH BOOK SHIP |
SHIP | Indicates which price phase third party should simulate. |
| OZF: Global Start Date (mm/dd/yyyy) | Yes | Site | Enter date | Suggested value: 01/01/1997 | Sets the start date for the manufacturer to track wholesalers' inventory. |
| OZF: Match Rule for Address Search Party | Yes | Appl Resp Site User |
List of DQM Rules for Address Search Party | HZ_ORE_SIMPLE_RULE_SEARCH | Defines the match rule that is used when searching for a specific addresses in the address merge step of the Data Librarian Feature. |
| OZF: Match Rule for Address Search Resale Contact | Yes | Appl Resp Site User |
List of DQM rules for Contact match | POS_Date_Party_Contact | Used to find the master contact record for the reseller and end customer names submitted by partners when submitting a special price request. |
| OZF: Match Rule for Address Search Resale Party | Yes | Appl Resp Site User |
List of DQM rules for Party match | POS_Data_Party | Used to find the master party record for the reseller and end customer names submitted by partners when submitting a special price request. |
| OZF: Match Rule for Address Search Resale party Site | Yes | Appl Resp Site User |
List of DQM rules for Site match | POS_Data_Party_Site | Used to find the master site record for the reseller and end customer names submitted by partners when submitting a special price request. |
| OZF: Price Difference Budget | Only with Third Party Accrual | Appl Resp Site User |
Enter correct values | Trade Management Price Difference Budget | Budget name for third party price difference |
| OZF: Request grace period in days for soft funds | No | Site | Numeric | 0 | Used to set up grace days to close soft fund requests. Default is 0 if not set. |
| OZF: Request grace period in days for special pricing | No | Site | Numeric | 0 | Used to set up grace days to close soft fund requests. Default is 0 if not set. |
| OZF: Third Party Accrual Price List | Yes | Appl Resp Site User |
List of available price lists | Corporate | Used to set a price list for third party accrual. |
| OZF: Third Party Accrual on Selling Price | No | Appl Resp Site User |
Yes/No | No | Sets whether you want the third party accrual calculation to be based on the selling price. The default value is No, which means that the calculation is based on list price. |
| Application Framework Agent | Yes | Appl | Enter URL | http://ap6167rt.us.oracle.com:8001 | Used to construct the return URL, which is passed to the Web. |
| Apps Servlet Agent | Yes | Appl | Enter URL | http://ap6167rt.us.oracle.com:8001/oa_servlets | Used to construct the return URL, which is passed to the Web. |
| ICX: HTML directory | Yes | Appl | Directory name | OA_HTML | Used to construct the return URL, which is passed to the Web. |
To implement point of sales, set up the defaults in the Indirect Sales section of the System Parameters page.
Log into Oracle Trade Management with Oracle Trade Management User responsibility. Navigate to Trade Management : Administration > Trade Management >Setup > System Parameters. Set the following parameters:
| Indirect Sales Parameter | Description |
|---|---|
| Batch Tolerance Type Line Tolerance Type |
You can set Batch Tolerance Type and Line Tolerance Type as either amount or percent type. Use Batch Tolerance and Line Tolerance to set a limit at which the difference between manufacturer's calculated rebate and wholesaler's claimed rebate will not cause a problem for the manufacturer to pay the claim discount. If the difference is smaller than the tolerance, the system allows the process to continue. However, If the difference is greater than the tolerance, the process is stopped and the line or batch is put in dispute. Batch tolerance limits the difference allowed for the whole batch. While line tolerance limits the difference allowed per unit of the product on the line. You can also set batch and line tolerance at the trade profile level. See Configure Trade Profiles for details. |
| Chargeback Calculation Basis | Set Claimed Amount - Use to set whether you want to pay a claimed amount from a second party Set Allowed Amount - Use to pay the amount calculated based on your accounting system Sometimes the claimed amounts are higher than calculated amounts, but you may have business reasons for permitting a higher payment to a particular client. For example, if they represent a substantial part of your business and you want to maintain a good relationship. |
| Create Accruals on Chargeback Claims | Use in situations where an offer must accumulate towards a final claim. For example, mail-in rebates or other time-sensitive offers. |
| Inventory Tracking | Check this box if you are concerned about matching quantities for claims. Note that this process can be time-consuming and you should only run it if absolutely necessary. |
| Create Relationship Between End User and Wholesaler | Check this box to create a relationship between an end customer who is not a party in TCA and a reseller. If you check the box, a party is created in TCA and a relationship between the end customer and the reseller is set up |
| Run Third Party Accrual After Chargeback Calculation | Check this box if you need to pay claims from a third party. For example, a coupon mailed in from end users. You can pay the claim to the end user after settling the claims of wholesalers. Only select this box to run for valid chargebacks. |
Data Processing uses DQM to call an API from the TCA to get information on the party, such as name, address, phone number, and so on. This step is also where code conversion is set up to map codes from wholesalers and third parties to the codes used by your enterprise.
Data processing includes these sections:
Set System Parameter Defaults for Point of Sales
Configure Trade Profiles
Set Up DQM Integration
Code Conversion
Import Cross References Using WebADI
Business Events and Subscription
You must import data into Oracle Trade Management for Indirect Sales to work correctly. You can import using WebADI or XML Gateway.
Complete the following procedures to import data:
To upload data to Trade Management using WebADI, you can create an empty spreadsheet and enter new data into it. If the spreadsheet already has data, the content should be converted to a delimited text file and uploaded to an empty spreadsheet in WebADI. The APIs are available for you to upload the data, validate it, and flag any errors. If any errors occur, the data will not be uploaded to the database.
It is important to validate that WebADI is installed properly before proceeding with loading data. To do this, perform the following procedure.
Installation
Install the Diagnostic Wizard patch. This patch copies BNETEST class file up to webserver.
Ensure that BNETEST is in the class path.
Copy the BNETEST.class under /servlets directory on the server.
Run the BNETEST using <app server:port>/oa_servlets/BNETEST URL to check if there is any problem with WebADI installation.
To set up WEBADI for Indirect Sales, set the BNE profile options to the values shown in Appendix A. See Profile Options for Indirect Sales.
As a prerequisite, give jserv write access to Group and All for $APPL_TOP/bne/11.5.0/log and $APPL_TOP/bne/11.5.0/upload directories.
Log in to Oracle Trade Management and navigate to Indirect Sales Management > Chargeback.
Click Import Batch and navigate to Select Layout Page in the WebADI Application.
Select Trade Management: Resale Layout if the data comes from Oracle Application.
Select Trade Management: Resale Text Layout if the data comes from a third party application and requires external code to internal code conversion.
On the Select Content page,
Select Download to update a batch, or
Select None to enter the data manually, or
Select Text File to import data to an Excel spreadsheet and upload it to Oracle Application Indirect Sales Management Interface Tables.
On the Select Mapping Page:
If Download is selected as content, enter the Batch Number for the batch to be downloaded.
If Trade Management: Resale Layout is selected, select Download mapping.
If Trade Management: Resale Text Layout is selected, select Download Text Map mapping.
If None is selected as content, skip the Select Mapping Page.
If Text File is selected, go to step 7.
If Text File is selected as content on the Select Mapping Page:
For the Select Text File section:
Select the text file from local directory that has the data to upload into Oracle Application Indirect Sales Management Interface Tables.
Select one of the delimiters that is used in the text file.
Enter the number for the line where the actual data starts. Skip the line that has the column title. For example, if the header is at line 1 and the data starts from Line 2, Enter 2 in the Start Importing at Line Number field.
For the Select Mapping section:
If Trade Management: Resale Layout is selected, select Text File Map mapping.
If Trade Management: Resale Text Layout is selected, select Text Entry Map mapping.
On the Document Creation Review Page, review the entries and click Create Document.
When Download and Text File content is selected, an Excel spreadsheet is created and populated with data.
If Download content is selected, update the data. If None content is selected, enter data in the Excel spreadsheet
After the data is entered, updated, or downloaded from a text file in the Excel spreadsheet, click the Oracle option menu and select Upload.
A status monitor page appears with Upload and Cancel buttons.
Click Upload.
The status shown on the page indicates the upload status and importer status.
Note: Importer validates the data uploaded into Oracle Application Interface Tables.
To set up the XML gateway to send and receive data, you must define the trading partner. You need to select the OZF transaction type and the two seeded transaction subtypes of POSI (inbound) and POSO (outbound). The POSI subtype has two maps you can use with it and the POSO has one. The basic procedure is described here, but for additional information, please refer to the Oracle XML Gateway User's Guide. To set up XML Gateway messages, set the three ECX profile options in Appendix A. See Profile Options for Indirect Sales.
Log into Oracle Forms with the XML Gateway responsibility.
Navigation: Trading Partner Setup.
Notes:
Trading partner: Customer.
Transaction type: Select OZF for Oracle Trade Management Inbound and Outbound Messages. See Guidelines. If the Document Confirmation Code is 2 for Inbound Message, then select ECX for confirmation message.
Transaction sub types:
Select OZF for the POSI and POSO transaction subtypes.
Select ECX for the CBOD transaction subtype.
For Inbound Message, select POSI.
For Outbound Message, select POSO.
For Confirmation Message, select CBODO.
Mappings: Perform these mappings:
For OZF transaction type and POSI transaction sub type, select OZF_PROCESS_SHDBT_IN for Inbound 844 Transaction or OZF_PROCESS_SLRPT_IN for Inbound 867 Transaction. You can add variables to USERAREA to customize the map.
For "OZF" transaction type and "POSO" transaction sub type select "OZF_PROCESS_SHDBT_OUT" for Outbound 849 Transactions.
If Document Confirmation Code is "2" for inbound Messages, select ECX_CBODO_OAG72_OUT_CONFIRM for Outbound Confirmation Message.
Source trading partner location code: This is the party site ID/location code of the party. Use this to enter the party site ID while sending data using XML Gateway.
Document confirmation: Select based on what level of confirmation the trading partner wants to receive for inbound and for all outbound messages.
0: Never send a confirmation
2: Always send a confirmation
See Guidelines for Workflow information.
Guidelines
Transaction Type is the standard product short code for the base Oracle Application. These values are defined in the Define Transactions form. The list of values displays the available combinations of Transaction Type, Transaction Subtype, Standard Code, External Transaction Type, External Transaction Subtype, and Direction. Select the desired combination. These values are only used internally to connect to the XML Gateway.
When the XML Gateway execution engine, oracle.apps.ozf.idsm.resli subscription, is triggered successfully, it processes an inbound message, which in turn starts the OZF: Resale Pre Processing workflow. The process is as follows:
When document confirmation is 2 for an inbound message and oracle.apps.ozf.idsm.confirm subscription is enabled, a confirmation message is sent to the trading partner that the inbound message was received by the Oracle Trade Management application.
For data received as an inbound message processed by the Data Process, if there is any data processing error, an outbound message is sent to the trading partner informing them of the error.
If there is any system error, the System Administrator is notified of the error.
Data Processing uses DQM to call an API from the TCA to get information on the party, such as name, address, phone number, and so on. This step is also where code conversion is set up to map codes from wholesalers and third parties to the codes used by your enterprise.
Data processing includes these sections:
Import Cross References Using WebADI
You can also configure batch and line tolerance in the trade profile for a party. To set up trade profiles, log in to Oracle Trade Management with Oracle Trade Management User responsibility.
Navigation: Administration > Trade Management > Administration > Setup > Customer > Trade Profiles.
For information on batch and line tolerances, see Set System Parameter Defaults for Indirect Sales.
Data Quality Management (DQM) is a tool from the trading community architecture (TCA) group that is used to check for potential duplicate customer, contact address, and contact points for a given customer, contact, or address.
There are 3 profiles options which hold value for the DQM: Match rule. These profiles are mandatory and must hold value of match rule. See Setting Point-of-Sale Profile Options.
For additional on setting up DQM Integration refer to the Oracle Trading Community Architecture Guide - Technical Implementation Guide, chapter on Data Quality Management (DQM)
When you define a rule, you need to determine which table column names are to be passed to acquisition attributes from the Pre Process API. An acquisition attribute can have values passed from several table column names. If you want to pass on the Bill_to information, for example, you can send the Name, Address, City, State, Country, Postal Code, Contact Name, Email Address, or Raw Phone Number acquisition attributes.
| Acquisition Attribute | Table Column Name |
|---|---|
| Name | Sold_from_party_name/Ship_from_party_name/Bill_to_party_name/Ship_to_Party_name/End_cust_party_name |
| Address | Sold_from_address/Ship_From_Address/Bill_to_Address/Ship_to_Address/End_cust_Address |
| City | Sold_from_city/Ship_from_city/Bill_to_city/Ship_to_city/End_cust_city |
| State | Sold_from_State/Ship_from_state/Bill_to_state/Ship_to_state/End_cust_state |
| Country | Sold_from_country/Ship_from_Country/Bill_to_country/Ship_to_country |
| Postal Code | Sold_from_postal_code/Ship_from_postal_code/Bill_to_postal_code/Ship_to_postal_code/End_cust_postal_code |
| DUNS Number | Bill_to_Duns_Number/Ship_to_duns_number |
| Contact Name | Bill_to_Contact_Name/Ship_to_ Contact_Name/Sold_from_Contact_Name/Ship_from_Contact_Name/End_Cust_Contact_name |
| Email Address | Bill_to_email/Ship_to_email/Sold_from_email/Ship_from_email/End_Cust_email |
| Phone Line Type | If phone number is not null , value will be "PHONE", if fax_number is not null , value will be "FAX" |
| Raw Phone Number | If a phone number is not null, the value will be "PHONE"Bill_to_Phone/Ship_to_Phone/Sold_from_phone/Ship_from_phone/End_cust_phoneif fax_number is not null , value will be "FAX"Bill_to_fax/Ship_to_fax/Sold_from_fax/Ship_from_fax/End_cust_fax |
Use code conversions to map the codes in a wholesaler's system to your enterprise's internal codes. External codes received from customers are converted into the internal values for the following data elements:
| Data Element | Description |
|---|---|
| Agreement | : Mapping between the Chargeback agreements that are set up as Price Lists and the customer's reference to these agreements. |
| Product | : Mapping between internal products and customer references to these products. |
| Reason | : Mapping between a claim reason and customer reasons. |
| UOM (Unit of Measure) | : Mapping between internal unit of measure and the customer's unit of measure. For example, a wholesaler may use EA for a single unit but your enterprise uses EACH. |
| Party | : Mapping between an internal party and the customer's party reference. |
| Party site | : Mapping between an internal party site and the customer's party site reference. |
To convert codes, log in to Oracle Trade Management.
Navigation: Administration > Trade Management > Indirect Sales > Code Conversion.
For code conversion, you can import cross references using WebADI.
Log in to Oracle Trade Management > Administration > Trade Management.
Continue navigation using either of the following paths:
Indirect Sales > Code Conversion
Customer > Trade Profiles > Click Code Mapping icon
Click Import.
On the Select Viewer Page in the WebADI Application, select Excel 2000 as viewer.
Note: Steps 4-6 may be automated. If so, proceed directly to On the Select Content Page section.
On the Select Integrator Page, select Trade Management: Code Conversion from the integrator drop-down list.
On the Select Layout Page, select Trade Management: Code Conversion.
Select Download to update Code Conversion Mapping, or
Select None to enter the data manually, or
Select Conversion Text Map, to import data from a text file into an Excel spreadsheet and upload it to the Oracle Application Code Conversion Mapping Table.
On the Select Mapping page:
If Download is selected as content, the Select Mapping Page is skipped.
If None is selected as content, the Select Mapping Page is skipped.
If Text File is selected, see step 9.
If the Text file is selected as content:
For the Select Text file section:
Select the text file from the local directory that has the data to upload into Oracle Application Code Conversion Mapping Table.
Select one of the delimiters that is used in the text file
Enter the number for the line where the actual data starts. Skip the line that has the column titles. For example, if the header is at line 1 and the data starts from Line 2, enter 2 in the Start Importing at Line Number field.
For the Select Mapping section, Text File Mapping is defaulted.
On the document Creation Review Page, review the entries and click Create Document.
An Excel spreadsheet is created and populated with data when Download and Text File Content are selected. If Non is selected, enter data in the Excel spreadsheet.
In the Context section:
For Account Level Code Conversion Mapping, Enter Value for Account ID
For Customer Level Code Conversion Mapping, Enter Value Party ID
If Party ID and Account ID then Code Conversion Mapping is set up at Org Level
After the data is entered, updated, or downloaded from the text file in the Excel spreadsheet, click the Oracle option menu and select Upload. A status monitor page appears with Upload and Cancel buttons. Click Upload to display the upload status.
A business event is an event in which you have an interest. The subscriptions to it are the actions that need to performed when that event happens.
Business events are used to invoke one process from another. The mainly serve as a link for four processing points.
Receiving data
Processing
Payment
Sending data
All business events are seeded in the application. You can unsubscribe to any that you do not need, except for the following:
oracle.apps.ozf.idsm.resli
oracle.apps.ozf.idsm.ridp
oracle.apps.ozf.idsm.rspi
| Business Event Name | Display Name | Meaning |
|---|---|---|
| oracle.apps.ozf.idsm. WEBADIPayment | Initiate Payment for WEBADI Submission | To start payment for batches submitted through WEBADI automatically |
| oracle.apps.ozf.idsm. WEBADIProcess | Initiate Data Process for WEBADI Submission | To start data process for batches submitted through WEBADI automatically |
| oracle.apps.ozf.idsm.XMLPayment | Initiate Payment for XML Gateway Submission | To start payment for batches submitted through XML Gateway automatically |
| oracle.apps.ozf.idsm.XMLProcess | Initiate Data Process for XML Gateway Submission | To start data process for batches submitted through XML Gateway automatically |
| Oracle.apps.ozf.idsm. | Populate the Order Management structure | To change the values of Order Management global structure for pricing simulation |
| oracle.apps.ozf.idsm.resli | Resale Inbound XML Event | To receive inbound messages through XML Gateway |
| oracle.apps.ozf.idsm.reslo | Resale Outbound Event | To send messages through XML Gateway |
| oracle.apps.ozf.idsm.ridp | Resale Interface Data Process | To start data process |
| oracle.apps.ozf.idsm.rspi | Resale Data Payment Initiation | To initiate the payment process |
| oracle.apps.ozf.idsm.confirm | Resale Confirmation Event | To send confirmation messages to trading partners |
The Third Party Accrual API enables customers to generate accruals on orders made through third party whole sale corporations. This API simulates the pricing of orders and then creates order information in chargeback order tables. It posts the difference between customer paid price and simulated price to a budget that is setup by the customer. Any discount and accrual applied to the order is accrued.
Order information is stored in ozf_chargeback_int_all table. The API process orders from direct customers as well as indirect customers. For indirect customer orders, the API does not run the pricing simulation. It copied the order information to the chargeback order tables.
For direct customers, the API validates the data, runs the simulation, creates the order and posts the accrual amount. Direct_customer_flag in ozf_chargeback_int_all indicates whether the order record is from a direct customer or not. Discount and accrual related information is stored in ozf_chargeback_price_adj_all table.
For any exception generated during the process, a log record is created in an interface log table. User can use this table to modify the data.
The API consists of the following two concurrent programs:
Third Party Accrual from Interface Table
Resale Batches Purge
Follow these steps before running the concurrent program:
Set up the profile: AMS: Price Different Budget to run the concurrent program.
Set up Oracle General Ledger account information in ozf_sys_parameters
Define Account Derivation Rules in Oracle Subledger Accounting.
The concurrent program purges resale order records and purges the entries in the OZF_RESALE_LINES_INT_ALL interface table.
For additional information see the Chapter 11, Indirect Sales Management in the Oracle Channel Revenue Management User Guide. In the section titled Working With Chargeback and Third Party Accrual Transactions you can find information on the following:
Import a transaction through Web ADI
View and update lines
Accept disputed lines and process a submission
Initiate payment for a transaction
A special pricing request enables customers to request discounted pricing from the user. They can request discounts on competitive sales deals, specific end-customer deals, and on inventory that they have not been able to move.
When a request is submitted, it gets routed to the appropriate approver(s). Approvers are notified of the request and they review the request and approve or decline the request. After the special pricing request has been approved, and the customer has closed the sale, they can submit a claim to receive the discount that was approved. The claim is routed to the claim approver who then validates the claim. When the claim gets approved, the user pays the discount amount.
Partners and vendors need to be notified of the status of a request when it is submitted. Oracle Workflow notifications are triggered to notify partners, channel managers and approvers. Notifications for each status is sent to alert different users about the request.
To set up notifications, log in to Oracle Trade Management as the Oracle Trade Management Administrator.
Navigation: Administration > Trade Management > Indirect Sales > Special Pricing Notifications.
The following table provides information on notifications, the user roles that can receive the notifications, and the status of the notification the user role can receive. Select from these while setting up the notifications.
| Notification Name | User Role | Status |
|---|---|---|
| Request Created - Channel Manager Notification | Channel Manager | Draft |
| Request Submitted - Partner Notification | Partner Contact, Special Pricing Super User (Partner) | Pending Approval |
| Request Submitted - Vendor Notification | Vendor Channel Manager, Vendor Approvers, Special Pricing Super User (Vendor) | Pending Approval |
| Request Approved - Partner Notification | Partner Contact, Special Pricing Super User (Partner) | Approved |
| Request Cancelled - Partner Notification | Partner Contact, Special Pricing Super User (Partner) | Void |
| Request Declined - Partner Notification | Partner Contact, Special Pricing Super User (Partner) | Declined |
When a request is created, the end customer name and reseller names are entered by the partner and must be matched to an existing record in TCA, if any exists. DQM is used for this purpose. See Set Up DQM Integration for more information on DQM.
If there are no matches for the end customer or reseller, a new customer is automatically created by the system.
If there are possible customer matches, the DQM approver reviews the matches and can either select an existing customer in the system or create a new customer.
Users must have permission OZF_SPECIAL_PRICE_DQM to be a DQM approver. Any user that has this permission and has access to the special pricing function can look up requests that need party matching from the entire request list by filtering for requests that have the Customer Merge Flag set as false.
When a request is created, it must be approved before it is converted to an offer. The approver views requests and approves or rejects them. Approvers are internal employees or vendors that are defined in Oracle Approvals Management (AME).
Approvers are assigned to review requests and can perform the following before approval of a request.
Validate the information entered by the partner.
Check for similar requests and accept or decline a request.
Compare pricing details between similar requests.
Forward to additional users for review.
For the procedure, see the Oracle Approvals Management Implementation Guide. Use the OZF: Special Pricing Request transaction type.
Three offer custom setups have been seeded for special pricing request:
Special Pricing OffInvoice: Ship and Debit special pricing requests use this setup.
Special Pricing Accrual: New inventory requests approved with Accrual offer use this setup.
Special Pricing ScanData: New inventory requests approved with Off Invoice offer use this setup. The suffix defined in this offer custom setup is used as the prefix for the special price request number.
Setting Up Claims
The following information describes settings related to Claims in Special Pricing.
Custom Setup
A custom setup can be seeded for Special Price request claims. Creating different custom setups provides the following benefits:
A different prefix can be used for special pricing claims.
Approvals can be routed differently based on this setup.
Claim validations can be different.
To create custom setups, see the information in the Oracle Channel Revenue Management Implementation and Administration Guide.
Claim Defaults
You can set up a default custom setup, claim type and claim reason for Special Pricing claims. For the procedure, see Set Up Defaults for Claims.
Trade Profiles
Trade Profiles allows defaulting of payment methods, vendor, and vendor site mapping for a partner. They also enable setting of the batch level and line level threshold limits for error margins of special pricing claims submitted through Channel Rebate and Point-of-Sale Management. For more information on setting up trade profiles see the Oracle Channel Revenue Management Implementation and Administration Guide.
Special pricing requests interact with other modules of Oracle Trade Management as described in the following table:
| Data | Description |
|---|---|
| Offers | When a special pricing request is approved, an offer is generated in Oracle Trade Management. Offer types include: Scan Data Offer: This offer enables users to reimburse customers for the discounted amount on products that the customer has already bought. OffiInvoice Offer: This offer acts as a pricing modifier for future orders. The Approver(s) can see this field during approval if the Ship from Stock check box is not selected. If approvers specify this type of offer, customers do not have to submit a claim. An authorization coded is generated for the customer upon approval, which needs to be used when booking their order to get this discount. Accrual Offer : This offer acts as a pricing modifier for future orders. The approver(s) can see this field during approval if the Ship from Stock check box is not selected. If approvers specify this type of offer, customers have to submit a claim. An authorization code is generated for the customer upon approval, which needs to be used when booking their order to get this discount. |
| Budgets | You can set up a default budget for sourcing special price requests. When a default budget exists, the system generates a budget request for the requested amount upon submission. You can configure the budget tab to display or not for the approvers. When the budget tab displays, approvers can change the budget sourcing options. If approvers do not change the sourcing option, the system automatically adjusts the budget amount based on the approved amount. |
| Claims | After a sale is completed at the discounted price, the customer can submit a claim to collect payment. Optionally, claims can be submitted along with the sale data as a proof of performance through Indirect Sales. Claims are validated in Oracle Trade Management. Claims must be submitted in the same user organization as the one in which the special price request was approved. |
Access to requests is controlled based on user permissions and roles.
User Permissions
You can assign Superuser permission to both vendors and partners. Vendors with this permission can view, update, and approve all requests. Partners with this permission can view and update all requests.
Giving DQM permission enables users to clean up their request by identifying end customers and resellers with the master party record. DQM does not have to be performed for a request to get approved.
User Types
The types of users assigned in Oracle Trade Management are listed in the following table. To assign Partner Superuser, Partner Request User, or Channel Manager, see the Oracle Partner Management Implementation Guide.
| User Type | Description |
|---|---|
| Vendor Superuser | Vendor users with the super user permission OZF_SPECIAL_PRICING_SUPERUSER. Vendor users with this permission can view, update, approve and perform DQM on all requests. |
| Request Approver | Request approvers are defined in OAM and cannot access requests until an approval is required. Once access is granted, the approver can continue to access requests but will not have the approval privilege. |
| DQM Approver | Users with permission 'OZF_SPECIAL_PRICING_DQM. These users can access requests that require data maintenance. |
Customers can request funds for specific marketing activities and thus boost sales.
When a request is submitted on behalf of a customer, it gets routed to the appropriate approver(s). Approvers are notified of the request and they review, approve, decline, or return the request. The approver can return the request asking the customer to provide additional information.
After the customer resubmits the request and the request is approved, they can execute the marketing activity and submit a claim to redeem money from the user. When they submit a claim, it is routed to the claim approver who then validates the claim. When the claim gets approved, the user pays the amount.
A soft fund can be set up as a benefit with the benefit type of Soft Funds. The fund can have one or many budgets and notifications associated with it. Associated budgets are sourced from during fund request approval.
You can set up Notifications rules to send notifications to various roles on changes of fund request status.
To create a soft fund as a benefit, log into Oracle Trade Management with the Channel Administrator responsibility.
Navigation: Programs > Benefits > Benefit Administration page.
Notes:
Create list of values: Select Fund Request.
Budget: The vendor approver will source from this budget during fund request approval.
Notifications: Attach a notification to the benefit. These notifications will be sent whenever there is any fund request activity.
The following table lists and describes the dependencies for setting up soft funds.
| Dependency | Description |
|---|---|
| Setting Up Expense Items | Breakdown of expenses are setup as marketing mediums in Oracle Trade Management. Accruals that are to be paid on approval of the partner fund are tracked against these marketing mediums. See Create Marketing Mediums for the procedure. |
| Setting Up an Activity | An Activity manages the relationship between an object's Activity Type and the Marketing Medium. To create an activity, see Create Activities. |
| Setting Up a Budget Category | When you create a soft fund request, you need to set up budget categories. Budget categories are used for:
|
| Setting Up Budgets | Every budget belongs to a budget category. Products specified in a soft fund request are not validated against the products in a budget. To set up a budget for a soft fund, see the Budgets chapter. |
| Setting Up Offers | When a request is approved, a lumpsum offer is generated in the background. The offer is used to track the fund committed for the partner. Vendors can:
|
| Setting Up Claims | When working with a partner you can set up claims using a custom setup. Claim reasons, claim defaults, and trade profiles can be defined in Oracle Trade Management for soft fund management. |
| Custom Setup | A custom setup can be seeded for soft fund request claims. Creating different custom setups provides the following benefits:
To create custom setups, see Create Custom Setups. |
| Claim Reasons | Partners can give specific reasons when submitting claims on special pricing requests. Reasons that can be seen by a partner user have to be flagged for 'Partner Access'. To set up claim reasons, see the Oracle Accounts Receivable Deductions Settlement Implementation Guide. |
| Claim Defaults | You can set up a default custom setup, claim type and claim reason for Soft Fund claims. To set up claim defaults see the Oracle Accounts Receivable Deductions Settlement Implementation Guide. |
| Trade Profiles | Use Trade Profiles to set up default payment methods, vendor and vendor site mapping for a partner. For this procedure, see the Oracle Accounts Receivable Deductions Settlement Implementation Guide |
| Setting Up Approval Rules | Approval rules determine what must be approved, by whom, and at what status. Approval rules for claims can be configured using multiple parameters such as amount, claim type, claim reason, and organization. To set up an approval rule for a soft fund request, see Create Approval Rules. Add Link Chapter 6. |
| Defining Performance Objectives | You must enter performance objectives for the soft fund as lookup codes in the OZF_PARTNER_PERFORMANCE lookup. For example, you can use Leads Generated, or Revenue Expected as performance objectives. See the Creating New Lookup Types section for this procedure. |
| Geography | Geographical regions where activities using soft funds will take place are defined in Oracle Territory Manager. See the Oracle Territory Manager Implementation Guide for the procedure. |
Soft fund requests interact with other modules of Oracle Trade Management including:
| Module | Description |
|---|---|
| Offers | When a soft fund request is approved, an offer of type lumpsum is generated. All lumpsum offers created from soft funds use the seeded custom setup Soft Fund - Lumpsum. |
| Budgets | Budget request approval can be enabled or disabled for soft fund requests from the Soft Fund - Lumpsum custom setup. Approvers are able to source only from budgets to which they have access. |
| Claims | After a request is approved and the customer has executed the desired activity, they can submit a claim to collect payment. Claims are validated in Oracle Trade Management. Claims must be submitted in the same vendor organization as the one in which the soft fund request was approved. |
The following table lists and describes the seeded data for Soft Fund Requests:
| Data | Description |
|---|---|
| Permission | OZF_SOFT_FUND_SUPERUSER Vendor users with this permission can view, update and approve all requests. Partner users with this permission can view and update all requests made by their organization. |
| Notifications | Notification messages that can be used to communicate changes of status are contained in workflow item type OZFSFBEN - 'Special Price Benefit Notifications'. Seeded messages in this workflow are:
|
| Offer Custom Setups | A new custom setup has been seeded for a Lump sum offer created by a soft fund request. The suffix defined in this offer custom setup is used as the prefix for the soft fund request number. |
| OAM Attributes | The following mandatory attributes are seeded:
In addition to mandatory attributes, some custom attributes are seeded: |
| Non Mandatory Header Attributes | ALLOW_EMPTY_APPROVAL_GROUPS : Whether to allow approval groups to have no members This attribute requires these approval types: approval-group chain of authority, post-chain-of-authority approvals, pre-chain-of-authority approvals. CURRENCY_CODE IS_VAD : To find whether the partner is a value added distributor MEMBERSHIP_TYPE : Partner Membership Type PARTNER_AMOUNT PARTNER_COUNTRY PARTNER_INDUSTRY PARTNER_LEVEL PARTNER_NAME PARTNER_TYPE REQUESTED_AMOUNT SOFT_FUND_ACTIVITY SOFT_FUND_BENEFIT TOTAL_AMOUNT : Total Amount |
| Non Mandatory Line-Item Attribute | EXPENSE_ITEM |
Access to requests is controlled based on user permissions and roles. Super User permission can be assigned to vendors by assigning them a user type of Vendor Superuser with OZF_SOFT_FUND_SUPERUSER permission. Vendors with this permission can view, update, and approve all requests.
Volume rebates or discounts are used to increase sales. Since different products and product categories can have different price and cost models, it is possible that a different set of rates exists for each product category or even product. If you are limited to one rate structure per volume offer, you must create multiple volume offers to handle this requirement, increasing time to create and maintain offers in the system.
In Oracle Trade Management you can create one single offer for multiple customers with the same rate structures.
A volume offer is configurable for the following:
Direct sales data only
Indirect sales data only
Indirect purchases only
Combination of direct and indirect purchases
Volume Offers track the cumulative sales from a customer to an end customer and update the discount or accrual rate accordingly. If both direct sales and indirect purchases qualify for this offer, both pieces of data are tracked and summed up to be evaluated for the volume offer.
Follow these steps to create a Volume Offer in Oracle Trade Management:
Create a volume offer by selecting custom setup.
Enter budget, budget amount, activity and other header details.
Define discount tables (one or many).
Define to track volume by amount or quantity and select if discount is in percent or amount.
Determine if the discount is a stated value or calculated by a formula.
The discount table can contain one or many tiers. For example, 1 to 10,000 cases get a 5% discount while 10,001 to 20,000 cases get a 6 % discount. The “To” value can be null on the last tier, creating an open-ended tier break. If the tier values overlap, the system sends an error message when you try to save.
Enter eligible products or product category for each discount table; each discount table can contain one or many products or product categories
Products and categories may be included or excluded from the volume calculation.
Products and categories may or may not be eligible for the discount.
Define market eligibility by entering customers, buyers and sellers to track.
Define market options including beneficiary and retroactive adjustments.
Determine if volume for each customer in a grouping will be tracked together or separately.
Determine if volume of all products on all discount tables will be tracked together or separately.
When you use indirect sales data for volume offers, it is important to correctly identify the seller and buyer for market eligibility rules. Seeded qualifiers are required to identify indirect sellers and buyers. The “Sold By” IDSM qualifier supports the following contexts and values:
A seller/buyer can be an account or an account site. Both need to be seeded as Advanced Pricing qualifiers.
A seller account is a valid account site defined in Accounts Receivable.
Indirect seller and buyer account sites are valid customer account sites defined in Territory Community Architecture (TCA).
The “Sold By” Indirect Sales Modifier (IDSM) qualifier supports the following contexts and values:
| Context Attribute | Context Value |
|---|---|
| Sales Method | Direct Sales and Indirect Sales |
| Distributor Name | Distributor Segment Name |
| Distributor List | Distributor List Name |
| Distributor Territory | Oracle Trade Management territory name |