Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Options for restricting authorizations by cost centers

Former Member
0 Kudos

Hi,

I need to create role for users who are responsible for cost centers. In addition to this role these users would only have common role for all users assigned to them.

Let's assume there are 50 cost centers and 25 users and therefore some users need authorizations for more than one cost center. Also, within a cost center group there can be several users responsible for the different cost centers (e.g. Cost center group AB: cc A: user1, ccB: user2).

What are my options to restrict authorizations for these users to individual/multiple cost centers?

Is there more a sensible way to do this than by creating a separate rolefor each cost center and then assignign these CC -roles to users?

This would mean creation of 50 new roles and inevitably a lot of maintenance in the future.

Thanks for all answers and please direct me to earlier threads if I've missed a discussion on this topic!

1 ACCEPTED SOLUTION

sdipanjan
Active Contributor
0 Kudos

Hi,

First of all let me provide you few of the Auth.Objects (but Important) used for Cost Center and Cost Center Group checks:

I_KOSTL PM PM: Cost Centers

K_CSKS CO CO-CCA: Cost Center Master

K_CSKS_PLA CO CO-CCA: Cost Center Planning

K_CCA CO CO-CCA: Gen. Authorization Object for Cost Center Accounting

K_REPO_CCA CO CO-CCA: Reporting on Cost Centers/Cost Elements

Before designing the roles you can have a look on the following proposals:

1. 1st prepare a list of the role users those who are going to belong to same Cost center. It will reduce the number of Roles considerably as you need to create one role for more than one users.

2. Also make the list of Cost centers which can be shared and thus you can create one role for multiple cost centers.

3. The Check of Cost centers comes after the check of Org. Unit segregation.. for e.g. Controlling Area, Company Code etc. So you should go for the SOD at this level more strictly rather than CC.

Let me know for more info needed.

Regards,

Dipanjan

9 REPLIES 9

sdipanjan
Active Contributor
0 Kudos

Hi,

First of all let me provide you few of the Auth.Objects (but Important) used for Cost Center and Cost Center Group checks:

I_KOSTL PM PM: Cost Centers

K_CSKS CO CO-CCA: Cost Center Master

K_CSKS_PLA CO CO-CCA: Cost Center Planning

K_CCA CO CO-CCA: Gen. Authorization Object for Cost Center Accounting

K_REPO_CCA CO CO-CCA: Reporting on Cost Centers/Cost Elements

Before designing the roles you can have a look on the following proposals:

1. 1st prepare a list of the role users those who are going to belong to same Cost center. It will reduce the number of Roles considerably as you need to create one role for more than one users.

2. Also make the list of Cost centers which can be shared and thus you can create one role for multiple cost centers.

3. The Check of Cost centers comes after the check of Org. Unit segregation.. for e.g. Controlling Area, Company Code etc. So you should go for the SOD at this level more strictly rather than CC.

Let me know for more info needed.

Regards,

Dipanjan

Former Member
0 Kudos

Hi and thanks for reply.

Regarding the proposals you mentioned:

1. I don't think this will help much. One user can be responsible for multiple cost centers, but in this setup multiple users cannot be responsible for one cost center. So, if separate roles are created, two different roles can be assigned to one user, but one role cannot be assigned to two different users.

2. Problem with this proposal is similar. One role for multiple cost centers cannot be created, since these cost centers might have different users responsible for them.

3. Yes, check of cost centers comes after CA, CC etc. but those restrictions are not sufficient as authorizations need to be restricted at cost center level.

Since transactional authorizations will be the same for all these users, would the use of derived roles be an option?

Former Member
0 Kudos

Hi,

Cost centers are not maintained at organizational level, hence derived role concept will not work here. You can create roles based on users. i.e. one role for one user. In long run, its going to increase more number of users and roles. However, this is the way it designed as of now.

Regards,

Gowrinadh

Former Member
0 Kudos

Hi, I find this challenging. Assuming my organization's authorization strategy is derived roles method. And when comes to cost center mangement, we will create single roles for each users. is this consider as a strategy itself? if i am the admin, will i get confused when to derive and when not to?

Former Member
0 Kudos

well, we do sometimes. The only difference we can make with derived roles is easy maintainance of same positions /roles across different plants / company codes/sales organizations. that means with the organizational values.

Hence derived roles has to be used only for organizational differences.

Regards,

Gowrinadh

Former Member
0 Kudos

We same kind of issue here. Is that mean we need create a separate role for each costcenter?

Ex: if I have 100 cost centers then I need to create 100 roles????

Former Member
0 Kudos

You can also consider implementing Org level restriction based on Cost Centre.

In that case you can use parent - child relationship.

Former Member
0 Kudos

Which field, KOSTL or RESPAREA (or both?) should be considered if implementing org. level restriction based on cost center?

If both of these fields are maintained in authorizations, how can it be determined, which of the fields should be included at org. level?

Former Member
0 Kudos

>

> Which field, KOSTL or RESPAREA (or both?) should be considered if implementing org. level restriction based on cost center?

Both

>> If both of these fields are maintained in authorizations, how can it be determined, which of the fields should be included at org. level?

Depends how you use them. If you use them as you would any other org level (e.g. in derived roles) then it may be useful to use them as org levels