TerritoriesWhitePaper V11 PDF

Release 12.1.
3 – Service Territories
An Oracle White Paper
September, 2013
R12.1.3 Service Territories
1 Executive Overview ................................................................................................................... 2

2 E-Business Service Routing Solution ....................................................................................... 2
3 E-Business Suite Oracle Territory Manager............................................................................ 3
4 Common Territory Concepts and Terms................................................................................ 4
4.1 Territory Usage .................................................................................................................. 4
4.2 Territory Types................................................................................................................... 4
4.3 Transaction Types.............................................................................................................. 5
4.4 Qualifiers or Matching Attributes ................................................................................... 6
4.4.2 Geographic Qualifiers – Alternative Spelling for Geographic Qualifiers ............. 7
4.4.3 Solution Implementation – Alternative Spelling for Geographic Qualifiers........ 8
4.5 Access Levels...................................................................................................................... 9
4.6 Territory Hierarchies ....................................................................................................... 10
4.7 Catch Alls .......................................................................................................................... 11
4.8 Operating Unit ................................................................................................................. 12
5 Retrieval Process ....................................................................................................................... 14
5.1 Locate Matching Territories ........................................................................................... 14
5.1.1 Territory Expression Evaluation............................................................................... 15
5.1.2 Using Contains ............................................................................................................ 17
5.1.3 Using Between ............................................................................................................. 18
5.2 Sort Matching Territories and Pick Winners ............................................................... 20
5.2.1 Sorting matching territories ....................................................................................... 20
5.2.2 Picking winning territories ......................................................................................... 22
6 WebADI ..................................................................................................................................... 23
6.1 Exporting data into an Excel spread sheet .................................................................. 23
6.2 Edit changes in Excel spread sheet ............................................................................... 23
6.3 Import data from the Excel spread sheet into Oracle Territory Manager .............. 24
7 Anatomy of a Territory Type .................................................................................................. 25
8 Anatomy of a Territory ............................................................................................................ 26
8.1 Select Usage ...................................................................................................................... 26
8.2 Select Parent Territory .................................................................................................... 26
8.3 Select Territory Type ....................................................................................................... 27
8.4 Define Basic Territory Information .............................................................................. 27
8.5 Select Resources and Define their Access Levels ....................................................... 28
8.6 Select Geographic Qualifiers.......................................................................................... 29
8.7 Select Non Geographic Qualifiers ................................................................................ 30
Appendix A – List of all Service Qualifiers ................................................................................... 31
Appendix B – Update statements to modify qualifier LOV SQL .............................................. 39
Appendix C - ERD ............................................................................................................................ 40
R12 Service Territories Page 1

1 EXECUTIVE OVERVIEW
Organizations that provide service and support to their customers and employees need an effective and robust system
to deliver this service and support. One of the keys to a successful service and support delivery system is to be able to
route service requests and their tasks to the correct resource for quick and efficient resolution. Service requests need
to be routed to the following types of resources for quick resolution:
• Call Center agents
• Help Desk agents
• Field Service Technicians
• Tech Support Groups
• Product specialist and so on.
Service providers rely on business applications to support and automate a structured rules based routing process. This
structured rules based routing process needs to support geographic, non geographic, and time components.
Geographic components are any reference to a physical location on a map – like country, state, postal code etc. Time
components refer to a specific time during the day – like 12 noon or a specific day during the week like Monday. Non
geographic components are all the other attributes that are associated to the object seeking assignment. For example,
if it is a service request that is seeking assignment, the non geographic components are the attributes of the service
request like Status, Severity, Type, etc.
Having a robust routing solution has the following benefits:
• Faster response times
• Satisfy Service Level Agreements
• Increase agent productivity
• Reduce cost of providing service
2 E-BUSINESS SERVICE ROUTING SOLUTION

The E-Business Service Suite of products has a comprehensive, robust, and efficient routing solution in place since its
early releases. Many Customers have used the solution effectively in small as well as in large implementations.
The key components of the routing solution are the Assignment Manager and Advanced Scheduler.
Assignment Manager assigns ownership to the following:
• Service request group owner
• Service request individual owner
• Service request task owner (Group or Individual)
• Service request task assignee for non field service tasks (Group or Individual)

Advanced Scheduler assigns ownership to the following:
• Service request task assignee for field service tasks
Both of these routing components use the rules setup in Oracle Territory Manager to retrieve eligible resources for
the assignment process. See Section 5 for details.
3 E-BUSINESS SUITE ORACLE TERRITORY MANAGER

Definition: Territory Manager is used in the assignment of business objects such as Service Requests and Tasks to Resources based on
configurable business rules. It defines who owns what.
Oracle Territory Manager consists of the following main components:

3.1 Territory Administration UI
The Setup UI helps Territory Administrators define and maintain their routing rules. As the organization providing
service grows, routing rules can become complex and hard to maintain. The Setup UI minimizes this complexity and
helps provides a pictorial representation of the routing rules.
Details of the Setup UIs are described in Section 8.
3.2 Get Territories API – the Retrieval Process
Once Territory routing rules are defined, the Get Territories API is the retrieval engine that identifies the best
Territory(s) for assignment. The process that the Get Territories API uses is as follows:
1. Locates matching Territory(s)
2. Sorts matching Territory(s) by Rank
3. Picks winning Territory(s)
4. Returns winning Territory(s) and Resources
These processes will be detailed in the sections ahead.
3.3 STAR Concurrent Program
The Synchronize Territory Assignment Rules concurrent program optimizes territory rules. This speeds up and
improves the performance of the retrieval process. Each time a territory structure is newly added or an existing
structure changed, the STAR concurrent program needs to be executed to optimize the addition or modification to
the structure. The following constitutes a structure change:
- Adding a new qualifier or changing an existing qualifier
- Adding a new qualifier value or changing an existing qualifier value
- Changing the rank of the territory
- Changing the parent territory
Note: Adding and removing Resources from a territory does not require the STAR program to be executed.
3.4 WebADI Interface for ease of Maintenance

Oracle Territory Manager has up taken the integration with WebADI. The Web Applications Desktop Integrator
interface helps territory administrators easily maintain their territory structure in an Excel format. Updates and
additions to the structure can be imported from Excel into the Oracle Territory Manager and vice versa. More
information on the WebADI interface is covered in a Section 6.

4 COMMON TERRITORY CONCEPTS AND TERMS
4.1 Territory Usage
Territory Usage corresponds to the different Applications within the E-Business Suite of Applications that use
Territory Manager for ownership assignment to their business objects. Ownership can be assigned to Individuals,
Groups, or 3rd party resources.
The following Applications use Territory Manager for ownership assignment to their corresponding business objects:
(these are the seeded Territory Usage codes)
• Collections
• Partner Management
• Service => assignment for Service Requests and Tasks
• Sales
• Service Contracts
• Trade Management
This white paper will focus on the Service Usage of Territory Manager.
Territory Usage has the following benefits:

• Territory Usages helps multiple applications across the E-Business Suite leverage the same territory
administration UI and retrieval process.
• Helps territory administrators manage and maintain their territories. When viewing territories, only territories
belonging to the Usage that is pre-selected are displayed. This helps in preventing the otherwise huge list of
territories from being displayed to the administrator.
• When assigning owner ship, only territories that belong to the application that is seeking ownership are scanned.
Territories that do not belong to the application that is seeking ownership are not scanned. As a result, the
search pattern to identify matching territories is optimized.
4.2 Territory Types

Territory Types are the building blocks for all territories. A type is blueprint for territories, defined by a specific set of
transaction types and corresponding matching attributes.
Territory Types easies the process of territory creation. Every territory that is created is created based on a Territory
Type. The three components of a Territory Type are:
• Usage
• Transaction Type
• Qualifiers
A Territory Type can belong to only one territory usage. However, a single Territory Type can contain more than one
transaction type (see section 4.3 for transaction types). The list of qualifiers defined in a Territory Type is the one that will
be available to the administrator when defining the actual territory (see section 4.4 for qualifiers and Appendix A for a
complete list of qualifiers).
When defining territories based on a Territory Type, the usage and transaction types are defaulted in – users will have
to then manually select the Qualifiers to complete the Territory definition. The list of qualifiers presented to the user
will be restricted to the list of qualifiers that are defined in the Territory Type.
R12.1.3 Service Territories Page 4

4.3 Transaction Types
Transaction Types refer to the different business objects within each Application or Usage that depends on territories
to determine ownership of that business objects. In the case of Service Usage, the seeded Transaction Types are the
following:
• Service Request
• Service Request and Task => refers to a Service Request Task
• Task => refers to a standalone Task – do not use this transaction type even though it is available. Standalone
Tasks are not used by Service.
Each Transaction Type can have a set of Qualifiers (see section 4.4 for Qualifiers details and Appendix A for a complete list of
qualifiers).
Territory Types have the following benefits:
• Ensures that an invalid territory cannot be defined. Once a Transaction Type is selected, the list of qualifiers is
filtered based on the selected Transaction Type.
• When defining a territory, routing rules can be defined only for the transaction types defined in the territory
type. For example if a territory type is defined with only the service request transaction type, then all territories
based on this territory type can be used to define routing rules only for service requests.
• When assigning owner ship to a Transaction Type, only territories whose definition contains the Transaction
Type are scanned. Territories that do not have the Transaction Type in its definition are not scanned.
For example, if there is a territory defined with the ‘Service Request’ Transaction Type, then this territory will be
scanned only when the Service Request object seeks assignment. This territory will be ignored when stand-alone
Tasks and Service Request Tasks are seeking assignment.
Service Request – Use this transaction type when setting up routing rules for service request assignment. Selecting
this transaction type provides a list of qualifiers that are associated to the service request. Qualifiers that are associated
to the task transaction type are filtered out.
Service Request and Task – Use this transaction type when setting up routing rules for service request task
assignment. Selecting this transaction type provides a list of qualifiers that are associated to both the service request
and task (basically all service qualifiers are provided).
Note 1: If routing rules need to be defined for both service request and task assignment, base the territory on a
territory type that contains both transaction types – ‘Service Request’ and ‘Service Request and Task’.
Note 2: When defining territory types, once the transaction type is selected, the list of qualifiers that the administrator
can select, are filtered based on the selected transaction type. In addition to this filtered qualifier list, there are some
common qualifiers that the administrator can select irrespective of the transaction type selected. These qualifiers are
associated to a transaction type called ‘Account’. The ‘Account’ transaction type is not an object that is seeking
assignment per se – it exists only for the purpose of having these common qualifiers associated to a transaction type.
An example of an ‘Account’ transaction type qualifier is ‘Customer Name’.
See Appendix A for the full list of qualifiers associated to the ‘Account’ transaction type.

4.4 Qualifiers or Matching Attributes
Qualifiers refer to the attributes of either
• A business object being assigned OR
• An object associated to the business object.
For example, service request is a business object. The service request’s attributes are the service request Qualifiers –
for example a service Request’s attributes can be its Status, Severity, Type, Address, etc. – these attributes are the
service request’s qualifiers.
An Account is a sub-object that is associated to a service request. The Account’s attributes such as Number, Site,
Customer, etc. are the Qualifiers of the Account object. The service request attributes together with the attributes of
its sub-objects are the full list of qualifiers that can be used when defining territories for service request assignment.
Qualifiers are categorized as geographic and non-geographic qualifiers. The following qualifiers are the geographic
qualifiers: City, Postal Code, State, Province, County, and Country. The rest of the qualifiers are non-geographic.
The entire list of Qualifiers can be found in Appendix A.
4.4.1 Enabling and disabling qualifiers

There are 45 Service qualifiers for customers to use (as of R12.1.3). However, in most cases, customers use only a
subset of these 45 qualifiers. In order to avoid setting up territories with qualifiers that are not to be used and to
simplify the process of setting up territories, qualifiers can be enabled or disabled in an implementation.
The following screen shot shows the enabling and disabling of qualifiers.
Figure 1 – Enabling / disabling territory qualifiers

If customers use multiple Operating Units, qualifiers can be enabled and disabled differently for different Operating
Units (see section 4.8 – Operating Units for more information on the uses of Operating Units).
4.4.2 Geographic Qualifiers – Alternative Spelling for Geographic Qualifiers
Geographic qualifiers refer to address information like Country, State, City, Postal Code etc. Geographic qualifiers are
numeric like Postal Code or text strings like Country, State, City etc. When using text strings, Oracle Territory
Manager does a text comparison between what is stored in territory tables and what is passed from the Service
application to determine matching territories. The text string match is not case sensitive however they need to match
exactly in the way they are spelt.
Address information created via the Service application can be validated against a geography hierarchy of metadata to
ensure that the address information is valid. The geography hierarchy of metadata is stored in the HZ Geography
tables in TCA (Trading Community Architecture). For example, in geography hierarchy, the state of California is
defined as the parent of San Mateo County, which is the parent of Redwood City, which is the parent of the postal
code 94065. If you enter just 94065, the application can determine that the postal code is in California, or that the
corresponding city is Redwood City.
Address information can also be created via the Service application that is not validated against the geography
hierarchy metadata. In cases where the address information is not validated, customers can encounter issues1 when
the address information in HZ Locations is different than the address information in HZ Geographies.
When setting up territories with geographic qualifiers, the list of values provided to the user for these qualifiers are
retrieved from the HZ Geography tables. Addresses in the Service application are stored in the HZ Location tables. If
addresses are validated, the data that is stored in the HZ Location tables are validated against the data setup in the HZ
Geography tables. In this case, all the information in the HZ Location table is in sync with the data in the HZ
Geography tables. In cases where address information in not validated, the data that is stored in HZ Locations tables
can potentially be different than what is stored in the HZ Geography tables.
Here’s an illustration of the discrepancy: For example when creating a territory with the City qualifier, the list of values
provided to the end user for Mexico from the HZ Geography table could have been only ‘Mexico City’.
Territory Qualifier => City = Mexico City
Whereas, the City captured on the Service Request could have been ‘Mexico’. This is what is stored in HZ Locations
and since the address in HZ Locations is not validated against HZ Geography, the city names are not in sync.
Service Request => City = Mexico
With the above scenario, Assignment Manager will fail to retrieve the territory, since the city value in the territory
definition does not match the city value passed from the service request.
Mexico City <> Mexico
The discrepancy can occur for the following geographic qualifiers – City, State, Province, and County.
The reason why customers can land up with these address discrepancies can be any one or more of the following
reasons:
• Address information is migrated from a legacy system
• HZ Geography metadata information is not available for certain countries / regions
1 The following bugs 4122637, 4249321, 4527721, and 6910757 capture the issue in 11i.

• HZ Geography metadata information is available but not used in customer implementation
4.4.3 Solution Implementation – Alternative Spelling for Geographic Qualifiers
For Customers who encounter the above issue, the following solution can be used. The solution described below is
for the City qualifier. The same principle can be used to resolve issues with the other geographic qualifiers.
The SQL that is associated to the City qualifier’s LOV in territories is based on HZ Geographies. This is seeded and
shipped out-of-the-box.
selectdistinct
a.geography_name col1_value,
NULL col3_value,
a.geography_element1 col4_value
from hz_geographies a
where a.geography_type = 'CITY'
With the above SQL, all cities that are setup in the HZ Geographies table will be provided to the user for selection. In
cases where the city is not defined in HZ Geographies or in case there is a discrepancy between what is setup in HZ
Geographies and what is stored n HZ Locations, the following solution can be used.
1. Create a lookup type called ‘CS_CITY’. Add all the cities that are required for territory matching as lookup
codes for the newly created lookup type ‘CS_CITY’. These cities will include:
a. All cities missing from HZ Geographies but available in HZ Locations and
b. All cities that have a discrepancy between what is stored in HZ Geography and HZ Locations (as
illustrated above for ‘Mexico’ and ‘Mexico City’)
2. Update the SQL that is associated to the City qualifier’s LOV to include the cities created for the lookup type
‘CS_CITY’. The updated LOV SQL for the City qualifier looks like the following:
selectdistinct
NULL col3_value,
a.geography_element1 col4_value
from hz_geographies a
where a.geography_type = 'CITY'
UNION
select distinct
a.meaning col1_value,
a.lookup_code col2_value,
NULL col3_value,
NULL col4_value
from cs_lookups a
where a.lookup_type = 'CS_CITY'
order by col1_value
The above statement retrieves all cities from HZ Geographies as well as all the cities that are defined as lookup codes
for the lookup type ‘CS_CITY’.

Note 1: The above solution is delivered as an out-of-the-box solution in Release 12.1.3. For customers using EBS
Service Releases 12, 12.1.1 and 12.1.2, the above two steps can be used to build a custom solution – that is to create a
lookup type and to update the LOV SQL associated to the qualifier (see Appendix B for update statements).
Note 2: For customers using the 11i version of EBS Service, please refer to Metalink Note 296539.1 for the solution
overview.
Note 3: If the solution needs to be used for the State qualifier, Customers can use the same approach – that is
1. Create a lookup type called ‘CS_STATE’ and add all the needed States as lookup codes for this lookup type.
2. Update the LOV SQL associated to the State qualifier to include the States created for the lookup type
‘CS_STATE’ (see Appendix B for update statement).
Note 4: When setting up lookup data Oracle Territory Manager performs the match as follows:
1. Matches the Lookup Code to the Service Request’s State and Province attributes
2. Matches the Lookup Meaning to the Service Request’s City and County attributes
4.5 Access Levels

Access Levels define what kind of access a resource has for a particular transaction type. A resource within a territory
can be setup to have different types of access for a given transaction type.
Resource Access Levels for the Service application are seeded lookup codes for lookup type
‘JTY_SERVICE_RSC_ACCESS’. The following are the seeded Access Levels for the Service application:
Default – Resources defined with Access Level ‘Default’ are eligible for assignment to the transaction type.
None – Resources defined with Access Level ‘None’ are not eligible for assignment to the transaction type.
Primary Contact– Resources defined with Access Level ‘Primary Contact’ are eligible for assignment to the
transaction type. This Access Level is defined for backward compatibility – a Resource with Access Level of Primary
Contact in R12 onwards is equivalent to a Resource in 11i defined as a Primary Contact. The concept of a Primary
Contact in 11i is replaced with the Access Level of ‘Primary Contact’ in R12 onwards.
Escalation Owner – Resources defined with Access Level ‘Escalation Owner’ are eligible for assignment to the
transaction type. Resources with this Access Level are also eligible for assignment to the escalation task that can be
associated to the transaction type.
Escalation Resource – Resources defined with Access Level ‘Escalation Resource’ are eligible for assignment to the
transaction type. Resources with this Access Level are also eligible for assignment to the escalation task that can be
associated to the transaction type. This Access Level is the same as the ‘Escalation Owner’ Access Level.
Note: Access Levels Escalation Owner and Escalation Resource replace the concept of Escalation Territories in 11i.
However these Access Levels are not used as of R12.1.3.

4.6 Territory Hierarchies
Territories are defined in a hierarchical structure – Parent – Child – Grand Child – and so on. This is done for the
ease of maintenance of territories. Hierarchies also allow child territories to inherit matching rules and territory
properties of its parent territory. The other importance of Territory Hierarchies is that it allows the definition of a
‘Catch All’ territory (see section 4.7 for Catch All).
Note: Territories with no more child territories defined underneath them are called the ‘Leaf Territories’.
For example, if there is a need to route service requests based on the following routing rules:
1. Route all service request that are reported for ‘Dell Laptops’ to the ‘Dell Laptop Monitoring Group’. Let’s
assume that there is a service request Type called ‘Dell Laptops’.
2. If that service request is for a specific product model of Dell Laptop – say ‘Latitude C610’ – then route that
service request to the ‘Latitude C610 Tech Support Group’.
3. If that service request has a problem code of ‘DVD Issues’ then route that service request to the group ‘DVD
Drive Support Group’.
The best way to setup the Territory structure to capture the above requirement is to create it in a hierarchy as follows:
Level Territory Name Parent Territory Name Qualifier & Value Resource
1 Dell Laptop Issues – Catch All Vision Operations Request Type = Dell Laptops Dell Laptop Monitoring
Group
2 Dell Laptop – C610 Issues Dell Laptops – Catch All Product = C610 Latitude C610 Tech
Support Group
3 Dell Laptop – DVD Drive Issues Dell Laptops – C610 Issues Problem Code = ‘DVD Issues’ DVD Drive Support
Group
The Level column indicates the number of levels the territory is from the root territory – in this example the root
territory is ‘Vision Operations’ (since this is the parent of ‘Dell Laptop Issues – Catch All’).
The figure below illustrates the territory structure in a hierarchy:
Let’s see how the above structure works with an example. When assignment needs to be done for a service request
with the following attributes:
• SR Type = ‘Dell Laptops

• Product = ‘C610’
• Problem Code = ‘DVD Issues’
Territory manager scans the list of territories defined for the service request transaction type and identifies territory
‘Dell Laptop Issues – Catch All’ as a matching territory. It then continues to scan down the hierarch of this territory.
The next two territories are also identified as matching territories since the qualifiers match the service request
attributes. The matching process stops when there are no more territories to be scanned in that hierarchy or if the
territory qualifiers do not match the service request attributes.

In this example, resources defined in the leaf territory ‘Dell Laptop – DVD Drive Issues’ are selected as the winning
resources.
Note: Depending on the number of winners defined (see section 5.2 for Number of Winners), resources from all three
winning territories can be returned back as winning resources.
Now if assignment needs to be done for a service request with the following attributes:
• SR Type = ‘Dell Laptops
• Product = ‘C610’
• Problem Code = ‘Monitor Issues’
Territory manager scans the list of territories defined for the service request transaction type and identifies territory
‘Dell Laptop Issues – Catch All’ as a matching Territory. It then continues to scan down the hierarch of this territory.
The next territory is also identified as a matching territory. However the third territory in the hierarchy is not
identified as a matching territory since the problem code of the service request does not match the problem code in
the territory definition.
In this case, resources defined in territory ‘Dell Laptop – C610 Issues’ are selected as the winning resources. Without
territory hierarchies, defining and maintaining territories will be a complex administration task.
4.7 Catch Alls

Catch All is a concept in Oracle Territory Manager that Customers can use when designing their territory hierarchy.
These are territories that are defined at a significantly high level and are intended to be the winning territory if all other
territories are not identified as winning territories. Usually territories directly under the root level territory are good
candidates to be setup as Catch-All territories.
When defining Catch Alls, use the following tips:
- Use qualifiers that will most definitely return a matching territory
- Use resources that are default resources who can work on service requests or their tasks in case no other
resources are available. Most likely resources in a Catch All are at a supervisor or administrator level who can
reroute the service request or its task to an appropriate resource
- Name the territory appropriately and append the phrase ‘Catch All’ for ease of identification of Catch All in
the territory hierarchy
Catch All territories are not distinguished differently by Oracle Territory Manager from other territories – they are like
any other territories. In order to be identified as a matching territory, the qualifier values in the Catch All territories
need to match the values that are passed by the Service application.
In the example provided in the ‘Territory Hierarchy’ section, territory ‘Dell Laptop Issues – Catch All’ can be
considered as the ‘Catch All’ territory. This territory is defined with the ‘Request Type’ qualifier. This territory will be
returned as a matching territory for all service requests that are defined with a Request Type of ‘Dell Laptop’.
When planning on the territory structure, it is recommended to define Catch All territories so that all business objects
are assigned to at least a monitoring group so that none are left without any assignment.

4.8 Operating Unit
Each territory is defined under an Operating Unit. A common example on the usage of Operating Unit is to be able
to define different geographic regions under different Operating Units.
Operating Unit is used to manage territory administration but is not used in the retrieval process. The Territory
Administration UI uses Operating Unit as a filtering mechanism – that is to only display territories defined for the
selected Operating Unit. Customers using territories in a global implementation can decentralize their territory
administration using Operating Unit. For example in a global implementation an administrator maintaining territories
in North America will most likely be different from the administrator maintaining territories for Europe. In such cases
these two administrators can be associated to two different Operating Units. This restricts the view of the North
American administrators to only the territories that are defined under the North American OU and the administrator
from Europe can create and maintain territories that are defined under the European OU. This decentralization makes
territory administration in a huge implementation easy and less cumbersome. More over administrators cannot modify
territories that do not belong to the Operating Units they have access to.
Apart from the decentralization of the territory maintenance, the second use of the OU for Service territories is that a
root level territory is created for every OU. The name of the root level territory is the same name as the OU. All other
territories need to be defined as children territories under this root level territory.
Figure 2 – Root Territory named after Operating Unit - Case 1
These root level territories are created via a concurrent program ‘Replicate Seed Data’. This concurrent program is
available under the ‘System Administrator’ responsibility. The parameter of this concurrent program is an Operating
Unit as shown in the screen shot below.

Figure 3 - Concurrent program to create root level territories with the same name as OU
Note: For an implementation where territory administration does not have to be decentralized, all territories can be
setup under one single operating unit.
The third use of the Operating Unit attribute is to determine if a qualifier needs to be displayed in the Assignment
Manager UI or not. The AM UI displays all qualifiers that are enabled in at least one operating unit.
Figure 4 - List of qualifiers displayed in the AM UI

5 RETRIEVAL PROCESS
The goal of the retrieval process is to identify the winning territory. Depending on the value of the ‘Number of
Winners’ (described later), more than one territory can be identified as a winning territory.
The retrieval process consists of the following:
1. Locate matching Territory(s)
2. Sort matching Territory(s) by Rank
3. Pick winning Territory(s)
4. Return winning Territory(s) and Resource(s)
The following sections describe these processes in detail – specifically the first two processes. Picking and returning
the winning Territory are only actions that are needed to complete the assignment process – these do not have any
additional details.
5.1 Locate Matching Territories

To understand how territories are identified as matching territories it is important to understand how rules are defined
within a territory and how these rules are evaluated. The rules in a territory have a similar structure as a database
expression – each rule has a Left hand side, an Operator, and a Right hand side. For example:
Service Request Type Equals Customer Call
Left hand side Operator Right hand side
The Left hand side of the expression or a territory rule is made up of the name of the qualifier.
The Operators that are supported are the following: Is Equal To, Contains, and Between. Most qualifiers can only
use the ‘Is Equal To’ operator; however there are some qualifiers like the Postal Code, Area Code, and Customer
Name Range that can make use of all three operators.
The Right hand side of the expression is the value of the qualifier that is either picked from a pre-defined List of
Values (LOV) or can be user entered free form text. In the majority of qualifiers, the value is picked from a LOV to
increase the level of accuracy.
Please refer to Appendix A for a list of Service Request and Task qualifiers, the operators that each qualifier can use, and whether the
qualifier value is free form or LOV controlled.
In the above example, service requests created with type ‘Customer Call’ results in the above expression evaluating to
true – hence resources within this territory will be considered for assignment. Territories whose expressions evaluate
to True are known as matching territories.
If there is more than one qualifier in a single territory, or if there is more than one value for the same qualifier in a
single territory, these need to be converted into a single expression that can then be evaluated to true or false. Also,
when evaluating expressions across a territory hierarchy, these multiple expressions need to be converted to a single
expression. To convert multiple expressions into a single expression, Conditional Operators are used – this is detailed
in the next section.

5.1.1 Territory Expression Evaluation
This section discusses how expressions across a territory hierarchy and within individual territories are evaluated to
either True or False by using conditional operators.
Let’s say for example the following parent / child territory structure exists.
Figure 5 - Territory Expression Evaluation - Example setup
The parent territory has the following qualifier and expression:

Request Creation Channel Is Equal To Web
The child territory has the following qualifiers and expressions:

Request Type Is Equal To Dell Laptops
Request Severity Is Equal To High
Request Severity Is Equal To Medium
Since there are three qualifiers and values in the child territory, it results in three expressions. Where there is more
than one expression in a single territory, conditional operators need to be used to join the different expressions and
generate a single expression that can be evaluated to either True or False.
The method Territory Manager uses to normalize the expression is as follows:
• If a single Territory contains the same Qualifier more than once, join the expressions using the ‘OR’ conditional
operator.
• If a single Territory contains different Qualifiers, join the expressions using the ‘AND’ conditional operator.

In the case of the child territory, the following is the single expression that is generated – this single expression can be
evaluated to either True or False.
Request Type Is Equal To Dell Laptops AND
(Request Severity Is Equal To High OR
Request Severity Is Equal To Medium)
Note: Similar qualifiers and their values are grouped together with the OR operator and evaluated. In the example,
the Request Severity qualifier is grouped within braces and evaluated with the OR operator.
Now, let’s discuss how the expressions between the Parent Territory and Child Territory are joined and evaluated.
Territory Manager always uses the ‘AND’ operator when joining the expressions between the Parent and Children
Territories.
In the example, taking the expression of the Parent and the Child Territories and joining them to generate a single
expression, we have the following:
Request Creation Channel Is Equal To Web AND

(Request Type Is Equal To Dell Laptops AND
(Request Severity Is Equal To High OR
Request Severity Is Equal To Medium ))
To summarize, Territory Manager uses the following rules when using the ‘OR’ and ‘AND’ conditional operators:
• Territory Manager uses the ‘AND’ operator when joining expressions between Parent and Children Territories
• If a single Territory contains the same Qualifier more than once, Territory Manager joins the expressions using
the ‘OR’ conditional operator.
• If a single Territory contains different Qualifiers, Territory Manager joins the expressions using the ‘AND’
conditional operator.
Given the above rules, the table below illustrates an example of the territories to be used for service request
assignment for different service request attributes and their values.
SR Attribute & Value Matching Territory
Channel = Web White, Phil
SR Type = Dell Laptops (From Child Territory)
Priority = High
Channel = Web White, Phil
SR Type = Dell Laptops (From Child Territory)
Priority = Medium
Channel = Web Smith, John
SR Type = Dell Laptops (From Parent Territory)
Priority = Anything Else
Channel = Web Smith, John
SR Type = Anything Else (From Parent Territory)
Priority = Anything

So far we have used the ‘Is Equal To’ operator when defining territory rules. Some of the qualifiers can use different
operators to evaluate their expressions. The three operators (not conditional operators) that can be used are the
following:
• Is Equals To
• Between
• Contains
All qualifiers can use the ‘Is Equals To’ operator. This is straight forward and has just one value on the right hand side
of the expression.
The ‘Between’ and ‘Contains’ operators are used to specify a range of values or a specific pattern of values
respectively. The next two sections cover how these operators can be used when defining territories. Also covered in
detail is how wildcard characters can be used in these operators to specify a specific pattern of values.
5.1.2 Using Contains
The ‘Contains’ operator works identical to the ‘Like’ operator in the database. Wildcard characters like the ‘%’ that
represents an indefinite string of characters and ‘_’ (underscore) that represents a single character need to be used
when using the ‘Contains’ operator.
For example if there is a need to route all service requests for all models of Dell to a particular resolving group, the
following expression using Contains can be defined in the Territory:
Product Contains Dell%
The above expression evaluates to true for all Dell models whose Product code starts with ‘Dell’. This can be ‘Dell-
C610-2010’ or ‘Dell-AnyThingGoesHere’.
Wildcards can be effectively used when it needs to be embedded within a value. For example if all Dell models for the
year 2010 are Product coded as follows:
• DELL-C610-2010
• DELL-C620-2010
• DELL-D100-2010
• DELL-D200-2010
And Dell models for the year 2009 are Product coded as follows:
• DELL-C610-2009
• DELL-C620-2009
• DELL-D100-2009
• DELL-D200-2009
If there is a need to route all service requests for Dell 2010 models to a resolving group that is different from all Dell
2009 models, then the wildcard character can be used effectively as follows:
Product Contains Dell%2010
The above expression will evaluate to true for all Dell 2010 models and filter out the Dell 2009 models.

Note: The same result can also be achieved by the following expression:
Product Contains Dell%10
The ‘_’ wildcard character represents a single character rather than a range of characters like the ‘%’. For example, if
there is another category of Dell models Product coded as follows:
• DELL-C610-2011
• DELL-C620-2011
• DELL-D100-2011
• DELL-D200-2011
If there is a need to route service requests for all Dell 2010 and 2011 models to a resolving group that is different than
the resolving groups that handles service request for the Dell 2009 models, the following expression can be defined:
Product Contains Dell%201_’
Note: It is not advisable to start with a wildcard character as it might result in performance issues.
5.1.3 Using Between
The ‘Between’ operator works identical to the ‘Between’ operator in the database. It requires two values – a lower
bound and an upper bound – to specify a range within which the actual transaction qualifier value needs to fall.
For example, if there is a need to specify a range of Postal Codes, the following expression can be defined:
Postal Code Between 94000 AND 95000
This expression will evaluate to true for all service requests whose postal code is greater-than-or-equal-to 94000 and
less-than-or-equal-to 95000.
i.e. 94000 >= Postal Code Value <= 95000
When using the ‘Between’ operator, wildcard characters should not be used to specify a specific pattern of values.
This is an important distinction between the ‘Contains’ and the ‘Between’ operators. Unlike the ‘Contains’ operator,
the ‘Between’ operator does not understand wildcard characters.
Defining expression values with wildcard characters for the ‘Between’ operator may not achieve the desired results.
When interpreting values for the ‘Between’ operator, the values are broken down into independent characters and the
character’s ASCII values are compared. Comparison is done on a character-by-character basis – once for the lower
bounds and once for the upper bound. For example if the value of a Service Request’s Postal Code is ‘94320’ – this is
clearly above 94000 and less than 95000. How Territory Manage derives at this conclusion is as follows:
It first strips the values in the lower and upper bounds into single characters and obtains the corresponding ASCII
values as follows:
Individual Characters Corresponding Individual Characters Corresponding
– Lower Bound ASCII value2 – Upper Bound ASCII Value
9 57 9 57
4 52 5 53
0 48 0 48
0 48 0 48
0 48 0 48
2 http://www.asciitable.com/

The value of the postal code is ‘94320’. The ASCII values of the individual characters of the postal code are derived.
The ASCII values of the postal code are compared with the ASCII values of the lower and upper bounds as follows:
Comparison with Result Comparison with Result
Lower Bound Upper Bound
(9)57 >= 57(9) True (9)57 <= 57(9) True
(4)52 >= 52(4) True (4)52 <= 53(5) True
(3)51 >= 48(0) True (3)51 <= 48(0) Not needed
(2)50 >= 48(0) Not needed (2)50 <= 48(0) Not needed
(0)48 >= 48(0) Not needed (0)48 <= 48(0) Not needed
The comparison is done until there is a clear indication that the value is either greater than the lower bound or lower
than the upper bound. From the above table, it can be observed that the comparison is done until the values are true
and equal. Once the values are not equal the comparison is stopped and the result is determined
Let’s see how the expression would evaluate if a wildcard character were to be used in the value of the lower and
upper bounds.
Postal Code Between 940% AND 950%
The assumption with the above expression is that any Postal Code that starts with ‘940’ and is less than a value that
starts with ‘950’ will evaluate to True. This includes Postal Codes such as ‘940’, 950’, ‘940999’, ‘9401-2345’, ‘9502-
12345’ etc. This will hold true if the wildcard in the expression was interpreted as a true wildcard and not as a ‘%’
character. However in the case of the ‘Between’ operator, wildcard characters are treated as themselves and not as
wildcards.
In the example above, the lower and higher range values are stripped down to individual characters and their
corresponding ASCII values are determined.
Individual Characters Corresponding Individual Characters Corresponding
– Lower Value ASCII value - Higher Value ASCII Value
9 57 9 57
4 52 5 53
0 48 0 48
% 37 % 37
If the value of the Service Request Postal Code is ‘9501’, it would appear that this value ‘9501’ should fall in between
‘940%’ and ‘950%’.
However when the ASCII comparison is done, we can see that it evaluates to False.
Comparison with Result Comparison with Result
Lower Bound Upper Bound
(9)57 >= 57(9) True (9)57 <= 57(9) True
(5)53 >= 52(4) True (5)53 <= 53(5) True
(0)48 >= 48(0) Not needed (0)48 <= 48(0) True
(1)49 >= 37(%) Not needed (1)49 <= 37(%) False
In this case the value of ‘9501’ is greater than the value of ‘950%’ and is considered higher than the upper bound. This
results in the expression evaluating to false.
When using the ‘Between’ operator, care should be taken not to use the wildcard characters.

5.2 Sort Matching Territories and Pick Winners
When defining territories, each territory has a rank. The use of the rank attribute is to sort the list of territories when
there is more than one matching territory. Territories with lower rank values precede those with higher rank values.
Number of Winners determines how many territories can be winning territories. For example, if there are five
matching territories, and the Number of Winners is set to a value of three, only three territories out of the potential
five are considered winning territories. The three territories out of the potential five are selected based on the rank
comparison of each territory.
Note: For the Service application, the Number of Winners associated to the root territory is the one that will be used
to determine the number of winning territories. Even though the Number of Winners is an attribute for each territory,
defining a rank value for a territory that is not the root territory is of no use.
Territory ranking works in conjunction with the Number of Winners. When more than one matching territory is
identified, the ranking and number of winners dictates which territories are the final winning territories and which
need to be filtered out.
5.2.1 Sorting matching territories

To understand how matching territories are sorted, the concept of Absolute Rank needs to be understood. Absolute
Rank is an internal calculation that is performed by Oracle Territory Manager to ensure that territories are sorted
correctly according to the rank values that are associated to them. More importantly, the Absolute Rank ensures that
Child territories are given preference over their parent territories. When a set of Territories are identified as matching
Territories, Absolute Rank helps determine the most appropriate Territory to be selected as the eventual winning
territory. Territories with higher Absolute Rank have a higher precedence than those with lower Absolute Rank.
Absolute Rank of a territory is calculated as follows:

1. Calculate relative rank. Relative rank is calculated using the formula:
1 / (Rank * POWER (MAX Rank in Service Usage, Level from Root))
2. Add relative ranks of all territories in that hierarchy up to the root node
Note: The second step where the relative ranks of all territories above a given territory are added up ensures that a
child territory will always have a higher Absolute Rank than its parent.
Let us assume that the following Territory structure is defined:
The table below illustrates the Absolute Ranks of the above Territory structure:
Note: Assume that the max rank of all territories defined for the Service Usage is 60.

Name Rank Level Relative Rank Absolute Rank Absolute Rank *
†
10,000
T1 50 1 0.0003333 0.0003333 3.333333333
T2 10 2 0.0000278 0.0003611 3.611111111
T3 60 1 0.0002778 0.0002778 2.777777778

T4 10 2 0.0000278 0.0003056 3.055555556
†-
This column is added for ease of reading the value of Absolute Rank. This is not a calculation
that is performed by Oracle Territory Manager.
Work sheet
Relative Rank Formula:
1 / (Rank * POWER (MAX Rank in Service Usage, Level from Root))
The following is how the Relative Ranks and Absolute Ranks are derived for the above
Territories.
For territory T1
Relative Rank of T1 => 1 / (50 * POWER (60, 1)) = 0.0003333
Absolute Rank of T1 => 0.000333 (since there is no other Parent Territory, the Absolute
Rank is the same as the Relative Rank)
For territory T2
Relative Rank of T2 => 1 / (10 * POWER (60,2)) = 0.0000278
Absolute Rank of T2 => sum of Relative Ranks of T1 and T2
0.0000278 + 0.0003333 = 0.0003611
For territory T3
Relative Rank of T3 => 1 / (60 * POWER (60, 1)) => 0.0002778
Absolute Rank of T3 => 0.0002778 (since there is no other Parent Territory, the Absolute
Rank is the same as the Relative Rank)
For territory T4
Relative Rank of T4 => 1 / (10 * POWER (60, 2)) => 0.0000278
Absolute Rank of T4 => sum of Relative Ranks of T3 and T4
0.0000278 + 0.0002778 => 0.0003056
If the above territories were to be sorted in order of their Absolute Ranks, the following would be the order:
Name Absolute Rank Absolute Rank *

10,000
T2 0.0003611 3.611111111
T1 0.0003333 3.333333333
T4 0.0003056 3.055555556
T3 0.0002778 2.777777778
T2 will be given highest preference and T3 will be given lowest preference.

5.2.2 Picking winning territories
Once the Absolute Ranks are derived, the winning territories can be easily identified. Depending on the value for
Number of Winners, different territories are returned as winning territories. The table below lists the different cases
depending on the Number of Winners. The winning territories are shown in the order in which they are retrieved.
Number of Winning Territories

winners
4 T2, T1, T4, T3
3 T2, T1, T4
2 T2, T1
1 T2
Note: Within a winning territory or a set of winning territories, there can be multiple resources defined. However,
only one resource needs to be identified for service request or service request task ownership assignment. In order to
be able to pick one resource out of a pool of resources returned by Oracle Territory Manager, Assignment Manager
and Advanced Scheduler use other logic like load balancing, resource availability, resource skills, parts availability,
travel distance etc to pick the winning resource. To learn more about these additional features please refer to the
Oracle TeleService Implementation and User Guide and the Oracle Advanced Scheduler User Guide3.
In cases where additional logic is not defined, the winning resource is selected randomly and no particular ordering is
followed.
3 http://download.oracle.com/docs/cd/B40089_07/current/html/docset.html

6 WEBADI
Oracle Territory Management has up taken the integration of WebADI in its module. This helps territory
administrators to better maintain their Territory details in a simple spread sheet format.
Territory structures can be exported from Oracle Territory Manager into an Excel spread sheet, and any additions or
changes made to the structure in the Excel spread sheet can be imported back into Oracle Territory Manager.
There are three simple steps to follow when using the WebADI feature:
1. Export data from Oracle Territory Manager into an Excel spread sheet
2. Edit changes in the spread sheet.
3. Import data from the Excel spread sheet into Oracle Territory Manager
6.1 Exporting data into an Excel spread sheet
Figure 6 – Web ADI – Exporting data into an Excel spread sheet

In the territory setup UI, click on the Export icon. The available options for export are:
Available Options Description
Selected node Exports territory details of the selected territory
Selected node and its Exports territory details of the selected territory
immediate children and all of its first level children territories
Selected node and all of its Exports territory details of the selected territory
children and all of territories underneath it
6.2 Edit changes in Excel spread sheet
Figure 7 – Web ADI – Edit changes in Excel spread sheet

Once the structure is exported to an Excel spread sheet, changes can be made to the structure. By selecting an
appropriate action – Create, Delete, or Update – the corresponding actions are performed when the structure is
imported back into Oracle Territory Manager.

6.3 Import data from the Excel spread sheet into Oracle Territory Manager
Figure 8 – Web ADI – Import data from Excel spread sheet into Oracle Territory Manager
After making changes to the structure in the spread sheet, the changes can be uploaded back into Oracle Territory
Manager by selecting the ‘Upload’ options in the special ‘Oracle’ menu in Excel.

7 ANATOMY OF A TERRITORY TYPE
The following screen shot shows the different components of a Territory Type.
Figure 9 – Anatomy of a Territory Type
In the above figure, a territory type called ‘SR Territories Only’ is defined. The three main components of the territory
type are shown – capturing the Usage, Transaction Types, and Qualifiers.
The list of qualifiers that are available when setting up territory types are those that are enabled for the Operating Unit
and Transaction Type selected.
When territories are defined based on the above template, the list of qualifiers that are available during territory
definition is restricted to the four qualifiers defined in the above template.
Administrators need to plan and define their territory types first before moving on to defining the actual territories.

8 ANATOMY OF A TERRITORY
The following set of screen shots show the different components of a territory. What is show in this example is a
territory that is based on the territory type ‘SR Territories Only’ defined in Figure 9.
8.1 Select Usage
Figure 10 – Selecting a Usage to filter the list of Territories
The list of Territories displayed to the Administrator is filtered by the ‘Usage’ selected. In this example, only
Territories used by the Service application are displayed.
8.2 Select Parent Territory
Figure 11 – Selecting a Parent Territory
A Parent Territory needs to be selected under which the new Territory can be created. In the case of a fresh
installation where there are no Territories defined, administrators need to select the root territory as the Parent
Territory. The root territory is the territory that is created for every operating unit – in the screen shot above ‘Vision
Operations’ is the root territory.

8.3 Select Territory Type
Figure 12 – Selecting a Territory Type
In the above screen shot, the new Territory definition is based on the ‘SR Territories Only’ Territory Type defined in
Figure 1. This indicates the following for the new territory:
• Can be used to determine ownership only for the Service Request Transaction Type
• The four Qualifiers that are defined in the Territory Type are the ones that can be used in the definition of the
new Territory
8.4 Define Basic Territory Information
Figure 13 - Basic Territory information

Each Territory needs to have a Name, Description, Rank, Start and End Dates.

8.5 Select Resources and Define their Access Levels
Figure 14 - Capture Resources
Resources together with their access levels form the third component of a territory. In the above screen shot, the
‘Access Type’ column refers to the ‘Transaction Types’ that were defined in the territory type. The ‘SR Territories
Only’ territory type in Figure 9 has one transaction type – Service Request – defined – therefore only one Access Type
is displayed in this territory definition. This means that resources in this territory can be used only for service request
assignment.
Note: If the same territory needs to be used for assignment for more than one transaction type, the territory type will
need to be defined with those transaction types first. The screen shot below shows a territory based on a territory type
whose definition contains all three Service transaction types. Resources defined in the territory below can be used for
service request tasks, service request, and standalone task ownership assignment.
Figure 15 – Territory with multiple Transaction Types

8.6 Select Geographic Qualifiers
Figure 16 - Geographic Qualifiers
Geographic qualifiers help break down a territory with respect to a location or an area on a map. For example, if
Thomas Johnson is based in the city of San Francisco, a territory can be defined to assign all service requests for the
city of San Francisco to Thomas Johnson.
Defining geographic qualifiers and their values is an optional component of a territory and can be skipped.
In the screen shot above, only the City Qualifier is displayed since the territory type defined in Figure 9 has only one
Geographic Qualifier defined – City.
Note: The other Geographic Qualifiers are Postal Code, State, Province, County, and Country.

8.7 Select Non Geographic Qualifiers
Figure 17 – Non Geographic Qualifiers
Non Geographic Qualifiers are the rest of the qualifiers. In the above screen shot there are three qualifiers displayed
since the territory type this territory is based on has only these three non geographic qualifiers defined.
From Figure 9 and Figure 10 we see how defining transaction types filter the list of qualifiers that are displayed,
making it easier to manage and create Territories.

APPENDIX A – LIST OF ALL SERVICE QUALIFIERS
LOV / SR/Task Attribute SR/Task Attribute
Qualifier Transaction Operators LOV Logic in Territory Works Works
# Free passed to Territory by passed to Territory by
Name Type Allowed Setup UI in AM? in AS?
Form Service Field Service
Geographical Qualifiers
All cities from table ‘HZ City of the Incident Address City of the Incident Address
Geographies’ where the associated to the service associated to the service
geography type = ‘CITY’. In request. request.
1 City Account Is Equal To LOV Yes Yes
addition all lookup codes This value is derived from table This value is derived from table
defined for lookup type ‘HZ_LOCATION’. ‘HZ_LOCATION’.
‘CS_CITY’ will also be listed.
All countries from table Country of the Incident Country of the Incident
‘FND_TERRITORIES_VL’. Address associated to the Address associated to the
2 Country Account Is Equal To LOV service request. service request. Yes Yes
This value is derived from table This value is derived from table
‘FND_TERRITORIES_VL’. ‘FND_TERRITORIES_VL’.
All counties from table ‘HZ County of the Incident Address County of the Incident Address
geography type = ‘COUNTY’. request. request.
3 County Account Is Equal To LOV In addition all lookup codes This value is derived from table This value is derived from table Yes Yes
‘CS_COUNTY’ will also be
listed.
Postal Code of the Incident Postal Code of the Incident
Is Equal To Address associated to the Address associated to the
4 Postal Code Account Between Free Form NA service request. service request. Yes Yes
Contains This value is derived from table This value is derived from table
‘HZ_LOCATION’. ‘HZ_LOCATION’.
All provinces from table ‘HZ Province of the Incident Province of the Incident
Geographies’ where the Address associated to the Address associated to the
geography type = ‘PROVINCE’. service request. service request.
5 Province Account Is Equal To LOV In addition all lookup codes This value is derived from table This value is derived from table Yes Yes
‘CS_PROVINCE’ will also be
listed.
All states from table ‘HZ State of the Incident Address State of the Incident Address
6 State Account Is Equal To LOV Yes Yes
geography type = ‘STATE’. In request. request.
addition all lookup codes This value is derived from table This value is derived from table

‘CS_STATE’ will also be listed.
Non Geographical Qualifiers

Area Code of the phone Area Code of the phone
Is Equal To
number associated to the number associated to the
7 Area Code Account Between Free Form NA Yes Yes
service request customer. service request customer.
Contains
Name of the Customer Name of the Customer
Customer All active parties from table associated to the service associated to the service
8 Account Is Equal To LOV Yes Yes
Name ‘HZ_PARTIES’. request. This is the Customer request. This is the Customer
who is reporting the issue. who is reporting the issue.
Name of the Customer Name of the Customer
associated to the service associated to the service
Is Equal To
Customer request. Territory Manager request. Territory Manager
9 Account Between Free Form NA ? ?
Name Range checks to see if the passed in checks to see if the passed in
Contains
Customer Name is within the Customer Name is within the
range setup in the territory rule. range setup in the territory rule.
If the Incident Address of the This Qualifier is not used in
SR is a party site, the Field Service.
Customer
10 Account Is Equal To LOV All active party sites from TCA. party_site_id of the Incident No No
Site *
Address is passed. If not
NULL is passed.
All active lookups from table The name of the week-day The name of the week-day
‘FND_LOOKUPS’ with lookup (Monday – Sunday) when the (Monday – Sunday) when the
type = ‘JTY_SR_WEEK_DAY’. service request is seeking service request is seeking
assignment. It can be the day assignment. It can be the day
Note: Introduced in R12.1.2 when the service request is when the service request is
11 Day of Week Account Is Equal To LOV Yes Yes
created or the day when it is created or the day when it is
updated. updated.
For service request tasks, the For service request tasks, the
day of the week is the day of day of the week is the day of
the task’s planned start date. the task’s planned start date.
Number of employees tied to Number of employees tied to
the Customer associated to the the Customer associated to the
Number of Is Equal To
12 Account Free Form NA Service Request. Service Request. ? ?
Employees Between
Column Column

‘EMPLOYEES_TOTAL’ in ‘EMPLOYEES_TOTAL’ in
table ‘HZ_PARTIES’ stores table ‘HZ_PARTIES’ stores
the number of employees the number of employees
associated to each party. This associated to each party. This
value is retrieved for the value is retrieved for the
Customer associated to the Customer associated to the
service request and passed to service request and passed to
Territory Manager. Territory Manager.
For SR Group and Individual The address_id of the Task
Owner Assignment: If the address from JTF_TASKS_B.
Incident Address of the SR is a
party site, the party_site_id of
the Incident Address is passed.
13 Site Number Account Is Equal To LOV All active party sites from TCA Yes Yes
If not, NULL is passed.
For Task Owner
Assignment: The address_id
of the Task address from
JTF_TASKS_B.
The time of the day when the The time of the day when the
Service Request is seeking Service Request is seeking
assignment. It is the hour and assignment. It is the hour and
Time of Day Is Equal To NA minutes component of the time minutes component of the time
14 (hh24:mi) Account Between Free Form when the Service Request is when the Service Request is Yes Yes
Contains Note: Introduced in R12.1.2 created or updated. created or updated.
For service request tasks, the For service request tasks, the
time of the day is the time of time of the day is the time of
the task’s planned start date. the task’s planned start date.
Is Equal To Nothing is passed from Service Nothing is passed from Field
At this point the LOV does not
15 Product Task Between LOV to AM. Candidate for Service to AM. Candidate for ? ?
return anything.
Contains obsolescence. obsolescence.
Is Equal To
16 Task Load Task Between Free Form Reserved for future use Reserved for future use Reserved for future use ? ?
Contains
All priorities from table Priority associated to the Priority associated to the
17 Task Priority Task Is Equal To LOV ‘JTF_TASK_PRIORITIES_VL’ Service Request Task. Service Request Task. Yes Yes
.
All statues from table Status associated to the Service Status associated to the Service
18 Task Status Task Is Equal To LOV Yes Yes
‘JTF_TASK_STATUES_VL’. Request Task. Request Task.

All task types from table Type associated to the Service Type associated to the Service
19 Task Type Task Is Equal To LOV Yes Yes
‘JTF_TASK_TYPES_VL’. Request Task. Request Task.
Component LOV The Component and The Component and
All active service items from the Subcomponent that is Subcomponent that is
item master table associated to the Service associated to the Service
‘MTL_SYSTEM_ITEMS_VL’ Request. Request.
which belong to the organization Note: These fields can be Note: These fields can be
that is returned by the function found in the ‘Subject’ tab of the found in the ‘Subject’ tab of the
‘CS_STD.get_item_valdn_orgzn Service Request Form. Service Request Form.
_id’
Subcomponent LOV
All active BOM items derived
Component/ Two
Service from the following tables:
20 Subcompone Is Equal To values Yes Yes
Request ‘MTL_SYSTEM_ITEMS’,
nt from LOV
‘BOM_BILL_OF_MATERIAL
S’, and
‘BOM_INVENTORY_COMP
ONENTS’.
All these items need to be setup
in the organization that is
returned by the function
‘CS_STD.get_item_valdn_orgzn
_id’. These items need to be a
subcomponent of the selected
Component.
All active lookups from table Contact preference of the Contact preference of the
Contact Service ‘AR_LOOKUPS’ where lookup Contact associated to the Contact associated to the
21 Is Equal To LOV ? ?
Preference Request type = service request. service request.
‘COMMUNICATION_TYPE’.
For SR Group and Individual The customer_site_id column
Owner Assignment and from
Task Owner Assignment: CS_INCIDENTS_ALL_B.
Customer Service If the Incident Address of the
22 Is Equal To LOV All active party sites from TCA. Yes Yes
Site Request SR is a party site, the
party_site_id of the Incident
Address is passed. If not,
NULL is passed.

Group Service All active groups from table Group owner associated to the Group owner associated to the
23 Is Equal To LOV ? ?
Owner Request ‘JTF_RS_GROUPS_VL’. service request. service request.
Inventory Service Inventory item associated to Inventory item associated to
24 Is Equal To LOV SAME AS IN #28. Yes Yes
Item Request the service request. the service request.
All platforms from table Supported Platform of the Supported Platform of the
‘MTL_SYSTEM_ITEMS’ that Product associated to the Product associated to the
belong to the organization that is service request. service request.
set in profile ‘Service: Inventory
Service
25 Platform Is Equal To LOV Validation Organization’. Also The Platform Item on the The Platform Item on the ? ?
Request
these platforms need to be under service request. service request.
the platform category set that is
set in profile ‘Service: Default
Platform Category Set’.
Primary Service
26 Is Equal To LOV Reserved for future use Reserved for future use Reserved for future use ? ?
Platform Request
All active lookups from table Problem Code associated to the Problem Code associated to the
‘CS_LOOKUPS’ where lookup service request. service request.
Problem Service
27 Is Equal To LOV type = Yes Yes
Code Request
‘REQUEST_PROBLEM_COD
E’.
All active service items from the Inventory item associated to Inventory item associated to
item master table the service request. the service request.
‘MTL_SYSTEM_ITEMS_VL’
Service
28 Product Is Equal To LOV which belong to the organization Yes Yes
Request
that is set in profile ‘Service:
Inventory Validation
Organization’.
Product LOV Product is the Item associated Product is the Item associated
All active service items from the to the service request. to the service request.
item master table
‘MTL_SYSTEM_ITEMS_VL’ Component and Component and
Product/Co which belong to the organization subcomponent are child items subcomponent are child items
Service Three
29 mponent/Su Is Equal To that is set in profile ‘Service: of the selected Product of the selected Product ? ?
Request LOVs
bcomponent Inventory Validation associated to the service associated to the service
Organization’. request. request.
Component LOV

from the following tables:
‘MTL_SYSTEM_ITEMS’,
S’, and
ONENTS’.
component of the selected
Product.
Subcomponent LOV
from the following tables:
‘MTL_SYSTEM_ITEMS’,
S’, and
ONENTS’.
subcomponent of the selected
Component.
Product Category Product Category is the Product Category is the
All product categories from table Inventory Category associated Inventory Category associated
‘MTL_CATEGORY_SET_VA to the service request. to the service request.
LID_CATS’ that belong to the
Product
Service Two Category Set that is set in profile Product is the Inventory Item Product is the Inventory Item
30 Category / Yes Yes
Request LOVs ‘Service: Default Item Category associated to the service associated to the service
Product
Set’. request. This product needs to request. This product needs to
belong to the selected product belong to the selected product
Product category. category.
All active items from the item

master table
‘MTL_SYSTEM_ITEMS_VL’
which belong to the organization
that is returned by the function
_id’. Also, the item needs to
belong to the selected Product
Category.
Is Equal To
Service
31 Product Type Between Free Form Candidate for obsolescence. Candidate for obsolescence. Candidate for obsolescence. ? ?
Request
Contains
All active lookups from table Channel through which the Channel through which the
Request ‘CS_LOOKUPS’ where lookup service request was created – service request was created –
Service
32 Creation Is Equal To LOV type = Phone, Email, Web, etc. Phone, Email, Web, etc. Yes Yes
Request
Channel ‘CS_SR_CREATION_CHANN
EL’.
All active severities from table Severity associated to the Severity associated to the
Request Service
33 Is Equal To LOV ‘CS_INCIDENT_SEVERITIE service request. service request. Yes Yes
Severity Request
S’.
All statues from table Status associated to the service Status associated to the service
Request Service
34 Is Equal To LOV ‘CS_INCIDENT_STATUES’ request. request. Yes Yes
Status Request
with subtype = ‘INC’.
All active types from table Type associated to the service Type associated to the service
Service
35 Request Type Is Equal To LOV ‘CS_INCIDENT_TYPES’. request. request. Yes Yes
Request
All urgencies from table Urgency associated to the Urgency associated to the
Request Service ‘CS_INCIDENT_URGENCIE service request. service request.
36 Is Equal To LOV Yes Yes
Urgency Request S’.
Service All active contract coverage Coverage type of the contract Coverage type of the contract
Service
37 Contract Is Equal To LOV types from table associated to the service associated to the service ? ?
Request
Coverage ‘OKS_COV_TYPES’. request. request.
All active serviceable items from Inventory Item Id defined in Inventory item defined in the
table ‘MTL_SYSTEM_ITEMS’ the Contract associated to the contract associated to the
Service which can be associated to a Service Request. service request.
38 Service Item Is Equal To LOV ? ?
Request contract. All these items need to Field Service passes item_id
be setup in the organization that + org_id from
is returned by the function OKC_K_ITEMS.

_id’.
Service All languages from table Preferred language of the Preferred language of the
Service
39 Request Is Equal To LOV ‘FND_LANGUAGES_VL’. customer associated to the customer associated to the Yes No
Request
Language service request. service request.
All active items from the item Subcomponent of the Subcomponent of the
master table Inventory Item associated to Inventory Item associated to
‘MTL_SYSTEM_ITEMS_VL’ the Service Request. the Service Request.
Subcompone Service
40 Is Equal To LOV which belong to the organization Yes Yes
nt Request
that is returned by the function
_id’
A concatenation of the party The support site where the The support site where the
name and address derived from owner of the service request is owner of the service request is
Service the following tables: located. Each support resource located. Each support resource
41 Support Site Is Equal To LOV ? ?
Request HZ_PARTIES, can be linked to a support site can be linked to a support site
HZ_LOCATIONS, and in Resource Manager. in Resource Manager.
HZ_PARTY_SITES.
Support Service
42 Is Equal To LOV Reserved for future use Reserved for future use Reserved for future use ? ?
Service Request
Is Equal To
Service List of all systems from Installed System attribute associated to System attribute associated to
43 System Between Free Form Yes Yes
Request Base. the service request. the service request.
Contains
Is Equal To
Service
44 System Type Between Free Form Reserved for future use Reserved for future use Reserved for future use ? ?
Request
Contains
VIP Service
45 Is Equal To LOV Reserved for future use. Reserved for future use. Reserved for future use. ? ?
Customers Request
* - Customer Site qualifier for Account Transaction Type – This qualifier is obsolete and is not used by Territory Manager. Customers should not use this qualifier
even though the Service API passes a value for this qualifier to the Territory Manager; instead the recommendation is for Customers to use the Site Number qualifier
for the Account Transaction Type OR the Customer Site qualifier for Service Request Transaction Type.

APPENDIX B – UPDATE STATEMENTS TO MODIFY QUALIFIER LOV SQL
Qualifier Name Update statement to modify LOV SQL associated to the qualifier
UPDATE jtf_qual_usgs_all j
SET j.HTML_LOV_SQL1 = 'SELECT DISTINCT a.geography_name col1_value, a.geography_name col2_value, ' || 'null col3_value, a.geography_element1 col4_value FROM hz_geographies a
WHERE a.geography_type = ''CITY'' UNION ' || 'SELECT DISTINCT a.meaning col1_value, a.meaning col2_value, null col3_value, null col4_value ' || 'FROM cs_lookups a WHERE
City
a.lookup_type = ''CS_CITY'' ' || 'ORDER BY col1_value', j.DISPLAY_SQL1 = 'SELECT city_list.city_name ' || 'FROM ( select distinct a.geography_name city_name ' || 'FROM hz_geographies
a ' || 'WHERE a.geography_type = ''CITY'' UNION ' || 'select distinct a.meaning city_name ' || 'from cs_lookups a ' || 'where a.lookup_type = ''CS_CITY'' ) city_list ' || 'WHERE city_list.city_name
='WHERE j.qual_usg_id = -1040;
SET j.HTML_LOV_SQL1 = 'SELECT DISTINCT a.geography_name col1_value, a.geography_code col2_value, ' || 'null col3_value, a.geography_element1 col4_value FROM hz_geographies a
WHERE a.geography_type = ''STATE'' UNION ' || 'SELECT DISTINCT a.meaning col1_value, a.lookup_code col2_value, null col3_value, null col4_value ' || 'FROM cs_lookups a WHERE
State
a.lookup_type = ''CS_STATE'' ' || 'ORDER BY col1_value ', j.DISPLAY_SQL1 = 'SELECT state_list.state_name ' || 'FROM ( select distinct a.geography_name state_name, ' ||
'a.geography_code state_code ' || 'FROM hz_geographies a ' || 'WHERE a.geography_type = ''STATE'' ' || 'UNION ' || 'select distinct a.meaning state_name, '
|| 'a.lookup_code state_code ' || 'from cs_lookups a ' || 'where a.lookup_type = ''CS_STATE'' ) state_list ' || 'WHERE state_list.state_code = 'WHERE j.qual_usg_id = -1042;
SET j.HTML_LOV_SQL1 = 'SELECT DISTINCT trim(a.geography_name) col1_value, trim(a.geography_name) col2_value, ' || 'trim(geography_element2) col3_value,
trim(a.geography_element1) col4_value FROM hz_geographies a WHERE a.geography_type = ''COUNTY'' UNION ' || 'SELECT DISTINCT a.meaning col1_value, a.meaning col2_value, null
County col3_value, null col4_value ' || 'FROM cs_lookups a WHERE a.lookup_type = ''CS_COUNTY'' ' || 'ORDER BY col1_value ', j.DISPLAY_SQL1 = 'SELECT county_list.county_name ' || 'FROM
( select distinct a.geography_name county_name ' || 'FROM hz_geographies a ' || 'WHERE a.geography_type = ''COUNTY'' ' || 'UNION '
|| 'select distinct a.meaning county_name ' || 'from cs_lookups a ' || 'where a.lookup_type = ''CS_COUNTY'' ) county_list ' || 'WHERE county_list.county_name =' WHERE j.qual_usg_id = -
1044;
SET j.HTML_LOV_SQL1 = 'SELECT DISTINCT a.geography_name col1_value, a.geography_code col2_value, ' || 'null col3_value, a.geography_element1 col4_value FROM hz_geographies a
WHERE a.geography_type = ''PROVINCE'' UNION ' || 'SELECT DISTINCT a.meaning col1_value, a.lookup_code col2_value, null col3_value, null col4_value ' || 'FROM cs_lookups a WHERE
Province a.lookup_type = ''CS_PROVINCE'' ' || 'ORDER BY col1_value ', j.DISPLAY_SQL1 = 'SELECT province_list.province_name ' || 'FROM ( select distinct a.geography_name province_name, ' ||
'a.geography_code province_code ' || 'FROM hz_geographies a ' || 'WHERE a.geography_type = ''PROVINCE'' ' || 'UNION '
|| 'select distinct a.meaning province_name, ' || 'a.lookup_code province_code ' || 'from cs_lookups a ' || 'where a.lookup_type = ''CS_PROVINCE'' ) province_list ' || 'WHERE
province_list.province_code ='WHERE j.qual_usg_id = -1046;

Note: The above SQL statements can be executed directly in the database. After executing any of the above statements, execute the COMMIT statement for the
changes to take effect.

APPENDIX C - ERD
Usage
Territory / Usage JTF_SOURCES_ALL Territory Types / Usage
Individual Resources JTF_TERR_USGS_ALL EBS Applications that use Territory Manager for JTF_TERR_TYPE_USGS_ALL
JTF_RS_RESOURCE_EXTNS Defines Territories for a given Usage. ownership assignment. They are: Defines Territory Types for a given Usage.
Individual Resources of Type: The setup UI allows a Territory to belong Service The setup UI allows a Territory Type to
Employee Groups to only one Usage. Example: Sales belong to only one Usage. Example:
Partner JTF_RS_GROUPS_B Usage = Service Service Contracts Usage = Service
Party Territory = Bay Area District; Western Trade Management Territory Type = Service Territory
Supplier Contact Region Collections Template
To be hired
Partner Management
Other
Teams
JTF_RS_TEAMS_B
Territory / Transaction Types

Usage / Transaction Type Territory Type / Transaction Types
JTF_TERR_QTYPE_USGS_ALL
JTF_QUAL_TYPE_USGS_ALL JTF_TYPE_QTYPE_USGS_ALL
Stores the association between
Defines the Transaction Types for a given Defines Transaction Types for a given
Territories and Transaction Types
Territories Usage. A Transaction Type can belong to only Territory Type. Example:
Territory Resources
(within an EBS Application) that use
one Usage. Example:
Territory Types
JTF_TERR_ALL Territory Type = Service Territory
them. Example: JTF_TERR_TYPES_ALL
JTF_TERR_RSC_ALL Based on a Territory Type and defines a Usage = Service Template
Transaction Type = Service Blueprint for a Territory defined
Defines Resources for a given Territory. configurable business rule. Example: Transaction Type = Service Request; Transaction Type = Service Request;
Request by a Usage, specific set of
Resources defined within a Territory will be Name = Bay Area District Service Request Task; Task Task
Territory = Bay Area District Transaction Types and
used for ownership assignment. Example: Parent Territory = Western Region
Qualifiers. Example:
Territory = Bay Area West Territory Type = Service Territory
Name = Service Territory
Resource = Smith, John; Barry, Steve Template
Template
Rank = 10
Transaction Types
Resource Access Level JTF_QUAL_TYPES_ALL
JTF_TERR_RSC_ACCESS_ALL Business Objects within each EBS
Defines what kind of access a resource Operating Application (Usage) that use Territory Operating
has for a Transaction Type. Example: Manager for ownership Assignment. Unit
Unit
Resource = Smith, John Example – for the Service Application the
Access Level = Default; Escalation Transaction Types are:
Owner Service Request Qualifiers / Transaction Type
Territory Type / Qualifiers
Territory / Qualifier Service Request Tasks JTF_QUAL_USGS_ALL
JTF_TERR_TYPE_QUAL_ALL
JTF_TERR_QUAL_ALL Tasks Defines Qualifiers for a given Transaction
Defines Qualifiers for a given
Defines Qualifiers for a given Type (within an EBS Application). A
Territory Type. Example:
Territory. Example: Qualifier can belong to only one
FND Lookups Territory Type = Service
Territory = Bay Area District Transaction Type. Example:
FND_LOOKUP_TYPES_VL Territory Template
Qualifier = Service Request Transaction Type = Service Request
Stores Oracle Application Object Library Quick Codes Qualifier = Service Request
Type; Postal Code Qualifier = Service Request Type;
types. The Resource Access Levels are stored in Lookup Type; Postal Code
Postal Code
type ’JTY_SERVICE_RSC_ACCESS’. The Access Level
Lookup Codes are:
Default
None
Primary Contact
Escalation Owner
Escalation Resource Qualifiers
Qualifier Values
JTF_SEEDED_QUAL_ALL_B
JTF_TERR_VALUES_ALL
Defines attributes of a Transaction Type. They could be Geographic or
Stores the values assigned to each qualifier.
Non Geographic. Example:
Values could be stored in the following Legend: Color Codes Used
expressions: Is Equal To, Between, and
Contains. Example:
Geographic Non Geographic Territory Definitions
Service Request Type = Dell Laptops City Service Request Type Territory Type Definitions
Postal Code Between 94000 and 95000 Postal Code Service Request Status Seed Data
State Service Request Creation
External Reference
Province Channel
County Service Request Severity
Country For a full list see Appendix – A.

September 2010 revised October 2013
Author: Denzil Joseph
Contributing Authors: John Olszewski, Vasanth Terrance
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com
Copyright © 2007, Oracle. All rights reserved.

This document is provided for information purposes only and the
contents hereof are subject to change without notice.
This document is not warranted to be error-free, nor subject to any
other warranties or conditions, whether expressed orally or implied
in law, including implied warranties and conditions of merchantability
or fitness for a particular purpose. We specifically disclaim any
liability with respect to this document and no contractual obligations
are formed either directly or indirectly by this document. This document
may not be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without our prior written permission.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Other names may be trademarks of their respective owners.

TerritoriesWhitePaper V11 PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

TerritoriesWhitePaper V11 PDF

Caricato da

Copyright:

Formati disponibili

Release 12.1.

1 Executive Overview ................................................................................................................... 2

R12 Service Territories Page 1

2 E-BUSINESS SERVICE ROUTING SOLUTION

R12 Service Territories Page 2

3 E-BUSINESS SUITE ORACLE TERRITORY MANAGER

Oracle Territory Manager consists of the following main components:

3.4 WebADI Interface for ease of Maintenance

R12 Service Territories Page 3

Territory Usage has the following benefits:

4.2 Territory Types

R12.1.3 Service Territories Page 4

R12.1.3 Service Territories Page 5

4.4.1 Enabling and disabling qualifiers

Figure 1 – Enabling / disabling territory qualifiers

R12.1.3 Service Territories Page 6

4.4.2 Geographic Qualifiers – Alternative Spelling for Geographic Qualifiers

R12.1.3 Service Territories Page 7

4.4.3 Solution Implementation – Alternative Spelling for Geographic Qualifiers

R12.1.3 Service Territories Page 8

4.5 Access Levels

R12.1.3 Service Territories Page 9

• SR Type = ‘Dell Laptops

R12.1.3 Service Territories Page 10

4.7 Catch Alls

R12.1.3 Service Territories Page 11

Figure 2 – Root Territory named after Operating Unit - Case 1

R12.1.3 Service Territories Page 12

Figure 4 - List of qualifiers displayed in the AM UI

R12.1.3 Service Territories Page 13

5.1 Locate Matching Territories

R12.1.3 Service Territories Page 14

Figure 5 - Territory Expression Evaluation - Example setup

The parent territory has the following qualifier and expression:

The child territory has the following qualifiers and expressions:

R12.1.3 Service Territories Page 15

Request Creation Channel Is Equal To Web AND

R12.1.3 Service Territories Page 16

5.1.2 Using Contains

R12.1.3 Service Territories Page 17

5.1.3 Using Between

R12.1.3 Service Territories Page 18

R12.1.3 Service Territories Page 19

5.2.1 Sorting matching territories

Absolute Rank of a territory is calculated as follows:

Let us assume that the following Territory structure is defined:

R12.1.3 Service Territories Page 20

T3 60 1 0.0002778 0.0002778 2.777777778

Name Absolute Rank Absolute Rank *

T2 will be given highest preference and T3 will be given lowest preference.

R12.1.3 Service Territories Page 21

Number of Winning Territories

R12.1.3 Service Territories Page 22

6.1 Exporting data into an Excel spread sheet

Figure 6 – Web ADI – Exporting data into an Excel spread sheet

6.2 Edit changes in Excel spread sheet

Figure 7 – Web ADI – Edit changes in Excel spread sheet

R12.1.3 Service Territories Page 23

R12.1.3 Service Territories Page 24

Figure 9 – Anatomy of a Territory Type

R12.1.3 Service Territories Page 25

8.1 Select Usage

Figure 10 – Selecting a Usage to filter the list of Territories