Fields updated to Organizational Field

[Former Member]

Hi all,

Does someone confirm that the only ones fields that cannot be converted into an organizational level field  are “Activity”, “ACTVT” and “Transaction code”, “TCD”.

In negative case, there is a list where i can get all of them? Can i have problems updating some of them?

Thank you in advanced.

Best regards.

[Bernhard_SAP]

Hello Sara,

checking pfcg_orgfield_create I found the following fields not accepted to be converted into orglevel fields:

ACTVT

AUTHPGMID

AUTHOBJTYP

AUTHOBJNAM

TCD

SRV_NAME

SRV_TYPE

RFC_TYPE

RFC_NAME

P_GROUP

P_ACTION

OBJECT

AUTH_FIELD

AUTH_VALUE

.INCLUDE

The report simply denies the conversion.

b.rgds, Bernhard

[mvoros]

Hi Bernard,

which version did you check? I can't see anything like that in old 7.01 system.

Sara: OSS note 727536 provides more info about custom org. level fields.

Cheers

[mvoros]

I found it. OSS note 1502568 brings additional check for fields not suitable for org. level.

Cheers

[Former Member]

With the help of an org. level value modelling workbench, one could model combinations of fields which may or may not be technically org. levels for PFCG in table USORG and pass them as templates to roles. You could tap into SPRO to get the org level customizing to import most of them.

Unfortunately it is not possible to demote SAP Standard org. fields to normal fields.

If your business processes are documented in Solman at tcode level and you can add such templates to a collection of process steps, then you could also generate roles from there for the collection of process steps, calculate the optimal size / granularity of the role build and adjust the menus centrally.

Otto Gold and I are working on such a project. If an org.level template workbench were available, it would actually be tempting to demote all fields to normal fields and then create templates for scenarios which can be mapped to business processes.

At most customers build "module" based roles which have excursions into objects from other module classes. Technically defined org. levels in the practice sometimes hinder the ability to create process alligned roles, in additon to the fact that any business person who can actually talk about role definitions generally has a very "module" (their data...)  related view of the world...  🙂

My 2 cents to the topic. (and would be intereste to know whether anyone else would like to demote Standard Org. Fields - the general trend seems to promote them to be able to use derived roles, which is IMO not a good solution even if it seems tempting at first).

Cheers,

Julius