Leveraging SAP Territory Management for Effective ......Leveraging SAP Territory Management for Effective Visibility on Transactions Applies to: SAP CRM 5.2, 6.0, 7.0. ... unauthorized

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com © 2010 SAP AG 1

Leveraging SAP Territory

Management for Effective

Visibility on Transactions

Applies to:

SAP CRM 5.2, 6.0, 7.0.

For more information, visit the Customer Relationship Management homepage.

Summary

Implementing complex visibility criteria on Sales data for Sales force can be a challenge specially considering the agility and dynamism required to be displayed by organizations in their sales operations to remain competitive. The challenge is to make SFA application stringent enough to protect sales data from unauthorized abuse and at the same time able to responds to the volatile environment and continuous changes in Organization to adapt to those changes. The document describes how SAP delivered standard functionality can be enhanced to effectively utilize the Territory management solution in SAP CRM to not only define areas of responsibility for Sales teams, but also extend the solution to define visibility of sales transactions to the people on ground. It also talks about combining the with Sales Organization structure to define the visibility to people in reporting hierarchy.

Author: Saurabh Agarwal

Company: Infosys Technologies

Created on: 20 February 2010

Author Bio

Saurabh Agarwal is a Lead Consultant in SAP CRM working for Infosys Technologies Limited, Bangalore, India. He has overall eight years of experience.

http://www.sdn.sap.com/irj/sdn/bpx-crm

Leveraging SAP Territory Management for Effective Visibility on Transactions


Table of Contents

Executive Summary ............................................................................................................................................ 3

Factors Responsible for Bringing Frequent Changes to Organization‟s Sales Environment ............................. 4

Common Visibility Concerns from an SFA Tool ................................................................................................. 5

Expectations from a Good „Visibility‟ Solution .................................................................................................... 6

What SAP CRM offers out of the box? ............................................................................................................... 6

Organization Management .............................................................................................................................. 6 Sales Organization Structure ....................................................................................................................................... 6

HR (Reporting) Organization Structure ........................................................................................................................ 6

Territory Management ..................................................................................................................................... 7

Authorization Check Model in SAP CRM ........................................................................................................ 8 Sequence of Authorization checks in SAP CRM transactions ..................................................................................... 8

Enhancement Options Authorization Check Model for Transactions ........................................................................... 9

A Simple Scenario for Authorizations on Sales Transactions .......................................................................... 10

Solution Highlights ............................................................................................................................................ 11

Exploiting SAP CRM Out-of-the-Box features .................................................................................................. 11

Implementing Territory Management ............................................................................................................ 11

Implementing Sales Organization Management ........................................................................................... 13

Transaction Customizing............................................................................................................................... 14

Implementing Authorizations ......................................................................................................................... 15

Implementing BadI „CRM_ORDER_AUTH_CHECK‟ .................................................................................... 16

New Features in SAP CRM 7.0 ........................................................................................................................ 17

Territory based Authorizations Objects ......................................................................................................... 17

Rule Based Territory Management ............................................................................................................... 17

Simulation Capabilities .................................................................................................................................. 17

Data Validation Reports ................................................................................................................................ 17

Territory Based Searches ............................................................................................................................. 17

Authorizations on Accounts .......................................................................................................................... 17

Related Content ............................................................................................................................................ 18

Disclaimer and Liability Notice .......................................................................................................................... 19



Executive Summary

As a multinational organization working in different geographies, having several product lines there is bound to be a complex and ever changing structure of sales teams aligned to cater to the sales operations across different customer classes.

Under such scenario, it becomes increasingly challenging for an SFA application to keep the processes simple, effective and enabling the entire sales team with a harmonized process and at the same time, ensure that the Sales employee doesn‟t get lost in an ocean of data in the system but is able to see only that data which is specific to him.

For the managers higher up in the sales team, it is as important to see the correct set of data in the SFA tool to ensure correct monitoring of their sales team‟s performance, track targets and budgets. More and more organizations are rearranging their organization structure to newer models like Matrix Organization model to improve competitiveness.



Factors Responsible for Bringing Frequent Changes to Organization’s Sales Environment

1. External environment: Competition in industry segment, newer models of Customer Acquisition and Retention

2. Organizational realignment: to respond to External environment changes

3. Rotation & realignment of responsibilities within teams 4. Employee movement and turnover

Today‟s market is increasingly becoming Globalized, Mature and demanding. With Globalization, more and more customers have access to more choices. Traditional markets have seen growth and maturity with increase in competitors as well as customers finding themselves at the end of decision making curve and hardening brand loyalties. Spoilt of choices, customer is demanding more for less and industries are under constant pressure to meet the demands or succumb to competition. Both in retail and industrial segment, there has been a constant evolution of newer methods of customer acquisition, retention, logistics and product delivery.

These changes not only force companies to constantly evolve newer “go-to-market” strategies and realignment of their sales force but also necessitate regular reorganization of its core internal functions to operate more efficiently and reduce operating costs.

Most industry segments are also observing high levels of employee movements and turnover. With employees turning to be the core assets of company, positions are being created to absorb talent and experience.

Whatever be the factor forcing the change, but change is inevitable. A business model which is very successful today will become obsolete and burden tomorrow.

The role of IT in enabling these changes is to ensure that the enterprise tools deployed by company are scalable to handle these changes. With minimal cost and effort the systems reflect the changes brought in structure of organizations and continue to display relevant information to users as per their new responsibilities.

Examples of Organizational Model types

FUNCTION

A manufacturing firm typically includes functional units such as engineering, production, finance, sales, and personnel. These different functions are controlled by managers who head each function. In this organizational structure, each function primarily focuses on its core tasks (e.g., production or finance).

PRODUCT

Large, diversified companies may find it advantageous to divide their tasks based on product groups, such as foodstuffs, farm chemicals, and pharmaceuticals. This organizational structure has the benefit of enabling each business unit to produce desired results. However, it can lead to high administrative costs and redundancy.

CUSTOMERS

Companies may be divided into different units based on target customers. For example, a book publisher may be organized by retail bookstores, mail-order book stores, online book stores, and school system tier, such as elementary, middle school, high school, and higher education.

GEOGRAPHIC LOCATION

Many sales and service companies use geographic location as the basis for creating departments within the organization. This organizational structure calls for members of each group to concentrate on particular locations for which they are responsible.

PROCESS

Some companies are organized by process. Process organization is common in manufacturing and clerical companies. For example, natural gas companies have different units for exploration, production, and distribution. This type of organizational structure enables each unit to have its own specialists.

MATRIX

Matrix organizational structures include not only general functional units like production, sales, and finance, but also product or geographic units. Company executives frequently oversee the product units directly. The product units, in turn, collaborate with and coordinate the functional units. By adopting the matrix arrangement, companies attempt to reap the benefits of the functional and the product or geographic structures, while bypassing the inefficient and redundant aspects of the product structure. A company with a matrix organizational structure has functional units such as development, production, and sales matched in a matrix by product or geographic location.



Common Visibility Concerns from an SFA Tool

There is hidden but very high value in Sales data of any company. The SFA tool would capture potential clients, hot leads, opportunities at different stages, Quotations made to customer. Right usage of this data can help towards positive impact on revenues and profits of the company, but if caught in wrong hands, it is a live wire. Especially so for loyal or high-worth customers and high value deals

For a sales person to translate his tacit knowledge of his customers and sales pipeline into explicit knowledge captured within the SFA tool, it is utmost important the sales person trusts the system and knows that the information would be visible to only to right people. The threat of exploitation of this data by external elements is only dwarfed by that the threat from colleagues within the team. This is a peculiar feature with sales department and is not that prevalent in other departments handling sensitive data like finance. This adds to the challenges of an SFA tool as it has to walk a thin line while providing for collaborative environment for sales as well as protect the data from wrong usage within the team.

Pretty often, visibility is directly or indirectly linked to data quality in the system as well. If for example, the controls are too tight on master data, different SFA users may end up creating duplicate records for same entity just because they don‟t have access to already existing entity.

Another aspect which is affected is the ease of use of the system itself. If the data relevant to a user is buried under piles of irrelevant data, only those users who are expert data diggers will stick to the tool and rest will show resistance to adoption. Sales reports, monitoring cockpits etc need to show only relevant data based on the user in order to make sense to him and help him perform his tasks more efficiently. This is one step towards ensuring that the sales team spends their time doing more meaningful work on the system rather than searching for right account, an opportunity created 2 weeks back or adjusting the sales forecast reports to reflect only relevant opportunities.

Key Visibility Concerns in an SFA implementation

1. High Business Value of Sales data 2. Privacy and confidentiality Versus Team

work and accountability 3. Data relevance - SFA as an overhead or SFA

as an enabler

Have you heard this before?

I used look after Account ABC but I no longer do so. I still see the Sales transactions for this account

I have started looking after Account XYZ. But I cannot see his sales transactions in SFA tool. My SFA admin tells me that it will take X weeks to get this done.

As an Account Manager I am responsible for a Geography or set of accounts. I only want to see transactions belonging to my area of responsibility. Everything else is garbage to me.

My colleague stole the lead I was working on for so long. All my hard work and he will take the credit.

As a Sales Manager, several Account managers handling different geographies or Accounts report to me. I wish to see only those transactions which my team is working on.

Key Design Criteria for Visibility Rules in an SFA implementation 1. Comprehensive

Applicability to all user groups/roles

2. Stringent but not restrictive Protects data, only displays relevant data, but does not inhibit business functions due to authorization issues

3. Agile and scalable Is adaptable to changes such as internal reorganizations, inorganic growth through mergers & acquisitions, and Organic growth into new geographies or product lines.



Expectations from a Good ‘Visibility’ Solution

Specific to the visibility and authorization design, following are the key design criteria that any SFA implementation should meet:

1. Implement the visibility needs of people at different levels of hierarchy in Sales force.

2. Be stringent and comprehensive towards implementing visibility rules.

3. Be agile and responsive towards Organizational realignments, people movement, change of responsibilities

What SAP CRM offers out of the box?

Let‟s dwell a little deeper and have a closer look at the features and functionalities offered by SAP CRM which can be used to govern authorizations. Key features to be discussed are:

1. Organization Management 2. Territory Structure 3. Authorization check model for transactions in SAP CRM 4. Enhancement options Authorization check model for transactions

Organization Management

Sales Organization Structure

Organizational Management in SAP CRM offers a flexible tool for displaying company's task-related, functional organizational structure as a current organizational model.

Org structure typically represents how the company is internally structured. It reflects how the company records sales, executes the delivery and calculates the financials related to the sales.

Organization Structure is a hierarchical structure and has 3 basic components:

A. Sales Organization

An organization that is responsible for selling goods and services of company. This can be hierarchically defined as per companies structure e.g. by geographies, product lines etc.

B. Distribution Channel

Typically, it represents the medium through which sale is executed e.g. direct sales, via channel partner, internet sales, military sales etc.

C. Division

Typically refers to the product line that has been sold. Each product line may have its own terms and conditions for sales and specific requirements for delivery.

HR (Reporting) Organization Structure

HR (Reporting) Organization Structure is a representation of the reporting structure and the distribution of tasks using organizational units (departments, for example) in an enterprise.

Using HR Org structure, the company can define (HR Org units) representing different departments or groups, assign Positions at each level representing responsibility areas and assign holders to each position

How SAP supports different Org Models

Except for the matrix organization, all the structures focus on the vertical organization; that is, who reports to whom, who has responsibility and authority for what parts of the organization, and so on.

SAP provides standard support for Vertical Organizations.

It is designed on hierarchical concept where: A) Different Organizational Units are

hierarchically placed.

B) Each Org unit can be assigned several

“Positions”, each position depicting a

unit of responsibility.

C) There can be only one position which

is “Head of Unit” per org unit.

D) Each position can have one or more

“Holders”, which represent one or

more employees delivering same

responsibility.

But this hierarchical design makes it difficult to map a “Matrix” form of organization to SAP Org Structure.



representing owners of the responsibility area. The hierarchical structure of org units and positions/holders assigned to it would represent the reporting hierarchy of the organization.

Territory Management

Territory Management enables you to structure and organize your sales market by dividing it into territories according to criteria of your choice (such as size, distance, revenue, products, number of visits). These territories are structured in a territory hierarchy.

You can use Territory Management to analyze your sales market and determine, for example:

1. Who is responsible for a particular territory or business partner 2. Which business partners belong to a particular territory 3. Which products can be offered in a particular territory

Integration

The territory hierarchy is linked to the organizational model via the position of the employee responsible. Whereas the organizational model reflects the internal view of your organization, the territory hierarchy reflects the market view. Changes to the territory hierarchy usually occur more frequently than changes to the organizational model e.g. the customer base can increase or decrease and territories must be resized or reallocated to accommodate this, to ensure that a sales representative has the appropriate workload.

Use

A territory is a part of Territory Management. A territory is placed within a territory hierarchy; you maintain the territory and the territory hierarchy in CRM Enterprise.

In CRM Enterprise you can assign a territory to an employee, for example to a sales representative who is responsible for selling in a certain area, or to a service engineer who is responsible for servicing particular equipment.

When you create a business transaction in CRM Enterprise, for example a sales order or an activity, the system can automatically determine

1. The territory based on the employee responsible 2. The employee responsible based on the territory

When you maintain a territory hierarchy, you can display the business partners and products that fall within the scope of a particular territory

Territory

Segment of the market that is defined by attributes to describe its responsibility, for example:

Geographical locations (for example, by zip codes)

Products, product lines

Directly assigned business partners (for example, key accounts)

User-defined attributes

A combination of attributes

You can assign a territory to an employee, for example to a sales representative who is responsible for selling in a certain area, or to a service engineer who is responsible for servicing particular equipment.



Authorization Check Model in SAP CRM

To access business objects or execute SAP transactions, a user requires relevant authorizations, as business objects or transactions are protected by authorization objects.

SAP Standard code includes relevant Authorization checks at each level of access to any object.

Sequence of Authorization checks in SAP CRM transactions

Notes:

1. Here is where custom logic to check authorizations based on customer specific criteria can be written.

2. The usage of this object type is restricted to Claim related documents. Although this would be generally available in SAP CRM 7.0

Authorization control within SAP

Before any operation is executed, system check the level of authorizations that are needed for executing the operation (e.g. display lead) and compares it with the level of authorization provided in the user profile. If the user profile authorizations match the required authorization, then only access to the operation is granted.

Syntax of Authority Check statement

AUTHORITY-CHECK OBJECT 'CRM_ORD_OP' ID 'PARTN_FCT' FIELD AAA ID 'PARTN_FCTT' FIELD BBB ID 'ACTVT' FIELD CCC CHECK sy-subrc EQ 0.

Multi Level Authority Check for CRM Sales transactions

Multiple Authorization Criteria are checked starting from specific to higher level checks.

First, the system checks for ACE based authorizations. Next it checks for any active BadI implementation. We will talk of this in detail in next section.

Then it checks whether user gets authorization due to being directly is assigned in the transaction. At the highest level it checks for authority on a specific “Org unit” itself.

Transaction Auth Check – Key FM’s

CRM_ORDER_CHECK_AUT_CRM_ORD_OP

CRM_ORDER_CHECK_AUT_CRM_ORD_LP

CRM_ORDER_CHECK_AUT_CRM_ORD_TE

CRM_ORDER_CHECK_AUTH_BUS_OBJCT

CRM_ORDER_CHECK_AUT_CRM_ORD_PR

CRM_ORDER_CHECK_AUT_CRM_ORD_PO

CRM_ORDER_CHECK_AUT_CRM_ORD_OE



Enhancement Options Authorization Check Model for Transactions

1. Enhancement through BadI ‘CRM_ORDER_AUTH_CHECK’

The standard authorization logic can be enhanced with complex customer logic by implementation of BadI „CRM_ORDER_AUTH_CHECK‟. This BadI provides several methods to be implemented as per the needs of the customer requirements.

2. Enhancement via Custom Authorization Objects

Authorization objects are responsible for holding authorization related data. They carry following information: - The object/transaction for which it is applicable. - The fields within the object/transaction to be used to define

authorization levels - The activities that can be performed at different authorization

levels

Apart from Standard delivered Authorization objects, there is a possibility of creating custom Authorization Objects. However, since these authorization objects need to be explicitly called via „Authority-Check‟ statements at appropriate place within code processing, custom authorization objects can be used in following ways: - Change standard classes (not recommended as SAP does not

support modified standard objects) - Include the object within relevant BadI implementations - Use in Custom RICEF components.

Methods in Authorization Check BadI

CRM_ORDER_ADD_AUTH_CHECK

(Additional Authorization Checks)

To implement “Additional” checks over and above those implemented through PFCG roles

CRM_ORDER_ALTERN_AUTH_CHECK

(Alternative Authorization Check)

To implement “Alternate” checks over and above those implemented through PFCG roles. Has a flag to indicate whether the standard PFCG role based authority check has to be carried out or not.

CRM_RFW_MODIFY_QUERY

(Modify selection query)

Modifies the selection query built by SAP standard program and append additional selection parameters in order to return only relevant transactions based on “Visibility Logic”.

CRM_RFW_CALL_AUTHORITY

(Call up Authorization Check According to Reporting Framework)

Gets the list of all transaction GUID’s and applies “Visibility Logic” to delete GUID’s that do not meet authorization criteria.

CRM_RFW_SET_MAX_HITS

(Set Maximum Records for Database Select)

The input to CRM_RFW_CALL_AUTHORITY contains only as many GUID’s as “Max results” value set on Web UI. Thus deletion from this GUID list reduces the result list further.

This method changes the MAX_HITS Value to allow reading as many records as specified from database.

Authorization Object Definition

Auth Object CRM_ORD_PR

(Authorization Object CRM Order - Business Transaction Type)

Authorization Fields

Field name Heading PR_TYPE Business Transaction Type ACTVT Activity

Permitted activities: 01 Create or generate 02 Change 03 Display 06 Delete This Auth object governs visibility and allows activities like Create, Change, Display and delete of Object ‘CRM Order’ based on field Transaction Type (PR_TYPE).



A Simple Scenario for Authorizations on Sales Transactions Consider an organization with following sales force structure: 1. There are multiple business units having responsibilities based on

product lines. Each business unit has a reporting structure from field sales representative, Area Sales manager, Zonal Sales Manager, Country Sales Manager, VP Sales and CEO.

2. Accounts are classified based on maturity of relationship and sales volumes into Platinum Accounts (High Volume, Global), Gold Accounts (High Volume, Regional), Silver Accounts (High Growth Potential, Regional), Special Accounts (Defense, Government) and Unclassified Accounts (Low volume, occasional buyers). Key Account managers are assigned to all “Classified Accounts”. Each “Account”

can have multiple business Partners belonging to different Geographical locations. There is a “Group Key Account Manager” for

the entire group of Business Partners and a “Regional Key Account

Manager” for each Business Partner in a region. This structure is

volatile as accounts move from one classification level to another based on volume of business and geographical spread. Reconciliation of data happens on quarterly basis.

3. A Key Account Manager may assume responsibility of “Group KAM”

for some Accounts and of “Regional KAM” for some other Accounts. 4. Each “Regional Key Account Manager” will report to will report to the

“Area/Zonal Sales Manager”. 5. Each product line has multiple products, each product having a team

of product specialists per geography to provide technical inputs during sales pursuit.

Visibility requirements from SFA tool for such an organization would be: 1. Automatically add respective Key Account manager to sales

transactions created on Classified Accounts. He and his team should be able to view and change all such sales transactions.

2. Automatically add relevant Product specialists to sales transactions created on Products they handle. They should be able to view all such sales transactions and provide technical inputs.

3. The higher level managers in reporting hierarchy should be able to view all transactions that belong to the sales team reporting to them.

4. System should allow flexibility to add employees manually to a transaction, in case he has some specific role to play in that particular transaction.

5. Visibility changes based on changes in reporting hierarchy, changes to Account classification, Changes to Account and product handling teams.



Solution Highlights

1. Build Sales hierarchy (reporting structure) in Sales org structure (since it is less susceptible to change).

2. Build responsibility matrix in Territory structure (mapping of employee with Accounts, Geographies etc).

3. Combine the two based on Positions data. 4. Determine responsible Territory for any transaction based on the

Account Attributes (Country, Region, Classification) 5. Determine the Account Manager(s) to be populated in transaction

based on the responsible Territory. 6. Now following data points are available for controlling Authorizations

a. Territory ID of Account Manager in Transaction <–> all Account Managers associated to the Territory ID

b. Position of Account Manager and other Partner Functions in transaction <–> People in reporting hierarchy in Sales Org

7. Build Authorization logic within CRM_ORDER_ADD_AUTH_CHECK BadI.

Exploiting SAP CRM Out-of-the-Box features

Implementing Territory Management

A Close analysis of Sales structure reveals that there are at least 3 dimensions on which it is built: 1. Reporting Hierarchy 2. Account Classification (for KAMs), Product Group (for Product

Specialists) 3. Geography

Also, the reporting hierarchy runs across the other two parameters of Account Classification/Product Groups and Geography. For example, there can be a team of Key Account Managers handling an Account at Global and regional level, but reporting to different Regional Managers. This creates a “Matrix” sort of structure where on one dimension employees are grouped based on parameters of Geography and Account and on other they are grouped based on the reporting hierarchy.

Such structure is impossible to build within SAP CRM Sales Organization.

Here, the functionality of Territory Management can play a crucial role as with the combination of Organization structure and Territory Structure, this sales matrix can be easily defined.

Territory Definition

Basic Configuration

Path: SPRO CRM Master Data Territory Management Define Territory Hierarchy Levels

Define the nomenclature carefully as the maximum length of Territory hierarchy ID can be 30. So the length + offset for the lowest level in hierarchy cannot exceed 30.

Standard Attributes

SA_SALES_AREA Sales Area

BP_COUNTRY Country Key

BP_REGION Region (State, Province, County)

BP_POST_CODE City postal code

BP_GUID Partner Number

PM_CATEGORY_GUID Global Unique Identifier

PM_CATEGORY Category ID

BP_MAIN_SPEC Additional spec

BP_GROUP Organization Group

BP_SUBGROUP Organization Sub-Group

BP_BRICK Brick Codes

PM_HIERARCHYGUID Global Unique Identifier

Customer Defined Attributes

Path: SPRO CRM Master Data Territory Management Additional Attributes Define Additional Attributes

To define Customer Attributes, you need to append following structures with custom fields:

CRMM_TERRATTRIB

CRMT_TERRMAN_LOCA_SEARCH

You would need to define logic for usage of custom attributes in BadI CRM_TERRMAN_ATTRIB



In this case the responsibility matrix of sales employees and products specialists can be built within the territory structure, using territory attributes

- Account classification (Customer Defined Attribute) - Account Country (Standard Attribute) - Account Region (Standard Attribute) - Product Category (Standard Attribute)

A representative Territory Structure may look like this:

AM1 (G): Global Key Account Manager

AM2 (R): Regional Key Account Manager

Territory Structure

Organization

Structure

Geography

Re

po

rtin

g H

iera

rch

y

Account Classification/Product Group

Key benefits of Territory Management 1. Territory Buckets can be defined based on

flexible criteria. In this case, they can be defined

based on Account Classification, Account

Geography and Account IDs, Product Category

and Product Ids.

2. Volatility can be handled well. The frequent

changes to Account Classifications, Account

handling teams at Global and Regional Levels,

new product ids and category introductions can

be easily handled with Territory Management

3. Integration with “Organization Structure” via

“Positions” is another useful feature. So when in

Organization structure, holder of a position is

changed, the data is immediately reflected in

Territory Structure as well.



Implementing Sales Organization Management

Now, in order to build the reporting hierarchy, Sales Org structure can be used. If the reporting hierarchy is already built in SAP HR and is relevant in SAP CRM also, it can be directly downloaded from SAP HR. However, the HR org Structure is much more exhaustive and covers all employees of the organization and not only the Sales employees. In such cases, manual creation of Sales org structure within SAP CRM can also be considered.

Basic benefit of building the reporting hierarchy in Sales Org Structure and not in Territory Structure is that this way both data can be de-coupled and changes to one data set will not necessitate changes in other. Also, at any given point of time, any of these hierarchies can be restructured on a totally different paradigm with minimal impacting on each other. It also gives flexibility to reflect cases where members of Account teams report to different managers, which would not be possible if reporting hierarchy as well as responsibility matrix would be built entirely within Territory Management or Sales Org Structure.

Using both Territory management and Sales Organization Management together and loosely coupled (via positions) with each other, renders the solution with benefits of agility and scalability. So, with this arrangement, when new Accounts are assigned to an Account Manager (which happens more often), there is no need to worry about the impact/changes on his reporting hierarchy (which happens less often).

Sales Organization Definition

Design Options

1. Explore the opportunity to download the HR

reporting hierarchy if it meets the reporting

hierarchy requirements.

2. If not, build a robust template for collecting

reporting hierarchy data to be collected by

business users. E.g. Visio templates

Additional Attributes in Sales Organization

You may need to define additional attributes at organization level also e.g. for classification of user groups. In the solution discussed in this paper, different visibility rule apply for 2 different user groups Key Account Managers

Upper and Middle Managers

There needs to be an identifier to distinguish these two user groups. Since these user groups represent two different “responsibility” areas, it is advisable to capture this data in “Position” level in Sales Organization. This will give us the flexibility to account for cases where: One user is handling more than one responsibility

for different sales organizations

User may “Fill-In” for another for a short duration

of time.

User moves from one responsibility are to

another e.g. promotions

Transaction: OOATTRCUST

Create a new Attribute for “Sales” scenario.



Transaction Customizing

Territory Management offers standard functionality through which we can determine business Partners to be assigned against Partner Functions in transactions. Moreover, the territory through which the BP was identified also gets updated against the partner function. In our scenario, this functionality can be utilized to determine the “Account Managers” in the transactions. The Account characteristics (Country, Region, and Classification) will determine the territory. The territory itself would have multiple AMs assigned. We may choose to populate all Account Managers in the transaction, but a drawback is that, this information will become “static”. Changes to the territory node, will not automatically update them to the transactions. Also, the tables containing partner data for transaction are mostly very huge and grow rapidly and would only add to performance issues.

Instead, we can use the functionality within Territory Management which lets us chose a specific AM from several assigned to the territory node. Against each AM assignment in Territory node, a Partner Function can be maintained. One of the AMs in Territory node can be marked as Global Account Manager. After making a few configurations, you can make the partner determination procedure to only consider those AMs which are assigned with a particular Partner Function in Territory Node e.g. Global KAM to o be determined in the transaction, along with the Territory node ID, which becomes a common link for other Account Managers to access this transaction.

Transaction Customizing

Partner Determination

Path: SPRO CRM Basic Functions Partner Processing Define Access Sequence

Relevant Access Sequence

0030 Preceding Document -> Territory Management -> User 1. Copy the access sequence to a Z Access

Sequence.

2. Enable “Mapping/Restrictions” checkbox and in

“Partner Function in source” mention the Partner

Function used in Territory Management for

Global KAM.

3. This will ensure that only the Global KAM gets

picked in transaction and not the Regional KAMs.

4. Use the Access sequence for PDP of Key Account

Manager in relevant transactions.



Implementing Authorizations

A close look on Authorization requirements would suggest that we got at least 3 different user groups which need access to transaction based on different criteria: 1. Rule #1 (Own Documents): People directly assigned to the

transaction (creator, Employee responsible etc). They need full access to the transaction by virtue of their direct assignment.

2. Rule #2 (Own Territory Documents): People linked to the transaction through Territory (KAM assigned to a transaction belongs to a Territory node and there are other Regional KAMs assigned to the territory also). They need full access to the transaction by virtue of being responsible of managing all customer interactions.

3. Rule #3 (Own Reporting Hierarchy Documents): People linked to the transaction through Sales Org (Managers of people who are directly or directly linked to a transaction based on rule 1 & 2). They need at least read only or reporting access to the transaction for monitoring and reporting purposes.

For Rule 1, there is a standard authorization object (CRM_ORD_OP) to handle authorizations for transactions where user is directly assigned through a partner function.

For Rule 2, there was no standard authorization object till 6.0*. From 7.0 a new authorization object (CRM_ORD_TE) has been introduced which grants access by matching the territory id determined for the transaction and those assigned to the user.

For Rule 3, there is a standard authorization object (CRM_ORD_LP) to handle authorizations for transactions where the user is a part of Sales organization determined in transaction. However, the pre-requisite for this is that the Sales organization data in CRM system also maps the reporting hierarchy. Typically, since in ERP, the Sales Organization data is defined differently than the HR Org data, is becomes a challenging task to map both into a single SAP CRM Sales org structure. Not in all cases would it happen that the sales area to which the user is assigned is also extended to the customer on which transaction is created.

Considering these limitations, especially till version 6.0, it would be impossible to map all these authorizations through standard configuration.

SAP provides a BadI ‘CRM_ORDER_AUTH_CHECK’ for implementing such complex (not so out of the box) visibility rules.

* Auth object CRM_ORD_TE was available in 6.0 with limited scope. It was applicable for only Claims and Submissions transactions.

In cases where the solution is to be implemented on SAP CRM 6.0 or less, necessary enhancements are discussed in subsequent section.



Implementing BadI ‘CRM_ORDER_AUTH_CHECK’

At the outset, this BadI appears to be the simplest choice and fairly straight forward solution. But it‟s not that simple. Let‟s take a closer look at what it has to offer and what are the challenges.

Method CRM_ORDER_ADD_AUTH_CHECK is the one that that SAP help mentions to implement. However, once you implement your first piece of code, you would realize that the method gets called for only one transaction at a time. So, when landing on a search result page, it gets executed for the first transaction in the search result and just skips the remaining. SAP suggests that this is intentionally built due to performance reasons. Similar issues arise with method CRM_ORDER_ALTERN_AUTH_CHECK.

Method CRM_RFW_MODIFY_QUERY is the most powerful method in the stack and aims at enhancing the selection query with additional filters based on the customer logic. This selection filters are then transformed into an SQL select query. The select query then returns only those transactions which not only satisfies user selection criteria but additionally meets the visibility rules also. But to design and implement a set of “additional” selection criteria that are valid with all core searches, be it from Account overview page, Interaction history, open leads, opportunities or from main transaction search pages, is a quite a big challenge in itself. Couple it with the fact that SAP does not even maintain the description of this method, leave alone any documentation.

Method CRM_RFW_CALL_AUTHORITY seems to be the most “implementable” one. It gives uniform results across application and the same code logic works exactly the same be it Account Overview page or lead search page. A big advantage being that it takes a list of all transactions returned by search as an input, so you can implement the visibility logic on all of them at one go, thus saving performance costs. However, this advantage itself has one major drawback. Since it is called after the standard SAP logic has returned the transactions meeting user selection criteria, it returns even fewer transactions after removing those which do not satisfy visibility criteria. In WebUI, “maximum number of results” is additional parameter that is passed by default along with other search criteria. Suppose if it is set to 100, SAP will return 100 transactions based on user search criteria and then this method will be called which will remove say 15 transactions from the list and thus user will finally see only 85 transactions on screen. The user ends up thinking that he has access to only 85 transactions as he searched for 100 but only 85 returned. If he sets the criteria to 200 transactions, he would then see may be 170 transactions, thus getting even more confused by the system behavior.

Method CRM_RFW_SET_MAX_HITS addresses this issue but at the cost of performance. This method sets a parameter which overrides the “maximum number of results” parameter given at WebUI. Once set, system returns as many transactions as mentioned by this parameter and passes it to CRM_RFW_CALL_AUTHORITY. As a workaround, you can increase this parameter to some large number, but this will increase burden on system as it will collect all data for as many transactions, most performance costly being current status and status change data. The biggest challenge in implementing this BadI is that there is absolutely no documentation available either with SAP or from any other sources.

BadI Pseudo logic

PSEUDO CODE (CRM_RFW_MODIFY_QUERY)

Changing Parameter: CT_GUID_LIST 1. Based on the user who has logged in, get the

business partner number.

2. Based on the business partner, get his

assignment in the org unit.

3. We retrieve the “User Group” that has been

assigned to his position.

4. If user group is Upper or Middle Management,

get the employees who are reporting to this user.

5. Get all transactions to which the user is directly

assigned with any partner function other than

“Key Account Manager”. (Rule #1 – Own Docs)

6. Get all transactions to which the subordinate

employees (fetched in step 4) are assigned as

Partner Function “Key Account Manager”. (Rule

#2 – Subordinate user’s Territories)

7. Get the list of transactions to which subordinate

employees (fetched in step 4) are assigned to the

transactions, with any partner function other

than “Key Account Manager”.

8. If user group is “Key Account Manager” then

execute only step 6 and Step 7

9. Concatenate the list of transactions obtained

from steps 5, 6 and 7 and delete duplicate

records.

10. Find transaction ids which are common between

the list and CT_GUID_LIST

11. Update the CT_GUID_LIST with common

transactions only.



New Features in SAP CRM 7.0

Territory based Authorizations Objects

With SAP CRM 7.0 a new authorization object CRM_ORD_TE is added. This object controls authorization on transactions based on Territory assignment of user. It has two options: 1. Direct Assignment:

All territory nodes where the user is directly assigned are considered. 2. Indirect Assignment:

All Territory nodes where user is directly assigned and all lower level nodes are considered.

Rule Based Territory Management

In SAP CRM 7.0, attribute based territory definition is replaced with rule based territory definition.

Simulation Capabilities

1. Analyze what if scenarios by simulating changes to territories without actually changing the underlying territory data

2. The changes can be simulated either on delivered KPIs or custom defined KPIs

3. The simulated changes can either be saved or discarded

Data Validation Reports 1. Identify territories without employees assigned to it 2. Identify accounts that are not associated with any territory 3. Temporarily assign the territory responsibility to another employee 4. Mass transfer the ownership of business documents to a new

employee and territory

Territory Based Searches

Search on Accounts, Products and Transactions based on Territory ID and Territory description

Authorizations on Accounts

Authorizations to define what accounts are available for use in business transactions using the value help. Depending on Customizing maintained for a particular business document,

the value help for accounts in the business transactions is enhanced, so that the territory ID is already pre-filled while doing the accounts search. Hence, the result list is already filtered and only contains those accounts which belong to a user as per his/her territory assignments.

Depending on the user‟s role, the user is able to search for “My Accounts”,

“My Team‟s Accounts”, and “All Accounts” while creating business

transactions. If the user enters an account manually by deleting the defaulted value help

while creating a business document, an authorization check shall be performed so that a user can only use those accounts during document creation which belong to a territory that is being associated with that business document.

New Features in SAP CRM 7.0

Territory Based Authorizations

You can enable Territory authorization check at transaction level. So only those transactions, for which the check is active, will be subjected to territory authorization check.

Path: SPRO CRM Transactions Basic Settings Define Transaction Types

Set Flag “Territory Check” to activate Territory based authorization check.

Rule based Territory Management

Rule Builder can be accessed from path:

SPRO CRM Cross Application Components Rule Builder Define Rule Policy Types

Relevant Rule policy type: TM

In case you are upgrading from earlier versions and you have already defined attributes, use transaction CRM_TERRMAN_DATA_MIG to migrate data from table CRMM_TERRATTRIB

You may need to execute report: CRM_TERRMAN_PROC_REL, to update territory relationships

Data Validation Reports

Accounts: No Territories

Accounts: Multiple Territories

Territories: No Employees

Authorization on Accounts

Set SU01 User Parameter:

CRM_TERR_SCOPE = 01 (My accounts)

CRM_TERR_SCOPE = 02 (My Team’s accounts)

CRM_TERR_SCOPE = 03 (All Accounts)



Related Content

You may also find following documents relevant or related to the topic.

7 Enhancements in Territory Management, CRM 7.0

Territory Management in SAP CRM 5.XX

PFCG Roles and Authorization Concept in SAP CRM 7.0

https://weblogs.sdn.sap.com/pub/wlg/13154

http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/b051fdab-0f7f-2a10-0eae-c9bb66675213

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/00515e75-f1d0-2c10-bebb-e5675f470ee6?QuickLink=index&overridelayout=true



Disclaimer and Liability Notice

This document may discuss sample coding or other information that does not include SAP official interfaces and therefore is not supported by SAP. Changes made based on this information are not supported and can be overwritten during an upgrade.

SAP will not be held liable for any damages caused by using or misusing the information, code or methods suggested in this document, and anyone using these methods does so at his/her own risk.

SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this technical article or code sample, including any liability resulting from incompatibility between the content within this document and the materials and services offered by SAP. You agree that you will not hold, or seek to hold, SAP responsible or liable with respect to the content of this document.