transaction variant problem

[Former Member]

Hi All,

I have a problem to get my own defined transaction variant work. I created a transaction variant for me21n and which suppress the field 'delivery tolerance' in the PO. the transaction variant works fine.. but when I assign the transaction variant to a role the role complains and ask for the original ME21N to be assigned as well. that's against the original idea that i have to assign both ME21N and transaction variant ZME21N to the user... is there anything that I didn't set to cause the problem? Please advise!

Elaine

[rupesh_brahmankar3]

Dear,

You need to assign it to the user after that need to set proposal in SHD0.

For details steps please refer my reply in this thread,

Regards,

R.Brahmankar

[Former Member]

Hi R Brahmankar,

Thanks for your reply, actually the transaction variant has been assigned to the users, and i am trying to use that user account to test and realize that the standard variant has to be assigned together with this transaction variant. That's totally what that I don't want to. based on some of my collegues said because the new transaction variant is fully copied from the standard transaction and so the original objects have always been copied, so it has to be assigned together. Please advise if that's the transaction variant design. if so, then what's the point of creating a transaction variant?

Elaine

[rupesh_brahmankar3]

Dear,

Even thou you create the transaction variant you need to assign it to user as it is user specific. Suppose you have 2 user for one user you want to hide the files and for other you don't want. So after creation of transaction variant you need o assign it to user then only it will work it is standard SAP functionality.

Regards,

R.Brahmankar

[Former Member]

Hi R Brahmankar,

The problem is found after the transaction variant was assigned to the user. I found out the system complaint that the user w/o the standard transaction. so when i run the transaction variant i.e. ZME21N, it complains the user w/o ME21N.

Elaine

[Former Member]

Hi All,

any more comments from any others?

Elaine

[jurjen_heeck]

> The problem is found after the transaction variant was assigned to the user. I found out the system complaint that the user w/o the standard transaction. so when i run the transaction variant i.e. ZME21N, it complains the user w/o ME21N.

If this is an authorization message and you do not want the user to have direct access to ME21N you need to investigate the mechanism of "called transactions". Best do a search for 'called transaction', SE97 or TDCOUPLES in the netweaver forum.

[Former Member]

Hi Elaine,

If this change would be for everyone on your system using me21n wouldnt it be better to have a display variant instead of having this z transaction, you could supress a field using a display variant which would be default for everyone as well.

Regards,

CP

[Former Member]

SE97 does not work in this case of transaction variants for the new "Enjoy Transactions" as they perform a further authority check on the original transaction code.

This is caused by the fact that when you start ZME21N, system field sy-tcode is anyway set to ME21N in which case it again calls function AUTH_CHECK_TCODE (compare to AUTHORITY_CHECK_TCODE) and if the user already is in the screen of ME21N then they should be authorized for it.

This means you cannot "couple" them as the system does not know about ZME21N anymore.

If this were not the case, then you could simply start the transaction variant and then enter /nME21N into the ok-code field and enter the "core" transaction or click "BACK" from the next screen - as was / is the case for many older transactions and implementations of transaction variants.

They are not really security - and this is more obvious now.

See SAP note 322090.

Cheers,

Julius

[jurjen_heeck]

> SE97 does not work in this case of transaction variants for the new "Enjoy Transactions" as they perform a further authority check on the original transaction code.

>

> This is caused by the fact that when you start ZME21N, system field sy-tcode is anyway set to ME21N in which case it again calls function AUTH_CHECK_TCODE (compare to AUTHORITY_CHECK_TCODE) and if the user already is in the screen of ME21N then they should be authorized for it.

>

> This means you cannot "couple" them as the system does not know about ZME21N anymore.

Ah. Didn't know that. Thanks!

[Former Member]

Hi chinmaya,

the transaction variant is used for certain group of people, not for all. that's why i need two transactions

Elaine

[Former Member]

> that's why i need two transactions

If you can forefeight the user friendliness of the Enjoy Transaction for one of the groups, then you could possibly also consider using ME21 (without N) with changed screen variant for them and leave ME21N to be used by the "special" group.

You should however first ensure that ME21 is not used in any batch-input recordings or other "calls". Also SAP standard transactions and menu paths which "call" ME21 still will be affected.

If you have a developer on site, then please also take a look in transaction BAPI for an API to the Business Object behind ME21(N). There, you can do whatever you like and choose the transaction completely on your own. The only little piece of work is to code the UI for it.

Cheers,

Julius

[Former Member]

Hi Julius,

I believe there's someting like what u said AUTH_CHECK_TCODE is checking, otherwise, it wouldn't find out ME21N not used. the very strange is when i did the same, creating the transaction variant ZME11 for ME11, the AUTH_CHECK_TCODE is not checked while testing the role. that's why i doubt if something i'd missed out while developing the ZME21N. but very obvious is i don't find any difference for creating both ZME11 and ZME21N. anyway, probably i'll take the option of using me21 to suppress the field. Many thanks!

Elaine

[Former Member]

Yes, there are auth checks within the programs to check if users have access to the transaction or not, we faced the same issue while we were developing the custom ZSE16 transaction, with the copy of SE16 program, where LSETBU03 include checks for

call function 'AUTHORITY_CHECK_TCODE'
  exporting
    tcode = l_tcode                                      "=SE16
exceptions
     ok     = 1
     not_ok = 2.

... finally we had to create a Z program and supress the SE16 check from the program.

AUTHORITY_CHECK_TCODE, see SAP Note :1254159

Cheers !!

Zaheer

[Former Member]

> ...it wouldn't find out ME21N not used.

The funny thing about transaction variants is that ME21N is being used when you start ZME21N.

See my comment above about sy-tcode.

Cheers and good luck,

Julius

[Former Member]

Moved to Security forum and duplicate post deleted...