Oracle® Territory Management Implementation Guide Release 11i (11.5.9) Part No.
Oracle Territory Management Implementation Guide, Release 11i Part No. B10553-01 Copyright © 2003 Oracle Corporation. All rights reserved. The Programs (which include both the software and documentation) contain proprietary information of Oracle Corporation; they are provided under a license agreement containing restrictions on use and disclosure and are also protected by copyright, patent and other intellectual and industrial property laws.
Contents Send Us Your Comments .................................................................................................................. vii Preface............................................................................................................................................................ ix Intended Audience ................................................................................................................................ How To Use This Guide ..........................
Part II 3 Implementing Oracle Territory Management Implementation Overview 3.1 Process Description ............................................................................................................... 3.1.0.1 Phase I: Territory Planning .................................................................................... 3.1.0.2 Phase II: Setting Up Territories ............................................................................. 3.1.0.3 Phase III: Creating Named Account Territories .....
Phase II: Setting Up Territories 5.1 5.2 5.2.1 5.2.1.1 5.2.1.2 5.2.2 5.2.3.1 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 Overview of Creating Territories........................................................................................ Qualifiers ................................................................................................................................ Transaction Qualifiers ...................................................................................................
Part III Post Implementation Tasks 7 Verify the Implementation 7.1 8 Troubleshooting 8.1 8.2 8.3 8.4 vi Verification Tasks .................................................................................................................. 7-1 Tips for Fine-tuning Territory Assignment Performance................................................ If the Generate Territory Packages Fails ............................................................................
Send Us Your Comments Oracle Territory Management Implementation Guide, Release 11i Part No. B10553-01 Oracle Corporation welcomes your comments and suggestions on the quality and usefulness of this document. Your input is an important part of the information used for revision.
viii
Preface Intended Audience Welcome to Release 11i of the Oracle Territory Management Implementation Guide. This guide assumes you have a working knowledge of the following: ■ The principles and customary practices of your business area. ■ Oracle Territory Management If you have never used Oracle Territory Management, Oracle suggests you attend one or more of the Oracle Territory Management training classes available through Oracle University. ■ The Oracle Applications graphical user interface.
■ Chapter 4 covers the planning phase of the implementation. ■ Chapter 5 explains how to enable qualifiers as part of the implementation. ■ Chapter 6 provides the procedures for creating territories. ■ Chapter 7 covers verifying the implementation. ■ Chapter 8 contains troubleshooting tips. Documentation Accessibility Our goal is to make Oracle products, services, and supporting documentation accessible, with good usability, to the disabled community.
Related Documentation Oracle Territory Management shares business and setup information with other Oracle Applications products. Therefore, you may want to refer to other product documentation when you set up and use Oracle Territory Management.
Installing Oracle Applications This guide provides instructions for managing the installation of Oracle Applications products. In Release 11i, much of the installation process is handled using Oracle Rapid Install, which minimizes the time to install Oracle Applications, the Oracle8 technology stack, and the Oracle8i Server technology stack by automating many of the required steps.
information to help you build your custom Oracle Forms Developer 6i forms so that they integrate with Oracle Applications. Oracle Applications User Interface Standards for Forms-Based Products This guide contains the user interface (UI) standards followed by the Oracle Applications development staff. It describes the UI for the Oracle Applications products and how to apply this UI to the design of an application built by using Oracle Forms.
Oracle Workflow API Reference This guide describes the APIs provided for developers and administrators to access Oracle Workflow. Oracle Applications Flexfields Guide This guide provides flexfields planning, setup and reference information for the Oracle Territory Management implementation team, as well as for users responsible for the ongoing maintenance of Oracle Applications product data. This manual also provides information on creating custom reports on flexfields data.
Support From on-site support to central support, our team of experienced professionals provides the help and information you need to keep Oracle Territory Management working for you. This team includes your Technical Representative, Account Manager, and Oracle’s large staff of consultants and support specialists with expertise in your business area, managing an Oracle8i server, and your hardware and software environment.
When you use Oracle Applications to modify your data, Oracle Applications automatically checks that your changes are valid. Oracle Applications also keeps track of who changes information. If you enter information into database tables using database tools, you may store invalid information. You also lose the ability to track who has changed your information because SQL*Plus and other database tools do not keep a record of changes.
Part I Getting Started This section of the contains the following chapters: ■ Chapter 1, "Introduction" ■ Chapter 2, "Before You Begin"
1 Introduction This chapter provides information on the following topics: ■ Section 1.1, "The Oracle E-Business Suite" ■ Section 1.2, "Oracle Territory Management Overview" ■ Section 1.3, "New in this Release" 1.1 The Oracle E-Business Suite The Oracle E-Business Suite is a comprehensive web-based answer for business-to-business (B2B) and business-to-consumer (B2C) selling, marketing, and servicing through the Internet.
The Oracle E-Business Suite (OLTP), query-intensive data warehouses, and high capacity web sites. Because the Oracle database is available on many different platforms, applications can scale from handheld to laptop to desktop to enterprise providing consistent information over multiple channels.
The Oracle E-Business Suite ■ the eCommerce suite The ERP applications include: ■ Oracle Order Management ■ Oracle Supply Chain Planning ■ Oracle Manufacturing ■ Oracle Financials ■ Oracle Human Resources Management System Customer Relation Management (CRM) Companies use Oracle's CRM suite of applications to acquire, maintain, and enhance customer relationships, by assisting companies with marketing automation, sales force automation, contracts management, customer service and support, and busi
The Oracle E-Business Suite service and support activities from initial contact with the customer through issue resolution. Automating service efforts can potentially transform an area that has historically proven to be a cost center into a revenue generator. This suite of applications provides customer support, field service and depot repair functionality. In addition, Oracle Services offers complete visibility into spare parts availability, logistics, service billing and customer contract entitlements.
Oracle Territory Management Overview Common Application Architecture The Common Application Architecture includes functionality that supports both CRM and ERP applications. For example, TCA, Oracle's Trading Community Architecture, consists of a database schema and Application Programming Interfaces (APIs) where you can model the complex relationships that occur within a business community and enter that data consistently throughout the enterprise.
Oracle Territory Management Overview 1.2.1 Components For all territory implementations the territory administrator uses the Forms windows to create qualification rules and to create territories and a hierarchy of territories, each with assigned resources. Sales territory implementors have the option to establish named account territories. Administrators use the HTML pages to create territory groups and named accounts.
New in this Release ■ Territory diagnostics 1.3 New in this Release This document describes functionality to be delivered in the Oracle E-Business Suite 11.5.9 release. If you are implementing this product prior to the release, using product minipacks or family packs, some new functionality may be dependent on integration with other Oracle products. Please consult MetaLink for relevant product patches and documentation.
New in this Release 1-8 Oracle Territory Management Implementation Guide
2 Before You Begin This chapter provides an overview of what you need to have installed, implemented, and verified before implementing the Oracle Territory Management. Topics include: ■ Section 2.1, "Related Documentation" ■ Section 2.2, "Installation Verification" ■ Section 2.3, "Oracle Territory Management Dependencies" 2.1 Related Documentation Oracle Territory Management User Guide 2.
Installation Verification Navigation CRM Foundation > Resource Manager > Territory Administration Steps 1. From the Territories Navigator, open Oracle Sales and TeleSales. 2. In the administration bar, click Define Territory. The Territory Details window opens. 3. In the Overview tab, set the Usage to Sales. 4. Enter a name for the territory. 5. Accept the catch all as the parent territory. 6. Select transaction types, including Leads. 7.
Oracle Territory Management Dependencies 2. From the Cue Card navigate to the Sales Team tab and verify that the resource you assigned to the territory is assigned to the lead. 2.3 Oracle Territory Management Dependencies The following are the modules that Oracle Territory Management depends upon: ■ ■ Oracle Application Object Library (AOL): Territory Manager uses AOL to manage responsibilities that are used in various modules.
Oracle Territory Management Dependencies 2-4 Oracle Territory Management Implementation Guide
Part II Implementing Oracle Territory Management This section contains the following chapters: ■ Chapter 3, "Implementation Overview" ■ Chapter 4, "Phase I: Territory Planning" ■ Chapter 5, "Phase II: Setting Up Territories" ■ Chapter 6, "Phase III: Creating Named Account Territories"
3 Implementation Overview Oracle strongly recommends that you implementOracle Territory Management in the order listed. ■ Section 3.1, "Process Description" ■ Section 3.2, "Implementation Task Sequence" ■ Section 3.3, "Multi-Org" 3.1 Process Description Before using the Oracle Territory Management, your functional implementation team must analyze your business and organization needs. This step is key before implementing the Territory Manager.
Implementation Task Sequence The process for named account territories requires territory administrators to run the Generate Territory Packages concurrent program which automatically generates the territories. These are visible from the Forms user interface in read only mode. Territory Manager is implemented in the following four phases: 3.1.0.1 Phase I: Territory Planning In Phase I, your implementation team analyzes business and organization needs and plans territories accordingly. 3.1.0.
Implementation Task Sequence Table 3–1 Phase I: Territory Planning Step Description Type Performed By Territory Planning Analyze the territory setup in your organization before utilizing Territory Manager. You need enterprise-wide cooperation and feedback. On paper Implementation Team You must expect to make multiple territory revisions in the early months of operation as your enterprise discovers omitted information or territories that do not work on a day-to-day basis.
Multi-Org Table 3–3 Phase III: Creating Named Account Territories (Optional, Sales only) Step Description Type Performed By Create Territory Groups and Named Accounts Create territory groups and assign resources and named accounts to the territory groups.
4 Phase I: Territory Planning This chapter explains the territory planning process and includes the following topics: ■ Section 4.1, "Planning Your Territories" ■ Section 4.2, "Sales Territory Planning Example" ■ Section 4.3, "Sales Territory Qualifiers" ■ Section 4.4, "Service Territory Qualifiers" 4.1 Planning Your Territories The planning phase is the most important step in territory setup.
Planning Your Territories ■ How many winners are allowed: A winner is the territory that receives the transaction or customer. ■ How are winning territories determined ■ Will Sales implement named account territories This list is not all-inclusive and planning factors depend on your business needs. Perform the following steps to plan your territories. This procedure is usually done in a group with pen and paper. Prerequisites None Responsibility None Navigation None Steps 1.
Sales Territory Planning Example ■ What are your products and how are they differentiated? 2. Decide what qualifiers you want to use to assign objects to territories. 3. Decide on the hierarchy of territories. 4. Decide what qualifier values to use for assigning resources to territories. 5. Identify any overlapping territories and decide the order in which the application chooses them. Rank any overlapping territories from 1 to N to determine the order.
Sales Territory Planning Example Business World is a large manufacturer of computer equipment selling in the US and Canada. They organize their products into three families: servers, desktops/laptops, and storage. In their direct sales model, Business World has a named account sales force consisting of an account manager working specific accounts, and a telephony sales force working the remaining general pool of customers.
Sales Territory Planning Example Table 4–1 Sales territory model Overlay Product Specialists US Canada Comments 3 product families, 9 product specialists for each product family and region 3 product specialists. Product specialists cover their mutually exclusive product families for the entire country. Product specialists service all opportunities for a product family and geographic location and their related customers (they are only allowed to view customer information).
Sales Territory Planning Example ■ ■ ■ ■ ■ CUSTOMER NAME RANGE, to identify the 200 named accounts COUNTRY, because this qualifier is used as a first criterion in identifying territory and offers the ability to support “Catch All” territories POSTAL CODE, to create geographic territories composed of postal codes. One can use less granular geographic qualifiers such as state or province as well.
Sales Territory Planning Example 4.2.4 Step 4: Territory hierarchy – Define Catch Alls We have separate sales forces for US and Canada so we will create 2 child territories underneath FY2004 Sales; one called US Catch All with a transaction qualifier rule COUNTRY = ‘UNITED STATES’ and another called Canada Catch All with a transaction qualifier rule COUNTRY = ‘CANADA’. The COUNTRY qualifier rules will be inherited by all child territories, easing maintenance.
Sales Territory Planning Example 4.2.5 Step 5: Territory hierarchy – Placeholder territories Sometimes we create territories purely for organization and ease of maintenance. The territories under the US Catch All territory are an example of this. Within the US and Canada, there are named account sales forces and geographic sales forces.
Sales Territory Planning Example 4.2.7 Step 7: How to implement geographic territories What geographic qualifier will you use? The decision is based on what granularity is used to distribute your geographies. Do you distribute by entire states or provinces or postal codes? If you distribute by postal code, your geographic qualifier should be POSTAL CODE. Other options include STATE, PROVINCE, CITY, COUNTY, COUNTRY and AREA CODE.
Sales Territory Planning Example 4.2.8 Step 8: How to support overlays We recommend that you implement Overlays in a separate territory hierarchy.
Sales Territory Planning Example 1. Either a named account OR a geographic general business territory 2. AND one overlay territories. Increasing the number of winners in the FY2004 Sales hierarchy and putting the overlay territories underneath it would not accomplish this. However, with the FY2004 Sales hierarchy and number of winners set to one, Territory Manager selects either a named account territory or a general business territory.
Sales Territory Planning Example Is your sales management organized by product family or by geographic area? The territory hierarchy should closely mimic your sales management hierarchy for ease of understanding and maintenance.
Sales Territory Planning Example If Business World’s overlay sales force is organized by geography and wants Catch Alls by geography, then we create three territories underneath the US Overlay territory: ■ ■ ■ “US East Overlay Catch All”, with transactional qualifier rules STATE = ‘NY’, STATE = ‘NJ’, STATE = ‘MA’, STATE = ‘VT’, and so on, and resource qualifier = Eastern Overlay territory administrator “US Central Overlay Catch All”, with transactional qualifier rules STATE = ‘IL’, STATE = ‘OH’, STATE =
Sales Territory Planning Example Alternative overlay territory hierarchy BY PRODUCT FAMILY If Business World’s US overlay sales force requires Catch Alls by product family or is organized by product family, we would create three territories underneath the US Overlay territory: ■ 4-14 “US Server Catch All”, with the transactional qualifier rule OPPORTUNITY EXPECTED PURCHASE = ‘SERVER’ and resource = Server territory administrator Oracle Territory Management Implementation Guide
Sales Territory Planning Example ■ ■ “US Desktop Catch All”, with the transactional qualifier rule OPPORTUNITY EXPECTED PURCHASE = ‘DESKTOP’ and OPPORTUNITY EXPECTED PURCHASE = ‘LAPTOP’ and resource = Desktop territory administrator “US Storage Catch All”, with the transactional qualifier rule OPPORTUNITY EXPECTED PURCHASE = ‘STORAGE’ and resource = Storage territory administrator The same 9 US overlay territories created in the first example are re-shuffled underneath the appropriate US product family
Sales Territory Planning Example all the 100 child territories will inherit its transaction qualifier rules. Instead of maintaining the rule in 100 territories it can be maintained in one parent territory. These parent territories can also be assigned resources and act as “Catch All” territories in case the customer, lead or opportunity did not match one of the child territories. We have two catch alls in our business world example: one for Canada and the other for the US.
Sales Territory Planning Example territories as named accounts because they say they have always done it this way. Questions to ask: ■ ■ ■ How many named accounts does the organization have? If sales management claims that named accounts make up more than 20% of all TCA organizations, then they are likely to have incorrectly implemented named accounts. For example, a Telecom territory is composed of 50 SIC codes.
Sales Territory Qualifiers 4.2.15 Qualifier Rules Best practices around qualifier rules are the simplest to follow because they are very concrete. Qualifier rules are converted to SQL and are subject to the same performance constraints. Always avoid the use of the following: ■ The use of the NOT operand forces full table scans and in the context of Territory Manager includes: NOT = NOT LIKE NOT BETWEEN.
Sales Territory Qualifiers Table 4–2 Sales Qualifiers Transaction Type Territory Qualifier Sales Online/TeleSales Attribute Account Account Hierarchy "Subsidiary Of" a particular organization Account Area Code Area Code Account City City Account Country Country Account County County Account Customer Category Customer Category Account Customer Name Customer Name Account Customer Name Range Customer Name Account Number of Employees Total Employees Account Postal Code Postal Co
Service Territory Qualifiers 4.4 Service Territory Qualifiers The following table maps the sales qualifiers to their Service counterparts. Table 4–3 Sales Qualifiers Transaction Type 4-20 Territory Qualifier Mapping to Oracle Service Contact Preference Service Request Communication Preference on SR Form. Derived from ar_lookups Customer Site Service Request Not currently used by SR Group Owner Service Request Group Field on SR Form. Derived from JTF Tables.
Service Territory Qualifiers Table 4–3 Sales Qualifiers Transaction Type Territory Qualifier Mapping to Oracle Service Service Item Service Request Not currently used in 11.5.8 and prior Service Request Language Service Request Language Field on SR Form. Support Site Service Request Support Site on SR Form. Derived from JTF Tables.
Service Territory Qualifiers 4-22 Oracle Territory Management Implementation Guide
5 Phase II: Setting Up Territories This chapter covers the implementation of territories for all applications. The steps are done using the Forms user interface. The chapter includes the following topics for Phase II: Setting Up Territories: ■ Section 5.1, "Overview of Creating Territories" ■ Section 5.2, "Qualifiers" ■ Section 5.3, "Territory Hierarchies" ■ Section 5.4, "Territory Winning Rules" ■ Section 5.5, "Enabling Existing Qualifiers" ■ Section 5.
Qualifiers 5.2 Qualifiers There are two types of qualifiers that help define a territory: Transaction Qualifiers and Resource Qualifiers. A qualifier also consists of three components: name, operator, and value. The following table describes each component: Table 5–1 Qualifier Components Components Description Name The name of the qualifier. It can be postal code, item, task priority, request status, job title, or others.
Qualifiers ■ Oracle Defect Management ■ Oracle Sales and Marketing ■ Oracle Service ■ Trade Management The following table describes a small sample of both resource and transaction qualifiers. Example of Predefined Territory Qualifiers Application Type Qualifier Type Qualifier Name Defect Management Defect Transactions Product Sales Account Customer Name Range Trade Management Trade Account State Service Service Request Request Type 5.2.1.
Qualifiers Like “Business World %”: This value represents Business World Motor, Business World Book, and Business World Service. Between “A% Business World” to “Z% Business World”: This value represents USA Business World, UK Business World, and Russia Business World. 5.2.2 Resource Qualifiers Resource Qualifiers specify what attributes are used to select the individuals responsible for those transactions. Examples include job title, competence, and language.
Territory Winning Rules 5.3 Territory Hierarchies The purpose of having territory hierarchies is to make the territory assignments and searches more efficient. Territory hierarchies also have the ability to store the parent-child relationship among territories. Parent-Child Territory Any territory consisting of one or more subterritories is considered as a parent territory. For example, a West Coast territory could consist of three subterritories: Washington, Oregon, and California.
Territory Winning Rules wins against the lowest rank of the territories (which would be the higher number) in the territory hierarchy. Multiple Winners If you enter a number greater than 1 in the Number of Winners field in the Overview tab, then Territory Manager assigns a transaction to multiple qualifying territories. Use the Number of Winners field to limit the number of winning territories.
Enabling Existing Qualifiers – Territory 3: Rank 2 Winner can be either Territory 1 or Territory 3. Reason: Any territory with rank 2 can be the winner. The Assignment Manager selects Territory 1 or Territory 3 randomly. ■ Condition B: – Territory 1: Rank 3 – Territory 2: Rank 2 – Territory 3: Rank 4 The winner is Territory 2. Reason: The territory with rank 2 wins over the territories with rank 3 and 4. 5.
Enabling Existing Qualifiers Login (Forms) Log in to Oracle Forms. Responsibility CRM Administrator Navigation (Forms) Territory Manager > Territory Administration to open the Navigator window Steps 1. Select Administration from the drop down menu and choose Setup Qualifiers. The Setup Qualifier window opens. 2. Select the Usage drop-down list. The Select Usage window opens. 3. Highlight your selection and click OK.
Creating Individual Territories 5.6 Creating Individual Territories You can create a stand-alone territory by entering territory qualifiers and their values directly. You can also select the territory that serves as a parent to the new territory and right-click to select New from the pop-up menu. Prerequisites ■ There must be a territory plan in place. ■ All the transaction qualifiers used in territory creation are enabled. Login Log in to Oracle Forms.
Creating Individual Territories 3. Enter a name and description for the territory. 4. To limit the time the territory is effective, enter the Start and End Dates. By default the territory become effective on the date that you create it. 5. (Optional) Verify that the parent territory is the territory you selected in the Navigator. If this is not the parent territory, then use the LOV to select the appropriate parent territory. 6. Enter an appropriate rank in the Rank field. 7.
Entering Transaction Qualifiers Note: Opportunity and Lead are considered a superset of the Account qualifiers. Therefore, the account-related transaction qualifiers, such as Postal Code and State, are available even if the account transaction type is not selected by Oracle Sales and TeleSales.
Entering Transaction Qualifiers Prerequisites ■ There must be a territory plan in place. ■ All the transaction qualifiers used in territory creation are enabled. ■ The territory overview information is saved Login Log in to Oracle Forms. Responsibility CRM Administrator Navigation Territory Manager > Territory Administration > Administration > Define Territory Double-click the territory in the Tree Navigator Steps 1.
Entering Resource Qualifiers 5.8 Entering Resource Qualifiers Optionally use the Resource Qualifiers tab to filter qualifying resources in a territory if you don’t know exactly which resources you are going to use for a territory. This aids in determining which resources you want to assign to the territory during territory creation.
Specifying Resources for a Territory Double-click the territory in the Tree Navigator Steps 1. Use the LOV in the Name field to choose an appropriate qualifier name (such as "Resource Type") for the territory. 2. Use the LOV in the Operator field (such as "=") and Value field (such as "Employee Resource") to make the appropriate selections. 3. Click Save from the toolbar to save the resource qualifier information.
Specifying Resources for a Territory Login Log in to Oracle Forms. Responsibility CRM Administrator Navigation Territory Manager > Territory Administration > Administration > Define Territory Double-click the territory in the Tree Navigator Steps 1. If the Resource Qualifiers tab is not used (Manually Assign Resources): Use the list of values (LOV) to enter the resources in the Name fields if you know exactly which resources used in this territory. 2.
Adding Subterritories For example, if the selected access type for John Walsh is Service Request, then John can be assigned only to a job related to a service request, and he cannot be assigned to a task or to a task created within a service request. 6. Click Save from the toolbar to save the resource information. Note: Full Access: This check box is used only in Sales and TeleSales. If this box is checked, the resource has full access to the transaction type you specified in the Access Type field.
Running Concurrent Programs 2. Click Save from the menu. 5.11 Running Concurrent Programs It is important that the territory administrator runs the following concurrent programs regularly. After the concurrent programs run successfully, the Territory Manager module is automatically updated to reflect the changes made to your territories. The following table describes the function of the seeded concurrent programs.
Running Concurrent Programs Navigation Requests > Run to open the Submit a New Request window Steps 1. Select Single Request. 2. Click OK. 3. In the Name LOV, select either Generate Territory Packages or Named Account Territory Post Processing. 4. In the Parameters pop-up window of the Submit Request, enter your parameters. 5. Click OK. 6. Click Schedule in the Submit Request window to set appropriate information to run concurrent programs periodically. 7. Click Submit.
6 Phase III: Creating Named Account Territories This chapter covers the following topics for Phase III: Creating Territories: ■ Section 6.1, "Overview of Creating Named Account Territories" ■ Section 6.2, "Named Account Territory Process" ■ Section 6.3, "Migrating from Existing Territories to Named Account Territories" ■ Section 6.4, "Enabling Qualifiers" ■ Section 6.5, "Creating a Parent Territory" ■ Section 6.6, "Creating Territory Groups" ■ Section 6.
Overview of Creating Named Account Territories The implementer or administrator creates named account territory groups by associating organizations to the territory group. The act of associating organizations to a territory group elevates an organization to a named account. An account that falls within the definition, and any leads or opportunities for accounts that match the definition, all belong to the defined named account.
Overview of Creating Named Account Territories Monthly Dun & Bradstreet uploads contain mergers and divestitures. Sales organizations will either maintain their sales team assignments even through corporate changes (requiring no named account territory maintenance), or change sales team assignments to reflect the divestiture (requiring new sales team assignments). Territory administrators diagnose why transactions are falling into their named account Catch Alls and fix the problem.
Named Account Territory Process territory administrators for centralized named account definitions and sales managers for resource assignments),Oracle Territory Management automatically generates hierarchies of named account territories that are configured to hang off of an existing territory hierarchy.
Migrating from Existing Territories to Named Account Territories 6. Territory administrations and sales operations can monitor how the completion percentages of the self-service named account process. 7. When this process is complete enough, territory hierarchies are automatically generated and enabled for territory groups. 8.
Migrating from Existing Territories to Named Account Territories 7. When you create new named account territories, administrators will need to create named account definitions for each new named account. Named account definitions or territory rules must be created to map customers, leads, or opportunities to named accounts. Default mappings are created based on CUSTOMER NAME RANGE = business name of account and POSTAL CODE = postal/zip code of named account.
Creating Territory Groups 6.4 Enabling Qualifiers In order to implement named account territories you must minimally enable CUSTOMER NAME RANGE and POSTAL CODE qualifiers. See Section 5.5, "Enabling Existing Qualifiers" for the procedure. 6.5 Creating a Parent Territory A parent territory must exist before you can implement named account territories. See Section 5.6, "Creating Individual Territories" for the procedure for creating the parent territory. 6.
Creating Territory Groups Details for the selected named account appear. 4. Enter a rank for the territory group. This is the rank of the territory group catch all. 5. Enter a start date for the territory to be active. 6. Optionally, enter an end date after which the territory group becomes inactive. 7. Click Next. The Define Role Access page appears. 8. Perform the following steps to assign roles and define the access for each role in the territory group. a.
Defining Named Account Rules The Assign Sales Management page appears. 11. Choose the name, group, and role for the top of the sales management hierarchy for this territory group. That manager in turn can assign accounts to sales organizations or salespeople in his sales hierarchy. 12. Click Next. The Add Organizations page appears. 13. Perform a search of the organizations to find the organizations you want to add to the territory group.
Defining Named Account Rules Responsibility Territory HTML Sales Administrator Navigation Territory Manager > Territories > Named Accounts Steps 1. Select the Territories tab. 2. Select the Named Accounts subtab. 3. Perform either a simple search or an advanced search. A list of your named accounts appears. 4. In the Select column, select one named account to define. 5. In the Map column, click the Update Mapping icon to define assignment rules. The Map page appears. 6.
Assigning the Sales Team to Named Accounts 12. If you want to preview what organizations match your qualifiers, then click Mapped Organizations. Return to the definition page. After the concurrent program Generate Territory Packages is run, leads, opportunities, or accounts that fall within the qualifiers you created will be assigned to the named account and the related territory. 6.8 Assigning the Sales Team to Named Accounts You can assign a sales team to one or more named accounts at a time.
Running Concurrent Programs 7. 8. a. Use the LOV to select the salesperson. b. Select the sales group from the LOV. c. Select the sales role from the LOV. d. If you want to add another salesperson, then click Add Another Row and repeat from step a. If you want to remove a salesperson from the sales team, then perform the following steps in the Remove Salesperson section: a. Use the LOV to select the salesperson. b. Select the salesperson’s sales group from the LOV. c.
Running Concurrent Programs Table 6–1 Seeded Concurrent Programs Name Generate Territory Packages Function ■ ■ Named Account Territory Post Processing ■ ■ Frequency To create the territory rules or to reflect the changes that you made to territories. Otherwise, your territories will not reflect the actual changes and will not work correctly when calling modules try to use the Assignment Manager to assign resources.
Usage Implementation 4. In the Parameters pop-up window of the Submit Request, enter your parameters. 5. Click OK. 6. Click Schedule in the Submit Request window to set appropriate information to run concurrent programs periodically. 7. Click Submit. Guidelines The parameter for Generate Territory Packages is the usage. Select the correct usage from the LOV, such as Oracle Sales and TeleSales or Oracle Service.
Part III Post Implementation Tasks This section contains the following chapters: ■ Chapter 7, "Verify the Implementation" ■ Chapter 8, "Troubleshooting"
7 Verify the Implementation This chapter contains material useful in verifying the implementation of the Oracle CRM Application Foundation modules. This chapter contains the following topics: 7.1 Verification Tasks Verify your implementation by performing one or more of the following tasks: 1. Create a territory for your usage and run the concurrent program. 2. Create a transaction for your usage. 3. Verify that the transaction is assigned to the correct resources.
Verification Tasks 7-2 Oracle Territory Management Implementation Guide
8 Troubleshooting This chapter covers the following topics: Section 8.1, "Tips for Fine-tuning Territory Assignment Performance" Section 8.2, "If the Generate Territory Packages Fails" Section 8.3, "Frequently Asked Questions (FAQs) about Transaction Qualifiers" Section 8.4, "Diagnostic Reports" 8.1 Tips for Fine-tuning Territory Assignment Performance 8.1.1 Ranking Strategy You can speed up processing time by ranking more frequently used territories higher than less frequently used territories.
If the Generate Territory Packages Fails Note: The "%" symbol is a wild card. ■ Territory B Qualifier: Company Name Range = Vision Enterprises% If you rank territory A higher than territory B, then territory B never receives any assignments. All Vision accounts are assigned to territory A. 8.1.2 Comparison Operators Avoid using "<>", NOT LIKE and NOT BETWEEN operators. 8.1.3 Additional Tips The following tips can be useful. ■ Set up territories in hierarchical fashion for easy maintenance.
Frequently Asked Questions (FAQs) about Transaction Qualifiers Steps 1. Log in with the CRM Administrator responsibility. 2. Select Territory Manager > Territory Administration to open the Navigator window. 3. Select Setup Qualifiers from the Administration pull-down menu. The Setup Qualifier window opens. 4. Select the type of Usage. In the status area select All, then click Find.
Diagnostic Reports Service Request and Task: This type allows you to define access for account, task and service request related transaction qualifiers. However, it limits the transaction access to a task associated with a service request only, not a task or a service request. For example, a territory is created with "Service Request" and "Task" transaction types.
