Explanation for the Organizational Level Fields concept

[Former Member]

Hello,

Could someone please hint me about the 'Organizational Level Fields' concept, and its relation to authorization fields.

I've gone through SAP note 323817, which explains that reports :

PFCG_ORGFIELD_CREATE or ZPFCG_ORGFIELD_CREATE are used to create an organizational level field for an authorization fields.

As far as I understood, Organization Level Fields exist by default after installing SAP, but my confusion is about their relation to the database, i.e. what are they exactly : entities, entity attributes, ...etc. ?

Thank you in advance.

Best regards.

Reda Khalifa

IT Department - Almansour Automotive Group - Egypt

[Former Member]

Org levels usually represent the data fields that SAP uses to portray a company structure.

There are standard org levels that are provided that do not fit this, but I'll explain that in a bit.

If we take company code for example. This is often setup to represent a legal entity or a company in an organisation. When you perform a financial transaction, company code is one of the pieces of data it uses to create and control that transaction. When you create a posting for example, company code will be one of the fields in a table line item.

When we create roles, we know that a number of different authorisation objects use company code as a controlling point. Maintaining each one of these individually would be a hassle so SAP provides the facility to update all of those fields in one go. Therefore if you maintain your company codes for a role in the organisational data popup, all instances of those fields will be updated.

There are cases where there are org level (Account Type is one example) where the org level doesn't exactly map to an element that could represent part of the companies organisational data structure. This is to allow the easy population of multiple fields within a role when you know that the same value needs to be assigned to all of those fields within that role.

The PFCG_ORGFIELD_CREATE and DELETE programs are there to allow you to create your own. Most implementations I have seen have not needed to create additional org levels, though creating custom ones can be very useful if used properly.

[Former Member]

there is one important additition to this: When you make use of Derived roles. all changes to objcts and values in the master role are passed through to the derived roles. The only thing derived roles can be different in are Org Level values. So when you need to segregate the business on a different entity you will have to use PFCG_ORGFIELD_CREATE first.

[Former Member]

Good point Auke. Also worth mentioning that if for some reason you need different field values in different objects for a role that they are not suitable to be created as an org level.

[Former Member]

Just to clarify, when you generate the child roles from the parent role - the ORG values - of the child roles are not overwritten. For example, if your child roles have different company codes - if you need to add a new tcode to the parent role, the child roles keep the same company codes that were previously set up. As a practice, I also leave the ORG values in the parent role in an unmaintained state so I can easily see what ORG values need to be maintained in the child roles.