So you want to restrict parts of your business to different groupings in Business Partner. By
default SAP doesn't support with this standard Auth objects (B_BUPA_ATT will not work for this). Lucky for us there is an easy and straight forward way of creating a custom auth check to satisfy the business needs.
1: In this example we will use the Treasury Partners as the grouping we want to restrict by. First things first, we need to create a new Authorization field, lets call it ZGROUPING. Go to SU20 and create a new Authorization Field and call it ZGROUPING:
The field is called ZGROUPING and the Data Element should be called BU_GROUP. Notice the Authorization Object used and also the class. We will speak about this next.
2: The next step is create a new custom Z Authorization Object, lets call this the same name as the previous Authorization Field, ZGROUPING. Go to SU21 to create the new Object:
Once you create the object, you get the option to choose which class you wish your new custom Z object to appear in, seeing as we are dealing with BP restrictions, the most logical place to put it is in the class AAAB, as this is where all the BP related Auth objects are held as standard. You want to make this process easy to maintain going forward as other security consultants will always check under AAAB for BP related restrictions.
Also, make sure you map your newly created Auth Field to this object or else this will not be pulled into the object after the SU24 step. Check the Authorization Fields section that it looks like the picture below.
Now that you have the field and object created, its time to look at which BAdI we are going to use to activate the authorization check on the grouping field in the Transaction BP.
Checking the SAP Documentation and more specifically, the SAP system itself, you will be able to find a standard BAdI called "BUPA_FURTHER_CHECKS". This is the BAdI we are going to copy for our own use here.
To do this, go to Transaction Code SE19 and Create a new Implementation of BUPA_FURTHER_CHECKS:
After clicking "Create" it will prompt you with a new screen where you can then create the new implementation in your own custom name space: ZBUPA_FURTHER_CHECKS
Once you have the new implementation created, you need to do some small modifying and a couple of lines of ABAP Code. Navigate to the new page where you can edit the BAdI and click on Interface. Now you should see the same screen as below:
Once you are here, double click on the Method called "CHECK_CENTRAL":
After you double click, you will see the following screen:
Here is where we will insert some small easy ABAP Code to activate the Authority Check on the Grouping field in the BP Tcode. Please copy and paste the following snippet: AUTHORITY-CHECK OBJECT 'ZGROUPING'
ID 'ZGROUPING' FIELD iv_group.
IF sy-subrc <> 0.
ET_RETURN = value #( ( type = 'E' id = 'ZBP_RETURNS_ERROR' number = '000' message = 'You are not authorized to change BPs in the group' ) ) .
ENDIF.
Once you copy the text in, it should look like this:
Once this is done, you have to Activate this AUTHORITY-CHECK by clicking on the Activate button:
Now, we have create the Authorization Field, the Authorization Object and a new Implementation for the BAdI. What is now left to do is to starting mapping this correctly and smartly in SU24. If you remember I said this particular example is going to be used for our Treasury teams, you can easily also apply this to other areas of your business, such as R2R, OTC, Accounts Payable, etc. As the check is done on the transaction BP, we need to go to the transaction SU24 and create a new variant: Go to Transaction SU24:
Create a new Variant of the Transaction Code BP:
Let's call this new Variant ZBP_TREASURY:
Once you have created the new Variant, click on the variant and add in the new Authorization Object we created called ZGROUPING.
In here you will also maintain the default value that would have received from the functional consultants as to what Group(s) should the users in Treasury be only allowed to Edit/View. In this example, the BP Group called TR02 is going to be the default value that Treasury users should only be allowed to Edit.
Once you have saved this in your transport, you then must make sure you are mapping this newly created variant to the correct Treasury BP roles in PFCG. Go to PFCG and open the role you are wishing to map to this new value, in our example we will use the below role. As you can see from the naming convention, TR means Treasury, which means only a user based in Treasury teams will receive this role.
Open the role in Edit mode and select the newly created Variant so that the new values will be pulled in from SU24:
After this has been saved, go to the Authorizations tab and confirm this new values have been put in, it might be worth double checking the values are pulled in by sync the Expert Mode, it should be necessary but just in case its always better to be sure you are pulling in the newest values from the variant:
Checking the class AAAB you will now see that the ZGROUPING object has been pulled in from the new SU24 variant and also the correct "TR02" value:
Now to checking that the Authorization Error is returning correctly if we try to create a BP outside of the Grouping that we have specified in the Object ZGROUPING:
As you can see, the AUTHORITY-CHECK is working as expected.
The beauty about using the SU24 Variants for such exercises as this, is that this can be easily applied to different parts of your business, it will of course mean creating a few more variants but it will ensure a strong role design based on standard which will be easier to manage going forward. I hope you found this useful.