Hiding Condition Type EK02 for selected users

[Former Member]

Hello gurus,

Please suggest me how to restict condition type EK02 for selected users.

I have give different condition types in the object v_konh_vks but still the users are able to view EK02 condition type.

Please let me know how to restrict EK02 condition type.

Thanks in advance

VJ

[arpan_paik]

What is the transaction user is using?

[Former Member]

Hello

The Transactions are VA01,va02,Va03..

Thanks

VJ

[arpan_paik]

Hi VJ,

Object v_konh_vks is not a must check for all the 3 transactions VA01, VA02, VA03. So even if you maintain authorization in user master then also the object is not getting check at all while user is trying to execute VA01/VA02/VA03. Prior to that these 3 transactions are very frequently used transactions for Sales. So getting a idea of user exit will not be great I think.

Arpan

[Former Member]

Hello Arpan,

Any suggestions fom your side..

Thanks

VJ

[Former Member]

Hello Vijay,

There are a couple of aspects to check first:

1. Find out in transaction SU24 for VA01 the status of the Check indicator. If it is Check its ok. If it is set to Do not Check you've got a problem on hand because this supresses the authorization error even if the program workflow is doing a check on the object.

2. Assuming that the check indicator is set to Check, get the functional follks to test the transaction while you start a trace on their ID (ST01). If you find out that the object V_KONH_VKS is not being checked, you then start thinking about includes(user Exits). Of course the feasibility of this aspect is decided by the ABAP folks.

Hope this helps...

Regards,

Prashant

[Former Member]

Guys,

I havent checked neither the settings in SU24 nor the program flow for VA01/02/03 but logically speaking, Immaterial of the su24 check object maintenance (either to YES or NO) the program for Sales order creation would definitely require authorization on V_KONH_VKS. this is more for the manual maintnenace of price conditions.

the pricing in the sales order is dependent on the particular pricing procedure for the customer and if additional pricing conditions like discounts or surcharges are defined as maunual conditions, in order to maintain them you would need authorization on the object

Now, coming to suppressing a particular condition type that is defaulted by the pricing determination proedure would not be an ideal thing to do - for sure. But, if you insist on it, the only option could be that you make a modifiction in the user exit for sales orders (MV45AFZZ - Exit should be something similar to "Pricing prepare " or "document save" ) - make a search on these linesand here you my try to modify the program to suit your need and logic

[Former Member]

guys,

just to add to what i mentioned above, i think you would need access on V_KONH_VKS (activity 02) if you have VA02 and if someone maintains a condition record via VK11/VK12 with a different price to the one that is in the order, then you would have to go to VA02 and click on update conditions (i would think the object would be checked in this case)

EX; If i have a sales order that has been created 10 days back, and the ist price of the materia has changed from what is in the sales order, then we would maintain the list price using VK12, go to VA02==> PRICING and clink on update - the current list price would then be copied into the order.

[Former Member]

If you ignore the hard-coding and the points-gaming, then you will find your answer in this thread:

Cheers,

Julius

[Former Member]

Julius,

My apologies on this, but the thread you refer to is a very bad and appalling one. I am not sure of all the SAP notes mentioned in the thread, but the general technical view exchange on the authorization security front is very poor.

There are people suggesting to change the condition types from Manual to automatic (or some crap like that) - this is the dumbest advise i would read on a thread

and what about the SY-UNAME hard-coding, crappy.......and even you were cheesed off with it, isnt it?

I would still thinik, the suggestion i made earlier on hiding a particular condition type in the user exit during sales order saving, would be a relatively safer option.

BUT, i think - to look into the condition type EK02, you need not go to VA01/02/03, any user who has SA38 access and the right combinations can execute and download quite a few programs for the prices

[Former Member]

The notes tell you where the exits and BADIs are, but not what you have to do there or how.

Unfortunately they don't mention everything which you should not do. When it gets to exits, that list gets very long...

Feel free to comment on the other thread with your opinion, but perhaps avoid the words "stupid" and "crappy". Ashish was very polite about the whole thing and already took some "flames" for his old blog.

Cheers,

Julius

[Former Member]

sorry to one and all for being a bit over the hill.........i dont mean anything bad or disrespectful

[Former Member]

I only mentioned that because I already used the word "stupid" myself and Ashish reacted in a very civil way. It was an old blog - take a look in your system at some of the older programs...

Anyway, Vijay has:

> Total Questions: 7 (7 unresolved)

...and if he does not follow up on his threads (see your and other's answers above) then we don't need to wonder that the discussion at most leads to answers for others, but not the OP.

Back to the topic: An exit with security coding in it should ideally use an authorization object check to make functionality available to the users with that authority. If you code sy-tcode or sy-uname checks, then you do not need to wonder that they can break out of your security in SA38 or SM37.

SU24 "no check" indicators do this to some extent in a "safe" way as an exclusion of the object, if the program checks the transaction code context correctly (and not excessively...). But you cannot use field values as exclusions!

The enhancement concept (and switch framework) as well as BADI's give you the option of adding code to the business logic of the program flow or the presentation logic. This is an important distinction, and I wonder why Vijay has not reacted to your second post - also distinguishing between the transactions which the user does have access to.

Perhaps he does not even understand the question, and the customer worked it out for themselves in the meanwhile...?

On a lighter note: Is customizing an option here? Once printed, some documents cannot be changed anymore...

Cheers,

Julius