Condition type restriction

[Former Member]

Hello Sap Guru's,

In the scenario, how to restrict condition type for manual entries to a particular user?

Regards,

JP

[Former Member · Accepted solution]

Hello,

You can prevent the manual entires of a condition type in sales order but I don't think only one condition type can be prevented to a particular user. Talk to your BASIS team, they may be able to help you out.

Prase

[Former Member]

Hi,

The following code will make the condition type PR00 modifiable for user ABAP1 and non-modifiable for all other users.

-

---

FORM USEREXIT_PRICING_PREPARE_TKOMP.

DATA : i_T685A TYPE STANDARD TABLE OF T685A WITH HEADER LINE.

IF SY-UNAME = 'ABAP1'.

LOOP AT XKOMV.

IF XKOMV-KSCHL = 'PR00'.

SELECT * FROM T685A INTO TABLE I_T685A WHERE KSCHL = 'PR00'.

READ TABLE I_T685A WITH KEY KSCHL = XKOMV-KSCHL.

I_T685A-KMANU = 'C'.

MODIFY I_T685A INDEX SY-TABIX.

MODIFY T685A FROM TABLE I_T685A.

REFRESH I_T685A.

ENDIF.

ENDLOOP.

ELSE.

LOOP AT XKOMV.

IF XKOMV-KSCHL = 'PR00'.

SELECT * FROM T685A INTO TABLE I_T685A WHERE KSCHL = 'PR00'.

READ TABLE I_T685A WITH KEY KSCHL = XKOMV-KSCHL.

I_T685A-KMANU = 'D'.

MODIFY I_T685A INDEX SY-TABIX.

MODIFY T685A FROM TABLE I_T685A.

REFRESH I_T685A.

ENDIF.

ENDLOOP.

ENDIF.

ENDFORM.

Revert for further clarification

Regards

Amit Gupta

[Former Member]

Hello Amit,

How have you make the condition types changeable only for certain order types?

Thanks,

Al Garcia

[Former Member]

Hi Amit,

You seems have to copied my blog.

[/people/ashish.mohapatra/blog/2007/11/28/sd-userexit--i|/people/ashish.mohapatra/blog/2007/11/28/sd-userexit--i]

Ashish Mohapatra

[Former Member]

Their user ID's will be deleted for copy&pasting and cheating the points-system... (I have already removed the ponits from this thread).

But tell me something, do you really think it is a good idea to hardcode sy-uname checks into exits?

What sort of authorization concept is that?

How would anyone be able to analyze it?

How does it scale when you have 500 thousand user ID's?

Sorry to say this, but it is a stupid idea and to promote it in a blog makes it worse!

Cheers,

Julius

[Former Member]

Hi Julius,

The blog was 2-3 year old. The best way is to follow the SAP note (the number I do not remember at the moment) for the specific issue. I came to know about the SAP note much after publishing the blog. But belive me If there are 20-30 exceptions and few thousand invoices in a day, this coding works perfect.

By the way, as a customer of SAP I have the freedom of solving my problem myself, however stupid it may look.

Thanks,

Ashish Mohapatra

[Former Member]

Hi Ashish,

Well I am also a SAP customer and feel free to comment on another customer's published solution if it causes problems - which is the case here.

Yes, in the past many customers have used these sy-uname checks without realizing at the time what the consequences are. In the SDN security forum we regularly have mass confusions discussed which turn out to be such techniques in the end. No one knows what's going on and changing the code each time an employee changes is of course not done... so they start sharing passwords and using "old" user ID's etc etc....

I was only being honest about the "stupid idea" because there is no other nice way to say it once you have had to maintain or fix such "solutions" a few times...

Anyway, thanks for spotting your blog - these two users ( Jaiprakash Tikoti and Amit Gupta from Fujitsu) were "points gaming" with each other and their ID's will be removed from SDN's sy-uname checks when they try to logon.

We have 1,9 million users and the code is 1,900,090 lines long... (just joking)

Cheers,

Julius

[Former Member]

How stupid I am !

I thought you are considering, changing value of T685A-KMANU table-field at transaction level, is a stupid idea.

It seems what disturbs you more is the use of SY-UNAME in the coding instead of an authorization object.

Ashish

[Former Member]

Sorry, I did not explain the context of my rant

Just today we have another such case "cooking" in the security forum -->

Cheers,

Julius

[Former Member]

Hi Julian,

Please read the following SAP notes

105621 - Authorization check for the condition screen

1165078 - Authorization check for conditions or subtotals

I am not sure if the first note was released before or after my blog, but the second one is quite recent release.

If you go through the notes you will understand the problem I was trying to address. The fundamental issue was not about user authorization, as the title of the blog would suggest it was about SD userexit. In a sample code you can not address all the issues. Creating a customized authorization object was not the central idea. I could have put an IF statement for the SD document types so that the codes are executed for a particular document type, instead of SY-UNAME.

Thanks,

Ashish

[Former Member]

Hi Ashish,

Version 5 of the note 105621 is the earliest still visible one, from the year 2000... which is even before SDN itself

Much of the note is occupied with how to create a custom authorization object to be able to add own code to the exits for doing "whatever" to the condition types.

The later note transfers these exits to BADI's, and keeps the authorization concept previously implemented, albeit it still describes using manual profiles in the reference to the older note - where PFCG roles are the prefered weapon of choice now-a-days.

Yes, I understand that you wanted to "simplify" that part of the blog to concentrate on the general possibility of adding logic based on the condition type.

I think many developers, when faced with the requirement of using an IF statement and not having any understandable authorization concept to work with, have reached out for the bluntest tool in the box to use: sy-uname. But for others this only makes it worse and even less understandable what is going on.

It always reminds me of [this scene|http://www.corbisimages.com/images/42-20041107.jpg?size=67&uid=2597837E-FED2-4E85-AE4C-CECF92B67B45] when I see such things... as do the new sy-unames of Amit and his clones...

Thanks for your patience with my rant and following up on the topic, so that others who use the search can see the full picture and the different (better) options (techniques).

A merry christmas and may all your authority-checks return sy-subrc = 0 in the new year 2010

Julius

[Former Member]

Merry Christmas Julian.

Yes, this thread is giving better idea on this issue, then my blog. Thanks Amit.

I just feel like adding the fact that the note 105621 mentions that "to add own code to the exits for doing "whatever" to the condition types" is a consulting service that SAP can provide when paid for.

Ashish

[Former Member]

Yes, I noticed that information as well.

The plot thickens

[Former Member]

Hi,

Often there is a requirement for making a condition type (price, discount etc) non-modifiable for some-users and modifiable for others using the same SAP system or modifiable for certain document types (say OR ie Standard Sales Order) and non-modifiable in another order type (say CR ie Credit Memo Request). In standard SAP this is not possible. Using the controls for the condition-type (V/06 transaction) we can either make a condition type 

1.       No Limitations

2.       A : Free

3.       B : Automatic Entry has Priority

4.       C : Manual Entry has Priority

5.       D : Not possible to process manually 

Selecting any one of this option makes the condition type uniform across all document type and for users. Often the requirements are like for a group of users the condition type should behave like C option, for another group like D or for a specific document type it should be A and for others D. 

One of the easiest way to achieve this is through the user-exit USEREXIT_PRICING_PREPARE_TKOMP in the include MV45AFZZ.

Revert for further clarification.

Regards

Amit Gupta

[Former Member]

Amit,

Thanx for u r promt reply, further will u please explain me about the USEREXIT and its code.

Regards,

JP

[Former Member]

Hi there,

If you want to control manual entries of condition type from any user then when you define the condition type, in the Changes view, select the option "manual entries not allowed".

But if you want a particular user not to access any condition type, then you need to work with Basis team to check his authorization to change the condition types in pricing.

Regards,

Sivanand