10-28-2008 6:32 PM
I am working for a client that wants to hide cost from the eyes of sales people. I am using the traditional method of analyzing each transaction that shows cost and determing if it can or can't be restricted with standard security. I am finding out that most of the time, you can't "hide" it with security. There are many transactions (ie: IW3*, DP80, DP90, MB03, etc) that is "all or nothing". Some transactions check objects (ie: MM03) that will allow you to do this. I am now tasked with researching other ways to do this. Is there any way to do this with security other than yanking every transaction away? Any third party products/services that do this? Any way to block the data off behind the scenes to everyone while allowing access for others? I thought about the possibility of creating an authorization object for this but I imagine that requires changing the code of many SAP programs.
Any thoughts and suggestions are greatly appreciated.
Thanks
10-28-2008 9:32 PM
Hi Joe,
I have a similar situation at one of my clients.
We have used the following, depending on the transaction
1. Transaction Variants (SHD0) - Hiding fields etc
2. Enhancement Points - basically like user exits, you can put custom validations in standard code. We have a good number of these where there are additional auth checks in place which toggle cost & price display in a wide range of transactions
3. Copy standard transactions - there are a few situations where we have needed to create a copy of a standard transactions and change the code.
4. Last but not least, standard authorisation concept. Some tx let you hide prices via condition types, Purchasing can control price in the M_BEST* objects with activity 09 etc.
For 2 & 3 we have used a single authorisation object which is referenced and allows display or no display of prices - quite easy to monitor.
Cheers
Alex
10-28-2008 9:32 PM
Hi Joe,
I have a similar situation at one of my clients.
We have used the following, depending on the transaction
1. Transaction Variants (SHD0) - Hiding fields etc
2. Enhancement Points - basically like user exits, you can put custom validations in standard code. We have a good number of these where there are additional auth checks in place which toggle cost & price display in a wide range of transactions
3. Copy standard transactions - there are a few situations where we have needed to create a copy of a standard transactions and change the code.
4. Last but not least, standard authorisation concept. Some tx let you hide prices via condition types, Purchasing can control price in the M_BEST* objects with activity 09 etc.
For 2 & 3 we have used a single authorisation object which is referenced and allows display or no display of prices - quite easy to monitor.
Cheers
Alex
10-29-2008 3:39 PM
Thanks, could you recommend any place to get more info on these things whether it be a web url or book? I've never been tasked with doing something this advanced.
Thanks again
10-29-2008 6:57 PM
Hi Joe,
For transaction variants: http://help.sap.com/saphelp_nw70/helpdata/EN/67/232037ebf1cc09e10000009b38f889/content.htm
For enhancement points:
http://help.sap.com/saphelp_nw70/helpdata/EN/94/9cdc40132a8531e10000000a1550b0/content.htm
It's worth speaking to your developers about both, I have found a few to be unaware of the potential options.
10-29-2008 11:13 PM
Another option is to use a completely different system for the costing, and the folks who enter, display or report on it have very specific transactions (or reports..) to access the data (in the remote system).
Everyone else does not see the data because the costing tables are (locally) empty.
Of course, this can mess up your reporting and some SPRO options might fall away (costing based validations, etc).
I have my doubts whether it is a good idea or whether you will find a neat (and secure) way of doing it, but it could be an option worth considering.
You seem to choose your directly executable transactions carefully (which is a good thing), but SAP transactions are often very navigable (via menus and double-clicks).
Cheers,
Julius