Companies are looking for ways to manage their sales forces more effectively. Did you know that Territory Management in SAP CRM allows you to divide your sales force according to criteria such as market or geographical location? Furthermore, by using Territory Management in a sales scenario, you can set up SAP CRM to determine the sales team in the sales documents dynamically based on the sold-to party in the sales order.

Although Territory Management has been available since SAP CRM 4.0, there is limited knowledge in the field. Let me show you how it can help you plan your sales force deployment. I’ll share tips I have learned through my experience in implementing Territory Management and show areas where you could customize it to meet your business needs. To do this, I will walk you through five parts of implementing Territory Management:

• Part 1: Configure the territory hierarchy
  
  
• Part 2: Configure the territory attributes
  
  
• Part 3: Configure the business partner functions
  
  
• Part 4: Maintain the territories
  
  
• Part 5: Assign authorization objects

I’ll use the example of a company, PC Works, which divides its markets based on country, zip code, and the revenue and industry vertical of the sold-to party. In this case, if the sold-to party in the sales document belongs to an industry vertical, then the system should determine two business partners in the sales document — the sales representative, based on the sold-to party’s zip code, and the vertical responsible, based on the industry to which the sold-to party belongs.

Part 1: Configure the Territory Hierarchy

The system defines the territory hierarchy based on how you divide your market. For this part of the process, you need to configure the territory hierarchy in two steps. First, you determine how many levels you want in the hierarchy, then you define the length of the territory ID.

Step 1. Determine how many levels you want in your hierarchy. In my example, the levels are defined as 0 Company, 1 Business Unit, 2 Region, 3 Area, and 4 Sub-Area. The hierarchy can be as deep as your business needs demand. Maintain the levels via transaction SPRO and follow menu path Customer Relationship Management>Master Data>Territory Management>Define Territory Hierarchy Levels as shown in Figure 1.

Figure 1

Define territory levels

After you define the territory levels and the system is live, avoid changing the number of levels because your old and new documents will have different levels. You can still merge, split, and create new territories.

Step 2. Define the length of the territory ID. Territory IDs are unique IDs given for each node in the territory hierarchy. You need to define how long each of the territory IDs should be for each level. Select the hierarchy level in Figure 1 and click on the lens icon to go to Figure 2. Enter the desired length in the Length field.

Figure 2

Details of the level

Part 2: Configure the Territory Attributes

Territory attributes define the responsibility of each of the territories. The system uses these attributes to determine the territory in the sales transaction. The system matches attributes from the sales document to the territory that has the same attributes — this is the territory of the sales document. For example, the country and zip code of a sold-to party can be a determination parameter to find the territory.

SAP provides a standard set of attributes, but you also can add your own attributes. If you only need standard attributes, follow the process in the “Standard Attributes” section. If you need custom attributes, follow the process in the “Custom Attributes (Optional) ” section. In the projects I’ve worked on, implementations typically require a mix of standard attributes (e.g., country or zip code) and custom attributes.

Standard Attributes

Some of the standard attributes SAP provides are:

• Geographical locations
  
  
• Products, such as product category or product hierarchy
  
  
• Directly assigned business partners
  
  
• Sales area. You can restrict the territory responsibility to certain parts of the sales organization to ensure, for example, that a territory (where certain sales areas are assigned as an attribute) is only responsible for products and customers of this sales area.
  
  
• Customer hierarchy nodes. Direct assignment of hierarchy nodes defines responsibility for all business partners assigned to this hierarchy node and all business partners assigned to hierarchy nodes below the directly assigned one.

Table 1 shows the standard attributes that are available out of the box.

You can activate these attributes by following menu path CRM>Master Data>Territory Management>Activate/Deactivate Attributes, as shown in Figure 3. Transfer the attributes you want to activate from the right side to the left side of the screen.

Figure 3

Activate/deactivate standard attributes

Custom Attributes (Optional)

You can add your own attributes to Territory Management if the standard attributes do not meet your needs. Some examples of when you might need custom attributes include:

• You defined marketing attributes for your business partner. When creating a sales document you want to use the values of marketing attributes of the sold-to party to determine the territory.
  
  
• You used Easy Enhancement Workbench to add fields to the business partner. When creating a sales document you want to use the value in these fields of the sold-to party to determine the territory.

To add the new attributes for your territory, follow these two steps. In my example, I have two custom marketing attributes that I want to use — Z_MKT_VERTICAL, which represents the business partner’s industry vertical, and Z_COMP_SIZE, which classifies the business partners according to their gross revenues. If you do not need to add custom attributes, you can skip to Part 3.

Step 1. Create an append structure in table CRMM_TERRATTRIB with the additional fields. Use transaction SE11. Enter CRMM_TERRATTRIB in the Transp. Table field and click on the Display button. In the screen that appears, click on the Append Structure… button, as shown in Figure 4. Enter the name of the structure that you wish to append, for example, ZTERR_ATTRIBUTES.

Figure 4

Add the append structure

Then enter the field names and the corresponding data elements. The field names are the fields that you want to add as custom attributes. In my example, I want to use the custom attributes Z_MKT_VERTICAL and Z_COMP_SIZE, so I added these as the fields in the structure as shown in Figure 5. Activate the new structure by clicking on the activate icon. After you activate the structure, you can see that in the table CRMM_TERRATTRIB, the new structure is visible towards the end as shown in Figure 6.

Figure 5

Append structure

Figure 6

The append structure is added to the table CRMM_TERRATTRIB

Step 2. Create an append structure in the structure. Follow the same process you did in step 1, only this time enter CRMT_TERRMAN_LOCA_SEARCH.

Part 3: Configure the Business Partner Functions

In this optional step, you can set up Territory Management to determine the sales team and assign the correct partner function to the sales team members. By activating the partner functions, you determine what roles Territory Management should determine. This functionality helps you manage the sales force effectively by providing it the right role in the sales document. This customizing step is optional. If you omit this step, the partner function is not visible when you maintain a territory, and all employees are assigned without a specific partner function to territories. If this suits your needs, you can skip to part 4.

In my example, I have a pharmaceutical territory defined for New Jersey. I assign four employees to this territory: Anil Mehta as a sales representative, Carol Jones as a key account manager, David Brown as a marketing specialist, and Andrea Michel as an industry expert. You can set up the system so that the partner functions are determined automatically in the business transaction. Data linked to the territory is distributed in Field Sales to the sales representative, industry expert, and key account manager, and not to the marketing specialist — even though the key account manager is not determined in the sales document.

Define the partner functions in transaction SPRO and follow menu path Customer Relationship Management>Basic Functions>Partner Processing>Define Partner functions. These are the same partner functions that you define in a partner determination procedure for a transaction. Refer to my article, “How to Set Up Business Partner Determination in mySAP CRM,” in the January/February 2007 CRM Expert for more information about this process.

After you have your partner functions you can decide which partner functions you want Territory Management to determine. You can also decide whether you want to download them to Field Sales. Use transaction SPRO and follow menu path Customer Relationship Management>Master Data>Territory Management>Assign Partner Function to Assignment Function Category.

You must map the partner functions to the assignment function categories. SAP predefines three assignment function categories — Sales Rep (0000), Field Sales Data Receiver (0001), and Back Office (0002). I use the Sales Rep and Field Sales Data Receiver categories for this example. The assignment function category determines how the partner function behaves in the sales document (Table 2).

For example, suppose you want Territory Management to determine two partner functions (industry expert and sales representative). The key account manager should get the information on her mobile device for the accounts she is responsible for even though she is not part of the sales document. In this case, maintain the three entries shown in Table 3.

After you define the partner functions, you need to assign the partner access sequence 0030, which is the standard access sequence that takes the sold-to party of the sales document as the source and finds the territory. After the system determines the territory, the system populates the users assigned to the territory in the sales document with the partner functions determined. I explain this in further detail in part 4. You also can refer to my article, “How to Set Up Business Partner Determination in mySAP CRM,” in the January/February 2007 CRM Expert for the access sequence setup.

If you maintain the settings as shown in Table 3 and assign the access sequence, then the system determines Andrea Michel and Anil Mehta in the business transaction automatically, but not Carol Jones and David Brown. However, Carol Jones will get the subscription to her mobile client if the field sales is active.

Part 4: Maintain the Territories

After you define the levels in your territory hierarchy, activate the attributes, and define the partner functions, you can link your employees to these territories. This is the most important part of the process because you delegate which employee is responsible for which territory.

Create the territories and assign them in transaction CRMM_TERRMAN (Figure 7). The back office is typically responsible for maintaining the territories, so these employees need access to this transaction. The authority for this trans-action is governed by the authorization object CRM_TERRMA, which I explain in detail in part 5.

Figure 7

Transaction CRMM_TERRMAN

This part of the process involves three steps: create the territory structure, assign the attribute values, and assign the employee position to the territory.

Step 1. Create the territory structure. Now that you’ve completed the previous parts of Territory Management, the territory hierarchy defined in Figure 7 is:

Level 0: SAP America

Level 1: Line 1

Level 2: North East

Level 3: New Jersey

Level 4: New Jersey East

Step 2. Assign the attribute values. With custom attributes you should provide some search help for your users when they maintain the values for these attributes. In addition, you must ensure that the system uses these attributes to determine the correct territory. For both of these tasks, SAP provides the Business Add-in (BAdI) CRM_TERRMAN_ATTRIB containing four methods, each of which provides a different functionality:

• GET_F4_HELP is called if the user requests input help for the custom attributes or if the system needs to check the entered value (existence check)
  
  
• GET_ATTRIB_DESCRIPTION finds a description text for an attribute value (e.g., NJ for New Jersey in Figure 6)
  
  
• GET_RELAT_OBJECTS finds all related business objects that comply with the attribute value. The system uses this function when you follow menu path Territory Management>Maintain Territory Hierarchy. Select Number of Objects in Territory.
  
  
• GET_BUSOBJ_ATTRIB_VALUE is the opposite of GET_RELAT_OBJECTS. You use it to determine an attribute value from a number of defined business objects.

For each method, you need to add ABAP code to tell it how to work. Figure 8 includes the sample code for the method GET_F4_HELP. To view all of the code you use in this method and the other three methods, go to the Downloads section at the end of this article.

METHOD   if_ex_crm_terrman_attrib~GET_F4_HELP. TYPES:   TYPES : BEGIN OF attribute_desc,             value TYPE atwrt,             description TYPE crmt _atwtb,           END OF attribute_desc. CASE iv_fieldname.     WHEN 'Z_MKT_Vertical' or 'Z_Comp_Size'.         CALL FUNCTION 'CRM_MKTPFCHR_READ'           EXPORTING             iv_name_char   & nbsp;     = iv_fieldname           TABLES             et_charactvaluedescr =&nbs p;lt_charactvaluedescr.     LOOP AT lt_charactvaluedescr INTO ls_charactvaluedescr.      ls_f4_values-value = ls_charactvaluedescr-value_char.      ls_f4_values-description = ls_charactvaluedescr- description.      APPEND ls_f4_values TO lt_f4_values.    ENDLOOP. ………………….   ENDCASE. ENDMETHOD.

Step 3. Assign the employee position to the territory. The best case is when you assign all of the attributes and employees at the leaf node, the lowest node in the territory hierarchy that you have maintained for each tree. For example, if you defined four levels in your territory hierarchy configuration, then the territory IDs at the fourth level are leaf nodes.

In my example, the territory New Jersey East is the leaf node. Figure 9 shows the leaf node in the territory hierarchy and how to maintain employees and territory attributes. You assign the users to the territory through their positions in the organization model, which you defined in Organizational Management (OM).

Figure 9

Attributes and position assignment

When you assign a position to the territory, all employees who belong to that position become responsible for this territory. After you assign this, the OM position also has a reference to the territory as shown in Figure 10.

Figure 10

Position assigned

You can assign an employee to more than one territory (same position assigned to multiple territories) and more than one employee to the same territory (more than one position assigned to the territory). As you can see in Figure 10, you can set a default territory flag for each employee by selecting the check box next to the employee to avoid receiving a decision pop-up screen when you determine more than one valid territory, such as in business transactions.

If you activated the partner functions feature, you also see the Partner Function column in Figure 10. When the system determines this territory (New Jersey East) as the territory of the sales document, then the system determines the two employees listed in Figure 10 (Andrea Michel and Anil Mehta) in the sales document with respective partner functions.

Territory Management allows you to plan the territories with date ranges so that you can plan them in advance, as shown in Figure 11. This is useful if you want to have time-dependant territory determination. For example, if your market is changing —big territories are splitting or small territories are merging — you can prepare your system in advance.

Figure 11

Validity period assignment

Part 5: Assign Authorization Objects

As with other CRM objects, such as business partners or products, you must control authorization to the territory master data. This could include who maintains and changes the territory structure or which users are allowed to edit which territory hierarchy.

Two authorization objects, CRM_TERRMA and CRM_TERRDY, provide these rights. In the transaction PFCG you can create a role for your users and assign these authorization objects with the correct field values to the role. Then you can assign users to this role and they will have the access rights as maintained in the role. This enables users to see only the territory nodes designated in the authorization object.

CRM_TERRMA controls which territories the user may process. This authorization object has following two fields for controlling authorizations:

• ACTVT (activity): The type of activity is allowed for users who have this authorization object their profiles. There are three possible activities: create, change, and display.

• PATH_ID (territory hierarchy ID): This is the territory hierarchy ID as shown in Figure 10.

CRM_TERRDY controls which territories the user may process according to the assignment of the user in the territory tree structure. This authorization object has the following two fields to control authorizations:

• ACTVT (activity): The type of activity allowed: create, change, and display
• TERR_LEVEL (scope of territory dynamic authority check). This offers three options:
  • Own territories
  • Own territories and territories under these
  • My Territories, My Colleagues, and Territories Under These

For example, if you use the CRM_TERRMA authorization objects, then you can store the hierarchy IDs that the users are allowed to see. If you use CRM_TERRDY, you can control the visibility dynamically.

After you configure and maintain your territory, you can start using it in your sales transactions (Figure 12). When you enter the sold-to party, Territory Management tries to find the territory from the set of attributes that are assigned to this partner. It then populates the partners assigned to this territory in the transaction.

Figure 12

Territory information in a sales transaction

Now when I create a sales document for the sold-to party PC4YOU Pharmaceuticals — a pharmaceutical company located in the zip code 07690 and revenue of 500M — the system determines the territory as New Jersey East. In addition, the system assigns Andrea Michel as the Industry Expert and Anil Mehta as the Sales Representative.

Amit Khanna

Amit Khanna has six-and-half years of experience with mySAP CRM. He joined SAP Labs India in February 2000 as a developer, where he managed a team 17 developers in the area of mySAP CRM. He moved to SAP CRM Consulting in June 2005 and is involved in several mySAP CRM projects.

You may contact the author at amitk76@yahoo.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.