This chapter covers the following topics:
Referral Management enables partners to refer leads and opportunities to the vendor that the partners cannot fulfill directly. For example, if a customer is interested in one of the vendor's products that the partner does not sell, the partner can submit a referral to the vendor and receive a percentage of the revenue.
When a partner user submits a referral, it is routed to the appropriate vendor approver(s). Approvers are notified of the referral and they review it and approve, reassign or decline it. The vendor also performs customer and contact duplicate checking using Oracle Data Quality Management to determine if the same lead or opportunity already exists in the system. If the referral is unique and meets other vendor qualifications, it is approved, and a lead or opportunity is generated. The new lead or opportunity contains a link to the original referral information.
After an order is generated, and the product is shipped to the customer, a claim is generated in the system. After the claim is approved internally, the partner receives notification to review and accept compensation. After a partner user accepts the compensation, the vendor pays the commission.
Referrals are integrated with Oracle Sales and Oracle Leads Management, which allow opportunity routing and lead qualification processes to occur successfully for referrals.
Vendor and partner users can access a summary list of referrals to which they have access. They can build personal views to quickly find referrals that they are most interested in.
The following are the partner subscriptions used for Referrals in this release of Oracle Partner Management: The same format is used for subscriptions as is shown in the section of this document called How Event Updates Work. The specific details of four fields changes for each subscription. Those fields are shown below:
Claim Paid
Event Filter: oracle.apps.ozf.claim.paymentPaid
Rule Function: pv_benft_status_change.CLAIM_REF_STATUS_CHANGE_SUB
Phase: Immediate
Description: Update referral status to "Closed. Fee Paid."
Claim Referral Approval
Event Filter: oracle.apps.ozf.claim.referralApproval
Rule Function: pv_benft_status_change.CLAIM_REF_STATUS_CHANGE_SUB
Phase: Immediate
Description: Update referral status to "Awaiting For Partner Acceptance" which in turn triggers the partner approval process.
Claim Update Status
Event Filter: oracle.apps.ozf.claim.updateStatus
Rule Function: pv_benft_status_change.CLAIM_REF_STATUS_CHANGE_SUB
Phase: Immediate
Description: Update referral status to "Compensation Cancelled."
Referral Status Change
Event Filter: oracle.apps.pv.benefit.referral.statusChange
Rule Function: pv_benft_status_change.status_change_sub
Phase: Deferred
Description: Triggers e-mail notification upon referral status change
A budget is a pool of money that vendors can use to execute trade promotion activities such as offers and campaigns. Because partners receive compensation for referrals, one or more budgets must be specified to fund referral compensation. Referral budgets are fixed budgets and have to be active in to be selected in the referral benefit. Accruals are created for each order line that matches between customer orders and referred products submitted.
An organization can create budgets specifically for referrals, or fund referrals from an existing budget. Use the following procedure to create a fixed budget for referral compensation.
Navigation
Log into Oracle Trade Management as the Oracle Trade Management User and navigate to Budget > Create, and then click Create to display the Create Budget page.
Prerequisites
A set of books must be defined.
Notes
Setup Type: Select Fixed Budget.
Number: If you leave the budget number field blank, a unique number is generated automatically for the budget.
Business Unit: Business units are organizations that are set up in Oracle Human Resources with Type - Business Unit. Business units are used mainly for classification purposes. Business units can also affect approval rules.
Category: Select the appropriate category for the referral budget. An approval rule for a budget can use category as one of its criteria.
Holdback Amount: The amount of funds to be reserved and not allocated to lower levels. A budget administrator can choose to reserve or release the holdback amount at any time by manually reducing the original holdback amount.
Owner: By default, the owner is the user creating the budget. A different owner can be specified.
Start Date and End Date: These dates are mapped in the Oracle General Ledger calendar, and limit the start and end dates of budgets.
The seeded custom setup Net Accrual Offer is used with partner referrals. When a partner's referral request is created and activated, a net accrual offer based on this custom setup is created automatically in Oracle Trade Management. The offer is used to track funds committed for the referral request.
By default, the Budget Approval process has been disabled for the New Accrual offer. Depending on business requirements, budget approval can be enabled for the offer, and then the vendor can set up an approval process for partner referral budgets.
It is not recommended that you create additional offers for partner referrals.
A default claim (which is called Claims) is available in Trade Management as a custom setup. This default claim is used for all flows that require a party (for example, a partner) to submit a claim to be reimbursed for a marketing activity or other situation.
When a referral request is approved, a Net Accrual offer is created. The offer creates an authorization code. When a partner user submits a claim for reimbursement for closed business resulting from her referral, she must include the authorization code on the claim to link the claim with the offer and the approved funding request. Claims are processed through Oracle Accounts Payable or Oracle Accounts Receivable.
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 customized claim, if required. Creating a custom claim provides the following benefits:
Easily identify partner referral claims. Since 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 customer claim allows you to set up a unique prefix for that customer.
Set up a different approval routing process for different types of claims. The default claim does not implement a claims approval process.
Set up a different claim validation process.
Refer to the Oracle Trade Management Implementation Guide for additional information on creating custom claims.
When a referral benefit is created, the channel administrator can create questions that a partner user must answer when submitting a referral request. The questions are associated with partner profile attributes, and the answers that the partner user provides for the questions are used to populate the profile attributes for the partner. In addition, some of the partner profile attributes can be mapped to the opportunity or lead generated as a result of a referral.
The following table lists the seeded partner profile attributes that are enabled for use with referral benefits. The channel administrator can also create custom attributes that can be used with referrals. To enable a custom attribute for referrals, the Lead Referral box must be checked for the attribute. For more information on working with partner profile attributes, refer to Chapter 7, Setting Up Partner Profile Attributes.
| Partner Profile Attribute | Map to Opportunity | Map to Lead |
|---|---|---|
| Industry | - | - |
| Source (Campaign) | X | X |
| DUNNS | - | - |
| Lead Description | - | - |
| Number of users | - | - |
| Opportunity Description | - | - |
| Opportunity Size | - | - |
| SIC | - | - |
| Total employees | - | - |
| Information Verified | - | - |
| Customer Annual Revenue | - | - |
| Time Frame (Purchase Timeframe) | - | X |
| Budget Status | - | X |
| Total Budget | X | X |
| Response Channel | X | X |
| Sales Stage | X | - |
| Close Date | X | - |
| Offer | X | X |
When the channel administrator creates a referral benefit, she specifies one or more product categories for the benefit. The product categories determine for which products a vendor can refer a lead or opportunity.
The product categories that a channel administrator can choose from are presented in a hierarchy that is relevant for the referral. This information is used as the basis for approving a referral, identifying orders that directly result from a referral, and computing the compensation amount due to the partner.
Product categories are set up in the Oracle Advanced Pricing application, and are common across all of an organization's product lines. For information on defining product categories, see Oracle Advanced Product Catalog User Guide.
Partner lead and opportunity referral requests are subject to an approval process. When a partner user submits a referral request, it is routed to one or more approvers, who are vendor users. The approvers can approve, reassign, or reject the request. The partner referrals approvals process is set up and managed through the Oracle Approvals Management application.
The vendor can configure approval workflow to route incoming referrals to multiple approvers simultaneously. This is called parallel approval. The approver group can approve the referral in first come, first serve mode, in consensus, or in serial order, depending on the way it is set up in the Approval Management System. In most companies, more than one person is empowered to approve or decline referrals. Thus, parallel routing enables vendors to better model their company's internal business processes. For instance, a company may have the first level be a specific person, such as the partner's channel manager, and the second level be a group of people, such as multiple directors. Parallel routing also prevents a transaction from being stuck in the approval queue when an approver is busy or on vacation. The group of approvers can be assigned at any approval level.
In addition to validating the information submitted by a partner user, referral approvers must perform checks for duplicate referrals, duplicate customers, and duplicate customer contacts. If a duplicate referral is identified, the referral request is rejected. If a duplicate customer or customer contact is identified, the approver links the referral with the existing customer information. He must also make sure that the referral is not for a lead or opportunity that already exists.
The seeded transaction for partner referral requests is PV: Referral Management Approvals. Numerous attributes have been defined for this transaction. A default referral request approver can be identified using the PV: Default Referral Approver profile option. For more information on setting up approvals for lead and opportunity referrals, refer to Creating Approval Rules in Oracle Approvals Manager.
Users who are granted access to all leads and opportunities within the sales application can access all referrals that generated a lead or an opportunity. In addition, there are two permissions that are associated with partner referral requests:
Super User Permission - [PV_REFERRAL_SUPERUSER] - Allows a vendor user to view and update all referrals and allows a partner user to view and update all referrals owned by their organization.
Compensation Approver - [PV_REF_COMP_APPROVER] - This permission enables partners to view and accept compensation for referrals.
Notification messages are sent to vendor and partner users in response to a number of partner referral request status changes. Notification messages for partner referral requests are created using the Oracle Workflow Builder application. An organization might be able to implement the notifications that have been seeded for referrals 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.
This business event is raised whenever there is a change in the status of the Referral benefit:
oracle.apps.pv.benefit.referral.statusChange
In Oracle Workflow Builder, the item type for referral notifications is PVREFFRL. The following table lists the notifications seeded for referrals and lists the types of users that are eligible for each notification and the referral request status that is applicable for the notification.
| Notification Name | User | Referral Request Status |
|---|---|---|
| Referral Accepted - Partner Notification | Partner Contact, Referral Superuser (Partner) | Approved |
| Referral Approved - Requires Customer Deduplication Vendor Notification | DQM Approver, Vendor Channel Managers, Referral Superuser (Vendor) | Pending Customer Review |
| Acceptance Letter/Referral Commission - Partner Notification | Referral Superuser (Partner), Partner Contact (Partner contact must have the Accept Compensation permission) | Awaiting Partner Acceptance |
| Referral Declined - Partner Notification | Partner Contact, Referral Superuser (Partner) | Declined |
| Referral Returned Vendor Notification | Vendor Approvers, Vendor Channel Managers, Referral Superuser (Vendor) | Returned |
| Referral Returned Partner Notification | Partner Contact, Referral Superuser (Partner) | Returned |
| Referral Created - Partner Notification | Partner Contact, Referral Superuser (Partner) | Pending Approval |
| Referral Created - Vendor Notification | Vendor Approvers, Vendor Channel Managers, Referral Superuser (Vendor) | Pending Approval |
A territory hierarchy must be set up for lead and opportunity referral requests. For referrals, a territory hierarchy allows the vendor organization to offer different referral benefits based on customer country. For example, the vendor might want to allow referrals on different products in Canada than in the United States, or source referral compensation from different budgets. The territories must be set up at the country level.
The territory hierarchy is set up through the Oracle Territory Management application. As part of implementation, the vendor must set up a territory with the Partner Management usage to create and populate channel teams. The territory that is set up for referrals is a different territory, and is created with the Trade Management usage. If a vendor organization has already implemented Oracle Trade Management, setting up another Trade Management territory is not required. For more information on creating a territory hierarchy, refer to Setting up Territories in Oracle Territory Manager.
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 lead or opportunity referral is created, the referral request approver must compare the customer or reseller name entered with existing records in TCA. If there are no matches for the customer or the customer contact, a new customer and/or contact are created. If there are matches for the customer, the approver can review and decide to create a new organization or use an existing organization. If the approver creates a new organization, she also creates a new contact.
The customer fields used for detecting duplicates are:
Customer Name
Customer Address 1-4
City
Country
State
Province
Zip/Postal Code
Customer Name Pronunciation
The contact fields used for detecting duplicates are:
First Name
Last Name
E-mail Address
Phone Type
Phone Number
The approver also uses DQM to identify whether or not the lead or opportunity being referred already exists in the system. If it matches an existing lead or opportunity, the referral request might be declined.
As part of implementation, the channel administrator may need to set up matching rules in DQM. The channel administrator can build rules on:
For more information on using DQM and creating rules, refer to Setting up Matching Rules with Oracle Data Quality Management.
Note that, for successful partner contact deduplication for referrals, a matching rule containing the "contact name" attribute must be created. If seeded matching rules are being used, the channel administrator may use the SAMPLE_SEARCH rule to enable partner contact deduplication, as it contains the "contact name" attribute.
Notes can be created for a referral request. By default, all note types that are not specifically associated with another business object are available for referrals. A vendor can create a note type for referral requests to limit the note type choices that a user sees when creating a note for a referral.
For more information about setting up notes and note types, refer to Setting up Notes.
The channel administrator is responsible for creating referral benefits, which channel managers can add to partner programs.
There are three basic types of referral benefits, and they are based on the type of sales transactions that result from the approval of the referral:
Opportunity: When the referral is approved, an opportunity is created and linked to the referral.
Opportunity assigned to partner: When the referral is approved, an opportunity is created and is subsequently routed to the partner that originally submitted the referral. The referral is linked to the opportunity.
Lead: When the referral is approved, a lead is created and linked to the referral. The lead can subsequently be qualified, and the resulting opportunity routed to the correct channel.
Use this procedure to set up a referral as a benefit.
Navigation
Log in as the channel administrator and navigate to Programs > Benefits, select Referral from the Create Benefit drop-down list, and click Go.
Prerequisites
For a benefit to become active, the following items must exist:
At least one budget has been set up for referral compensation.
The Net Accrual Offer is present.
At least one product category has been set up.
At least one territory has been defined with the Trade Management usage.
Notes
Sales Transaction: Select Opportunity, Opportunity assigned to Partner, or Lead from the list depending on desired outcome of the referral benefit.
Budgets region: Select one or more budgets that will provide funds to compensate partners for referrals.
Budget Name: Select the name of the budget to be used from the drop-down list. The list displays fixed budgets that are active and that the channel administrator has access to. A user has access to a budget if he is the budget owner or is on the access list for the budget.
Requested Budget Amount: The requested budget amount is the amount of money that should be used to fund referrals created from the benefit. The amount entered here is marked as Committed funds in the budget.
If the profile option OZF: Allow committed budget to exceed total amount is set to No, the requested budget amount cannot exceed the amount in the budget. If the profile option is set to Yes, the benefit pass validation in spite of the difference in funds.
Request Status: This is populated by the system. When the budget passes the validation process, the status is Approved.
Additional Details region: In this section you create questions that will be used by approvers to evaluate the referral. The partner responds to these questions on the referral create page. These responses are stored as additional information about the referral. Some of them are used to populate fields on the lead or opportunity that is generated upon referral approval. For each question that you add, specify the following:
Label: This is the label displayed in the referral details under the additional details section when the partner is creating a referral.
Profile Attribute: Select a profile attribute. The profile attributes list displays seeded attributes that have been seeded for lead or opportunity referrals and custom attributes that are defined to be valid for referrals.
Order: The order in which the questions will appear on the referral request.
Mandatory: Select to make a question mandatory.
Products region: The referrals requests created from this benefit are restricted to the product categories specified here. Select the product category and then provide the following information for each category included in the benefit:
Compensation Percentage: Specifies the referral compensation to be paid to the partners based on a percentage of the net sales amount.
Maximum: Sets a cap on the referral compensation on a product-by-product basis. For a specific product, the referral compensation for the referral cannot exceed this amount regardless of the compensation percentage specified.
Territories region: In the territories region, you select one or more territories for the benefit from the drop-down list of territories that have been set up for referrals. The customer associated with the referred lead or opportunity must be located in one of the geographic regions specified for the benefit. Territories must be specified for the benefit. Select the territory and then provide the following information:
Threshold: The threshold is the minimum amount that is allowed for a referral request.
The threshold is the total unit price for all the products listed on the request. For example, a referral for the sale of five laptop computers at a unit price of $1000 each and 10 desktop computers at unit price of $500 each has a threshold amount of $1500, or the total unit price of all the products included in the request.
Currency: Select the currency used for the territory.
Action: Select the error or warning that is used when a referral request does not meet the threshold amount:
Display Error: An error is displayed, and the request cannot be submitted.
Warning to Approver: The referral request can be submitted for approval, but the approver sees a warning about the threshold.
Warning to Partner and Approver: The referral request can be submitted for approval, but both the approver and the partner submitting the request see a warning.
Expiration (Days): Optionally, you can specify the number of days that the territory qualifications are in effect.
Notifications region: Select the notifications that will be set to partner and vendor users in response to status changes on referral requests generated from this benefit. For each referral status that for which you want to provide a notification, specify the following:
Status: Referral status change that requires notification.
User Role: Group of users that needs to be notified for the corresponding status change.
Notification Name: The workflow notification message that the user will receive.
Apply: Click to save the benefit.
Activate: Click to run the benefit validation process.
During the creation process, a benefit goes through a number of benefit statuses: Active, Inactive, Draft, Failed Validation. When the process completes, the status is updated to Active or to Failed Validation.
When a benefit is created, it can be saved in the draft status by clicking Apply. At this point, no validation is done on the budget. When the channel administrator clicks Activate, a Net Accrual Offer is created in the background and budget validation is performed on the offer. Budget validation involves ensuring that the products and territories information specified in the benefit setup screen correspond and fall under their counterparts specified in the budget. Budget validation also ensures that each of the budget requests has a valid amount. If any one of the above items failed the validation, the benefit status becomes Failed Validation. Otherwise, it becomes Active. When the benefit status becomes Failed Validation, it can still be re-activated by correcting the failed item(s) and reapplying the changes. This process can be repeated until the benefit becomes active.
Once a benefit becomes active, the following conditions hold:
Budget lines cannot be removed, but new lines can still be added.
Products and territories can neither be removed nor added.
New Additional Detail lines cannot be added.
Notification lines can be added or removed.
When a referral request is approved, an unqualified lead, an unmatched opportunity, or an opportunity for a specific partner is created. The system automatically specifies a sales channel for each lead or opportunity created from a referral request.
When a lead is created, the system assigns the Direct channel to the lead. The lead is then routed to the lead engine, which subsequently qualifies the lead and then assigns a channel to the resulting opportunity.
When an unmatched opportunity is created, the channel is determined by the profile option OS: Default Sales Channel. This profile option is part of the Oracle Sales application. For additional information on this profile option, refer to the Oracle Sales Implementation Guide
When a referral generates an opportunity for a specific partner, the system assigns an indirect sales channel to the opportunity. The profile option PV: Default Indirect Channel Type determines the name of the indirect channel that will be used by default for all opportunities that are routed to partners as a result of a referral.
There are certain system profile options that must be set for partner referral requests 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 referral requests.
There are some Lookups that can be modified for referral requests. Refer to Appendix B, Lookups, for more information.
There are several concurrent programs that need to be run periodically for referral requests. Refer to Appendix C, Concurrent Programs, for information about setting up and running the programs.