USOBT table - how SAP Interprets it in the code ?

[Former Member]

Hello Experts,

When SAP populates USOBT table, there are certain authorization objects that are in No check. I am interested to know how does SAP understands not to do authority-check for these even though the authority-check for these objects are in the code. Also when we change it to check or check/maintain it starts cheking it.

Example - For t-code VKM1 - authorization object V_VBAK_AAT is in No-check so when you release a SD document using VKM1 and run a trace on this user id - you will find in trace that for V_VBAK_AAT, return code is 0. Understandable as the auth object is in No-check, SAP probably ignores it but once it is changed to Check or Check/maintain it starts checking for it. I would like to know how does SAP do that.

Reason for all this is because we created a custom t-code ZSD_VKM1 which uses the same program as VKM1 but when you release the document and try to save it using this custom t-code it gives the error message - " No maintenance authorization for the order type XXX" . But VKM1 does not. I tried to put V_VBAK_AAT as No Check in SU24 for this custom t-code but it does not help.

[jurjen_heeck]

> I tried to put V_VBAK_AAT as No Check in SU24 for this custom t-code but it does not help.

It should so this is strange.

About the workings, first of all concentrate on the customer table USOBT_C. That's the one you manipulate with SU24.

The AUTHORITY_CHECK statements checks this table for entries corresponding the obejct to be checked for the transaction used. So the checks can behave differently for the same coding triggered through different transactions. Checks that are switched off through SU24 should indeed show up in the trace with return code 0.

After you tried to switch off the V_VBAK_AAT check for your custom transaction, what does the trace show?

[Former Member]

For the custom t-code, auth object V_VBAK_AAT has return code 12 in the trace. In SU24 V_VBAK_AAT is N for this t-code. Also just want to add another point. From this custom t-code, we are able to release the document but error comes when you go to save it. That is when you get RC = 12 for V_VBAK_AAT (ACTVT =02, AUART =XXX)

[mvoros]

Hi,

are you sure that at that moment you are still in VKM1 transaction? VKM1 calls VA02 and V_VBAK_AAT is checked in VA02. After you get an error message you can jump to debugger and see what is in system variable SY-TCODE.

Cheers

[Former Member]

For this same reason (as mentioned by Martin) you cannot use variant transactions to disable the s_tcode check via SE97 in all cases.

If you can navigate further and then return BACK into a screen of the core transaction then you are in the same situation as if you had been authorized to start the tcode directly - so you need to be authorized.

An alternate for you could be to create a new variant for the standard transaction, and assign the standard screen to the z-transaction.

This is safer but might confuse some other batchinput programs and call transactions you might be using.

Cheers,

Julius

[Former Member]

Martin,

I am able to release the SD document using VKM1 and it does not give me " no maintenance authorization for an order type" becuase V_VBAK_AAT is in No Check for VKM1. It is when I am using this Z t-code ZSD_VKM1 which is giving this error when you release the document and then try to save it. I tried to put V_VBAK_AAT as No Check in SU24 for this custom t-code but to no avail. It still give the error.

That is why I wanted to know how does SAP interprets USOBT_C data ? but looks like that code is probably written in Kernel and is not in ABAP.

Here is what probably happens - for a specific t-code SAP understands by looking at USOBT_C table that because the auth object is in "No Check", it should not look at the authority-check object and move ahead. But I am not able to do this for my custom t-code. SAP looks for the auth object value and when it does not find it, ends up giving error message as described above.

[Former Member]

I have raised an OSS message for this issue. Would keep you guys updated if we find something..

[Former Member]

While waiting you might want to take a read through [SAP Note 515130|https://service.sap.com/sap/support/notes/515130] and the documentation in transaction ABAPDOCU on the keywords "call transaction" and "call screen".

BTW: In table PRGN_STAT field STEP_NR = '001' is there an entry in the field "Date"? Your question seems to be implying that you are maintaining SU22 and not SU24?

Cheers,

Julius

[Former Member]

Hi Julius,

I mentioned USOBT just because wanted to know how SAP Interprets authority check. But I am maintaining SU24 only and not SU22. Actually the problem that we have is ZSD_VKM1 is not a transaction that is being called by VKM1. It is a custom transaction that calls the same program as VKM1 but with slight modification. The t-code was created to improve performance of VKm1 and instead of processing the orders sequentially all of them are processed parallely in different packets using this t-code.

Table PRGN_STAT has entry in the date field from 2005 by user DDIC and t-code SU25.

[Former Member]

Z- tcodes are not affected by SAP upgrades (unless someone maintained SU22 or "original data" is processed in Su25) or your Z-tcode is a parameter transaction for a standard SAP tcode which has changed and you did not maintain it specifically (although this was your apparent intention...)

> Table PRGN_STAT has entry in the date field from 2005 by user DDIC and t-code SU25.

This suggests a "mass acceptance" by some basis person...

Process Su25 step 2b carefully (be very carefull here, because it saves you a lot of work later) and once your roles are upgraded in step 2c then transport it through (PRGN_STAT will go with, if you use step 3).

Normaly I execute step 3 first, and then create a mass transport for all roles after upgrade. But you can also change the roles (this takes some time..) and the create the transport in step 3.

As a good habit, you should anyway record the roles again into the transport request ( *so that the new versions of the profiles are transported as well" ).

Cheers,

Julius

[Former Member]

Maybe I am not able to explain my question properly, so I will try to do that again -

I created a role and gave access to two t-codes. VKM1 and ZSD_VKM1 and assigned to some users.

Users are able to release a blocked SD document and save it using VKM1(Program- RVKRED02), though in this role I did not give access to authority object V_VBAK_AAT. I sat with a developer and while debugging we saw SY-SUBRC=0 for Authority-check on object V_VBAK_AAT even though the role does not have this authority object. Reason : in SU24 (USOBT_C table) this object is in No Check for t-code VKm1.

Now here is my dilemma. With t-code ZSD_VKM1 (Program - ZRVKRED02) users are able to release the document but when they try to save it, they get authorization error for V_VBAK_AAT auth object. Program ZRVKRED02 is enhancement on RVKRED02 to improve the performance by processing the orders in parallel. Per the abaper who developed it, he has not added any new authority-check in this custom Z program. Now in SU24 I updated this t-code ZSD_VKM1 to have No Check for auth object V_VBAK_AAT but the problem is program still checks for it and gives authorization error.

One thing that I noticed when I looked at Su24 for ZSD_VKM1 t-code is that the only object that I see there defaulted is S_TCODE while in case of VKM1 it is already populated with quite a few objects. I had to add the V_VBAK_AAT object and then make it as No Check. Does that make some difference?

[Former Member]

Yes, it does make a difference if for one tcode there is a "no check" and for another there is not.

Is the check from the trace performed in FM authority_check_tcode and is sy-tcode changing in the Z tcode?

If that is the case, you should revert back to the same in SE97.

Cheers,

Julius

[Former Member]

Looks like Developers did not create the custom t-code in a proper way. That is what SAP had to say.