Oracle B10553-01 User Manual

Download

Oracle® Territory Management

Implementation Guide

Release 11i (11.5.9)

Part No. B10553-01

April 2003

Oracle Territory Management Implementation Guide, Release 11i

Part No. B10553-01

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. Reverse engineering, disassembly or decompilation of the Programs, except to the extent required to obtain interoperability with other independently created software or as specified by law, is prohibited.

The information contained in this document is subject to change without notice. If you find any problems in the documentation, please report them to us in writing. Oracle Corporation does not warrant that this document is error-free. Except as may be expressly permitted in your license agreement for these Programs, no part of these Programs may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Oracle Corporation.

If the Programs are delivered to the U.S. Government or anyone licensing or using the programs on behalf of the U.S. Government, the following notice is applicable:

Restricted Rights Notice Programs delivered subject to the DOD FAR Supplement are "commercial computer software" and use, duplication, and disclosure of the Programs, including documentation, shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement. Otherwise, Programs delivered subject to the Federal Acquisition Regulations are "restricted computer software" and use, duplication, and disclosure of the Programs shall be subject to the restrictions in FAR

52.227-19, Commercial Computer Software - Restricted Rights (June, 1987). Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065.

The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently dangerous applications. It shall be the licensee's responsibility to take all appropriate fail-safe, backup, redundancy, and other measures to ensure the safe use of such applications if the Programs are used for such purposes, and Oracle Corporation disclaims liability for any damages caused by such use of the Programs.

Oracle is a registered trademark, and SQL*Plus and OracleMetaLink are trademarks or registered trademarks of Oracle Corporation. Other names may be trademarks of their respective owners.

Send Us Your Comments.................................................................................................................. vii

Preface............................................................................................................................................................ ix

Intended Audience ................................................................................................................................ ix

How To Use This Guide ....................................................................................................................... ix

Documentation Accessibility ................................................................................................................ x

Other Information Sources.................................................................................................................... x

Do Not Use Database Tools to Modify Oracle Applications Data ................................................ xv

About Oracle ........................................................................................................................................ xvi

Part I Getting Started

1 Introduction

1.1 The Oracle E-Business Suite................................................................................................. 1-1

1.1.1 The Applications in the E-Business Suite ................................................................... 1-2

1.2 Oracle Territory Management Overview .......................................................................... 1-5

1.2.1 Components.................................................................................................................... 1-6

1.2.2 Named Accounts............................................................................................................ 1-6

1.2.3 Oracle Territory Management Features...................................................................... 1-6

1.3 New in this Release............................................................................................................... 1-7

2 Before You Begin

2.1 Related Documentation........................................................................................................ 2-1

2.2 Installation Verification........................................................................................................ 2-1

2.2.1 Create a Territory........................................................................................................... 2-1

2.2.2 Run Concurrent Programs............................................................................................ 2-2

2.2.3 Test with a Lead ............................................................................................................. 2-2

2.3 Oracle Territory Management Dependencies................................................................... 2-3

iii

Part II Implementing Oracle Territory Management

3 Implementation Overview

3.1 Process Description ............................................................................................................... 3-1

3.1.0.1 Phase I: Territory Planning.................................................................................... 3-2

3.1.0.2 Phase II: Setting Up Territories ............................................................................. 3-2

3.1.0.3 Phase III: Creating Named Account Territories ................................................. 3-2

3.1.0.4 Phase IV: Managing Territories ............................................................................ 3-2

3.2 Implementation Task Sequence........................................................................................... 3-2

3.3 Multi-Org................................................................................................................................ 3-4

4 Phase I: Territory Planning

4.1 Planning Your Territories..................................................................................................... 4-1

4.2 Sales Territory Planning Example....................................................................................... 4-3

4.2.1 Step 1: What business objects are we assigning?....................................................... 4-5

4.2.2 Step 2: What qualifiers should we use?....................................................................... 4-5

4.2.3 Step 3: Territory hierarchy - Define date effectivity and number of winners....... 4-6

4.2.4 Step 4: Territory hierarchy – Define Catch Alls......................................................... 4-7

4.2.5 Step 5: Territory hierarchy – Placeholder territories................................................. 4-8

4.2.6 Step 6: How to implement named account territories.............................................. 4-8

4.2.7 Step 7: How to implement geographic territories ..................................................... 4-9

4.2.8 Step 8: How to support overlays................................................................................ 4-10

4.2.9 Step 9: What is an appropriate territory hierarchy for overlays?.......................... 4-11

4.2.10 Step 10: What rank should each territory have?...................................................... 4-15

4.2.11 Step 11: Have you met all your business requirements?........................................ 4-15

4.2.12 Leverage Territory Hierarchies and Inheritance ..................................................... 4-15

4.2.13 Leverage Territory Ranking and Number of Winners ........................................... 4-16

4.2.14 Appropriate Choice of Qualifiers............................................................................... 4-16

4.2.15 Qualifier Rules.............................................................................................................. 4-18

4.2.16 Migrating Territories.................................................................................................... 4-18

4.3 Sales Territory Qualifiers.................................................................................................... 4-18

4.4 Service Territory Qualifiers................................................................................................ 4-20

5 Phase II: Setting Up Territories

5.1 Overview of Creating Territories........................................................................................ 5-1

5.2 Qualifiers ................................................................................................................................ 5-2

5.2.1 Transaction Qualifiers ................................................................................................... 5-2

5.2.1.1 Sample List of Seeded Transaction Qualifiers.................................................... 5-2

5.2.1.2 Customer Name and Customer Name Range,................................................... 5-3

5.2.2 Resource Qualifiers........................................................................................................ 5-4

5.2.3.1 Seeded Qualifiers.................................................................................................... 5-4

5.3 Territory Hierarchies ............................................................................................................ 5-5

5.4 Territory Winning Rules ...................................................................................................... 5-5

5.5 Enabling Existing Qualifiers................................................................................................ 5-7

5.6 Creating Individual Territories ........................................................................................... 5-9

5.7 Entering Transaction Qualifiers ........................................................................................ 5-11

5.8 Entering Resource Qualifiers............................................................................................. 5-13

5.9 Specifying Resources for a Territory ................................................................................ 5-14

5.10 Adding Subterritories......................................................................................................... 5-16

5.11 Running Concurrent Programs......................................................................................... 5-17

6 Phase III: Creating Named Account Territories

6.1 Overview of Creating Named Account Territories.......................................................... 6-1

6.1.1 Components of Self-Service Named Accounts.......................................................... 6-2

6.1.2 Ongoing Maintenance ................................................................................................... 6-2

6.1.3 Annual Maintenance ..................................................................................................... 6-3

6.1.4 Territory Autogeneration Mechanics.......................................................................... 6-3

6.2 Named Account Territory Process...................................................................................... 6-4

6.3 Migrating from Existing Territories to Named Account Territories ............................. 6-5

6.4 Enabling Qualifiers ............................................................................................................... 6-7

6.5 Creating a Parent Territory.................................................................................................. 6-7

6.6 Creating Territory Groups ................................................................................................... 6-7

6.7 Defining Named Account Rules ......................................................................................... 6-9

6.8 Assigning the Sales Team to Named Accounts .............................................................. 6-11

6.9 Running Concurrent Programs......................................................................................... 6-12

6.10 Usage Implementation........................................................................................................ 6-14

Part III Post Implementation Tasks

7 Verify the Implementation

7.1 Verification Tasks .................................................................................................................. 7-1

8 Troubleshooting

8.1 Tips for Fine-tuning Territory Assignment Performance................................................ 8-1

8.2 If the Generate Territory Packages Fails ............................................................................ 8-2

8.3 Frequently Asked Questions (FAQs) about Transaction Qualifiers.............................. 8-2

8.4 Diagnostic Reports ................................................................................................................ 8-4

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.

■ Did you find any errors?

■ Is the information clearly presented?

■ Do you need more information? If so, where?

■ Are the examples correct? Do you need more examples?

■ What features did you like most?

If you find any errors or have any other suggestions for improvement, please indicate the document title and part number, and the chapter, section, and page number (if available). You can send comments to us at:

Oracle Corporation Oracle Territory Management Documentation 500 Oracle Parkway Redwood Shores, CA 94065 USA

If you would like a reply, please give your name, address, telephone number, and (optionally) electronic mail address.

If you have problems with the software, please contact your local Oracle Support Services.

vii

viii

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.

To learn more about the Oracle Applications graphical user interface, read the Oracle Applications User’s Guide.

See Other Information Sources for more information about Oracle Applications product information.

How To Use This Guide

This document contains the information you need to understand and use Oracle Territory Management.

Preface

■ Chapter 1 introduces the application and what is new in this release.

■ Chapter 2 provides reference information including other documentation and

dependencies for the application.

■ Chapter 3 lists the sequence of tasks needed to implement the application.

■ 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. To that end, our documentation includes features that make information available to users of assistive technology. This documentation is available in HTML format, and contains markup to facilitate access by the disabled community. Standards will continue to evolve over time, and Oracle Corporation is actively engaged with other market-leading technology vendors to address technical obstacles so that our documentation can be accessible to all of our customers. For additional information, visit the Oracle Accessibility Program Web site at http://www.oracle.com/accessibility/.

Accessibility of Code Examples in Documentation JAWS, a Windows screen

reader, may not always correctly read the code examples in this document. The conventions for writing code require that closing braces should appear on an otherwise empty line; however, JAWS may not always read a line of text that consists solely of a bracket or brace.

Other Information Sources

You can choose from many sources of information, including online documentation, training, and support services, to increase your knowledge and understanding of Oracle Territory Management.

If this guide refers you to other Oracle Applications documentation, use only the Release 11i versions of those guides.

Online Documentation

All Oracle Applications documentation is available online (HTML or PDF). Online help patches are available on MetaLink.

Do Not Use Database Tools to Modify Oracle Applications Data

Oracle STRONGLY RECOMMENDS that you never use SQL*Plus, Oracle Data Browser, database triggers, or any other tool to modify Oracle Applications data unless otherwise instructed.

Oracle provides powerful tools you can use to create, store, change, retrieve, and maintain information in an Oracle database. But if you use Oracle tools such as SQL*Plus to modify Oracle Applications data, you risk destroying the integrity of your data and you lose the ability to audit changes to your data.

Because Oracle Applications tables are interrelated, any change you make using Oracle Applications can update many tables at once. But when you modify Oracle Applications data using anything other than Oracle Applications, you may change a row in one table without making corresponding changes in related tables. If your tables get out of synchronization with each other, you risk retrieving erroneous information and you risk unpredictable results throughout Oracle Applications.

About Oracle

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.

Oracle Corporation develops and markets an integrated line of software products for database management, applications development, decision support, and office automation, as well as Oracle Applications, an integrated suite of more than 160 software modules for financial management, supply chain management, manufacturing, project systems, human resources and customer relationship management.

Oracle products are available for mainframes, minicomputers, personal computers, network computers and personal digital assistants, allowing organizations to integrate different computers, different operating systems, different networks, and even different database management systems, into a single, unified computing and information resource.

Oracle is the world’s leading supplier of software for information management, and the world’s second largest software company. Oracle offers its database, tools, and applications products, along with related consulting, education, and support services, in over 145 countries around the world.

xvi

Getting Started

This section of the contains the following chapters:

■ Chapter 1, "Introduction"

■ Chapter 2, "Before You Begin"

Part I

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 consists of front-office Customer Relationship Management (CRM) applications and back-office Enterprise Resource Planning (ERP) applications. These applications automate marketing, sales, contracts, service, manufacturing, and supply chain processes as well as financial operations, project management, human resources operations, and business intelligence systems.

Introduction

The Oracle E-Business Suite sits on a multi-layer platform which includes:

■ Oracle 9i Database

■ Oracle 9i Application Server

■ Common Services and Components

■ Oracle Internet Business Intelligence

Oracle 9i Database

All applications reside on the Oracle9i Database. The Oracle database drives enterprise E-Business applications, online transaction processing applications

Introduction 1-1

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.

Oracle 9i Application Server

The Oracle 9i Application Server (Oracle 9iAS) is a middle-tier server which independently delivers the technology needed to build web sites and applications, create personalized portals, extract business intelligence, and manage a secure web site infrastructure.

Common Services and Components

All the applications can leverage the common infrastructure and services components. Functionality includes Oracle Forms, Oracle Reports, Oracle Application Object Library (AOL), the Oracle JDeveloper and Oracle Discoverer development tools, the coding and UI standards, and other functionality used by the applications.

For example, you can extend the applications according to your business needs using flexfields. You can create and assign responsibilities using the system administrator responsibility. Also, you can use Oracle Workflow to configure background processes and set up notifications so that all the appropriate managers and groups are notified.

Oracle Internet Business Intelligence

Above the E-Business Suite sits the Internet Business Intelligence application. This application integrate data from all of the E-Business Suite applications to provide key performance measurements, operating alerts, and management reports to every decision maker across the enterprise.

1.1.1 The Applications in the E-Business Suite

Customers can seamlessly share data from front-end applications (CRM) to backend applications (ERP). The CRM applications include:

■ the Marketing suite

■ the Sales suite

■ the Contracts suite

■ the Service suite

1-2 Oracle Territory Management Implementation Guide

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 business intelligence, in a multi-channel environment.

■ The Marketing suite provides campaign planning and execution, budget

management, list creation, reporting and analysis tools. Marketing professionals use the Oracle Marketing applications to drive quality leads to sales, to expand reach and to maximize marketing effectiveness by using a comprehensive set of marketing automation, analysis and multi-channel execution capabilities. The Marketing suite offers seamless integration with sales, service and operations.

■ The Sales suite provides integrated tools for all those who are involved in the

sales process, including field salespeople, telesales agents, distributors and resellers, customers purchasing over the Internet and sales executives.

Armed with up-to-the minute information regarding customers, leads and opportunities, as well as forecasts and compensation plans and projections, managers can proactively and effectively manage a sales force while providing the sales people with the information needed to close sales. Using this information, the field sales force, telesales teams, resellers, and web storefronts can collaborate in closing more business together as one sales team.

■ The Contracts suite enables authoring, executing and managing contracts,

warranties and extended warranties which provides visibility to contract entitlements and proactively acting upon contractual commitments. Whether a buyer or a seller, issuing contracts or receiving them, the Contracts suite automates the full contract life cycle.

■ The Service suite manages service activities with the goals of profitability,

employee productivity and complete customer satisfaction by addressing all

Introduction 1-3

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 Customer Care provides full access to customer information from each touch point in the enterprise and to each customer care agent or other employees who interact with the customer. All of the Service products can be deployed across web, call center and mobile field channels.

■ The eCommerce suite of products aids in establishing profitable long-term

relationships with customers through one-to-one marketing and personalized shopping experiences as well as proactive support and self-service capabilities. Oracle eCommerce synchronizes all customer interactions and transactions by integrating web-based channels with traditional channels.

Enterprise Resource Planning (ERP)

Companies use the ERP applications to control their back-office operations. For example:

■ Oracle Order Management applications feature advanced configurator

functionality, global available to promise, flexible pricing support, efficient delivery, high volume transactions and flexibility to adapt to changing business conditions.

■ Oracle Supply Chain Planning applications provide the tools required to

optimize flow of material, cash, and information across the extended supply chain.

■ Oracle Manufacturing applications support all styles of manufacturing -

engineer-to-order, discrete, process, flow, lot based, and project based manufacturing.

■ Oracle Financials provide solutions for strategic planning, accounting, treasury,

project management, and travel management.

■ Oracle Human Resources Management System is a comprehensive solution for

managing a company's human resources, allowing organizations to attract, retain and develop critical skills and knowledge on a global basis.

1-4 Oracle Territory Management Implementation Guide

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. Because the model is not hierarchical, Oracle applications can model complex B2B2C relationships and not to be limited to either a B2B or B2C implementation. TCA delivers a 360-degree view of the customer.

1.2 Oracle Territory Management Overview

Oracle Territory Management assigns business objects (customers and leads, for example) to resources based on configurable business rules. It defines who owns what.

An example of a sales territory is: all high-tech companies within a specific geographic area assigned to sales representative Joe or Sam’s sales group. This territory is defined using the following qualifiers:

■ Account Classification = High Tech

Oracle Territory Management Overview

■ State = California

The resource assigned to the territory is Joe who is in Sam’s sales group. When concurrent programs are run, the territory assignment engine assigns

resources to business objects such as the following:

■ customers

■ leads

■ opportunities

■ service requests

■ tasks

■ contract renewals

■ defects

■ trade management claims and offers

■ delinquencies

Introduction 1-5

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. Sales managers then use the HTML pages to assign their named accounts to individual sales representatives.

Individual sales representatives use the HTML pages to review the named accounts they own and information about the sales team for an account.

The territory lookup tool in HTML is available for anyone to look up the salespeople assigned to an account.

1.2.2 Named Accounts

Most customers fall into sales territories segmented along geographic or industry boundaries. Named accounts represent individual customers elevated from geographic territories and deemed by a sales organization as critical enough to have their own salesperson or account manager.

By their very nature, named account territories are difficult and complex to maintain and revolve around a decentralized business process.

A set of named accounts are identified and associated to a sales division by upper levels of sales management. The sales vice presidents responsible for the sales division distribute named accounts to their directs in a top down fashion through the sales hierarchy until all named accounts are owned by salespersons.

1.2.3 Oracle Territory Management Features

Oracle Territory Management includes the following features:

■ Over 100 qualifiers through which to define territory rules

■ Assignment to individual resources or groups (for sales)

■ Assignment to individual resources or groups or teams (for service)

■ Named account support

■ HTML based product flows for the distribution of named accounts

■ Configurable territory exception handling through Oracle Workflow

1-6 Oracle Territory Management Implementation Guide

■ 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.

The following new features have been added to Oracle Territory Management in this release.

HTML Self-Service Named Accounts for Sales

Named accounts are centrally identified to a sales organization and distributed top down to individual salespeople. Sales managers use self-service pages to distribute named accounts.

Enhanced HTML Reporting and new Portlets for Sales

Sales managers and administrators can easily view the following information:

New in this Release

■ Named account distribution

■ Named account lists

■ Unassigned named accounts

■ Unmapped named accounts

■ Leads, accounts, and opportunities fall to catch alls

■ Named account conflicts

Integration with Oracle Collections

Configurable Territory Exception Handling for Sales

Integration with Oracle Workflow means you can define a workflow to handle exceptions in a territory group. An exception is an object (such as lead or account) that is not assigned to a territory but ends up in the catch all territory.

Introduction 1-7

New in this Release

1-8 Oracle Territory Management Implementation Guide

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.2 Installation Verification

You can verify that your installation of Oracle Territory Management is working by creating a test territory and then testing it with a lead.

Before You Begin

2.2.1 Create a Territory

Responsibility

Oracle Sales Administrator

Before You Begin 2-1

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. In the Transaction Qualifiers tab, enter the qualifier name and criteria, such as

State = ’California’.

8. In the Resource tab, select resource name, team, and group information along

with the access type.

9. Click Save.

2.2.2 Run Concurrent Programs

Run the following concurrent request:

■ Generate Territory Packages for the Oracle Sales and TeleSales usage

2.2.3 Test with a Lead

Test using a lead in Oracle Sales Online.

Responsibility

Sales Online User

Steps

1. Create a lead that matches your territory definition.

2-2 Oracle Territory Management Implementation Guide

Oracle Territory Management Dependencies

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. (Required)

■ Resource Manager: Territory Manager uses resources defined in the Resource

Manager to assign resources to a territory. (Required)

Before You Begin 2-3

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"

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.

The implementation team enables seeded qualifiers used in your territories based on the planning decisions.

The territory administrator then begins the territory creation process, according to the implementation.

Implementation Overview

If you implement named accounts for sales, then the administrator creates territory groups, selecting named accounts, and assigning them to the top level of sales management. Sales managers in turn assign the named accounts to the salespeople or sales managers who report to them. The next level of sales managers in turn assign named accounts to their directs.

After territories are manually created, you can search and view territory hierarchies through either the Administration menu or the Navigator tree. The territory administrator must run the “Generate Territory Packages” concurrent program to generate territories before calling modules assign resources defined in your territories.

Implementation Overview 3-1

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.2 Phase II: Setting Up Territories

In Phase II, the territory administrator starts the territory creation process for all applications based on territory planning.

3.1.0.3 Phase III: Creating Named Account Territories

Phase III is optional. If you have sales territories and your planning includes the use of named accounts, then the territory administrator and sales managers use the self-service application to create named accounts and territory groups for sales.

3.1.0.4 Phase IV: Managing Territories

In Phase IV, the territory administrator manages territory changes, such as copying an entire territory or mass change territory resources if needed. In addition, the administrator can run territory reports to verify territory change information. See the Oracle Territory Management User Guide for more information.

After updating existing territories, the Generate Territory Packages concurrent program still needs to be run to generate the updated territories and named account territories as well.

Note: After territory creation or updates, your territory

administrator must run the Generate Territory Packages concurrent program to generate the correct and updated territories before a calling module can properly assign resources that are defined in your territories.

3.2 Implementation Task Sequence

The following table describes the order and process of implementing Oracle Territory Management.

3-2 Oracle Territory Management Implementation Guide

Implementation Task Sequence

T a b le 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.

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.

Table 3–2 Phase II: Setting Up Territories

Step Description Type Performed By

On paper Implementation

Te am

Enable Qualifiers Use qualifiers as the criteria to create a territory. Forms Implementor,

Create Territories Create territories for a variety of transactions.

For example: account, lead, opportunity, and service requests.

Run Concurrent Program Run the concurrent program "Generate

Territory Packages" after creating or modifying your territories.

This allows the system to compile the business rules defined during territory creation. If this step is not completed, the territories will not work correctly.

Table 3–3 Phase III: Creating Named Account Territories (Optional, Sales only)

Step Description Type Performed By

Enable Qualifiers you must minimally enable CUSTOMER

NAME RANGE and POSTAL CODE qualifiers.

Create a Parent Territory Create a territory to act as the parent for the

named account territories

Forms Implementor,

Territory Administrator

Implementation Overview 3-3

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.

HTML Implementor,

Territory Administrator

Assign Named Accounts to Salespeople

Run Concurrent Program Run the concurrent program "Generate

T a b le 3–4 Phase IV: Managing Territories

Step Description Type Performed By

Copy an Entire Territory Use to copy an entire territory hierarchy with or

Run Territory Reports Run reports to track your selections and

Sales managers assign named accounts to their direct reports

Territory Packages" after creating or modifying your territories.

This allows the system to compile the business rules defined during territory creation. If this step is not completed, the territories will not work correctly.

without resources, or copy a territory with resources that you are copying from.

changes.

HTML Sales Managers

Forms Implementor,

Forms or HTML

Territory Administrator

Implementor, Territory Administrator

3.3 Multi-Org

You are not required to set up territories by Operating Unit (OU) in a multi-org (MO) environment. You can create a World-Wide territory hierarchy by picking one OU and then creating all your territory definitions (for all countries) under that OU. This way your World-Wide hierarchy is visible under that single OU. This means you can create a single responsibility for that OU for your territory administrators.

The only reason you may want to define territories in separate OUs is if you are concerned about security and do not want users from different OUs to access one another's territory definitions.

The actual territory assignment is across all OUs. When you assign a transaction object, such as an Account, it looks at all territories: it does not care about the OU for the territory, only that it matches the territory qualifier values.

3-4 Oracle Territory Management Implementation Guide

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. Before using Oracle Territory Management, a territory planning team should be established to analyze the territory setup in your organization. This territory planning process needs enterprise-wide cooperation and feedback. Multiple territory revisions in the first months of operation should be expected as your enterprise discovers omitted information or territories that do not work on a day-to-day basis.

Phase I: Territory Planning

Based on your business needs, your team needs to determine the following:

■ Usage: What applications need territories

■ Transaction Type (which is based on usage): for example, leads, opportunities,

service requests, and delinquencies

■ How many territories are needed

■ What transaction qualifiers should be enabled

■ Who should be attached to the territories

■ What should the territory hierarchy structure be

Phase I: Territory Planning 4-1

Planning Your Territories

■ How many winners are allowed: A winner is the territory that receives the

■ 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. Review your existing territories.

transaction or customer.

You need the following types of information:

■ What is your usage? In other words, what business applications are you

building territories for? For example, sales, telesales, collections, or service.

■ What transactional objects within your chosen usage are you assigning

resources to? This is your transaction type. For example, for Sales, it is account, opportunity, or lead.

■ How are your territories currently assigned (by state, by industry, by zip

code, by account, and so on)?

■ Is Sales currently using named account territories, even if being manually

maintained?

■ What are the names and current territory assignments for your sales or

service personnel?

■ What are the names of employees in other organizations who receive

account, lead, and opportunity information and how is that information accessed and used?

4-2 Oracle Territory Management Implementation Guide

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. A territory

with a lower number wins over a territory with a higher number rank. In case of a tie, the assignment is made randomly.

6. Decide how many territories will win. For example, do you need one territory

to win, which can be appropriate for service, or multiple winners, which can be appropriate for sales?

7. Decide if named account territories are needed.

8. Test the strategy before implementing territories throughout the company and

consider any future territory maintenance efforts.

9. Consider future territory maintenance efforts.

Note: Remember that the first territory setup is not necessarily the

one that works best. You achieve optimum territory definition only gradually after much fine-tuning to accommodate user reactions and various interests in your organization.

Guidelines

In general, there is no limitation on territory creation. Create as many territories as you want for your business. However, in considering the purpose of future territory maintenance, for example, you need to modify territories due to sales, service, or support people changes or relocations, as well as organizational changes. You need to have a reasonable size of territories to minimize the efforts of territory management.

4.2 Sales Territory Planning Example

This territory planning example utilizes best practices for a fictitious company with a typical sales model involving named accounts and geographic territories with overlay sales organizations.

Phase I: Territory Planning 4-3

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. A product overlay sales force works with account managers and telesales reps based on what products a customer is interested in. Each account manager or telesales representative works with three overlay specialists, one for each product family. In planning for FY2004, Business World is expected to have the following:

■ US and Canada have separate sales forces

■ The direct sales forces manage their top 200 key accounts

■ The general business telesales forces manage their remaining customer pool

■ The overlay sales forces service all opportunities for a product family and

associated customers. There are 3 types of product specialists: Server, Desktop/Laptop, and Storage product specialists.

The following table shows the sales model:

Table 4–1 Sales territory model

US Canada Comments

Account Managers

15 account managers manage 150 large, key customers

Telesales Representatives

6 Telesales representatives in 6 geographic territories

4-4 Oracle Territory Management Implementation Guide

5 account managers manage 50 large, key customers

3 Telesales representatives in 3 geographic territories

Account manager territories encompass all leads and opportunities associated to a key customer.

Telesales representative territories encompass all leads and opportunities associated to a customer.

Table 4–1 Sales territory model

US Canada Comments

Sales Territory Planning Example

Overlay Product Specialists

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.

4.2.1 Step 1: What business objects are we assigning?

Which business objects (transaction types) are being assigned to each type of resource? Are we defining territories to access customers, leads or opportunities for account managers, telesales reps and product specialists? Do you need to provide read access only or update privileges as well? To what territory usage are the business objects associated?

Business World is going to assign customer, lead and opportunity transaction types for all territories assigned to account managers and telesales reps.

Product specialists service all opportunities for a product family and geographic location and their related customers (they are only allowed to view customer information).

Each account manager and telesales representative has a Server, Desktop/Laptop, and Storage product specialist.

Territories assigned to overlay product specialists will have a transaction type of opportunity because they need update privileges for opportunities. Oracle Sales products (Sales Online and TeleSales) provide, by default, read only access to customers if a resource is assigned to the sales team of any of the customer’s opportunities.

Investigate how to set up Oracle Territory Management business objects in conjunction with the Oracle Sales data security model. If you need update access to customers, leads or opportunities in Oracle Sales or Oracle TeleSales, then you will need to assign them in Oracle Territory Management.

4.2.2 Step 2: What qualifiers should we use?

We enable the following qualifiers:

Phase I: Territory Planning 4-5

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.

■ STATE, to create geographic “Catch All” territories for overlay product

specialists

■ OPPORTUNITY EXPECTED PURCHASE, to create overlay territories for

product specialists.

Review Section 4.2.14, "Appropriate Choice of Qualifiers" to analyze your particular situation in greater detail.

4.2.3 Step 3: Territory hierarchy - Define date effectivity and number of winners

The hierarchy is largely designed for ease of maintenance and for the creation of “Catch All” territories. Hierarchies allow you to inherit qualifier rules and territory properties such as date effectivity and number of winners. Catch alls will be discussed later in Step 4.

Under the Sales and TeleSales usage, we need to create a top-level territory representing Business World’s FY2004 Sales territories. This FY2004 Sales territory will be effective from January 1, 2004 and does not have any transactional qualifiers or resources. It is the top of the FY2004 Sales territories and is used to maintain the date effectivity of all territories underneath it and is used to set the number of winning territories (number of winners = 1).

4-6 Oracle Territory Management Implementation Guide

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. These 2 territories will also serve as “Catch Alls” for exceptions of the assignment process. These are important because customers, leads or opportunities that do not find matching leaf node territories will fall into these “Catch All” territories based on their country qualifier and can be assigned to a designated owner (e.g., typically the territory administrator) for resolution. The territory administrator should have customer, lead and opportunity access.

Sales Territory Planning Example

Catch Alls are used to “catch” business transactions that fall through the cracks (leaf node territories) and usually are assigned to territory administrators. To be more exact, they “catch” all business transactions that fall into the catchall territory itself or any territory below it in the hierarchy that does not have a resource.

It is recommended that you use the term “Catch All” in the naming of these territories to help visually distinguish this type of territory.

Phase I: Territory Planning 4-7

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. We create two territories under the US Catch All territory:

■ “US Named Accounts”, with no transactional qualifiers or resources

■ “US Geographies”, with no transactional qualifiers and typically with the

territory administrator as the resource in case zip codes are missing.

Similarly, Canada has 2 territories called CAN Named Accounts and CAN Geographies underneath the CAN Catch All territory.

4.2.6 Step 6: How to implement named account territories

From a business perspective, there are various types of territories. Organizations will pull particular customers from the general pool that they deem as critical and assign a specific resource to it. These are termed “named accounts”. In an attempt to organize the remaining pool of customers, general business customers are segmented by a simple criteria such as SIC code, state or area code.

Named account territories have rules utilizing the CUSTOMER NAME RANGE qualifier. For example, if IBM is a named account you define a territory with CUSTOMER NAME RANGE like ‘IBM%’ and CUSTOMER NAME RANGE like ‘International Business Machines%’. This assigns IBM to the account manager regardless of how many customers exist begin with IBM or International Business Machines.

The US direct sales force consists of 15 account managers, each responsible for a territory of large key accounts. There will be 15 US named account territories as children of the US Named Accounts territory, one for each account manager. Similarly there will be 5 Canadian named account territories as children of the CAN Named Accounts territory.

Lowest level territories or leaf node territories should always have resources assigned to them and therefore also require access types to be defined. All account managers are associated to territories with customer, lead and opportunity

access. See Section 4.2.14, "Appropriate Choice of Qualifiers" for a discussion on the

selection of qualifiers for named accounts.

4-8 Oracle Territory Management Implementation Guide

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.

The US and Canada each have separate general business telesales forces responsible for all remaining non-named accounts in a particular geography. The US will have 6 geographic territories as children of the US Geographies territory. Canada will have 3 geographic territories as children of the CAN Geographies territory. Each geographic territory will have transactional qualifier rules of the contained zip codes or postal codes and be assigned to a general business telesales representative.

All telesales reps will be associated to territories with customer, lead, and opportunity access.

Sales Territory Planning Example

Phase I: Territory Planning 4-9

Sales Territory Planning Example

4.2.8 Step 8: How to support overlays

We recommend that you implement Overlays in a separate territory hierarchy. The desired business behavior is to find:

4-10 Oracle Territory Management Implementation Guide

Sales Territory Planning Example

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. With a separate FY2004 Overlay hierarchy and number of winners set to one, Territory Manager selects a single overlay territory.

Under the sales usage, you will need to create another top-level territory representing Business World’s FY2004 Overlay territories. This FY2004 Overlay territory will be effective from January 1, 2004 and does not have any resources.It does have transaction qualifier rules to distinguish it as an overlay hierarchy, for example:

OPPORTUNITY EXPECTED PURCHASE = ‘SERVER’, OPPORTUNITY EXPECTED PURCHASE = ‘DESKTOP’, OPPORTUNITY EXPECTED PURCHASE = ‘LAPTOP’, OPPORTUNITY EXPECTED PURCHASE = ‘STORAGE’. It is the top of the FY2004 Overlay territories and is also used to maintain the date

effectivity of all territories underneath it and is used to set the number of winning territories. Note the OPPORTUNITY EXPECTED PURCHASE qualifiers are necessary to distinguish these territories from Business World’s geographic telesales territories.

What transaction types should the territories assign? Product specialists work opportunities so we are going to assign opportunity transaction types for all overlay territories.

4.2.9 Step 9: What is an appropriate territory hierarchy for overlays?

We have separate sales forces for the US and Canada so we will create 2 child territories underneath FY2004 Overlay: one called USA Overlay with a transaction qualifier rule COUNTRY = ‘UNITED STATES’ and another called Canada Overlay with transaction qualifier rules COUNTRY = ‘CANADA’.

Do you require Catch All territories and how are they organized? If Catch All territories are required, these need to be reflected in the hierarchy.

Phase I: Territory Planning 4-11

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.

Overlay territory hierarchy BY GEOGRAPHY

4-12 Oracle Territory Management Implementation Guide

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 = ‘AK’, STATE = ‘WI’, and so on, and resource qualifier = Central Overlay territory administrator

■ “US West Overlay Catch All”, with transactional qualifier rules STATE = ‘CA’,

STATE = ‘NV’, STATE = ‘OR’, STATE = ‘WA’, and so on, and resource qualifier = Western Overlay territory administrator

Similarly underneath the Canada Overlay territory, we create three territories:

■ “Server CAN”, with the transactional qualifier rule OPPORTUNITY

EXPECTED PURCHASE = ‘SERVER’ and resource = Canadian server specialist

■ “Desktop CAN”, with the transactional qualifier rule OPPORTUNITY

EXPECTED PURCHASE = ‘DESKTOP’ and OPPORTUNITY EXPECTED PURCHASE = ‘LAPTOP’ and resource = Canadian desktop/laptop specialist

■ “Storage CAN”, with the transactional qualifier rule OPPORTUNITY

EXPECTED PURCHASE = ‘STORAGE’ and resource = Canadian storage specialist

As Canada has a smaller number of customers, three product specialists cover the entire country, one for each product family.

The US overlay sales force consists of 9 product specialists, each responsible for a territory of product family and geography. As there is no fixed teaming of account managers or telesales reps to product specialists, we have chosen to implement the overlays separately as children of the country overlay territory. There will be 9 US overlay territories as children of the US Overlay territory, one for each product specialist. Each specialist will cover one of three geographies: East, West, or Central.

All product specialists will be associated to territories with customer and opportunity access.

Phase I: Territory Planning 4-13

Sales Territory Planning Example

Alternative overlay territory hierarc hy 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:

■ “US Server Catch All”, with the transactional qualifier rule OPPORTUNITY

EXPECTED PURCHASE = ‘SERVER’ and resource = Server territory administrator

4-14 Oracle Territory Management Implementation Guide

■ “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 Catch Alls.

4.2.10 Step 10: What rank should each territory have?

To the left of all the territory names in Figures 1, 2 and 3, is the rank of each territory. Named account territories are always ranked higher than geographic territories because a named account in California should fall in a named account territory and not the geographic territory that includes California. Catch Alls are always ranked lower than their associated territories. See Section 4.2.13, "Leverage

Territory Ranking and Number of Winners" for a detailed discussion of territory

rankings.

Sales Territory Planning Example

4.2.11 Step 11: Have you met all your business requirements?

Stand back and review your business requirements for sales territories. Ensure your territory implementation has met all your business requirements. How will you validate your territories are correct? Create and enable your territories on a test environment. Ensure you have an implementation plan in place that involves systematic validation and user acceptance testing. Don’t forget about your ongoing maintenance requirements. See Section 4.2.16, "Migrating Territories" for a discussion on how to migrate territories from one year to the next.

For any implementation to succeed in the long run, clear and consistent business processes should be implemented to complement your territory setup.

4.2.12 Leverage Territory Hierarchies and Inheritance

Territory hierarchies do more than organize your territories. They also organize your transactional qualifier rules, critical to improving the ease of maintenance. Child territories always inherit transactional qualifier rules.

If you are building a set of 100 representative territories exclusive to the US, it is a best practice to introduce a hierarchy layer representing countries which should include the transactional qualifier rule “Country = United States”. In this manner,

Phase I: Territory Planning 4-15

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. Assigning a resource to “Catch All” territories will route customers, leads and opportunities to the designated resource for resolution. Catch alls are typically assigned to territory administrators.

4.2.13 Leverage Territory Ranking and Number of Winners

Territories do not need to exclude overlaps via transactional qualifier rules (using the NOT operand). It is far better to rank your territories and properly set up the number of winners. The number of winners refers to the number of winning territories allowed and is defined once at the top-level territory only, for example, FY2004 Sales territory in the Business World example. Territory rankings work in conjunction with the number of winners = “w” by selecting the top ranked “w” territories. When a territory is found to have won all resources of the winning territory are assigned to the business object.

A good example of this is the difference between named account territories and geographic territories. You don’t want to have to maintain the exclusion of named accounts from the geographic territories explicitly. Rather, you would set the number of winners to one and use the customer name range qualifier in the named account territories and rank these higher than the geographic territories utilizing postal code qualifier. The territory engine finds that both territories match but the number of winners and rankings dictate that the higher ranked named account territory wins.

4.2.14 Appropriate Choice of Qualifiers

Named account qualifier choices are customer name range and customer name. The customer name qualifier identifies TCA (Trading Community Architecture) organizations through the Party ID. The customer name range qualifier identifies TCA organizations through exact or partial name matches. Unless you have strict data quality management policies in place and there is only one occurrence of each customer, we recommend that you use the CUSTOMER NAME RANGE qualifier for named accounts.

Be careful not to confuse SIC code, geographic, etc. territories from named accounts. Many organizations will attempt to implement geographic or SIC code based

4-16 Oracle Territory Management Implementation Guide

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. Implementing a Telecom territory as 20,000 named accounts would require a minimum of 20,000 CUSTOMER NAME RANGE qualifier rules. Clearly, it would be better implemented as a territory with 50 SIC CODE qualifier rules. In release 11.5.8 of Territory Manager, there is a diagnostic test within the Oracle Diagnostic Framework for this.

■ How many named accounts does a typical resource have? If sales management

claims their reps have any more than a hundred named accounts, they are likely to have incorrectly implemented a simple territory as named accounts. Investigate how the business derived the set of named accounts. Typically, reps do not have the bandwidth to manage more than 100 named accounts and give them the proper attention associated to critical customers.

■ Does your business qualifier fluctuate in the context of the business object you

are assigning? Does it segment customers periodically based on a dynamic business qualifier? It is important to examine the fluctuation of the dynamic qualifier in the context of the business object you are assigning. For instance in the credit card industry, customers are segmented by their total A/R balance every quarter into three territories (e.g., <$250k, $250k-$500k, >$500k) and customers maintain their segmentation even though their balances change.

In these cases, we recommend that you designate account classifications based on the dynamic qualifier periodically and then use the account classification qualifier in Territory Manager.

Using named accounts in lieu of geographic territories is an ineffective way to distribute a representative’s territory. It is ineffective in terms of Territory Manager performance, scalability and ease of maintenance. 20,000 customers are segmented by the number of employees quarterly into three territories (e.g., <100, 100-1000, >1000 employees). Instead of maintaining three qualifier rules based on the number of employees qualifier, you are maintaining a minimum of 20,000 customer name range qualifier rules. Territory assignment performance is directly correlated to the number of qualifier rules. Territory assignment will be slower with 20,000 qualifier rules than with three.

Phase I: Territory Planning 4-17

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. To aid our best practices, we will be decommissioning the NOT operand and a

diagnostic test exists within Oracle Diagnostic Framework.

■ The use of the % wildcard as the first character of the qualifier value prevents

the use of indexes.

4.2.16 Migrating Territories

For how long are your territories active? Your sales organization may migrate to new territories yearly or quarterly and you want to use the existing territory hierarchy as a starting baseline. By following best practices, it will be easier to migrate territories to the next period. The trick is to define a territory start date at the top level territory, since all those below it will be gated by the start date property. Copy the top-level territory, which will automatically copy all the child territories as well. Rename the top-level territory and give it a new start date. Don’t forget to go back to the old territory hierarchy and end date the top-level territory.

4.3 Sales Territory Qualifiers

The following table maps the sales qualifiers to their Sales Online and Telesales counterparts.

Table 4–2 Sales Qualifiers

Transaction Type Territory Qualifier Sales Online/TeleSales Attribute

Account Account Classification Interest of "party site"

Account Account Code Customer Name + Address (party

4-18 Oracle Territory Management Implementation Guide

site ID)

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 Code

Account Province Province

Account SIC Code SIC Code

Account Sales Partner Of Partner Of

Account State State

Lead Budget Amount Budget

Lead Lead Expected Purchase Product Category

Lead Lead Inventory Item Inventory Item

Lead Lead Promotion Identifier Source Name

Lead Purchase Amount Amount

Opportunity Opportunity Channel Sales Channel

Opportunity Opportunity Classification Classification

Opportunity Opportunity Expected

Purchase

Opportunity Opportunity Inventory Item Inventory Item

Opportunity Opportunity Status Status

Opportunity Total Amount Total

Product Category

Phase I: Territory Planning 4-19

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 Territory Qualifie r Mapping to Oracle Service

Contact Preference

Customer Site Service Request Not currently used by SR

Group Owner Service Request Group Field on SR Form. Derived

Inventory Item Service Request Item field in SR form. Derived

Platform Service Request Platform field in Product

Primary Platform

Problem Code Service Request Problem Code field in Workbench

Product Service Request Item field in SR form. Derived

Product Category/ Product

Request Creation Channel

Request Severity Service Request Severity field in SR form.

Service Request Communication Preference on SR

Form. Derived from ar_lookups

from JTF Tables.

from Inventory.

Coverage tab of SR form. Derived from Inventory.

Service Request

Tab. Deri ved f rom CS_ LOOK UPS

from Inventory.

Service Request Category field in SR header.

Derived from Inventory.

Service Request Channel field on SR Form.

Derived from CS_LOOKUPS

Request Status Service Request Status field in SR form.

Request Type Service Request Type field in SR form.

Request Urgency

Service Contract Coverage

4-20 Oracle Territory Management Implementation Guide

Service Request Urgency field on SR Form.

Service Request Coverage Field on SR Form.

Returned by Contracts API.

Service Territory Qualifiers

Table 4–3 Sales Qualifiers

Transaction Type Territory Qualifie r 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

VIP Customers Service Request Not currently used by SR

Account Code Account Customer Name + Address of

Area Code Account Same from address of customer on

City Account Same from address of customer on

Country Account Same from address of customer on

County Account Same from address of customer on

Customer Name Account Organization

Customer Name Range

Number of Employees

Postal Code Account Same from address of customer on

Province Account Same from address of customer on

Account Organization

Account Total Employees of customer

from JTF Tables.

customer on a SR or Task

a SR or Task

State Account Same from address of customer on

Task Prio rit y Task Task Prio rity o f tas k

Task Sta t us Ta sk Task Stat us of task

Task Type Ta sk Task Type o f task

a SR or Task

Phase I: Territory Planning 4-21

Service Territory Qualifiers

4-22 Oracle Territory Management Implementation Guide

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.6, "Creating Individual Territories"

■ Section 5.7, "Entering Transaction Qualifiers"

■ Section 5.8, "Entering Resource Qualifiers"

■ Section 5.9, "Specifying Resources for a Territory"

■ Section 5.10, "Adding Subterritories"

■ Section 5.11, "Running Concurrent Programs"

5.1 Overview of Creating Territories

A territory defines who owns what. The who is the resources assigned to the territory. The what is the business object, such as leads, service requests, customers, and delinquencies. Qualifiers are used to define both.

Phase II: Setting Up Territories 5-1

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.

Operator Use operator to connect a qualifier name and its values to make a qualifier

meaningful. The operator’s list of values (LOV) depends on the data type of the qualifier. Possible values are =, < >, >, <, >=, <=, Like and Between. The default value for this field is "=".

Value The selection from the LOV in this field is based on the selected qualifier.

5.2.1 Transaction Qualifiers

Transaction Qualifiers are used to specify the criteria about how the territory module assigns resources to transactions. It is the first key decision point when Assignment Manager tries to assign resources to a document or a task.

For example, use area code, postal code, company name, or opportunity channel as the criteria to help assign qualified resources for transaction needs.

Different territory usages, like Oracle Sales or Service, use different sets of transaction qualifiers and those transaction qualifiers are grouped by transaction type. For example, a sales or telesales territory has three predefined transaction types: Account, Lead, and Opportunity. Some examples of transaction qualifiers within the Account Transaction Type are company name, area code, and postal code. Opportunity channel is one transaction qualifier for the Opportunity Transactio n Type .

Note: You must enable transaction qualifiers before using them.

5.2.1.1 Sample List of Seeded Transaction Qualifiers

Territory Manager includes seeded qualifiers for the following CRM modules:

For example, the LOV for the request status qualifier can be Open or Closed. If the qualifier is area code, then manually enter this field, for example, 408, 415, and so on.

5-2 Oracle Territory Management Implementation Guide

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 Ty pe Qualifier Type Qualifier Name

Defect Management Defect Transactions Product

Sales Account Customer Name Range

Trade Ma n age ment Trade Accou nt Stat e

Service Service Request Request Type

5.2.1.2 Customer Name and Customer Name Range,

Among all the transaction qualifiers, there are three which should be explained to avoid confusion:

■ Customer Name

■ Customer Name Range

Customer Name

This transaction qualifier defines a customer name.

Customer Name Range

In contrast to a Customer Name qualifier, a Customer Name Range qualifier is used to indicate more than one customer (or customer names) by entering appropriate values. This qualifier captures a range of the business names.

Example

Business World Worldwide has the following branches and subsidiaries: Business World Motor, Business World Book, Business World Service, USA Business World, Russia Business World, and UK Business World. You can use the Customer Name Range qualifier to group similar customer names together by using the following values:

Phase II: Setting Up Territories 5-3

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. These qualifiers act as filters which define resource selections.

For example, if you are looking for specific resources who speak Italian for your customer needs, then the resource qualifier can be identified as "Language = Italian.” This aids in selecting resources that qualify for your condition.

You can still make selections from the qualified resources suggested by the resource qualifier before assigning them to a territory.

There is no need to specify the resource qualifiers if you know exactly which resources are needed for a certain territory. Instead, identify the resource names on the Resources tab of the Territory Details window.

5.2.3 Using Qualifiers

Why Use Transaction and Resource Qualifiers?

After understanding the concepts of transaction qualifiers and resource qualifiers, it is easier to understand how a territory works. A territory uses resource qualifiers to filter resources that you want to attach to a territory. A territory uses transaction qualifiers and values to determine if a territory can win in that transaction. If the territory happens to win, then the resources attached to the territory can be assigned to the transaction.

5.2.3.1 Seeded Qualifiers

Territory Manager provides a large number of seeded qualifiers for Oracle Defect Management, Oracle Sales and Marketing, Oracle Service, Oracle Collections, and Oracle Trade Management.

5-4 Oracle Territory Management Implementation Guide

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. This West Coast territory and the three subterritories have the parent-child relationship.

Features of a Child Ter ritory (Subterrito ry)

To help maintain integrity in the hierarchy, each child territory logically inherits the qualifiers and values of the parent territory. Also, additional qualifiers and values can be added.

5.4 Territory Winning Rules

Territory Manager uses the Number of Winners field set to the top level of territory hierarchy to determine the winning territories. This field cannot be entered if it is not the top level territory.

Territory Winning Rules

Territory winning rules are used in several different ways in the Oracle E-Business Suite. For example, Oracle Service tends to enter ONE in the Number of Winners field, which helps to select the most qualified resources for the service requests.

Multiple winners are commonly used in Oracle Sales to meet the business needs, but a single winner is also used in Sales. If the Number of Winners field is not set, then the number of winning territories defaults to one for the hierarchy under that top-level territory.

There are two possible outcomes based on values entered in the Number of Winners field:

One Winner

If you enter 1 in the Number of Winners field in the Overview tab, then Territory Manager assigns the transaction to a single territory in the territory hierarchy.

Use the territory ranking mechanism for breaking ties between wining territories. The highest rank of competing territories (which is represented by a lower number)

Phase II: Setting Up Territories 5-5

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. However, if there are three territories that qualify for the criteria, but it can only have two winners, then ranking determines the final two winners among the three territories.

Note: Only the territory that has resources attached can be a

winning territory.

Rank

Rank is used to specify the priority of a territory among multiple winners. The choice is only random if no rank has been defined. The lowest rank of competing territories wins at the same level in the hierarchy. For example, from rank 1 to 10 for the same hierarchy level, rank 1 has the highest priority.

Example

The following example shows how zip codes are used to set up three overlapping territories:

Territory 1: zip code Between 90001 and 90051 Territory 2: zip code Between 90020 and 90070 Territory 3: zip code Between 90049 and 90052 Note that the transaction value: zip code = 90050 The previous three territories are all qualified for this transaction. If the Number of

Winners is set to ONE, then the single winning territory in the following both situations is:

■ Condition A:

– Territory 1: Rank 2 – Territory 2: Rank 3

5-6 Oracle Territory Management Implementation Guide

– 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.5 Enabling Existing Qualifiers

Territory Manager has seeded qualifiers for the following usages:

■ Collections

■ Defect Management

Enabling Existing Qualifiers

■ Sales and Marketing

■ Service

■ Service Contracts

■ Trade Management

Before using a transaction qualifier, you need to enable it. Territory Manager provides a large number of seeded qualifiers for Collections,

Defect Management, Sales and TeleSales, Service, Service Contracts, and Trade Management. In general, qualifiers are used by the Assignment Manager or Scheduler to assign qualified resources for transactions. Unlike the transaction qualifiers classified by the territory usage, resource qualifiers are shared throughout the application regardless of territory usage except for Service Contracts and Collections. Therefore, you do not need to enable them.

Perform the following steps to enable the existing transaction qualifiers.

Prerequisites

None

Phase II: Setting Up Territories 5-7

Enabling Existing Qualifiers

(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.

2. Select the Usage drop-down list.

3. Highlight your selection and click OK.

The Setup Qualifier window opens.

The Select Usage window opens.

The Setup Qualifier window opens and the Usage Field is populated with your selection.

4. Select Find.

You can also select appropriate qualifier status (Enabled, Disabled or All) before finding them. Note that all resource qualifiers are not listed here.

5. Select (or deselect) the targeted qualifiers and select Update Qualifiers.

Guidelines

For service territory even if Account transaction qualifiers are enabled, you won’t be able to see Account from the Transaction Type LOV. The Account transaction type is used as subsets of Task or Service Request (usage). This forces you to tie account qualifiers to either Task or Service Request.

The “Service Request and Task” transaction type means tasks are created through a service request. If it is a stand-alone task, use the “Task” transaction type instead.

5-8 Oracle Territory Management Implementation Guide

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.

Responsibility

CRM Administrator

Navigation

Territory Manager > Territory Administration > Administration > Define Territory Right-click the parent territory from the Tree Navigator and select New

Creating Individual Territories

Steps

1. In the Overview tab, select an appropriate organization in the Organization

field if multiple organization (Multi-Org) is considered while creating territories.

Note: When multiple organization is considered while creating

territories, use the Organization field to identify the appropriate level for your territory creation. You can create territories at the top organization level (Vision Corporations) or at a specific operating unit level. For example, use the “MO: Operating Unit” profile option to set at the responsibility level that the territory administrator has logged in with.

2. Use the list of values (LOV) in the Usage field to select the type of application

that will use this territory. Your selection limits the types of qualifiers that can be used in the territory definition.

Phase II: Setting Up Territories 5-9

Creating Individual Territories

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. Enter an appropriate number in the Number of Winners field.

8. (Optional) If you have created an escalation territory for this territory, then

enter it using the LOV in the Escalation field.

9. (Optional) If you want to use an existing territory type to create this territory,

then use the LOV to enter it in the Type field.

10. Use the Transaction Types LOV to select one or more types of transactions

based on the territory usage. Note that some application types allow you only one transaction type.

Note: If you use a territory type, then you are restricted to using

the qualifiers set up in that territory type.

11. Leave the Freeze check box unchecked.

12. Click Save from the toolbar to save the territory overview information.

Guidelines

Relationship Between Usage, Transaction Types, and Transaction Qualifiers

The territory usage is tied to the application, such as Sales and TeleSales, Service, or Trade Management. Each application uses its specific sets of transaction qualifiers for their unique business needs and these transaction qualifiers are grouped by transaction type.

For example, a territory created for Sales and TeleSales usage has three seeded transaction types: account, lead, and opportunity. While a territory created for Service usage can only see task, service request, as well as “task and service request” shown in the Transaction Type field.

5-10 Oracle Territory Management Implementation Guide

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.

If task transaction type is selected in a service territory (Service usage), then you can only see the task related transaction qualifiers, such as task type, status, and priority shown in the Transaction Qualifier name list of values.

Therefore, territory usage limits the selection for transaction types, and the selection of transaction qualifiers is based on the selected transaction types.

Territory Winning Rules

Oracle Territory Management uses the Number of Winners field (only set at the top level of a territory hierarchy, such as the top-level territory directly under Oracle Service) to determine the number of winning territories. This field is protected if it is not the top-level territory and an error message appears if you attempt to enter a value when it is not appropriate.

Rank is used to specify the priority of a territory among multiple winners. The choice is only random if no rank has been defined. The lowest rank of competing territories wins at the same level in the hierarchy. For example, for rank 1 to 10 for the same hierarchy level, rank 1 has the highest priority.

5.7 Entering Transaction Qualifiers

Use the Transaction Qualifiers tab to enter transaction qualifier names and their values based on the transaction types selected in the Overview tab.

Transaction qualifiers are criteria used to determine the winning territory (the territories win among competitive territories). This is the first major decision point when the Assignment Manager tries to assign resources to a task.

Transaction qualifiers serve as the “if” clause. If an object qualifies for a territory, then the resource assigned to the qualified territory will be selected for a transaction (a service request, or task). For example, use area code, postal code, company name, or opportunity channel as the criteria for a transaction to determine winning territories first. Then the resources assigned to the winning territories can be assigned for the transaction.

Phase II: Setting Up Territories 5-11

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

Responsibility

CRM Administrator

Navigation

Territory Manager > Territory Administration > Administration > Define Territory Double-click the territory in the Tree Navigator

Steps

1. (Optional) If this territory is part of a hierarchy of territories, then in the

Transaction Qualifiers tab click Show Inherited Qualifiers to examine which qualifiers this territory has inherited from its parent territory or territories.

2. In the Name field enter the qualifier name you are going to use in the

Transaction Qualifiers region. The transaction type populates automatically in the Type field for the selected qualifier name.

3. If you have used a territory type to create this territory, then the qualifiers are

already prefilled.

4. If you want to enter overlapping values for a qualifier, then check the Overlap

Allowed check box.

5. Enter at least three letters to bring up the LOV in the Value From and Value To

fields. For example, enter "Bus" to launch the LOV starting with "Bus". If wildcard "%" is used, then use it with letters, such as "B%%", or "%%%" to query the list of values.

6. Click Save from the toolbar to save the transaction qualifier information.

Note: The Next Value Set, and Mass Create Territories buttons,

as well as the Mode field are used only in territory templates.

5-12 Oracle Territory Management Implementation Guide

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.

For example, use “Job Title = Manager” to help you identify resources with manager title if you don’t know the exact names of those who have manager’s job titles when defining a territory.

After the resource qualifiers are identified, you can click the Auto Assign Resources button in the Resources tab to retrieve qualified resource names based on the resource qualifiers.

Note: Resource qualifiers are criteria that are used specifically for

resource selections while defining territories. They are not used in determining which territory wins among competition for a transaction. That is determined by the transaction qualifiers.

You do not need to enter this tab if you know exactly which resources you want to use while creating your territory.

Entering Resource Qualifiers

Unlike transaction qualifiers, the availability of the resource qualifiers is not limited by the usage and transaction types that you chose for a territory.

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

Responsibility

CRM Administrator

Navigation

Territory Manager > Territory Administration > Administration > Define Territory

Phase II: Setting Up Territories 5-13

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.

Note: The Next Value Set, and Mass Create Territories buttons,

as well as the Mode field are used only in territory templates.

5.9 Specifying Resources for a Territory

Use the Resources tab to specify resource information in a territory. It is important to use this tab because only territories that have resources attached to them can be winning territories. Therefore, after a resource is added to a territory for the first time, you must run the Generate Territory Packages concurrent program. Resources assigned to territories in this tab can be any CRM resource defined in the Resource Manager. They can be employees, salespeople, groups, teams, parties, partners, and supplier contacts.

There are two ways to identify resources while defining a territory. Manually Assign Resources: This is used if you know exactly which resources you

are going to assign to a territory. You do not need to use the Resource Qualifiers tab to guide you for the resource selection. Instead, use the Resources tab to enter the resource in the Name field. The resource type populates automatically.

Auto-Assign Resources: This is used if you do not know the resources that you want to assign to a territory, or you may have a large pool of potential names.

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

5-14 Oracle Territory Management Implementation Guide

Specifying Resources for a Territory

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. If the Resource Qualifiers tab is used (Auto-Assign Resources), then perform

the following steps:

a. Click Auto Assign Resources if resource selection criteria are entered in the

Resource Qualifiers tab. The Qualifying Resources window displays a list of people that fit the

resource qualifier’s values you have entered.

b. Select the people you want to assign to this territory by checking the Assign

check box next to their names.

c. Click OK and return to the Resources tab.

Note: If no people or the wrong people are found, then go back to

the Resource Qualifiers tab and enter a different set of resource qualifier values, or select resources manually in the Resources tab.

3. Check the Primary Contact check box next to the resource who becomes the

primary contact for the territory.

4. For each resource you can add start and end dates to limit their participation.

5. For each resource, select the transaction types you want them to access in the

Access Type field.

Phase II: Setting Up Territories 5-15

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. For example, if the access type is Lead, the resource can be assigned only to Lead and Account. The resource cannot be assigned to an Opportunity.

5.10 Adding Subterritories

Use this procedure if your territory hierarchy includes territories under the current territory.

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

Responsibility

CRM Administrator

Navigation

Territory Manager > Territory Administration > Administration > Define Territory Double-click the territory in the Tree Navigator

Steps

1. Click New Subterritory and repeat the territory creation procedure for the new

sub-territory.

5-16 Oracle Territory Management Implementation Guide

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.

Table 5–2 Seeded Concurrent Programs

Name Function Frequency

Running Concurrent Programs

Generate Territory Packages

Named Account Territo r y Post Processing

Prerequisites

None

Responsibility

CRM Administrator

■ 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.

■ Builds the API that returns the

winning territories and resources attached to the winning territories, which are defined in territory setup.

■ Kicks off named account catchall

workflow processing

■ Refreshes territory administration

portals for Sales

As often as you need to activate territory changes, for example, nightly

As often as you want the numbers in the catch all portlet updated and workflows run

Phase II: Setting Up Territories 5-17

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.

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.

Named Account Territory Post Processing uses two parameters:

■ Run the Workflow: choose either yes or no

■ Name of the Bin: Select the bin to be calculated. Your options are:

■ All

■ Catchall Bin (Catchall portlet)

■ KPI Bin (Key Performance Indicator portlet)

■ None (Select to run workflow only)

5-18 Oracle Territory Management Implementation Guide

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.7, "Defining Named Account Rules"

■ Section 6.8, "Assigning the Sales Team to Named Accounts"

■ Section 6.9, "Running Concurrent Programs"

■ Section 6.10, "Usage Implementation"

6.1 Overview of Creating Named Account Territories

Named accounts are centrally defined, associated to sales groups, and distributed from the top down to individual salespersons. Named account territories apply to the Sales and TeleSales usage only.

A company can have multiple sales forces each with their own roles, exception handling rules, sales hierarchies, and sets of named accounts. These are loosely associated to territory groups. Planning considerations should be evaluated in the determination of territory groups.

Phase III: Creating Named Account Territories 6-1

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.

Territory groups are associated to sales groups within the sales hierarchy and distributed top down to individual salespeople.

Greater named account accuracy is achieved through a division of tasks to the most appropriate user. Territory administrators are responsible for centrally managing territory groups and defining named accounts. Sales management is responsible for assigning named accounts down the sales hierarchy.

Behind the scenes, a concurrent program generates a set of sales territories similar to those created manually in the Oracle Territory Management Forms windows. The application generates a single territory for each named account utilizing the definitions (customer name range and postal code values) maintained by territory administrators and assigns salespersons as defined by sales management. This generation is part of the Generate Territory Packages concurrent program used to enable territories.

6.1.1 Components of Self-Service Named Accounts

There are two components of self-service named accounts:

■ Named Accounts: Those customers that have been identified by a division as

important or critical enough to have their own account teams.

■ Territory Groups: Each division has its own set of named accounts. For instance,

each division or line of business will have its own sales organization, its own set of named accounts, and its own business processes. We loosely associate lines of businesses or divisions to "territory groups." Each territory group will be associated to a particular sales force and have its own set of named accounts with its own business policies and processes. The territory group is assigned a parent territory already set up in the Forms application. When Generate Territory Packages is run for Sales and TeleSales, the territory group becomes a single level territory hierarchy inserted into an existing territory hierarchy.

6.1.2 Ongoing Maintenance

New hires, fires, and to be hireds require sales managers to update named account assignments throughout the selling year. Any change to named account assignments can be made by sales managers at any time.

6-2 Oracle Territory Management Implementation Guide

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. Typical problems are:

■ An incorrect postal/zip code on a correct business name. The fix is to correct

the address.

■ A missing subsidiary of a named account. The fix is to add a named account to

a territory group and have it assigned or refine a named account definition to include the new postal code.

Oracle Workflow can be used to automate the exception handling of both these problems.

Occasionally, new named accounts are added or moved between divisions. These changes are managed by territory administrators following each business's checks and balances. Removing named accounts from a territory group immediately unassigns the sales teams.

6.1.3 Annual Maintenance

Before the start of the new sales year, existing territory groups can easily be copied and changes made for the new selling year by territory administrators.

Once active, named accounts can be distributed down the sales hierarchy in an efficient and effective manner, making it possible to reduce territory set ups and implementations to a minimum.

The bulk of named account definitions are created by territory administrators when you first migrate to the new named account territories. After that, only new named accounts require named account definitions. It is unlikely that your list of key customers is going to change drastically from year to year, which again minimizes your territory setup times.

6.1.4 Territory Autogeneration Mechanics

Territories are composed of qualifier rules and resources. Qualifier rules are derived from centralized named account definitions: specifically customer name range and postal qualifier rules. Resource assignments are derived from the self-service assignments made by sales managers. Taking information from two user bases (e.g.,

Phase III: Creating Named Account Territories 6-3

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.

Generated territories have the following structure:

Administrators can review the read-only generated territories via the Forms interface. Existing geographic based territories managed through the Forms interface will continue to be supported and require no changes to work with the new self-service named account management solution.

6.2 Named Account Territory Process

The process for setting up named account territories includes the following steps:

1. At the beginning of a sales planning cycle, upper management assigns a set of

named accounts to a sales VP of a division.

2. Sales operations is responsible for creating a "territory group" modelling the

named account process of a division.

3. Transactions falling to Catch Alls can be assigned to territory administrators or

IT can develop workflows to manage exception handling of customers, leads, and opportunities.

4. Sales managers under the VP then distribute all named accounts top down until

every named account is assigned to a lowest level salesperson.

5. At the same time, territory administrators are responsible for creating a named

account definition to capture other customers, leads, and opportunities equivalent to the same named account. This is done by defining customer name range and postal code qualifier rules. Named account definitions or territory rules are defaulted to CUSTOMER NAME RANGE = business name of the account and POSTAL CODE = postal code of the account. Territory administrators can also add alias CUSTOMER NAME RANGES and other postal codes or postal code ranges. It is important to note that these named account definitions can be continually refined as they are set up once and cross selling years.

6-4 Oracle Territory Management Implementation Guide

Migrating from Existing Territories to Named Account Territories

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. These read-only, generated territories can be reviewed by territory

administrators from the Forms interface and are used just like any other manually created territories for real-time and batch territory assignment.

9. Territory administrators diagnose and fix transactions falling to their named

account Catch Alls.

6.3 Migrating from Existing Territories to Named Account Territories

Perform the following steps to migrate from territories created using the Forms user interface to the self-service named account territories.

1. Territory administrators should ensure the CUSTOMER NAME RANGE and

POSTAL CODE qualifiers minimally are enabled. Other qualifiers you wish to use in the parent territory, like COUNTRY, should also be enabled.

2. Territory administrators need to create a parent territory in the Forms interface

that is a child of the Oracle Sales and TeleSales usage folder. This will be the territory under which a generated territory group hierarchy will be inserted. It should address effective dates, the number of winners and any qualifier rules that its generated child territories need to inherit; e.g., COUNTRY = 'United States'.

3. Sales operations compiles a list of named accounts for each division, and

determines necessary exception handling procedures.

4. Determine how existing or new sales roles will be used to drive account, lead,

and opportunity access. Lead and opportunity access can further be refined by product category thereby giving access to leads and opportunities if a representative's product specialization exists.

5. Territory groups are created based on exception handling processes and

division lines, and named accounts and sales division vice presidents are associated.

6. Assign territory administrators to territory group Catch Alls for customers,

leads, or opportunities that match on CUSTOMER NAME RANGE qualifier rules only. Otherwise, have IT create workflows encompassing your division's exception handling processes and procedures.

Phase III: Creating Named Account Territories 6-5

Migrating from Existing Territories to Named Account Territories

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. Alias business names and postal codes can be added to named account definitions. For example, Hewlett-Packard is commonly known as HP or Compaq.

8. Before each named account mapping is complete, territory administrators

should check that the definition they are creating does not conflict with any other named account definitions. This ensures that a customer, lead, or opportunity will only fall into one named account territory. Utilities are provided to identify conflicting named accounts and their territory rules at a click of a button so administrators can tighten or loosen their existing territory rules as necessary. After all conflicts are eliminated the administrator marks the named account as mapped.

9. To access the self-service sales management side of Territory Manager, sales

managers, and representatives are given the HTML Sales Territory User responsibility.

10. Named accounts are distributed down the sales hierarchy from the sales

division vice president one level at a time until all named accounts are assigned to lowest level salespersons.

11. Portals provide territory administrators with the ability to track the progress of

territory assignment down to lowest level reps and named account mapping. When enough progress is achieved, a territory administrator generates named account territories by submitting a concurrent program.

12. Submit a concurrent program to run batch mode Territory Assignment. This

will reassign sales teams to all customers, leads, and opportunities based on the latest territory definitions generated.

13. Validate the new named account territories through user acceptance testing.

As part of our mapping process, named account definitions or territory rules are defaulted to CUSTOMER NAME RANGE = business name of the account and POSTAL CODE = postal code of the account. Territory administrators can also add alias CUSTOMER NAME RANGES and other postal codes or postal code ranges.

6-6 Oracle Territory Management Implementation Guide

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.6 Creating Territory Groups

A territory group is a group of named accounts. You designate sales roles for each territory group and define what access each sales role has to leads, opportunities, or accounts. Use this procedure to create a territory group and designate specific organizations as named accounts within the territory group.

Prerequisites

None

Creating Territory Groups

Responsibility

Territory HTML Sales Administrator

Navigation

Territory Manager > Territories > Territory Group

Steps

1. In the Territory Group page, click Create Named Account Territory Group.

The Create Territory Group page appears.

2. Enter a name for the territory group.

3. Select the parent territory from the LOV. This places the territory group into the

hierarchy of physical territories created in the Forms administration windows.

Phase III: Creating Named Account Territories 6-7

Creating Territory Groups

4. Enter a rank for the territory group. This is the rank of the territory group catch

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.

8. Perform the following steps to assign roles and define the access for each role in

Details for the selected named account appear.

all.

The Define Role Access page appears.

the territory group.

a. Use the LOV to select a role from CRM Resources. b. Select the access types for the role. Choices are account, lead, and

opportunity.

c. If the role has lead or opportunity access time, then you can specify product

categories. Click the icon in the Product Category column. The Select Product Categories page appears.

d. If you are specifying product categories, then use the LOV to select a

product category.

e. If you want to select additional product categories, then click Add Another

Row and repeat step d.

f. When you have completed adding product categories to the role click

Apply.

The Define Role Access page appears.

g. If you want to add additional roles, then click Add Another Row and

repeat from step a.

h. Click Next.

The Setup Rules page appears.

9. The territory group acts as a catch all territory for any transactions that match

the account name but do not fit the named accounts within the territory group. Choose the resource from the LOV who owns the catch all records and optionally enter the name of a workflow for catch all transactions.

10. Click Next.

6-8 Oracle Territory Management Implementation Guide

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. The organizations that match your search criteria appear on the page.

14. In the Select column, select each organization to be added to the territory.

15. Click Add to Territory Group.

The selected organizations appear in the territory group list at the bottom of the page.

16. Click Finish.

The Territory Group page displays the list of territory groups and the number of named accounts in each territory group reflects the changes you made. The organizations you selected become named accounts.

Guidelines

The concurrent program Generate Territory Packages must be run for your territory changes to be effective.

6.7 Defining Named Account Rules

You can use a range of account names and postal codes to ensure that any records that fall within those ranges are treated as part of the territory group for the related named account. Use this procedure to define the accounts that relate to a specific named account.

Prerequisites

At least one territory group exists with a named account.

Phase III: Creating Named Account Territories 6-9

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. Enter a customer keyname. The keyname is the qualifier used to search for

accounts in the database that belong in the territory with the named account.

7. If you want to enter more than one keyname qualifier, then click Add New Row

and repeat step 6.

8. Enter a range of postal codes to further qualify the accounts that match the

keyname.

9. If you want to enter more than one postal code qualifier, then click Add New

Row and repeat step 8.

10. To prevent overlapping named account territories, ensure there are no conflicts

by performing the following steps:

a. Click Select All and click Show Conflicts.

The Map page lists conflicting named accounts and their overlapping qualifier rules.

b. If conflicts appear, then tighten or loosen the named account qualifier rules

to avoid conflicts.

c. Return to the definition page.

11. Click Apply.

6-10 Oracle Territory Management Implementation Guide

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. Use this procedure to add or remove salespeople from one or more named accounts.

Prerequisites

You are the sales manager for an existing territory group that contains named accounts.

Responsibility

Territory HTML Sales User

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 named accounts appears.

4. In the Select column, select one or many named accounts to update.

5. Click Update Sales Team.

The Update Sales Team page lists the selected accounts.

6. If you want to add a salesperson to the sales team, then perform the following

steps in the Add Salesperson section:

Phase III: Creating Named Account Territories 6-11

Running Concurrent Programs

a. 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

7. 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. Select the salesperson’s sales role from the LOV. d. If you want to remove another salesperson, then click Add Another Row

8. Click Apply.

Your changes are saved.

Guidelines

In order to remove a salesperson from the sales team you much select the exact salesperson, group, and role combination that is on the sales team.

Use the LOV to select the salesperson.

repeat from step a.

and repeat from step a.

6.9 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.

6-12 Oracle Territory Management Implementation Guide

Running Concurrent Programs

Table 6–1 Seeded Concurrent Programs

Name Function Frequency

Generate Territory Packages

■ To create the territory rules or to

reflect the changes that you made to territories. Otherwise, your territories will not reflect the actual

As often as you need to activate territory changes, for example,

nightly changes and will not work correctly when calling modules try to use the Assignment Manager to assign resources.

■ Builds the API that returns the

winning territories and resources attached to the winning territories, which are defined in territory setup.

Named Account Territo r y Post Processing

■ Kicks off named account catchall

workflow processing

■ Refreshes territory administration

portals for Sales

As often as you want

the numbers in the

catch all portlet

updated and

workflows run

Prerequisites

None

Responsibility

CRM Administrator

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.

Phase III: Creating Named Account Territories 6-13

Usage Implementation

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.

Named Account Territory Post Processing uses two parameters:

■ Run the Workflow: choose either yes or no

■ Name of the Bin: Select the bin to be calculated. Your options are:

■ All

■ Catchall Bin (Catchall portlet)

■ KPI Bin (Key Performance Indicator portlet)

■ None (Select to run workflow only)

6.10 Usage Implementation

Additional implementation steps relate to the usage for Oracle Territory Management. For example, if your usage is sales, see the Oracle Sales Online Implementation Guide.

6-14 Oracle Territory Management Implementation Guide

Post Implementation Tasks

This section contains the following chapters:

■ Chapter 7, "Verify the Implementation"

■ Chapter 8, "Troubleshooting"

Part III

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.

Verify the Implementation

Verify the Implementation 7-1

Verification Tasks

7-2 Oracle Territory Management Implementation Guide

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.

Example:

There are two sales organizations, one in Canada and one in the United States. In this case, you know that 80 percent of your customers come from the United States. You can rank the US territory higher than the Canada territory. The application saves processing time as a result because it looks for a US territory before it looks for a Canadian territory.

You must use caution that your modifications do not result in erroneous assignments, however.

Suppose you have two overlapping territories.

■ Territory A

Qualifier: Company Name Range = V%

Troubleshooting 8-1

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.

■ Make the territories as generic as possible.

■ If you create a territory and do not assign resources to it, then the Territory

Manager does not return this territory as a winning territory.

■ You can create your own module specific "Catch All."

8.2 If the Generate Territory Packages Fails

If you run the Generate Territory Packages concurrent request and it errors out, run it again with the Debug and Trace flags set to Yes. Then review the log file that results. The log file gives clear information on exactly what step the error occurred at in the program and what the error is.

8.3 Frequently Asked Questions (FAQs) about Transaction Qualifiers

The following are frequently asked questions about transaction qualifiers. Answers to these questions may help you in troubleshooting problems with Territory Manager.

8.3.1 How to Find All Seeded Transaction Qualifiers?

Answer: Use the following steps to list all seeded transaction qualifiers:

8-2 Oracle Territory Management Implementation Guide

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.

The Setup Qualifier window opens with the seeded transaction qualifiers that match the selected usage information including a description, transaction type, and an organization.

5. Select different Usage to find other seeded transaction qualifiers if necessary

8.3.2 How to Find Possible Transaction Qualifier’s Values?

Answer: In the Transaction Qualifiers tab, you must enter at least three letters in order to bring up the LOV in the Value From and Value To fields. For example, enter "Bus" to launch the LOV starting with "Bus". If wildcard "%" is used, then use it with letters, such as "B%%", or "%%%" to query the list of values.

8.3.3 What is Customer Name Range Transaction Qualifier?

Answer: Customer Name Range is used to group similar customer names. It allows you to define access based on pre-defined customer names.

8.3.4 What Is the Difference Between the Following Service Transaction Types?

Service Request: This transaction type allows you to define access for account and service request related transaction qualifiers. It limits the transaction access to a service request only.

For example, a territory is defined with appropriate rank information and has Service Request transaction type identified. That territory can be a winning territory among other competitive territories only if it is for a service request transaction, but not a task or a task associated with a service request transaction.

Ta s k : This type allows you to define access for account and task related transaction qualifiers. It limits the transaction access to a task only, not a task created within a service request.

Troubleshooting 8-3

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. When a transaction is lunched through a task within a service request, that territory will not be selected as a winning territory even the qualifier and its value is matched to the transaction (a task associated with a service request).

8.4 Diagnostic Reports

Run diagnostic reports using the following steps and send the reports to Support:

1. Log into HTML APPS as SYSADMIN/SYSADMIN.

2. Select the Diagnostics tab. This opens a new window.

3. Select the Basic tab in the new window.

4. Change the Application to CRM Foundation.

5. Select Territory Manager in the left menu.

6. Click Run Without Prerequisite.

7. Click Report to see the report details.

8-4 Oracle Territory Management Implementation Guide

Oracle B10553-01 User Manual

Specifications and Main Features

Frequently Asked Questions

User Manual

Contents

Send Us Your Comments

Intended Audience

How To Use This Guide

Preface

Documentation Accessibility

Other Information Sources

Do Not Use Database Tools to Modify Oracle Applications Data

About Oracle

1.1 The Oracle E-Business Suite

Introduction

1.1.1 The Applications in the E-Business Suite

1.2 Oracle Territory Management Overview

1.2.1 Components

1.2.2 Named Accounts

1.2.3 Oracle Territory Management Features

1.3 New in this Release

2.1 Related Documentation

2.2 Installation Verification

Before You Begin

2.2.1 Create a Territory

2.2.2 Run Concurrent Programs

2.2.3 Test with a Lead

Oracle Territory Management Dependencies

3.1 Process Description

Implementation Overview

Implementation Task Sequence

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

3.1.0.4 Phase IV: Managing Territories

Multi-Org

4.1 Planning Your Territories

Phase I: Territory Planning

Sales Territory Planning Example

4.2.1 Step 1: What business objects are we assigning?

4.2.2 Step 2: What qualifiers should we use?

4.2.3 Step 3: Territory hierarchy - Define date effectivity and number of winners

4.2.4 Step 4: Territory hierarchy – Define Catch Alls

4.2.5 Step 5: Territory hierarchy – Placeholder territories

4.2.6 Step 6: How to implement named account territories

4.2.7 Step 7: How to implement geographic territories

4.2.8 Step 8: How to support overlays

4.2.9 Step 9: What is an appropriate territory hierarchy for overlays?

4.2.10 Step 10: What rank should each territory have?

4.2.11 Step 11: Have you met all your business requirements?

4.2.12 Leverage Territory Hierarchies and Inheritance

4.2.13 Leverage Territory Ranking and Number of Winners

4.2.14 Appropriate Choice of Qualifiers

Sales Territory Qualifiers

4.2.15 Qualifier Rules

4.2.16 Migrating Territories

Service Territory Qualifiers

Phase II: Setting Up Territories

5.1 Overview of Creating Territories

Qualifiers

5.2.1 Transaction Qualifiers

5.2.1.1 Sample List of Seeded Transaction Qualifiers

5.2.1.2 Customer Name and Customer Name Range,

5.2.2 Resource Qualifiers

5.2.3.1 Seeded Qualifiers

5.3 Territory Hierarchies

5.4 Territory Winning Rules

5.5 Enabling Existing Qualifiers

5.6 Creating Individual Territories

Entering Transaction Qualifiers

5.8 Entering Resource Qualifiers

Specifying Resources for a Territory

Adding Subterritories

5.11 Running Concurrent Programs

6.1 Overview of Creating Named Account Territories

Phase III: Creating Named Account Territories 6-1

6.1.1 Components of Self-Service Named Accounts

6.1.2 Ongoing Maintenance

6.1.3 Annual Maintenance

6.1.4 Territory Autogeneration Mechanics