This chapter covers the following topics:
When partners resell your products, there is often a conflict between your direct sales force and your partner network. Deal Registration enables partners to submit opportunities and receive your commitment not to compete with them directly and to support them on the deal. You increase partner loyalty and gain visibility into partner activity.
When partners register a deal, it is routed to the appropriate approver(s). Approvers are notified of the deal registration and they review it and approve, reassign, or decline it. When the deal registration is approved, a new opportunity is created in the system and assigned to the partners' organization for fulfillment.
Vendors and partners receive notifications about deal registration activity and can navigate directly from the notification into the associated deal registration. Notifications are configured by the vendor and sent when the status changes, for example, when a deal registration is approved.
The following are the partner subscriptions used for Deal Registration 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:
Deal Status Change
Event Filter: oracle.apps.pv.benefit.deal.statusChange
Rule Function: pv_benft_status_change.status_change_sub
Phase: Deferred
Description: Triggers e-mail notification upon deal registration status change
When a deal registration benefit is created, the channel administrator can create questions that a partner user must answer when submitting a registration request. The questions are associated with partner profile attributes, and the answer 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 generated as a result of a registration.
The following table lists the seeded partner profile attributes that are enabled for use with deal registration benefits. The channel administrator can also create custom attributes that can be used with registrations. To enable a custom attribute for registrations, the Deal Registration checkbox must be selected for the attribute.
| Question | Map to Opportunity |
|---|---|
| Industry | - |
| Source (Campaign) | X |
| Number of users | - |
| Opportunity Description | - |
| Opportunity Size | - |
| SIC | - |
| Total employees | - |
| Information Verified | - |
| Customer Annual Revenue | - |
| DUNNS | - |
| Total Budget | X |
| Response Channel | X |
| Sales Stage | X |
| Close Date | X |
| Offer | X |
When the channel administrator creates a deal registration benefit, she specifies one or more product categories for the benefit. Partners can then register opportunities that include these products.
The product categories that a channel administrator can choose from are presented in a hierarchy that is relevant for deal registration. This information is used as the basis for approving a deal registration request.
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 deal registration requests are subject to an approval process. When a partner user submits a registration, it is routed to an approver, who is a vendor user. The approver can approve, reassign, or reject the request. The partner deal registration approvals process is set up and managed through the Oracle Approvals Management application.
The vendor can configure approval workflow to route incoming deal registration requests 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 deals. 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, deal registration request approvers must perform checks for duplicate opportunities, duplicate customers, and duplicate customer contacts. If the opportunity that the partner is trying to register is already in the system, the registration request might be rejected. If a duplicate customer or customer contact is identified, the approver links the information on the registration request with the existing customer information.
The seeded transaction for registration requests is PV: Deal Registration Management. Numerous attributes have been defined for this transaction. A default registration request approver can be identified using the PV: Default Deal Registration Approver profile option. For more information on setting up approvals for deal registrations, refer to Creating Approval Rules in Oracle Approvals Manager.
Notification messages are sent to vendor and partner users in response to a number of deal registration request status changes. Notification messages for deal registration requests are created using the Oracle Workflow Builder application. An organization might be able to implement the notifications that have been seeded 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 deal registration notifications is PVDEALRN. The following table lists the notifications seeded for deal registrations and lists the types of users that are eligible for each notification and the registration request status that is applicable for the notification.
| Notification Name | User | Deal Registration Request Status |
|---|---|---|
| Deal Registration Accepted - Partner Notification | Partner Contact, Referral Superuser (Partner) | Approved |
| Deal Approved - Requires Customer Deduplication - Vendor Notification | DQM Approver, Vendor Channel Managers, Referral Superuser | Pending Customer Review |
| Deal Registration Declined - Partner Notification | Partner Contact, Referral Superuser (Partner) | Declined |
| Deal Registration Returned - Vendor Notification | Vendor Approvers, Vendor Channel Managers, Referral Superuser (Vendor) | Returned |
| Deal Registration Returned - Partner Notification | Partner Contact, Referral Superuser (Partner) | Returned |
| Deal Registration Created - Partner Notification | Partner Contact, Referral Superuser (Partner) | Pending Approval |
| Deal Registration Created - Vendor Notification | Vendor Approvers, Vendor Channel Managers, Referral Superuser (Vendor) | Pending Approval |
The business event oracle.apps.pv.benefit.deal.statusChange is raised whenever there is a change in the status of the Deal Registration benefit. The following table lists deal registration statuses and the corresponding code.
| Deal Registration Status | Deal Code |
|---|---|
| Closed. Dead Lead | CLOSED_DEAD_LEAD |
| Closed. Lost Opportunity | CLOSED_LOST_OPPTY |
| Expired | EXPIRED |
| Draft | DRAFT |
| Closed by Vendor | MANUAL_CLOSE |
| Pending Approval | SUBMITTED_FOR_APPROVAL |
| Extended by Vendor | MANUAL_EXTEND |
| Pending Customer Review | APPRVD_PENDNG_CSTMR_DQM |
| Declined | DECLINED |
| Approved | APPROVED |
A territory hierarchy can be set up for deal registrations. For deal registrations, a territory hierarchy allows the vendor organization to offer different registration benefits based on customer country. For example, the vendor might want to allow registrations on different products in Canada than in the United States. The territory must be set up at the country level.
A territory hierarchy is optional for deal registrations. If no territory is defined, deal registration is enabled for all countries. However, when a territory is used for deal registrations, only countries in that territory are available.
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 deal registration 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 registration request is submitted for approval, the deal registration 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
Email Address
Phone Type
Phone Number
The approver also uses DQM to identify whether or not the opportunity being registered already exists in the system. If it matches an existing opportunity, the registration request might be declined.
As part of implementation, the channel administrator may need to set up matching rules in DQM. For more information on using DQM and creating rules, refer to Setting up Matching Rules with Oracle Data Quality Management.
Notes can be created for a deal registration request. By default, all note types that are not specifically associated with another business object are available for deal registrations. A vendor can create a note type for deal registration requests to limit the note type choices that a user sees when creating a note for a registration.
For more information about setting up notes and note types, refer to Setting up Notes.
The channel administrator is responsible for creating deal registration benefits, which channel managers can add to partner programs.
Use this procedure to create a deal registration benefit.
Navigation
Log in as the channel administrator and navigate to Programs > Benefits, select Deal Registration 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 product category has been set up.
Notes
Additional Details region: In this section you create questions that will be used by approvers to evaluate the deal registration request. The partner will respond to these questions on the deal registration create page. These responses are stored as additional information about the deal registration. Some of these responses are used to populate fields on an opportunity that is generated upon registration approval. For each question that you add, specify the following:
Label: This is the label displayed in the registration details under the additional details section when the partner is creating a registration request.
Profile Attribute: Select a profile attribute. The profile attributes list displays seeded attributes that have been seeded for deal registrations and custom attributes that are defined to be valid for deal registration.
Order: The order in which the questions will appear on the deal registration request.
Mandatory: Select to make a question mandatory.
Products region: The deal registration requests created from this benefit are restricted to the product categories specified here.
Territories region: In the territories region, you select one or more territories for the benefit from the drop-down list of territories. The customer associated with the registered opportunity must be located in one of the geographic regions specified for the benefit. Territories are optional for deal registration.
Select the territory and then provide the following information:
Threshold: The threshold is the minimum amount that is allowed for a deal registration request.
The threshold is the total unit price for all the products listed on the request. For example, an opportunity 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 opportunity.
Currency: Select the currency used for the territory.
Action: Select the error or warning that is used when a registration request does not meet the threshold amount:
Display Error: An error is displayed, and the request can not be submitted.
Warning to Approver: The registration request can be submitted for approval, but the approver sees a warning about the threshold.
Warning to Partner and Approver: The registration request can be submitted for approval, but both the approver and the partner submitting the request see a warning
Notifications region: Select the notifications that will be set to partner and vendor users in response to status changes on registration requests generated from this benefit. For each deal registration request status for which you want to provide a notification, specify the following:
Status: Deal registration request status.
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 three benefit statuses: Draft, Inactive, and Active. When a benefit is created, it can be saved in the draft status by clicking Apply. If any of the Header fields are not filled in, the user is not allowed to save. After it is saved, the deal benefit goes to Draft status, and then the user can manually set it to Active. If the benefit passes validation, its status changes to Active.
Once a benefit becomes active, the following conditions hold:
Products and territories can be neither removed nor added.
New additional detail lines cannot be added.
Notification lines can be added or removed.
When a deal registration request is approved, an opportunity is created and routed to the partner that registered the deal. When the system creates the opportunity, it assigns it to an indirect sales channel. The profile option PV: Default Indirect Channel Type determines the indirect channel that will be used by default for all opportunities that created from deal registrations.
Users who are granted access to all opportunities within the sales application can access all registration requests that generated an opportunity. In addition, the Super User Permission (PV_DEAL_SUPERUSER) allows a vendor user to view and update all deal registrations and allows a partner user to view and update all deal registrations owned by his organization.
There are certain system profile options that must be set for deal registration 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 deal registration requests.
There are some Lookups that can be modified for deal registration requests. Refer to Appendix B, Lookups, for information about Lookups related to deal registration requests.
There are several concurrent programs that need to be run periodically for deal registration requests. Refer to Appendix C, Concurrent Programs, for information about setting up and running the programs.