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: 

Restrict users by the Cost centers

Former Member
0 Kudos

Hi Guys,

Situation: Users of two types

1. Who need access to Change & Display access to all Cost centers - (PS_FKSTL & KOSTL field values)

2. Who need display access only to one particular Cost center.

There are 10roles which already exist in the system(includes these field values) & they need to be copied & changed.

Requirement: Need to create roles for these Users

I am assuming they have to be limited by Field values. If there is any solution, please guide me.

Thanks

Puneeth

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Org Level does not have Cost center entry.

Would there be any other way around?

13 REPLIES 13

Former Member
0 Kudos

use the profile generator and apply the right values in the orglevel field

Former Member
0 Kudos

Org Level does not have Cost center entry.

Would there be any other way around?

0 Kudos

then fill in the fields manually in every object in the profile generator.

be sure to use the same value in a role for all objects.

field name is KOSTL.

0 Kudos

Definitely this is possible. There are quite a few existing roles which users need for Display access to one Cost center.

Assuming there are X roles, Y cost centers & Z users, does that mean to create X*Y roles?

Thanks

0 Kudos

Hi Puneeth,

Create one parent role with all the required tcodes in it and then create derived roles for each of the Cost centers you want to restrict users.

Hope this helps.

Regards,

Kiran Kandepalli.

0 Kudos

Create cost centre as an org level using PFCG_ORGFIELD_CREATE & use derived role functionality as pointed out by other posters.

With cost/profit centre security, find out if it is 100% needed & that it must be a preventative control implemented. It can be a pain in the neck for very little return. The restrictions around CO data are not that great either.

I assume the users you are restricting don't have access to SE16, SQ01, Report Painter etc....

0 Kudos

Thanks Alex.

That does really help.

However, can cost center be created as an Organizational level only for one/some Roles?

0 Kudos

When you create cost centre it will be for all roles. You can test the conversion of the field KOSTL into an org level which will give you an indication of any manual cleanups you have to do.

It's generally one of the few that I usually convert to an org level (seeing as profit centre is also an org level as standard).

0 Kudos

I don't know the release of your SAP system but since some years there are some new authorization objects handling cost centers. One of them is K_CCA. Within this object you can grant access to cost centers directly or by hierarchy or by cost center groups. If you find such objects in your roles it is not sufficient to create an org level for KOSTL. You have also create an org level for field RESPAREA.

Read SAP note 565436 first because RESPAREA is a "special" field.

Former Member
0 Kudos

Thanks everyone,

It looks like the cost center field value cannot be limited only to some roles if it is used as an Org level.

It will be distributed to all roles.

0 Kudos

>

> Thanks everyone,

>

> It looks like the cost center field value cannot be limited only to some roles if it is used as an Org level.

>

> It will be distributed to all roles.

That is correct, I can't see why it is a problem though. You can use * for where no restriction is required and then apply your more granular restrictions where required.

0 Kudos

My question relates to this thread, so I will "wake it up" again.

Do you run PFCG_ORGFIELD_CREATE for RESPAREA to implement K_CCA authorizations properly?

And then KOSTL is outdated and not used?

0 Kudos

Hi Mary,

Creating it as an org level doesn't really allow you to run K_CCA auths properly, just make it easier to administer for derived roles. If you are using RESPAREA values to derive on, or there are values tied to org units and you want to keep it restricted then I find it easier to have it as an org level.

KOSTL is still used in some situations, but that depends on what & how you are using in CO. On my current implementation it has no use any more as a restriction.