Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

XK05 and XK06 not checking auth the same way

krysta_osborn
Active Participant
0 Kudos

Hi all,

I've discovered something a bit funky with XK05 and XK06. I'm splitting central block / delete access of vendors from company code / purchasing org block / delete access. One group of users, however, will have central access AND their company code and purchasing org. Here's I've got the roles defined.

Role #1

F_LFA1_GEN activity 03, 05, 06

F_LFA1_BUK activity 03, company code *

M_LFM1_EKO activity 03, purch org *

Role #2

F_LFA1_GEN activity 03

F_LFA1_BUK activity 03, 05, 06, company code CC1

M_LFM1_EKO activity 03, 05, 06, purch org PO1

Both roles are assigned to the same user. The system behaves differently in XK05 than it does in XK06. Both are set to check all of the listed auth objects, but here is what happens.

The user executes XK06 for a company code not included in role #2. The system checks F_LFA1_BUK and fails.

The user executes XK06 for a purch org not includes in role #2. The system checks M_LFM1_EKO and fails.

The user executes XK05 for a company code not included in role #2. The system checks F_LFA1_BUK and passes.

The user executes XK05 for a purch org not included in role #2. The system checks M_LFM1_EKO and passes.

I would have expected XK05 to behave the way that XK06 did. The only thing I can think of is that the two programs somehow determine what the user is authorized for differently. XK06 seems to be looking at the combination of values defined in each role. XK05, on the other hand, seems to be combining them so for example 03/* and 03/05/06/CC1 in F_LFA1_BUK becomes 03/05/06/*.

Now I realize that I should try taking F_LFA1_BUK and M_LFM1_EKO out of my central role entirely and see if that works. I'll update with the results of that test.

Has anyone else seen this behavior?

Thanks!

Krysta

5 REPLIES 5

Former Member
0 Kudos

There is the same program and screen which is started by both programs, but a spagetti of IF SY-TCODE = xyz ... validations in it to determine the program behaviour and which transaction to leave to for further processing.

It seems the difference is that XK06 follows the path of changing the account group for the company code segment of the master record and looks for the first BUKRS and EKORG for which you are marking it for deletion (LFB1 has a field for this).

XK05 is a central lock and the BUKRS and EKORG are not considered for which the master record is being blocked. So it only checks F_LFA1_APP etc but not the BUKRS and EKORG.

*------- Berechtigungspruefung: RM-Ebene (EKORG-Berecht.) --------------
  IF KRED-XEKOR NE SPACE.     " <---- same for BUKRS if not relevant for the activity.
     AUTHORITY-CHECK OBJECT 'M_LFM1_EKO'   "<--- same for F_FLA1_BUK, no check in = SPACE.
        ID 'EKORG' FIELD LFM1-EKORG
        ID 'ACTVT' FIELD B_ACTVT.
     IF SY-SUBRC NE 0.
       IF NOBER_SPM NE 'X'.
         NOBER_SPM = 'X'.
*        CASE B_ACTVT.
*          WHEN '05'.
*            MESSAGE I333 WITH LFM1-EKORG.
*          WHEN '06'.
*            MESSAGE I334 WITH LFM1-EKORG.
*        ENDCASE.
       ENDIF.
     ENDIF.
  ENDIF.

So it looks as if it is intentional and a dependency on where (which segment) the master record field is located in.

Perhaps of you choose MK05 and FK05 as transaction codes then you can achieve what you seem to want from the program?

Cheers,

Julius

0 Kudos

Hi Julius,

Thanks for your response. I hear you about using the MK/FK tcodes instead, but we're small so I've got one group of users that will block centrally and also for their company code / purchasing org so they'll need the XK tcodes. Since they can block centrally anyway, it's not a problem that XK05 allows them to block for any company code and or purchasing org; it's just confusing that both XK05 and XK06 don't behave the same way.

My debugging skills are pretty sad, but I was able to see that both transaction codes hit the code you highlighted below. When XK05 hits it and KRED-XEKOR is not blank, it passes the authority check even if the purchasing org entered on the screen is not included in the user's role. When XK06 hits it and KRED-XEKOR is not blank, it fails the authority check if the purchasing org entered is not included in the user's role. What I'm trying to figure out is why. I can't figure out how to see what the system is comparing when it executes the authority-check statement. I also wasn't able to find the spaghetti you mentioned about the program checking the tcode before deciding what to do. Can you please tell me where that is?

Regards,

Krysta

0 Kudos

Hi Krysta,

The "spagetti" I mentioned is the necessary evil of having many transactions using the same program and expecting it to behave differently.

You can see this by the number of validations of system field sy-tcode in it and the number of leave to transaction and call transaction statements.

Personally I agree that it is a lesser evil although one should expect the two transactions to use the same semantics in the checks. so I would open a customer message with SAP and report it if I were you.

A possible explanation for it is that the blocks and delete flags are set in different master data segments (LFA1, LFB1, LFM1) and that this had a higher priority for the checks than the expected semantics based on use of transaction code.

Let us know what SAP's explanation is and can test the impact or the reason behind it, also if the checks would be changed and made stricter (but please dont ask us all to open a connection to all our systems - you can skip that by asking for screenshots of the "cannot replicate the problem"..

Cheers,

Julius

0 Kudos

I have a message open with SAP. Their first response was it depends on how you have your role defined so ask your consultant if you're confused. Now I have to figure out how to word my response so that they get that it's a program behavior issue not a role definition issue.

And I promise not to ask everyone to open up a connection for SAP to back me up that this really is an issue! : )

Krysta

0 Kudos

I find that it works to ask them for screenshots of their test role(s) and the test result(s) and also send them mine.

Works for me...

Cheers,

Julius