top of page
  • Writer's pictureCorrib Consulting

MDG - Master Data Governance - Company Code Restrictions

Updated: Nov 25, 2023

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



Sub Entity

Profit Center


Internal Order



General Ledge


Cost Center



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**

446 views0 comments


bottom of page