This chapter covers the following topics:
Oracle Partner Management enables a partner to be part of a vendor's indirect sales force by enrolling into programs designed by the vendor. Programs provide a basis for vendors to effectively segment and manage partner interactions. Vendors can group programs to target certain partner segments.
After an organization has registered with the vendor as a partner, programs that the partner is eligible for appear in the Enroll Programs bin on the Partner Dashboard. A partner user can enroll her organization into a program listed in the bin. The enrollment request is then routed to an approver, who is a vendor user. If the partner's enrollment is approved, the partner receives the benefits associated with program membership, for example, the ability to submit special pricing requests or to request funding for marketing activities. Partner who are distributors can in turn invite their partners to join partner programs.
When a partner user initiates the program enrollment process, she is prompted through a series of enrollment-related web pages. Depending on the partner program, the enrollment process can involve some or all of the following:
A program overview page, which describes the program benefits and requirements and other information provided by the program creator.
An enrollment questionnaire, which presents a series of questions that the partner must answer.
A terms and conditions page, which the partner must agree to.
A request to the partner for billing and payment information if a fee is associated with program membership.
All the program enrollment-related items listed above were set up by program managers as part of the partner program creation process. For more information on creating partner programs, refer to Chapter 8, Setting Up Partner Programs. There are additional set ups that the channel administrator or another vendor employee must complete to enable program enrollment; these are presented in this chapter.
After the partner dashboard is set up, be sure that program bins are mapped to one of the locations on the Partner Dashboard. Partner Dashboard sites are created in iStore by a user with the iStore Administrator responsibility.
Log in to iStore as the administrator to create sections. The catalog hierarchy page provides a visual representation of the sites an organization has created. The Root section is the parent for all other sections. The root is never accessed by users, and does not contain content. Under Root, an area has been seeded for Partner Management: Partner Sites Hierarchy. This is known as the Partner Management site root, and you add subsections underneath this section to create the Partner Dashboard. The subsections that appear directly below the site root appear on the Partner Dashboard as tabs, which correspond to pages.
When you provide information about the section, select Featured section if you want the section to contain information but not products. Select Published to make the tab visible on the site. When a section’s status is Unpublished, the section appears on the Preview UI for the site administrator, but it does not appear on the public UI viewed by partners.
The structure and appearance of your site pages is determined by the layout and templates you choose for the sections. There are two template types that you use--the Layout template and the Display template. The Layout template determines whether all sections included in your site have the same bin locations (a Fixed Layout) or whether each section can have separate bin locations (a Configurable Layout). It also provides templates for all but the center section. The Display template determines the appearance of the center section.
Two types of layout templates are available: The Configurable Layout allows you to configure bins by section, meaning that each section can have a mapped bin (or bins) in a different location. For example, on the Partner Dashboard demo page, you can use a Configurable layout if you want different bins to appear on the Home page than appear on the Support or Products pages. The Fixed Layout insures that bin location will be the same for the site. In addition, when you select Fixed Layout, you must map the bin JSPs to templates. Refer to the iStore Implementation Guide for further information.
When you select a configurable layout, the right and left sides of the page are used to display bins. The center of the page is available for additional content. The appearance of the center part of the page is determined by the Display Template used. (Display templates are also sometimes referred to as Section Templates.) Subsequently, all sections that use the same Display Template will have the same center section rendering, but can have different bins surrounding the center.
The display template that you use for a section is determined by whether you intend the section to be Navigational or Featured: Navigational sections can contain either products or subsections, but not both. Featured sections can contain products only. For a section using a Configurable layout, the following types of Display Templates are used by Partner Management:
Component for Sections Containing Navigational Subsections Only
Component for Sections Containing Products Only
Each type of display template has a group of actual templates associated with it. The UI provides an illustration that gives an approximation of how the page will look with the template selected. You can also create a custom template and select it. Each template is actually a JSP; creating a custom template involves creating a new JSP. For further descriptions of each template, including the JSP file name and programmatic access name, refer to the iStore Implementation and Administration Guide.
A number of bins have been seeded for Partner Management:
Quick Links
Available, Upgrade, and Renewal Programs
My Opportunities
Manage My Partners
Welcome
Marketing Posting
Partner Group
Store Group
Bins hold specific information, in the form of JSP files. On a page, bins appear in a specific formation (left, right, top, and bottom). The bins provided for Partner Management are mapped to JSP files automatically. You can also change a seeded JSP mapping for a bin, if required. For more details on working with bins, refer to the Oracle iStore Implementation and Administration Guide.
You can enable a Quick Links bin on the Partner dashboard to provide partners with links to Oracle Partner Management features, such as deals, referrals, and opportunities. Out-of-the-box, this bin is mapped to a JSP, but you must create a menu linked to a responsibility to allow users with the responsibility to see the bin. The bin’s programmatic access name is: STORE_QUICK_LINKS_BIN_IBEWC. Its JSP is: ibeCAcdQuickLinkBin.jsp.
All links inside a bin are rendered as relative URLs. Thus, if the container page is non-secure, all the links inside the bin will be non-secure as well, and vice versa.
Oracle iStore features reusable content tools that allow you to present content in the Partner Dashboard UI. The content tools allow you to map content source files to UI pages. The content can be images, HTML files, or text messages. During iStore implementation, the mechanism for content storage is specified. Content can be stored in a content database, a file list, or Oracle Content Manager.
A content component is a placeholder that expects a certain type of content. The types of content components that are available for a section are determined by the display template associated with the section. A media object is a logical bridge that connects content component placeholders with source files to present images or HTML content in the UI. Content components define the types of media objects that can appear on a web page. All but the Message, Other, and Logo classes of media objects must be linked to a content component in order to present information in the UI. A media object links to at least one source file. A media object can be associated with more than one file. Note: In the iStore framework, a media object is associated with an image or a text file. A template is associated with a Java Server Page (JSP).
Six seeded content components are available:
Product Large Image
Product Small Image
Product Additional Information
Section Small Image
Section Additional Information
Section Additional Information 1 Through 5
Creating the site makes the Partner Dashboard available for partner users. When you create the site, you specify the partner user responsibilities required to access the dashboard.
When you are creating the site, select the ’Restrict customer access by responsibility’ check box. Do not select the ’Allow un-registered users to browse the site’ check box.
Responsibilities determine the operating unit against which any orders that are placed in the current session are booked. In the Site Display Name field, enter a unique name. The name should help in identifying that the site is applicable to partners.
Groups provide ways to organize an organization’s specialty sites on the Site Selection page. When a customer goes to the Site Selection page, he sees a list of sites organized according to Group: for example, Partners sites or Store sites. Without Group information, a site’s intended customer base might not be obvious based on the site name alone. The list of groups is populated by the IBE_M_SITE_GROUP lookup. Additional groups can be added to the list by editing this lookup.
Oracle Partner Management leverages iStore's template management framework to achieve the same look and feel as partner dashboard. Users can now enroll into a program from the partner dashboard provided by a common foundation component called Template Management Framework.
The top header renders <html>, <head> tags. Customers can add anything that they would like to see prior to menu rendering in this page.
The Left 1, Left 2, Left 3, Left 4, Right 1, Right 2, Right 3, Right 4, Center 1, Center 2, Center 3 and Center 4 templates are part of the Layout template.
The layout template includes the content rendering part of the enrollment flow.
The bottom header renders </html> tags.
Enrollment pages do not have the menu section hierarchy. So, the menu template renders logo, global icons and a thin menu bar without any section hierarchy.
The following figure displays the enrollment flow template with top header, menu, and bottom header locations.
Enrollment Flow Template
Each page in the enrollment flow has different data that needs to be processed when user clicks the Next button. Hence, each page in the enrollment flow has separate container pages. To minimize the amount of work when a customer wants to customize the layout, the same layout template is used across all the pages in the enrollment flow. Any change in the layout template is reflected immediately in all the pages of the enrollment flow.
The Enroll Now, Questionnaire, Questionnaire Summary, Contract, Payment Address, Payment Information, Payment Confirmation and Thank you pages are container templates.
The following figure illustrates the container templates mentioned above.
Container Templates
The following templates are used in partner registration flow. For information on how these templates are used, see Oracle iStore Implementation Guide.
Processing page for partner types during registration: Processing page template to process user selected partner type and member type during self registration of partner primary user.
Displays partner types during registration: Template for displaying partner type and member type during self registration of partner primary.
Oracle Order Management is used to process sales orders when a partner submits an enrollment request for a program that contains fees. It is used to process financial liabilities.
For partner program enrollments, three profile options must be set up to integrate Oracle Partner Management with Oracle Order Management:
PV: Default Sales person used for Orders: Oracle Order Management requires that a salesperson be identified for each order. Depending on business requirements, the salesperson can receive a commission for partner program enrollments; however, if the vendor chooses not to associate a salesperson with program enrollments, a fictional name can be used instead.
The setting for this profile option must be a valid sales rep (a fictional sales rep can be created, if necessary). As sales reps are org striped, this profile option needs to be set at either the responsibility or site level depending on what orgs the partner users belong to. At run time, sales rep retrieved from this profile option needs to be a valid sales rep for the 'MO: operating Unit' of the user's logged-in responsibility.
PV: Order Cancel Reason: Use this profile option to provide a reason for the cancellation of an enrollment request. This reason will be used when an enrollment request is cancelled because:
The partner chose to cancel the enrollment request
An approver rejected the enrollment request
The setting for this profile option is taken from the Order Management CANCEL_CODE Lookup. The profile is set at the Site level.
PV: Order Transaction Type: A partner program is not a shippable item. Set this profile option to any transaction type that is applicable for non shippable items. As Order Management transaction types are org striped, this profile option needs to be set at either the responsibility or site level depending on what orgs the partner users belong to. At run time, the transaction type retrieved from this profile option needs to be a valid transaction type for the 'MO: operating Unit' of the user's logged-in responsibility.
For more information on these profile options and on setting up Oracle Order Management, refer to the Oracle Order Management Suite Implementation Guide and Oracle Order Management User Guide.
Credit card payments are handled by the Oracle Payments application. An Oracle Payments user with the Payment Administrator responsibility sets up and maintains the Oracle Payments application and server. For information on setting up and maintaining the Oracle Payments Server, refer to the Oracle Payments Implementation Guide.
Depending on business requirements, an organization might choose to use secure http (https) for enrollment requests, especially for requests that are paid with a credit card. However, https can have a performance impact on a site, so the organization might want to limit https to the payment portion of the enrollment request. For Oracle Partner Management, you can specify whether or not to user https through two profile options:
IBE: iStore Secure URL: Use to specify a secure server and port for payment pages.
IBE: iStore Non Secure URL: User to specify a nonsecure server and port for other pages.
These two profile options are optional, and are both set up at the Site level. For more information providing settings for the options, refer to Appendix A, System Profile Options.
A partner user can pay for a partner program enrollment with a credit card. Using the Payment Book within the Profile menu of the Oracle iStore Customer Application, partners can store credit cards to be used during the enrollment process when a program has a fee. The partner can mark a single credit card as preferred; this credit card is defaulted into the payment method page in the enrollment flow when the credit card is used as the payment method. The Payment Book is available as part of the partner's profile.
Oracle Payments integration allows a vendor to decide whether or not to require a card holder to provide the CVV2 code during payment transactions. This global setting is set on the System Security Options page in Oracle Payments. If the vendor decides to use the CVV2 code, a mandatory field appears on the payment method page in the enrollment flow. The CVV2 code is not stored with the partner's credit card number in Oracle Payments.
Further security is provided by the Address Verification Services (AVS) feature in Oracle Payments. This feature is set up in Oracle Payments on the System Security page. If this feature is enabled, the statement address is matched against the user's credit card billing address. A Credit Card Statement Address drop-down field with the list of active addresses of logged in partner contacts appears on the payment method page in the enrollment flow, from which the partner user can select an address. The default setting is "Same as Billing Address."
The vendor can choose to limit the number of authorization attempts allows for a single credit card transaction. If a limit is placed on authorization attempts, and the number of allowable attempts has been exceeded, the enrollment request will be ended, and the user will be returned to the Partner Dashboard. However, the enrollment registration information is saved. In addition, Oracle Order Management saves the billing information.
The number of allowed authorization attempts is specified using the profile option PV: Max number of credit card authorization. This profile is set at the Site level, and the setting is a numeric value. The default value is 3.
The jtt_cookie_path and jtt_cookie_domain java runtime variables need to be set up properly for transferring user cookies from the https server to the http server and vice versa. This is done so that users do not need to explicitly enter the user name and password again when switching from https to http and vice versa. This setup is needed only if payment pages must be secure and the rest of the pages can be nonsecure.
For information on how to use the java runtime variables, see JTT documentation.
Tax rules need to be set up for calculating tax for membership fee.
For information on how rules should be set up, see the Oracle Receivables Tax Guide.
Partner program enrollment requests are subject to an approval process. When a partner user submits an enrollment request, it is routed to an approver, who is a vendor user. The approver can approve or reject the request. You can set up multiple approvers. The partner program enrollment approvals process is set up and managed through the Oracle Approvals Management application.
The seeded transaction for enrollment requests is PV: Partner Program Enrollment Requests. Numerous attributes have been defined for this transaction. A default program enrollment request approver can be identified using the PV: Default Enrollment Request Approver profile option, which is used when AME does not return any approvers for any enrollment request. For more information on setting up approvals for program enrollment requests, refer to Creating Approval Rules in Oracle Approvals Manager .
The administrator can designate one or more vendor users as partner program enrollment administrators. Administrators can see all enrollment requests in the system, whereas other users can only see the enrollment requests for which they are approvers, or the enrollment requests submitted by partners to which they have access.
A partner program enrollment request administrator is designated by giving a Oracle Partner Management vendor user the resource role Vendor Administrator. The user can have other Oracle Partner Management vendor user roles as well.