While I’m the VC or the SM person on most of my projects, one of the things I’ve heard rather often is that the business wants to control who can access the material master by screen. Now, I’ve heard that through security, you can provide field by field authorization restrictions. Short story, nightmare for your security team. No project that I’ve worked on has been willing to go down that path. No, most companies I’ve worked for have “given up”. They give people access to everything and use the honor system to make sure people only touch “their” data.
First question, does this sound familiar to you? If so, I’d like to hear how you’ve overcome the issue.
Why am I asking? we are actually working a little mini-app that creates a single transaction for each set of screens in the material master. For example, the four MRP screens are 1 transaction, Work Scheduling another, etc… We’ve included a configuration screen so that you even hide all of the fields that you don’t care about.
http://javellinsolutions.com/products/material-master-advances-sap-material-master-applications/
What I’m trying to do is to get a pulse on the need for something like this before I invest too much time in it. I confess, it’s not our most creative application or our most complex, but it seems like there’s a need for something like this. So if you happen to have an opinion on whether or not I’m wasting my time, I’d love to hear from you.
Thanks for your input.
As always, thanks for reading and don't forget to check out our SAP Service Management Products at my other company JaveLLin Solutions,
Mike
From what I’ve seen, usually the screen level security is sufficient…with the expectation of long text and the material description. Every place hates the fact that anyone can change the description….I don’t know why SAP just hasn’t setup an authorization object for that one field…it would end most of the complaints.
From there you can could control the screen level it through the M_MATE_STA object.
I think the difficultly you’re going to face moving away from the authorization object approach however is from the SOD/SOX reporting. If a company is using GRC…or some other SOD tool…your custom application needs to be able to tie to that as well for reporting, especially if the field controls are for SOD purposes. Additionally, you are going to face issues with the fact that your security configuration will need to be done directly in a PRD system since your users are most likely not in DEV so you cannot transport it through and audit the transports themselves. As auditors really like paper trails, that’s going to be a challenge to deal with….