How to suppress vendor bank account for vendor types

[Former Member]

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

[Former Member]

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).

[Former Member]

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

[Former Member]

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

[Former Member]

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

[Former Member]

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

[Former Member]

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

[Former Member]

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

[Former Member]

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

[Former Member]

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

[Former Member]

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

[Former Member]

 ...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

[Former Member]

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

[Former Member]

> 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

[Former Member]

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

[Former Member]

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

[Former Member]

re-opened to see if there are any further options available