Account Authorzation of GL Accounts (F_BKPF_BES)

[Former Member]

Hi,

I would like to know how to restrict the authorization group BANK in the authorization object F_BKPF_BES, FI Consultant has assigned the BANK authorization group in the G/L Account code, remaining GL Account authorization group are blank.

I am able to post the GL Account code who has the authorization group is BANK, also, I can post the GL A/C code whose authorization group is NULL, which should not be post .

I have been defined the following value in the ROLE of authorization object F_BKPF_BES

Activity 01 / 03

Authorization group BANK

It is also accepting the GL Account code that don’t have authorization group is BANK and NULL, I also maintained the one authorization group which IS XXXX and has been assigned the 2 GL Account code.

So, I am not able to perform the following transaction code which has the XXXX authorization group. Where condition has been true?

So, How to restrict the GL Account code whose authorization groups are NULL or BLANK?

Does NULL OR BLANK authorization group should be maintained with the XXXX authorization group?

Please advise us

Anwer Waseem

[Former Member]

Anwer,

If you want to restrict GL Account where the Auth Group is Blank or Null, your only option will be populate those GL Account's Auth Group with a Value. The FI consultant can do this for you.

This is because during the syntax of Auth-Check for Auth Object F_BKPF_BES where the BEGRU = NULL, This statement is always true as long as you have Auth Object F_BKPF_BES in your profile.

This will only change if SAP decide to change the coding to check the BEGRU = NULL condition first. For example, Transparent Table that do not have Authorization Group assign, SAP will check to see if user has S_TABU_DIS-DICBERCLS = &NC& (without Authorization Group).

Regards,

Lye

[Former Member]

Hi both,

My understanding of the concept of these type of objects (such as F_BKPF_BES) is that they are designed as <b>optional</b> and <b>protective</b> access. They are over and beyond the common denominator of the standard (usualy mandatory) concept (such as F_BKPF_BUK). As Lye mentioned, if you want to (or there is a requirement to) use them for granting access (as opposed to protecting access), then you need to first exclude all the others to technically reverse the concept. (Noting that some accounts in this case would / should be flagged for automatic postings only (with customized account determination)!)

Regarding S_TABU_DIS... try this => Remove &NC& from the role(s) of a test user in a test system (if you want to, even remove all S_TABU_DIS authorizations), and then drill down to or try to post a G/L entry from any transactions of your choice to see if it still works...

The system checks:

F_BKPF_BUK - an all or nothing concept

F_BKPF_KOA - restriction on the account type, unless other business object prevail.

F_BKPF_BLA - the document type (optional for forcing automatic account determination)

F_BKPF_BES - the account group (optional for protecting sensitive accounts).

If you find that direct table display / update is required for some reason, then you should report it to SAP... because this is an absolute check which bypasses the business logic of the system (SAP is business application software with the logic in the application coding and some other "higher" kernel checks; it is not logic in the data... (like data in MS Access, txt or Excel workbooks).

At least that is my understanding of the intended concept...

Cheers, Julius

[Former Member]

Julius,

I was using S_TABU_DIS as an comparison example how SAP handle Authority-Check logic on a NULL Auth Group value. In Transparent Table case, SAP will check to see if the Auth Group is NULL, if true, check if user have &NC&. For the GL Account Case, SAP was not checking to see if the Auth Group is NULL before performing the Authority-Check syntax. Nothing to do with GL.

Look like I did a lousy job explaining today.

Nice to hear from you again.

Lye

[Former Member]

Hi Lye,

Nice to hear from you too. You were away for a while, but I have enjoyed your

posts again. Always something new to learn at SDN...

I would participate more, but there are some limitations... Unfortunate but true, I have also been rather busy and fixing the own back-yard mostly takes priority.

I will think some more about your comments.

Cheers, Julius

[Former Member]

Hi all of you.

Thanks to all of you, your expert reply on my problem. i really appreciate your experience.

I come on the conclusion that NULL authrozation is not able to check.

i also defined the lot of authorzation group but the problem remain same.

FI Consultant told by me that you should maintain the Authorizaton group in the GL Account master list.

Now, we are waiting for the ABAPER to run the BDC and fill the authrozaton group.

If, there are any possibility, so please update us .

Regards

Anwer Waseem

SAP BASIS

[Former Member]

Hi Anwer,

Are you also using BDC to post to the G/L...? This can sometimes cause strange behaviour (check out SAP note 87150).

There are a lot more on the topic; perhaps some of the symptoms in 175047 sound familiar to you as well?

I am away for a while (leaving in 5 minutes!). I hope that you get your problem solved and do not need to work over the weekend... )

Cheers, Julius

[Former Member]

Hi julius,

Sorry for the delay reply of your response, I will use BDC to replace all the BLANK Authorization group with 'XXXX', then i will take few GL Account code which will replace with the BANK authorzaton group.

Thanks for your expert reply, I will also welcome to any expert opinion.

REgards

Anwer Waseem

SAP BASIS