R12 – Territory Manager – JTY

Back to R12 – Upgrade Overview

In 11i we assign collectors using the profile options and optionally manually override this at account level if needed.

This gets rather hard to manage in large departments especially when people leaves or joins.

However in R12 you have the ability to use Territory Manager which originally is a sales tool for sales territory administration.

You can now also assign collectors at Customer/Party level however this easily cannot be seen as the collector cannot be stored at this level but is stored in an internal table instead.

The Territory Manager will assign collectors to delinquent customers automatically hence removing the need to manage customer profile class plus account and bill to level overrides. When assigning collectors to customer profile class just use the “Default Collector” – this value will be overridden by the Territory Manager if the customer becomes delinquent.

The article below will mainly concentrate on the use of Territory Manager with Advanced Collections.

Overview

  • Implementing
  • Territories – Intro
  • Resources
  • Matching Attributes
  • Territories – Defining
  • Concurrent Programs

Implementing

JTY is a bit tricky to get started with in form of an extra layer of role based access control (RBAC).

In order to setup JTY you need to following:

  • Login as user SYSADMIN
  • Using responsibility “User Management” grant role to yourself: “Security Administrator”
    or if not allowed then just grant roles to yourself:
    ”Collections Territory Administrator”
    ”Territory Manager Application Administrator”
  • Also assign yourself responsibilities “User Management” and “Territory Management”
  • Login as yourself
  • Using responsibility “User Management” grant roles to yourself (if not done above):
    ”Collections Territory Administrator”
    ”Territory Manager Application Administrator”

Also be aware that JTY uses full MOAC control so be sure to set correct Security Profile.

Note: You must set the profile option “MO: Default Operating Unit” due to an error in the 12.1.2 Territory Definition form. You should however leave “MO: Operating Unit” blank.

Territories – Intro

Territories in Advanced Collections are used to distribute the UWQ workload amongst collectors in large departments.

A single territory has one or more resources assigned and matching attributes that applies to customer attributes.

Territories can form a hierarchy where we have the following territory types:

  • Child Territory – Contains resources and matching attributes
  • Parent Territory – Contains one or more child territories
  • Catch-All Territory – A parent territory containing rules not covered by child territories below
  • Placeholder Territory – A parent territory not containing rules but only child territories
  • OU Territory – The top level owning parent territory. There is one per OU accessible

All territories can be defined using OAF forms or by using WebADI except for the OU territory which cannot download to Excel. Therefore it is a good idea to have a placeholder territory just below the OU territory.

Territories have the additional following attributes:

  • Effective Date Range – Value inherited from parent territory
  • Rank – a number where lowest rank wins if customer matches more than one territory.
    Normally just assign value: 1
    This value is inherited from parent territory
  • Winners – number of territories a customer can match at any one time.
    Default to 1 when left empty. 2 or higher can cause overlapping territories

Resources

In order to define resources you need to have access to the responsibility “CRM Resource Manager”.

Resources can be any one of:

  • Individual – CRM resource
  • Group – CRM defined group. Groups can be assigned to multiple individuals
  • Team – Similar to group but normally used in lead management

Groups can be a handy way of managing customers so instead of reassigning individuals to customers you assign groups to customers. This enables you to manage your resources by reassigning individuals between groups rather than between specific customers.

Matching Attributes

Matching Attributes are building blocks for creating rules for assigning customers to territories.

Advanced Collections only supports custom made or Customer based matching attributes which is the following:

  • Account Classification (this is actually a sales lead item and does not really work with Collections)
  • Area Code
  • City
  • Country
  • County
  • Customer Category
  • Customer Name
  • Customer Name Range
  • Customer Name Range Group
  • D-U-N-S
  • Number of Employees
  • Party Hierarchy
  • Postal Code
  • Province
  • Registry ID
  • SIC Code
  • Site Number
  • State

So if there is a need to allocate collectors based on something different than the list above you will need to create a custom matching attribute.

In order to use a matching attribute it must be enabled first:

image

In the above I will be enabling Customer Category and Customer Name Range.

Next step is to define a Territory Type in order to use the enabled attributes above:

image 

So now we have created a territory type allowing the use of Customer Category and Customer Name Range.

Territory – Defining

You start from the OU territory and work your way down:

image

Note the search default to what you have in your profile options “MO: Default Operating Unit” however if another OU is desired just change the value in “Operating Unit” and click GO. Do not leave “Operating Unit” blank as that may cause problems in pre-R12.1.4 versions.

Select the operating unit “Vision Operations” and click “Create”:

image

Pick the Territory Type we created earlier and click continue:

image

Lets create the following hierarchy:

Vision Operations – OU Territory
> Top – Placeholder Territory
>> Other
>>> Commercial – Parent
>>>> NameRange1 – Child
>>>> NameRange2 – Child
>>> Federal – Child

So we want a catch all if a customer has not been assigned to a customer category and we split the commercial customers into two name ranges to level the volume.

So first we create Top:

image

No resources and matching attributes – so just click Finish:

image

Lets create the Other territory:

image

Click Next and add resource:

image

Assigned just one resource as this is the resource for an exception – the catch all.

I will not show how to add resources to the remaining territories…

Click next:

image

In spite of what the manual says you need to add a matching attribute for a catch-all territory. To ensure we catch all customers we use name range of 0% to Z%.

To define ranges like the one above you need to follow some basic rules:

  • Always use wildcard “%” so A to Z becomes A% to Z%
  • Single wildcard range will not work like A% to A%
  • If range for one letter is needed use: A0% to AZ%

Next we define Commercial and Federal territories…

Commercial matching attribute:

image

Federal matching attribute:

image

The we add another two Commercial child territories…

Name range 1:

image

and name range 2:

image

So now we have:

image

Nice and easy…

Concurrent Programs

When you have finished creating your territory hierarchy you need to run the following in JTY:

  • Synchronize Territory Assignment Rules

This is one of these programs with no real purpose except for if you don’t run it – it will not work.

When you want to assign territories to collectors and customers you must run the following in IEX:

  • IEX: Territory Assignment

But ONLY after you have run the IEX: Scoring Engine Harness with Delinquencies Management otherwise you may miss any newly delinquent customers.

This entry was written by Kent Willumsen , posted on Tuesday August 03 2010at 06:08 pm , filed under Functional Knowledge, Territory Manager and tagged , , . Bookmark the permalink . Post a comment below or leave a trackback: Trackback URL.

Comments are closed.