XK05 and XK06 not checking auth the same way

Question

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

Answer 1

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