This chapter covers the following topics:
Special Pricing Management enables partners to submit and check the status of special pricing requests and claims online. A special pricing request enables partners to request discounted pricing from the vendor. Partners 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 it. After the special pricing request has been approved, and the partner has closed the sale, he/she 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 vendor pays the discount amount.
Partners receive notifications about the special pricing request activity and can link directly from the notification into the associated special pricing request. Notifications are configured by the vendor and sent when the status changes, for example, when a special pricing request is approved.
Partners can access a summary list of all the special pricing requests that they have access to, in the system. They can build personal views to quickly find the special pricing requests that they are most interested in.
In case of special pricing requests, the liability gets created upon approval for each of the products for the total approved discount amount. When a request is linked with another request, the liability is created only for amounts in products, which exceeds the current liability for that product.
For example:
A special pricing request (SPR1234) has been submitted to sell products mentioned in the table below, to a Customer A for the Existing Inventory scenario.
| Product | Discount Amount | Units | Discount |
|---|---|---|---|
| Laptop | $120 | 10 | 1000 |
| Desktop | $100 | 60 | 6000 |
A special pricing request (SPR1235) has been submitted to sell products mentioned in the table below, to a Customer A for the Existing Inventory scenario.
| Product | Discount Amount | Units | Discount |
|---|---|---|---|
| Laptop | $120 | 11 | 1100 |
| Desktop | $100 | 55 | 5500 |
If SPR1234 is approved first and SPR1235 gets linked to SPR1234 because it is a request for the same end-customer deal, when request SPR1235 gets approved, it creates an additional $100 liability for laptops and an additional liability is not created for desktops.
In the above scenario, the same underlying offer authorization code would be used to track liabilities for both requests and both would have the same agreement numbers.
Special pricing requests are funded from one or more budgets. Budgets are set up in the Trade Management application by a user with the Oracle Trade Management User responsibility.
A special pricing budgets is a fixed budget. A fixed budget is a pool of money with a value greater than zero. When you create a fixed budget, you decide the maximum amount of funds that it can include (although additional funds can be specified later if needed).
A fixed budget allows the vendor to track the amount of funds that have been committed, used, earned, and paid for from the budget. When the budget is set up, an account can be specified and then used to track liability for the budget.
A budget is specified as a special pricing budget through the OZF: Default budget for special pricing requests. Depending on an organization's business needs, a single special pricing budget can fund all special pricing requests, or multiple budgets can be set up. This option needs to be set for each budget that will fund special pricing requests.
Special Pricing budgets are funded from one or more fixed budgets, usually set up at the country level. Use the profile option OZF: Default budget for special pricing to indicate whether your organization has one or multiple special pricing budgets.
For a single budget, specify the name of the budget at the Site level
For multiple budgets, specify each specific budget at the Responsibility level, with the responsibility corresponding to a business unit or a geographical entity.
Use this procedure to create a new special pricing budget.
Navigation
Log on to the Trade Management application with the Oracle Trade Management User responsibility, and navigate to Budget > Create to access the Create Budget page.
Prerequisites
None
Notes
Setup Type: Select Fixed Budget.
Category: Select the appropriate category for the special pricing budget. An organization can create a category to organize special pricing budgets. Refer to the Oracle Trade Management Implementation Guide for additional information on categories.
Owner: By default, the owner is the user creating the budget. A different owner can be specified.
Create button: When you click Create, the Budget Detail page appears. From that page, you can specify accounting information, including an accrual liability account and a sales/expense/charge account. Refer to the Oracle Trade Management Implementation Guide for additional information.
After the special pricing budget or budgets have been set up, the OZF: Default budget for special pricing profile option must be set to identify the budgets appropriately.
If an organization is going to use a single special pricing budget, the profile option is set at the Site level. The value is the name of the budget.
If an organization is implementing multiple budgets for special pricing, the profile option must be set for each budget at the Responsibility level, where the responsibility corresponds to a business unit or geographic entity. The value is the name of the budget.
When a special pricing request is approved, an offer is created in Oracle Trade Management. The type of offer created is determined by the type of special pricing request:
ScanData Offer: This offer is generated when a partner requests special pricing for products that already exist in the partner's inventory. The offer enables vendors to reimburse partners for the discounted amount on products that partners have already bought. The partner will need to submit a claim to be reimbursed for the product discount.
Off Invoice Offer: This offer is generated when a partner requests special pricing for products that it plans to purchase and the vendor approver indicates that the partner will receive the discount at the time an order is placed. This offer acts as a pricing modifier for future orders. Vendors can see the Offer Type field during approval if the Ship from Stock check box is not selected. If the vendor approver specifies this type of offer, partners do not have to submit a claim. An authorization code is generated for the partner upon approval, which needs to be used when booking the order to receive the discount. The authorization code is displayed on the approved special pricing request.
Accrual Offer: This offer is generated when a partner requests special pricing for products that it plans to purchase and the vendor approver indicates that the partner will need to submit a claim to receive the discount. This offer acts as a pricing modifier for future orders. Vendors can see this field during approval if the Ship from Stock check box is not selected. If the vendor approver specifies type of offer, partners have to submit a claim to receive the approved discount. An authorization code is generated for the partner upon approval, which needs to be used when booking the order to receive the discount. The authorization code is displayed on the approved special pricing request.
The three offers used with special pricing are seeded in Trade Management as custom setups. It is not recommended that additional offers be created for special pricing.
Each budget has five kinds of the budgeted amounts:
Planned: The planned amount increases when a request is made on that budget.
Committed: The committed amount increases when the budget request is approved.
Utilized: If an Accrual or Off-Invoice offer is generated, the utilized amount increases when an order is booked. If a Scan Data offer is generated, the utilized amount increases when the offer is approved.
Earned: If an Accrual or Off-Invoice offer is generated, the earned amount increases after the order is shipped. If a Scan Data offer is generated, the earned amount increases when the offer is approved.
Paid: For Scan Data and Accrual offers, the paid amount increases after claims are closed. For Off-Invoice offers, the paid amount increases after an invoice is generated for that order.
In this flow, liabilities are earnings that are tracked based on the offer types.
In the Existing Inventory scenario, accruals are created that can be paid upon completion of the sale.
In the New Inventory scenario:
When a request is approved with Accrual offers, utilizations are created after orders are placed and become available for payments after` they are shipped.
When a request is approved with Off-invoice offers, liabilities are not tracked as the discount is taken directly off the invoice.
For more information on liabilities, see the Oracle Trade Management User Guide.
A claim is used for partner reimbursement in two special pricing scenarios:
When a partner is requesting special pricing on existing inventory. When a request of this type is approved, a Scan Data offer is created and an agreement number is generated. The partner uses the code when submitting a claim.
When a partner requests special pricing on new inventory and the vendor approver indicates that the partner will need to submit a claim to receive the discount. With an Accrual request, an Accrual offer is created and an agreement number and an authorization code are generated. The partner uses the authorization code when booking the order and the agreement number when submitting a claim.
When a Scan Data or an Accrual special pricing request is approved, a claim is automatically generated in Trade Management. A default claim (which is called Claims) is available in Trade Management as a custom setup.
The default claim specifies that a number of items will be included in the claim form, including team information, notes, and request history. An organization can also create a custom claim, if required. Creating a custom claim provides the following benefits:
Because all claims that use the default custom setup have the same prefix, identifying the type of partner request a claim is associated with could become difficult. Creating a custom claim allows you to set up a new prefix that can be used to easily identify special pricing claims.
You can set up a different approval routing process for different types of claims. The default claim does not implement a claims approval process.
You can set up a different claim validation process.
Refer to the Oracle Trade Management Implementation Guide for additional information.
Trade Profiles allow defaulting of payment methods, vendor and vendor site mapping for a partner and batch level, line level threshold limits for error margins of special pricing claims submitted through the Indirect Sales Management module. Trade profiles are set up from Oracle Trade Management User > Administration > Trade Management > Customer > Trade Profile.
For more information, see Oracle Trade Management Implementation Guide.
A vendor might want to limit the products or product categories for which partners can request special pricing. By default, all products are enabled for special pricing. Limiting the products eligible for special pricing involves first enabling product security through the OZF_SP_ENABLE_PRODUCT_SECURITY profile option, and then specifying product categories for a partner from the partner's profile tab.
The OZF_SP_ENABLE_PRODUCT_SECURITY profile option is set at either the Site or the Responsibility level, where the responsibility corresponds to a business unit or geographic entity. An organization would set the profile at the Responsibility, for example, if it wanted to enable security for partners for one country but disable it for partners in different country.
If the value is set to No, partners can request special pricing for all products. If the value is set to Yes, partners can request special pricing for products specified in the Special Pricing Product Categories attribute only.
The product categories that can be used for special pricing requests are specified individually for each partner from the Profile tab on Partner Details page. The categories that are listed come from the Product Catalog.
To make the Special Pricing link available in the Quick Links bin, a custom responsibility must be created and this responsibility can include the special pricing function in the menu structure.
Menus tied with the Partner Super User responsibility can be used as a reference to create menus for custom responsibilities. For defining menus that can be used with the Quick Links bin, see the Oracle iStore Implementation Guide.
Use this procedure to create a custom responsibility for accessing a special pricing request, with root menu and menu exclusions.
Navigation
Log into Oracle Forms as the system administrator and navigate to Security > Responsibility > Define.
Prerequisites
None.
Notes
Responsibility Name: Partner Special Pricing
Application: Partner Relationship Management
Responsibility Key: PV_SPECIALPRICE
Description: Responsibility for Special Pricing
Name: Standard
Application: Partner Relationship Management
Menu: Root menu name
Submenu: OZF_SPECIAL_PRICE_OTHER
Special pricing is made available to partners as a benefit of partner program membership. A special pricing benefit is created by the channel administrator as a benefit of the type Other.
A channel manager can assign the Special Pricing benefit to a partner program. Subsequently, the channel administrator maps the program with the Special Pricing responsibility, which provides the partner users access to special pricing pages.
Special pricing requests are subject to an approvals process. When a partner user submits a special pricing request, it is routed to an approver, who is a vendor user. The approver can approve or reject the request. The special pricing approvals process is set up and managed through the Oracle Approvals Management application.
The seeded transaction for special pricing approval is OZF Special Pricing Request. Numerous attributes have been defined for the transaction. A default special pricing approver can be identified using the OZF: Default Special Pricing Request Approver profile option. For more information on setting up approvals for special pricing, refer to Creating Approval Rules in Oracle Approvals Manager.
Two permissions are associated with special pricing. The permissions can be assigned to an existing role, or a new permissions-based role can be created and assigned to selected special pricing users.
OZF_SPECIAL_PRICE_SUPERUSER: Vendor users with this permission can view, update, approve and have DQM access to all requests. Partner users with this permission can view and update all requests made by their organization.
OZF_SPECIAL_PRICE_DQM: Vendor users with this permission can match a party record to a master TCA record or create a new party record. Anyone with this permission can see the DQM flag in the Personalize screen and select records where DQM has not been run and then select an existing record or create a new record.
Notification messages are sent to vendor and partner users in response to a number of special pricing request status changes. Notification messages for special pricing are created using the Oracle Workflow Builder application. An organization can implement the notifications that have been seeded for special pricing without modification. However, if you need to make changes to the seeded notifications, such as changing the message text, adding URLs to messages, or even creating additional notifications, you will need access to Oracle Workflow Builder and the Oracle database.
In Oracle Workflow Builder, the item type for special pricing notifications is OZFSPBEN. The following table lists the notifications seeded for special pricing, and lists the types of users that are eligible for each notification and the special pricing request status that is applicable for the notification.
| Notification Name | User | SP Request Status |
|---|---|---|
| Request Created - Channel Manager Notification | Channel Manager | Draft |
| Request Submitted - Partner Notification | Partner Contact, Special Pricing Super User | Pending Approval |
| Request Submitted - Vendor Notification | Vendor Channel Manager, Vendor Approvers, Special Pricing Super User | Pending Approval |
| Request Approved - Partner Notification | Partner Contact, Special Pricing Super User | Approved |
| Request Returned - Partner Notification | Partner Contact, Special Pricing Super User | -- |
| Request Cancelled - Partner Notification | Partner Contact, Special Pricing Super User | -- |
| Request Declined - Partner Notification | Partner Contact, Special Pricing Super User | Declined |
The following table lists special pricing statuses and the corresponding special pricing code.
| Status | Code |
|---|---|
| Draft | DRAFT |
| Pending Approval | SUBMITTED_FOR_APPROVAL |
| Approved | APPROVED |
| Declined | DECLINED |
| Closed | CLOSED |
The notification messages listed in the Seeded Notifications for Special Pricing are available for use with special pricing requests, but are not enabled by default. The channel administrator is responsible for selecting which of the seeded, as well as any additional custom notifications created by the vendor, will be used by the vendor.
Navigation
Log in as the Channel Administrator and select Special Pricing Notifications. Then, click Add Another Row.
Prerequisites
None
Notes
Any combination of special pricing request status, user type, and notification message can be created. Use the Seeded Notifications for Special Pricing table as a guide to make sure that you have associated notifications, users, and special pricing statuses appropriately.
DQM is a tool from the Oracle Trading Community Architecture (TCA) group that is used to check for potential duplicate customers or contacts for a given customer or contact.
When a special pricing 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 partner record, and the system links the selected record with the special pricing request. If the system finds an exact match with one and only one party, then the system automatically links the selected record with the special pricing request. If a duplicate record does not exist, the approver creates a new end customer or partner record.
Users with the permission OZF_SPECIAL_PRICE_DQM and OZF_SPECIAL_PRICE_SUPERUSER can identify DQM approvers. Any user with this permission and with access to the special pricing function can look up requests that need party matching from the entire request list by filtering requests. In the Create View page, add the Customer Data Merged column in the search query to filter data and view requests for which DQM is required to be run.
For more information on setting up matching with DQM, refer to Setting up Matching Rules with Oracle Data Quality Management.
Notes can be created for a special pricing request. By default, all note types that are not specifically associated with another business object are available for with special pricing notes. A vendor can create a note type for special pricing to limit the note types choices that are available for a special pricing request.
For more information about setting up notes and note types, refer to Setting up Notes.
The transaction type for special pricing is seeded and the value is OZF: Special Pricing Request.
The following mandatory attributes are seeded.
ALLOW_DELETING_RULE_GENERATED_APPROVERS
ALLOW_REQUESTOR_APPROVAL
AT_LEAST_ONE_RULE_MUST_APPLY
EVALUATE_PRIORITIES_PER_LINE_ITEM
Special Pricing Management has header and line level attributes.
The following table describes the header attributes.
| Attribute | Description | Requiring Approval Types |
|---|---|---|
| ALLOW_EMPTY_APPROVAL_GROUPS | Whether to allow approval groups not to have members. | approval-group chain of authority, post-chain-of-authority approvals, pre-chain-of-authority approvals |
| CURRENCY_CODE | Currency Code | None |
| END_CUSTOMER_COUNTRY | End Customer Country | None |
| END_CUSTOMER_NAME | End Customer Name | None |
| IS_VAD | To find whether the partner is a distributor | None |
| MEMBERSHIP_TYPE | Partner Membership Type | None |
| PARTNER_COUNTRY | Partner Country | None |
| PARTNER_INDUSTRY | Partner Industry | None |
| PARTNER_LEVEL | Partner Level | None |
| PARTNER_NAME | Partner Name | None |
| PARTNER_TYPE | Partner type | None |
| REQUESTED_AMOUNT | Total Discount Amount | None |
| REQUEST_TYPE_CODE | Discount Type | None |
| SHIP_FROM_STOCK | Ship From Stock | None |
The following table describes the line level attributes.
| Attribute | Description | Requiring Approval Types |
|---|---|---|
| DISCOUNT_AMOUNT | Requested Discount Amount | None |
| DISCOUNT_TYPE | Discount Type | None |
| PRODUCT | Product | None |
| REQUESTED_QUANTITY | Requested Quantity | None |
| REQUESTED_UOM | Requested UOM | None |
Interactions are logged whenever the status changes for a special pricing request.
The following table provides information on seeded interaction messages that would be logged for the corresponding status changes.
| Message Name | Status Logged |
|---|---|
| OZF_SP_PENDING_LOG | Pending Approval |
| OZF_SP_REJECTED_LOG | Declined |
| OZF_SP_APPROVED_LOG | Approved |
| OZF_SP_CLOSED_LOG | Closed |
| OZF_SP_DRAFT_LOG | Draft |
There are certain system profile options that must be set for special pricing to function properly. In addition to the profile options mentioned in this chapter, there are additional profile options that may need to be set. Refer to Appendix A, System Profile Options, for a complete list of profile options for special pricing.
There are some Lookups that can be modified for special pricing. Refer to Appendix B, Lookups, for more information.
There are several concurrent programs that need to be run periodically for special pricing. Refer to Appendix C, Concurrent Programs, for information about setting up and running the programs.