2010 Oct 18 8:09 PM
Hi
I'll bet this has been asked a few times before but I'm struggling to find anything relevant in theforums. This really isn't a security issue as there is the option to suppress the bank account field in SPRO but I just wondered if anybody had found a work around or proper SAP standard S&A to resolve please?
The perennial "We need to stop people seeing vendor bank account details for our employees but still can see the 'real' vendors' bank account details!" question has been raised, I've offered the suppress bank account details field (load blunderbus and fire option) but is there anything I can do to refine this?
This is a fairly old 4.6D system due to be upgraded late next year and there's been no XK03 custom transaction mod made so far as I can see.
Vendors have been define as EMPLOY,..., etc so the split is there if needed...
Thanks for your attention - just wanted to see if this was possible?
Regards
David
Edited by: David Berry on Oct 18, 2010 8:15 PM
Edited by: David Berry on Oct 19, 2010 3:37 PM
2010 Oct 19 4:22 PM
Hi David,
It's not much help but by far the most common approach I have seen/used is to strictly control access to see any part of the employee vendor. That way you use F_LFA1_BEK + F_LFA1_GRP to completely restrict employee vendors to the responsible team and avoid issues with visibility of bank data and other key data that could potentially fall under the DPA (too many people being able to access address data etc - very subjective of course).
2010 Oct 19 6:04 PM
Hi Alex
Thanks for replying - I'll have a look tomorrow as we're a bit braindead today (been one of those days!)
Cheers
David
2010 Oct 21 6:33 PM
Hi Alex
It's a nasty one alright - can't seem to lock it down unfortunately. I've tried the following objects:#
Customer: Central Data F_KNA1_GEN
Customer: Account Group Authorization F_KNA1_GRP
Vendor: Change Authorization for Certain Fields F_LFA1_AEN
Vendor: Application Authorization F_LFA1_APP
Vendor: Account Authorization F_LFA1_BEK
Vendor: Authorization for Company Codes F_LFA1_BUK
Vendor: Central Data F_LFA1_GEN
Vendor: Account Group Authorization F_LFA1_GRP
Tried staring with empty object field values and, after a few SU53's ended up with access to Bank details again - looks to be a lost cause
ST01 shows little me I have little / no option:
18:27:05.525.984 AUT 0 <- F_LFA1_GEN:ACTVT=03
18:27:05.526.415 AUT 0 <- F_LFA1_GRP:KTOKK=OWDR,ACTVT=03
18:27:05.526.458 AUT 0 <- F_LFA1_BUK:BUKRS=0100,ACTVT=03
18:27:05.526.499 AUT 0 <- M_LFM1_EKO:EKORG=0100,ACTVT=03
Thanks for trying - if I can't do this by auths then maybe I should go down the SHD0 route but I've never done this before so will get some help within the business.
Cheers
David
2010 Oct 21 7:02 PM
I thought this is what transaction OB23 is for? (in customizing)
If you create a vendor group called "employees" in OSMG then I think it should be possible without SHD0.
Cheers,
Julius
2010 Oct 21 7:27 PM
Hi Julius
This i why I like SAP - always learning. I'll investigate that option first thing tomorrow, probably won't have change SPRO access which is probably a good thing but I'm sure somebody in the FI config team will have a look for me.
I'll post as soon as I have any progess.
Thanks to both of you for your time as this may also resolve another XK02 issue just received for a different restriction.
Cheers
David
2010 Oct 21 7:50 PM
Hmmm... at a closer look, OB23 is a transaction code related suppression of the screen, and not a vendor type or group control.
This means you will have to suppress it for all users, but could possibly use different tcodes for different groups of them to get the split right.
An alternate option is protecting all employee type vendors using F_LKA1_BEK groups. This object is only seen in the trace if the vendor account is assigned to a group, otherwise the check is skipped completely (it is an optional object).
Plan C: find a BADI in the screen program and clear the back details if the user is not authorized (either for something you already have in place in auths, or worste-comes-worste a custom object).
I think you should open the thread again as "unanswered"...
Cheers,
Julius
2010 Oct 22 10:17 AM
Hi Julius
Just checked transaction OB23 - it's where I was looking in SPRO previously (the load the blunderbus and fire approach) but I didn't realise it was that transaction
Cheers
David
2010 Oct 22 11:02 AM
Hi David,
doesnt a restriction on F_BNKA_MAN, help? Along with XK01,02,03 You might have to check the users authorizations for FI01, FI02, FI03 on the same object
Cheers
2010 Oct 22 11:54 AM
Hi
Thank you!
Interesting... the object is set to check only (which is also the SAP default), the program seems to be set up to verify create access:
MF02KI00 999 AUTHORITY-CHECK OBJECT 'F_BNKA_MAN'
ID 'ACTVT' FIELD '01'.
I've updated SU24 which this client doesn't do, I'll run the SU24 to QAS and test it after 2pm today.
Cross fingers
Cheers
David
2010 Oct 22 1:44 PM
HI
Well, it was worth a go ;-(
SU24 in QAS = Check/maintain F_BNKA_MAN Banks: General Maintenance Authorization
One role assigned to the test user with XK02 in it:
Manually Cross-application Authorization Objects
Manually Banks: General Maintenance Authorization
5 Manually Banks: General Maintenance Authorization
Activity 03
22.10.2010 SAP trace analysis
Terminal Task Type V* PID
Time 13:37:15 BST Date 22.10.2010 Trans/Rep. XK02
user ZTEST1 client 001 mode 1
Host tauksap_tst System AT1
13:37:15.521.278 AUT 0 <- F_LFA1_GEN:ACTVT=02
13:37:15.521.317 AUT 0 <- F_LFA1_GRP:KTOKK=OWDR,ACTVT=02
13:37:15.521.349 AUT 0 <- F_LFA1_BUK:BUKRS=0100,ACTVT=02
13:37:15.521.386 AUT 0 <- M_LFM1_EKO:EKORG=0100,ACTVT=02
I'll have a word with one of the developers to see if the program is working correctly
Have a lovely weekend
Cheers
David
2010 Oct 22 1:59 PM
...the object is set to check only (which is also the SAP default), the program seems to be set up to verify create access:
Crossing your fingers won't help here. SU24 does not control authority-checks at field value in programs. The Check/Maintain only determines which field values are proposed in PFCG.
The ST01 trace will also show you authority-checks which are used in program and screen flows - you do not necessarily need the access to be able to use the program.
SE38 will also show you checks in the code which using the program might never reach (hence no trace of them).
I would go for the BADI option.
Cheers,
Julius
2010 Oct 25 7:59 PM
Hi
Given the problems, the decision has been to bounce this back to the business as trying to make the transaction behave in way that is against its nature. We'll try to get them to move the access out and back into the master data team where it belongs.
Cheers
David
Edited by: David Berry on Oct 25, 2010 7:59 PM
2010 Oct 25 8:17 PM
> We'll try to get them to move the access out and back into the master data team where it belongs.
If that is the way they are set up and have requirements (to isolate the access for that group based on the transaction context) then that should certainly be the easier way.
The navigation calls in SAP standard generally determine the tcode context based on the user's access to set the context, but you might also want to check Z-programs or "CALL SCREEN" statements...
Cheers,
Julius
2010 Oct 25 11:00 PM
Hi Julius
I'm trying to guide them back to an SAP standard way of working instead of creating more Z codes etc (the 'we need' policy) being 'sorry but you can't have it' instead
Cheers
David
Edited by: David Berry on Oct 25, 2010 11:00 PM
Edited by: David Berry on Oct 25, 2010 11:04 PM
2010 Oct 26 10:29 AM
Hi Julius
I'm looking at the CALL SCREEN entries returned when searching program SAPMF02K and I'm lost - backed away and hid under the desk...
We just batted back the Z tcode request we got verbally as I still think this is an SoD however the tcode is hacked to reduce the bank data.
Cheers
2010 Oct 21 8:39 PM