Search
  • Corrib Consulting

MDG - Master Data Governance - Company Code Restrictions

Updated: May 18

When designing MDG roles, you may come across the requirement to restrict roles by their respective company codes. You are more than likely familiar with the common and well known method of restricting roles via $BUKRS when it comes to Company Code but unfortunately its not so straight forward when it comes to MDG. The following blog will explain how to apply Company Code restrictions on different Entity types in MDG.


Take for example the four most common types:

  1. Profit Center

  2. Internal Order

  3. General Ledger

  4. Cost Center


First off, there is some SPRO config that is needed to be switch on in order for Entity types to check on Company Code.


SPRO > Cross-Application Components > Master Data Governance > General Settings > Data Modelling > Define Authorization Relevance per Entity Type



The following table represents the ENTITY types that relate to Profit Center, Internal Order, General Ledger & Cost Center

Component

Entity

Sub Entity

Profit Center

PCCCASS

Internal Order

​IORDER

CCODEIORD

General Ledge

ACCCCDET

Cost Center

CCTR

CCODECCTR

Once the SPRO config has been done, you are ready to build the SAP roles. The main authorization object that is used for this purpose is USMD_MDAT. This is populated from SU24 by the Web Dynpro Application - USMD_EDITION_CREQUEST


Here are the default SU24 entries for this Auth Object:


An example of how a role can be restricted can be seen below. You will know that the new authorization check has been configured correctly as the "Internal Order" and "Company Code" option now appears.


Another example that can be seen is Cost Center. The below role is built for "Change Requests" for Cost Center. Here you can restrict on Controlling Area & Company Code.


The last example is General Ledger. We can see that the Entity type for General Ledger is ACCCCDET. ACCCCDET checks on COMPCODE which allows your security consultant to restrict on Company Code in the role.


You will of course have to fit this into your role design, you may need to promote KEY_FLD1/2 to an Org Level, but it would not be recommended in our experience. Single roles would be the our recommendation but you may also be able to achieve this with derived roles with some careful planning.

**An important tip to know, in the security roles, to over come a design bug in the authorisation checks, you must place ‘‘ into the company code range in order to overcome an issue in cost centre checking. There is an issue where by the user cannot proceed unless a cost center is entered which shouldnt the case**


156 views0 comments