Vendor Master Maintenance Security

[Former Member]

Fellows, are you able to review and lend your thoughts around the below described security requirement.

Vendor maintenance requirement: Transactions XK01/02/03 and FK01/02/03.

At our client we have a Master Data team which globally maintains all the Master Data records (Vendor/Material/Customer etc.). Thus the task of creation and maintenance of Vendors rests with this group. And we have one single role (Global) for this Master Data team which provides global access for this maintenance.

But we have a requirement such that Master Data team should not have access to Banking details of Vendors located in the US. Banking information of Vendors belonging to US Company code should only be available to AP (Accounts Payable) Managers in the US. With this, while creating the US Vendors, the Master Data team are responsible for maintaining all the necessary Vendor information except for Banking information, the responsibility of which lies with the US AP Managers only. But at the same time Master Data are required to create vendors and maintain all (including Banking) information for Vendors outside of the US. Is there a way we can achieve this i.e. Master Data team maintaining Banking information for Vendors belonging to all company codes except for a few company codes (e.g. say US* company codes). Are you aware of any authorization object with Company code field along with field that helps restrict specific tabs within these transactions ?

Let me know if you have questions and are having difficulty understanding the requirement described above.

Would appreciate your suggestions.

JJ.

[Former Member]

One of the ways of doing this is via field groups for the vendor master to be protected but the vendor group or BUKRS of the vendor view is a different object - so you cannot create a "slice" out of the authorizations for which you do not authorize. At least, not without creating 2 user IDs for each of the central mast data team members.

As a form of workflow (alternately), you could also turn the F_LFA1_AEN object around and protect all fields with a "global" group except the bank details. Mark the bank details field as a "sensitive field" requiring a confirmation (see activity 'C2'). Then the US can change that field only but the global team must confirm it. (global team must also confirm each other's changes for any other country as well..).

You could also attempt to protect all fields with F_LFA1_AEN but that is a lot of customzing and complexity and "false positives" in GRC type reporting just because of a few managers who want to hang on to some access flexibility.

If I were you, I would tell the purchasing managers in the US to conform with the company policy if the rest of the world has to do it as well.

If you want to enforce this for any of the countries, the master data team must provide a good service of maintaining it fast and in high quality for them. For what other reason did you implement centram master data maintenance?  😉

Cheers,

Julius

[Former Member]

Thanks Julius.

Do you think there is a way I can utilize auth. object F_BNKA_BUK (Banks: Authorization for Company Codes) by incorporating a check on this object in the code for Vendor master transactions XK01/02/03. I'm not very sure about the usage and functionality of this object but sounds like it allows restriction on banking information based on Company code.

JJ.

[Former Member]

Unlikely. That is to maintain the house banks own master data...

Another (similar) idea would be to define all US vendors as CPD accounts. But then they should all pay cash in advance ideally as the bank data is entered into the transaction data screens and not the master data derivation...  🙂  (just a joke)

I will think about it a bit more, but it sounds like you have an in house political problem and not a technical one. I would throw it back to the project manager that the US managers are wanting something which is not intended in the concept.

Cheers,

Julius