Well, can you? Or can you get someone else to do it? Like Jane, the security administrator for Alan's new department, or Colin, the security administrator for Alan's old department.

It's not much fun being the only person who can change the SAP Supplier Relationship Management (SAP SRM) organizational plan. It's even less fun if there's more than one person who can maintain the SAP SRM organizational plan, and someone else accidentally overwrites a change you've just made.

But with versions up to SAP SRM 3.0 (Enterprise Buyer Professional [EBP] 4.0), unless you replicated your organization plan from another SAP system, your only options were:

1. Have one person do all the plan maintenance

2. Take the risk of having many people maintain the plan

Figure 1

Use transaction PPOMA_BBP to view the SAP SRM organizational plan

Up to SAP SRM 3.0 (EBP 4.0), there was no way to split up maintenance of the organization plan satisfactorily among the different companies, departments, vendors, and locations. Beginning with SAP SRM 4.0 (EBP 5.0), the introduction of SAP HR structural authorizations for the SAP SRM organizational plan means that, for the first time, you can decentralize your plan maintenance safely.

If you've never used SAP HR structural authorizations before, or if you've used them in another SAP system, you should know that they work just a little bit differently in SAP SRM. If you want to decentralize SAP SRM organization plan maintenance, you'll need to know a little about how SAP HR structural authorizations work and how to turn them on.

How Authorization Works

Whenever you access the SAP SRM organizational plan object, the SAP SRM system considers two types of access in a kind of matrix (Table 1). To view or change a particular piece of data in the SAP SRM organization plan, the system must be able to affirm both of these questions:

• Do you have sufficient SAP HR base authorization (i.e., are you allowed to work with this type of data)?

• Do you have sufficient SAP HR structural authorization (i.e., are you allowed to work with this object, which could be an organizational unit, position, central person, or user ID)?

SAP HR base authorization corresponds to whether you are allowed to view or change data on the various tabs in the org plan — Basic data, Address, Function, Responsibility, Attributes, and Extended attributes. For example, you can use SAP HR base authorization to allow someone to change the default cost center (in Attributes) of the marketing department (an organizational unit in your org plan), but prevent them from changing the name or statement address.

You can also use SAP HR base authorization to control what sorts of relationships can be created, changed, or deleted between one organizational object and another, such as the relationship between employee Alan and the department to which he belongs.

You control HR base authorization using the Personnel Planning authorization object (technical authorization object ID PLOG, see Figure 2) in a user's security profile, assigned to their user master in SAP SRM. Maintain security profiles using the SAPGUI in transaction PFCG.

Figure 2

Example security profile authorizations for PLOG (transaction PFCG) — view all tabs and also maintain Attributes tab

The most important fields to set in the Personnel Planning authorization object are:

• Infotype — Indicates the type of data that can be accessed. Examples: 1000 (basic data), 1028 (address), 1001 (relationships), 1222 (attributes), 5500 (functions), 5501 (responsibility), 5502 (locations), and 5503 (purchase order value limits).

• Subtype — Refines the type of data the user can access. It is usually only used for infotype 1001. Examples: A003 and B003 are used for "belongs to/incorporates" relationships, A491 and B491 are used for "is purchaser of/has purchaser" relationships.

• Function Code — Indicates what actions can be taken on the data. Examples: To read data, you need function codes DISP and LISD. Other key function codes are INSE (create), AEND (change), CUTI (move/delimit), DEL (delete).

SAP HR structural authorizations control which objects you are allowed to change, i.e., which organizational units (companies, departments, sections, purchasing organizations, purchasing groups, vendor root nodes), and which positions/central persons/user IDs (employees, vendor contacts). However, you usually don't want to list every organizational unit or position someone can change; there could be thousands! It's much more likely you will want to give someone access to everyone in a particular company or department, or all the purchasing groups in a particular purchasing organization, or all the vendors connected to a particular vendor root node. SAP HR structural authorizations let you do this by using structural profiles and assigning the profiles to users.

Set Up Profiles

You use transaction OOSP (Figure 3) to configure structural profiles. By default, the ALL (all access) profile gives access to the whole organization plan. If you want more profiles, you'll need to create them yourself.

Figure 3

Use transaction OOSP to configure structural profiles

Structural profiles have two parts:

1. Profile ID/name

2. Profile access

The ID and name are easy enough; just don't put any spaces in the ID. The profile access takes a little more understanding (Figure 4). You use the profile access lines to indicate the starting object in the org plan and the evaluation path, or how to find all objects the user can access, by following relationships from the starting object. The most common requirement is to access everything hierarchically below a particular object (including the object itself) — for example, everyone in a company, department, or section, or all vendors below

Figure 4

Access the profile using transaction OOSP

The important fields are:

• Number (No.): A sequential number to separate one access line from another; just make this number unique for each line.

• Plan version (Plan vers.): Use the wildcard ** or enter 01 — they give the same result, as only Plan version 01 is used in SRM anyway.

• Object type (Obj. type): Type of the starting object in the org plan: usually O for organizational unit, or use the wildcard * for all objects.

• Object ID: The number of the starting object in the org plan, i.e., the org unit ID

• Maintenance flag: Whether or not these objects can be maintained. Off means they can only be viewed.

• Evaluation path: How to find other accessible objects because of their relationship to the starting object. In SAP SRM, you can use evaluation path OO-S-CP1 to find everything beneath the starting object.

• Status vector: Always enter 12 (all statuses).

For example, if you want to create a "can view everything" profile, you would set the fields as shown in Table 2.

If you want to give someone access to change everyone in the marketing, sales, and production departments — assigned to org units 50000025, 50000024, and 50000027 respectively — you might set up your profile as shown in Table 3.

Assign Profiles to Users

You can assign structural profiles to users by:

1. Linking the user to one or more profiles in transaction OOSB directly

2. Programming the link using an implementation of BAdI HRBAS00_ GET_PROFL

All assignments are time-effective — they have start and end dates. The user only has access to the organizational data specified in the profile between the start and end dates (inclusive of the start/end dates). If you assign more than one profile, the user gets both profiles — in the example in Figure 5, a profile in which they can view everything and one in which they can change only marketing, sales, or production.

Figure 5

Assign structural profiles to users with transaction OOSB

It's a good idea to give all SAP SRM users access to view everything, whether or not they have access to the organization plan transactions (PPOSA_BBP and PPOMA_BBP). After all, you don't want to prevent someone from creating a shopping cart just because they can't read the org plan details of a location.

If you want to give a default profile to all SAP SRM users, you don't have to enter all users individually in transaction OOSB. Instead, enter the profiles you want assigned to all users against the special user ID SAP*. All users who do not have an entries against their user IDs in OOSB will be given whatever profiles are assigned to SAP*. Conversely, if users are entered directly in transaction OOSB, then they are only granted the profiles assigned directly to them — they do not get whatever profile is assigned to SAP*.

You must consider these three special types of users:

1. Background system users, i.e., any user specified as a System or Communication user in the user master, must have the ALL profile. This includes the workflow system user, WF-BATCH.

2. Users who use the Web transaction Manage Business Partner must have access to the vendor root nodes and everything hierarchically below them in the organizational plan, so they can create new vendors and vendor contacts.

3. Similarly, you need to consider any users with access to administration transactions that create locations. They'll need access to the locations' root nodes and everything hierarchically below them.

With a few simple configuration settings and a couple of hours training Jane and Colin in organizational plan maintenance, you can happily point Alan in their directions, while you proceed to relax with a cup of coffee.

Jocelyn Dart

Jocelyn Dart is a senior solution consultant at SAP Consulting working in Australia/New Zealand. She currently specializes in workflow and Supplier Relationship Management (SRM). As well as speaking at various SAPPHIREs and at ASUG, Jocelyn is a co-author of the book, Practical Workflow for SAP.

You may contact the author at jocelyn.dart@sap.com.

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