Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Hiding cost? Field level security

Former Member
0 Kudos

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

1 ACCEPTED SOLUTION

Former Member
0 Kudos

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

4 REPLIES 4

Former Member
0 Kudos

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

0 Kudos

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

0 Kudos

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.

Former Member
0 Kudos

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