Skip to Content

Restricting a Characteristic With Its Compounding Characteristic.

There are situations when there is a need to make a restriction on a characteristic with its compounding characteristic. I will try to explain the problem with an example, mention about the SAP Note related with this problem and propose a shortcut solution for this problem.

Problem Definition:

Suppose we have a characteristics ZDUMMY_PA (Personnel Area) and ZDUMMYPSA (Personel Sub Area). ZDUMMY_PA is the compounding characteristic of ZDUMMY_PSA. We have data such as:


We have an infoprovider using these two characteristics. We have a query where we make a restriction on ZDUMMY_PA. We want to restrict the Sub Areas: 100 from A area and 200 from C area. In the query when we drag A/100 for the restriction, only 100 is dragged and all personnel areas related with 100 are included in the restriction as seen below:


An overview on SAP Note related with this problem:

The SAP Note: 541253 describes this situation and proposes a solution. However, this solution is not suitable for the requirement described above. The note suggests restricting the compounded infoobject. When we do that in this case, we have to restrict A and C for personnel area and 100 and 200 for personnel subarea. Then in the report we will see all 100 and 200 subareas belonging to A and C. That is; even if we don’t want to show A/200, it will be shown in the report.

Solution approach for the problem:

The shortcut solution I suggest will be defining a new attribute to Personnel Subarea characteristic. For this aim, we define a new characteristic with data type char 8 (8 comes from the total number of characters defined in personnel area and personnel subarea. In our example, personnel area is defined as char 4 and personnel subarea is also defined as char 4).

We add this new characteristic as the attribute of personnel sub area: ZDUMMYPSA.


In the transformation for master data we add personnel area and subarea to source fields list and select rule type as routine:


We write a small routine to update ZDUMMYCH:


In this part, we may give any other character in between the personnel and subarea. I generally use ‘/’ sign in between.

This kind of approach may become a must in some situations. For example if we had personnel_areas such as A and A1 and subarea

such as 100 and 00, when we concatenate there will be one concatenated value for two different personnel area – subareas: A100.

Then it will mislead the report when filtered. For sake of simplicity in this blog I go with direct assignment without any character in between.

After we load and activate master data we see the master data as:


Now we need to add ZDUMMYCH to the navigation attributes of the infoprovider. Then in the query designer we can add ZDUMMYCH to the characteristic restrictions pane and we can easily select ZDUMMYCH to filter with our desired restrictions:


As a result, with some modeling changes in both characteristic and the infoprovider, we can achieve to see the desired results. I hope it gives an idea.

Yasemin Uluturk

You must be Logged on to comment or reply to a post.
  • Well documented and good presentation with scenario.

    Compounding characteristic is one of the object which place tricky role at bex level.

    Thanks for sharing the problem with solution.



  • Really interesting and tricky way you shared to overcome that issue.I guess this approach can also be a solution to the problem when we make user input variable on compounding characteristic and user is supposed to choose the values from both the objects to get the required combination.



  • Yup a clever way of going around things.

    But i just wanted to put one point here Yasemin. You took a scenario where the values of the compounded InfoObject ZDUMMY_PA is "A" or "B". What i mean here that it is easy to recognize "A" or "B".

    This will not always be a case in the practical scenario. For example :

    Your personal area is : A00 itself

    And your personal sub area is : A001

    After your concatenation routine the output would be : A00A001.

    So you see this might confuse a normal user .

    Now what could be a good add on to your approach :

    You can put a "/" in between while concatenating. So that the user will be able to differentiate completely . Of-course "/" should be allowed as a special character in your system .

    Hope my above point is clear Yasemin.

    But nonetheless what you had a presented is a complete solution in a way.


    Ashutosh Singh

    • Hi Ashutosh,

      You have mentioned a good point. Thanks for that. Generally I go with assigning '/' character in between as you have mentioned. In the blog, first, I wrote it as you have said (That is why the zdummych characteristic is defined as type  char 9 (you can see in the transformation rule 🙂 ) . Then I just thought that in some of the systems '/' may not be defined as special character and mentioning that would take the subject to another point. So I changed my mind to do that way. But at least I could mention that such an assignment may be possible so as to handle any confusion. Furthermore, zdummych can be defined with text and meaningful text can be uploaded and shown in the report.

      Thank you very much for your comment and like. Have a great day 🙂



  • Thanks for your time and sharing knowledge on solving the issue in a tricky way!

    Hope this will give answers/ideas to many who face the scenario.

    Cheers! keep posting,


  • Playing with Compunded chars is always a tough task in Bex 😉 Your approach seems to be good but additional Modeling changes may require some approvals till you get it in place 🙂 ANyway it's our job to convince people 😉 . Thanks for sharing this approach..Bookmarking it..



    • Hi Suman,

      Thank you for your valuable comment 🙂 Sometimes modelling changes makes life easier, makes performance better. Performance related convincements work every time 😉 By the way welcome back...