Called tcode FV50

[Former Member]

Hi,

User is getting error 'no authorization for FV50' when executing MR42.

Per search on sdn :

"SAP is working as designed - tcode A calls Tcode B (no check), user tries to run tcode B directly and is blocked correctly."

And read SAP note 358122, however could not understand it much.

Now when i check TCDCOUPLES table, there is no link between MR42 & FV50. Rather i see entry for FBV4.

Please advice what is causing this authority check in MR42?

In SE97, i need to check tcode MR42 or FBV0 (checked both and there is no link. for MR42, it show red status or FBV4 !!!)

But no link with FV50...

please help.

Regards,

Surpreet

so what does YES in SE97 means....

YES - separate access to called tcode required?

NO - separate access to called tcode not required?

Edited by: Surpreet Singh Bal on Dec 8, 2010 12:21 PM

[Former Member]

Hi Surpreet,

Give tcode MR42, u will get error no authorization, on same page, give tcode /nsu53, you will get the details that on which objects you need the authorization, take the authorization of that objects from your Basis administrator or super user, after that you will be able to use the tcode MR42.

Regards,

Kiron.

[arpan_paik]

Hi Supreet,

This park and post are very much related and there are very complex set to tcode calling. Like in MR42 after entering Doc number, cocode, fiscal year a user can change the same via header option invoice verification or can go to FV50 for further processing and posting the document also (if required). So these are related transactions for completing entire process for document.

Regarding TCDCOUPLES I still could not figure out what data actually it through. I need to go deep into it and some day I might understand.

Regards,

Arpan Paik

[Former Member]

Hi Surpreet,

TCDCOUPLES is a table where you can find out Call-in transaction codes, but doesn't mean that all the tcodes listed there should be added in the role.

Further, most of the functional tcodes such as MR42 will have links to other transaction codes. When you select an option from the menus, or click a button they may call other related functional transaction codes.

It is always wise to check the requirements before adding any additional tcodes/authorization objects manually in the role.

Also, refer TACTVT table to identify the minimum required authorization objects, fields, values for the tcode(s) before you build the roles.

The other best approach is to enable ST01 trace while doing the unit testing and fix the authorization issues.

Hope this clarifies.

Best Regards,

Raghu

[Former Member]

so what does YES in SE97 means.... 
YES - separate access to called tcode required?
NO - separate access to called tcode not required?

First part of your question is already answered I suppose by the previous posts.I would try to answer the second part:)

Yes- means authority check on object S_TCODE is performed for the called transaction.

No- means no authority check on S_TCODE is performed for the called transaction and users can switch from the calling transaction to the called transaction even without any S_TCODE check for the later.

Thanks,

Sandipan

[Former Member]

Right On spot buddy...

Cheers!!

zaheer

[Former Member]

Hi

Since I replied giving TCDCOUPLES if found that this is/may be a fairly basic initial indicator of the calling-called links. (sorry for any confusion)

Recent posts have shown that the program used by an initial transaction can have a CALL TRANSACTION/SKIP FIRST SCREEN etc adds more to the search.

Julius and Alex recommend involving the developer (think that is correct?) when you want to get into the detail which isn't always possible but may mean your time is better spent rather than investigating.

Best wishes

David

[Former Member]

I think here is what is happening.

As you mentioned, MR42 do not have any entry for FV50 in its TCDCOUPLES. And there is a check on TCDCOUPLES for TCODE=MR42 and CALLED=FV50 (info from Table buffer trace).

So it is pretty good indicator that there is an AUTHORITY_CHECK_TCODE prior to the CALL TRANSACTION in the code.

So tried to look at the code based on the trace, and there is a CALL TRANSACTION command in LF040F00 include with a AUTHORITY_CHECK_TCODE right before it.

Normally, when AUTHORITY_CHCK_TCODE is used prior to CALL TRANSACTION, system checks in TCDCOUPLES for an entry for the t.code mentioned in the CALL TRANSACTION right below it in all situations unless a specific NO entry is there in TCDCOUPLS. So unless there is a specific u2018NOu2019 in TCDCOUPLES, systems checks for S_TCODE. I mean an entry with YES or Unmaintained or even no entry , system checks for authority on S_TCODE.

I think in this case, it is a NO ENTRY situation. So it checks for S_TCODE=FV50 by default. And SAP might have missed to include an entry. and for reference, if you want to, you can include an entry for MR42 and FV50 in TCDCOUPLES of MR42 and leave it unmaintained or YES. And if you donu2019t want a check( not so preferrable I think) then set the entry with NO. and you wonu2019t see any check on S_TCODE=FV50.

some info on 'call transaction':-

until 4.6C, CALL TRANSACTION command do not used to check for any authorizations on called transaction. So the solution SAP used to fix the authorization gap is to include the function module AUTHORITY_CHECK_TCODE before CALL TRANSACTION. Something like this:-

call function 'AUTHORITY_CHECK_TCODE'

exporting

tcode = 'SM01'

exceptions

ok = 1

others = 2.

if sy-subrc = 1.

call Transaction 'SM01'.

From 4.6C, SAP thought lets give the customers flexibility in choosing whether to have authority check or not. So they created TCDCOUPLES/SE97 and created a relation between CALL TRANSACTION command, AUTHORITY_CHECK_TCODE Function module and TCDCOUPLES/SE97.

So from 4.6c, here is how it works:- When CALL TRANSACTION commands comes across, kernel will check with the profile parameter Auth/Check/Call transaction and TCDCOUPLES table entries of the Transaction code from which the call is made.

| auth/check/calltransaction, default = 2

| 0 1 2 3

-

---

tcdcouples-okflag = X | n j j j

tcdcouples-okflag = N | n j n n

tcdcouples-okflag = ' ' | n j n j

no entry in tcdcouples | n j n j

and the above entries work the same if there is a AUTHORITY_CHECK_TCODE within the called transaction(tcode=sy-tcode).

And if the AUTHORITY_CHECK_TCODE is in the calling transaction( tcode <> sy-tcode )

| auth/check/calltransaction, default = 2

| 0 1 2 3

-

---

tcdcouples-okflag = X | n j j j

tcdcouples-okflag = N | n j n n

tcdcouples-okflag = ' ' | n j j j

no entry in tcdcouples | n j j j

reference:-SAP Note:-358122

[Former Member]

Hi All,

Thanks.

Here is what I found. Kindly correct me if I am wrong.

In SE97 i see below entries:

Calling Tcode Called Tcode Check Ind. Message Type

MR42 FBV4 no value no value

FBV4 FV50 YES X

FV50 FV60 YES X

now when i gave user access to FV50, they said now they need access to FV60 also.

so I found above values

although no access to FBV4 was required, however I had to give access to FV50 & FV60.

what is your recommendation, should I have changed the Check Ind to NO or direct access is better way.

Kindly advice.

Regards,

Surpreet

[Former Member]

Hi,

Calling Tcode           Called Tcode             Check Ind.              Message Type
MR42                                 FBV4                       no value                  no value
FBV4                                  FV50                       YES                       X
FV50                                   FV60                       YES                       X
now when i gave user access to FV50, they said now they need access to FV60 also.
so I found above values 
although no access to FBV4 was required, however I had to give access to FV50 & FV60. 

When FV50 calls tcode FV60, an auth check on S_TCODE will be performed for FV60 since field Check Ind. is marked with YES in TCDCOUPLES.

FBV4 access is not required since it is the Calling Transaction for FV50 and Auth Check on S_TCODE (via values in Check Ind. field) is always performed for the Called Transaction not the Calling Transaction through TCDCOUPLES. Also Check Ind.= No value is equilvalent to Value NO i.e no check on S_TCODE for the Called Transaction

You may go through following SAP notes for details on TCDCOUPLES and updating the authorization check for called transaction via SE97.

1. SAP Note # 358122

2. SAP Note # 515130

Thanks!

Sandipan

[Former Member]

Try this.

Create this new entry in SE97 for MR42

MR42, FV50, Yes or unmaintained, no value(space)

and for FV50 you already have

FV50 FV60 YES X

if you put it all together, MR42 is calling FV50. and once your user gets to FV50(sy-tcode=FV50) its calling FV60.

what I mean to say is, an authority check is carried out in a call transaction situation not just based on SE97 entries. It also considers the Function module AUTHORITY_CHECK_TCODE(well, even this is defined in many different ways) if included in the code. In this MR42/FV50 case, its this function module that is causing the call and SAP is missing a se97 entry for MR42 which can refer the customers(us) to it.

conclusion is, If you can create an entry for MR42/FV50 as mentioned above and do not change anything existing, you should be alright. and I think its better to keep the rest of checks as they are. and regarding FBV4, we do not worry about it, because its unmaintained. so its acting right. 'Call transaction' is a topic which has more to look for besides SE97 entries.

[Former Member]

So... what the recommendation .....???

"what is your recommendation, should I have changed the Check Ind to NO or direct access is better way."

Regards,

Surpreet

[arpan_paik]

Hi Supreet,

Sometimes we (Security person) work as shield headed bull :). What is there in trace or SU53 we just think on that perspective. However on your case as this transactions are calling each other so I believe there must be some reason for the same so it's been delivered by SAP. Before doing anything my suggession would be to check with function person on business process.

Edited : If the purpose is to change parked document only then FV50 & FV60 might create violation as they provide access for post as well. In that case ther might be some other transaction (FB02 may be) for changing document.

Regards,

Arpan Paik

Edited by: P Arpan on Dec 14, 2010 1:52 PM

[Former Member]

I think You should be able to decide for yourselves based on the information above and the process in your company.

If its me, I will not change the SE97 entries. just let them be as they are.

and will create an SE97 entry for MR42 FV50 YES(just for my future reference).

and regarding the process, I want the users to get to FV50 and FV60 thru Mr42, So I will provide them with FV50 and FV60 access.

[arpan_paik]

 I think You should be able to decide for yourselves based on the information above and the process in your company.
If its me, I will not change the SE97 entries. just let them be as they are. 
and will create an SE97 entry for MR42 FV50 YES(just for my future reference). 

I like the idea

 I want the users to get to FV50 and FV60 thru Mr42, So I will provide them with FV50 and FV60 access. 

However regarding last part I also might like to do that but atleast taking a confirmation from functional guys so later I can say you said that's why I gave that

Regards,

Arpan Paik