I have heard this title few times and always thought: “Mhhh… Either it will never do what I need… Or it will be full of bugs… Or it’s probably a hell configuring it”
Well, no. It works, and it’s also a nice feature. If you have to deal with a complex geography which need to be mapped in CRM, for instance structuring Business Partner and Sales Representative relationships, Territory Management may turn very useful.
So let’s start giving a look at it.
SAP CRM Territory Management component is specifically designed to structure and organize markets by dividing it into territories through a territory hierarchy.
A country geographic structure can be mapped into Territory Hierarchy through existing Standard Attributes or Additional Attributes according to customer flavour (attributes maps Business Partner Master Data fields). Hence Business Partners will be automatically assigned to the appropriate Territory Level accordingly.
Customers are able to assign a Territory Level to a Position in the Organizational Structure in order to indirectly assign the Employee Responsible assigned to that Position.
Territory Hierarchy can be changed anytime according to customer needs and market development, splitting and merging (logically) Territory Levels; business partner assignment is dynamic and will follow without any need to adjust existing data, de facto decoupling the assignment between BP Employee/Position from geographical area (it’s indirect through Territory). Hence, Sales Representative replacement can be achieved in a quick and simple way.
Also remember that a skilful Organizational Assignment Plan allow easy management of SR vacation and temporary replacement. Let me repeat that, once you have built your Territory Hierarchy and assigned Organizational Structure Positions to each Territory Level as needed, the appropriate Sales Representative is dynamically determined according to his assignement to the Position based on assignment plan and corresponding validity dates. That’s beautiful.
Additional benefits are the availability of standard determination procedure and replication rule to Mobile Application, based on Territory; in addition if pricing is done on CRM you can use it in condition tables to define pricing.
Territories are created according to few customizing options. Levels need to be defined as n-tier stack, each one with it’s own Territory ID length, hierarchy can thus be created accordingly strictly to the defined n-levels. But not every hierarchy level has to be sub-structured to the maximum n-tier.
Attributes need to be maintained in customizing. Attributes such as Country/Region/ZIP/City are assigned to territory levels in order to appoint to each Territory Level those BPs whose addresses matches appropriately.
A Territory Level could have been assigned ZIP ranging from 1100 to 1200 for Country Botswana, BP with the matching address would be appointed accordingly.
You can assign BP numbers directly, and you can code BADIs to better trim selections.
Among the missing functionalities I would surely count the display of assigned territory level in the standard BP transaction. You just don’t see it there. But nowadays there are plenty of option to customize it in order to show that piece of information.
A custom field can be added to BP MD using Easy Enhancement WorkBench, code generated can be easily changed to query the appropriate function module: CRM_TERRMAN_GET_TERR_BY_BUPA, in order to retrieve the assigned Territory Level to show, the sames goes for the assigned Sales Representative.
As I said it’s a nice feature, it’s quite easy to configure and does offer some customization. I suggest taking it into consideration and adopt it whenever it’s possible.