ST01 trace = Return Code 4

[Former Member]

Hello,

Using transaction ST01, all return codes are 0 except for:

P_TCODE RC=4 TCD=FCH8

RC=4 (no profile contained in user buffer)

How do I fix this?

Kind Regards

Panks.

[jurjen_heeck]

Look for the role with FCH8 in the S_TCODE object (AGR_1251, filter on S_TCODE) and add the object P_TCODE with value FCH8.

or

Create a role whit this object (P_TCODE) in it and assign the value FCH8. Generate the profile and assign the role to this user.

[Former Member]

Hello Jurjen,

Thx for the reply. Error on my part.

Testing was carried out in the wrong landscape.

Auth. Obj. P_TCODE is defined with FCH8 in the correct landscape/client.

We shall retest.

[Former Member]

> Look for the role with FCH8 in the S_TCODE object (AGR_1251, filter on S_TCODE) and add the object P_TCODE with value FCH8.

This would be seem a bit illogical, to me. Why would the user need P_TCODE with FCH8, when they could start it directly via the ok-code field, checking S_TCODE? I would think that it would be required for a role which does not have FCH8 in S_TCODE, and that is assuming that FCH8 is at all an executable transaction code.

Cheers,

Julius (not logged on).

[jurjen_heeck]

>

> > Look for the role with FCH8 in the S_TCODE object (AGR_1251, filter on S_TCODE) and add the object P_TCODE with value FCH8.
> This would be seem a bit illogical, to me. Why would the user need P_TCODE with FCH8, when they could start it directly via the ok-code field, checking S_TCODE? 

Some HR transactions check both as far as I know. Going by the OP's sentence about the trace giving RC=0 except for P_TCODE I assumed the S_TCODE check was passed successfully.

[Former Member]

It might be undesirable that the user can enter FCH8 (Reverse Check Payment!) directly.

I don't see any HR related checks except possibly P_ORGIN, so would think that those checks are taken care of by the calling program, and FCH8 is called with a different screen (or without stopping in screen 800 at all).

It was just a thought which occurred to me,

Julius

[Former Member]

> Some HR transactions check both as far as I know. Going by the OP's sentence about the trace giving RC=0 except for P_TCODE I assumed the S_TCODE check was passed successfully.

The S_TCODE code was checked and passed. You are right that certain HR transactions do check both S_TCODE and P_TCODE.

[Former Member]

Thanks Pankaj. I understand that your question is answered and you solved the issue.

@ Jurjen: Would you like to discuss this further? I still think that a role with this value in P_TCODE should not have the value in S_TCODE. Take a look at the SU24 indicators. Only P_TCODE is proposed. This indicates that the authorizations required to complete the transaction need to come from some other transaction.... the calling one!

I also did a where-used-list on it: nothing, except possible "dynamic calls".... i.e. CALL SCREEN or CALL TRANSACTION.

[jurjen_heeck]

>

> @ Jurjen: Would you like to discuss this further?

Sure, but what is 'this'?

> I still think that a role with this value in P_TCODE should not have the value in S_TCODE. Take a look at the SU24 indicators. Only P_TCODE is proposed. This indicates that the authorizations required to complete the transaction need to come from some other transaction.... the calling one!

I Haven't got a system at hand right now and must admit I do not know this transaction. The trace results Pankaj gave us suggested that P_TCODE was missing so it could have been a called transaction or S_TCODE was in the users' roles. (I expect the latter reading Pankaj 's responses)

> I also did a where-used-list on it: nothing, except possible "dynamic calls".... i.e. CALL SCREEN or CALL TRANSACTION.

What point are you trying to make? That S_TCODE shouldn't be given to the user in this case? He/she already had it. The S_TCODE check passed, but P_TCODE check failed.

Jurjen

[Former Member]

Hi Jurjen,

Actually, I thought earlier it was going to be an area menu, but then I took a look and discovered it is a dialog transaction, and SU24 only proposes F_PAYR_BUK actvt 05 (void check information) for it.

This is often an indicator that other business transactions provide the required authorization to complete this transaction, or it is a "core transaction" for parameter transactions or generic use transactions.

It also checks P_TCODE object for this TCD value, and HR objects, if a special indicator in the payment file is set to flag it as HR relevant.

My instinct told me that the user is not meant to enter the transaction directly (hence no S_TCODE), but I might have been wrong.

Cheers,

Julius