Authority Check issue in VL01N - V1 Update

[Former Member]

Hello,

I am running into an issue with a authority check object being used in a invoice print program called from the VL0xN transactions. There is an authority check being made that is always returning 0 in ECC 6.0. Previously in the 4.7 system, this check worked fine. The original developer wrote it as a negative check, ie if you had the object you were not allowed to print. So if the object returned 0 you were prevented from issuing the invoice. Now in 6.0, with object and profiles double and triple checked we are all getting return code 0 and no one can print.

This object is checked in the V1 update LUW and shows up as a failure in SM13. From there I can run it in debug and see the authority check executing and returning a 0 when it should not.

An ST01 trace shows no check occurring.

If I copy the auth check code to a separate z-program it works correctly and shows up in ST01.

The only difference between these two pieces of code is that the original is running in the V1 Update task on save of a shipment.

Searched OSS and Forums and have seen no mention of a similar issue.

This is an ECC 6.0 / NW 7.01 system.

Any suggestions would be greatly appreciated and rewarded!

John

[Former Member]

ST01 is app server specific.

The LUW's might be load balanced.

You can switch servers in SM51.

Negative checks are seldom a good thing...

Cheers,

Julius

[mvoros]

Hi,

the AUTHORITY-CHECK returns zero also if authorization check is not performed. Hence have you checked if you object is flagged as Do Not Check in SU24? You can also try to use addition FOR USER for testing purposes to confirm that it does not work for user with proper authorization.

Honestly, it does not sound like a good idea to put authorization check in V1 update FM. You should really have only SQL update statements there. You are asking for problems if you include additional logic. On the other side AUHTORITY-CHECK is in set of statements which are forbidden.

Cheers

[Former Member]

Thanks for the reply! I have been trying to find some documentation that shows what is permitted/forbidden in V1 modules and have not had any luck. Do you happen to know where I can find that reference? This is code I inherited so if I can show it was incorrect to begin with it will be easier to get changes to the process approved.

Thank you for your help!

[mvoros]

Hi,

here is a section from [this document|http://help.sap.com/printdocu/core/print46c/en/data/pdf/BCCSTUP/BCCSTUP_PT.pdf] on page 12.

When you are working with the SAP Update System, it is important to make sure that
only inserts, updates and deletes are performed in the update. The necessary
data (with select etc.) should, of course, be collected beforehand. Programming
that has not be carefully thought through can result in poor system performance, and
can, in certain cases, cause serious problems.

You can see list of prohibited statements in ABAP documentation (F1 in SE38 or SE80) but as I said AUHTORITY-CHECK is not there.

Cheers

[dieter_goedel]

Hello,

it's a kernel feature that the authority check does not run during V1 update. That's not bug, because all checks should be done before - such a late update failure could result in in long and useless lists of broken updaste records - that's the reason therefore.

What now ...?

If you really need the authority check to decide about the print target you can use the function module SUSR_AUTHORITY_CHECK_SIMULATE to get the result of the check. But please, do not stop the update module - please find a solution with dummy printer i.e. to complete the update process.

Sorry I can not remember when this feature was introduced, but it was supposly before 1995 ... that's why we have no note therefore. Best regards,

Dieter.

[Former Member]

Thank you all for the helpful answers. The basic answer is to remove the auth check and look at a different piece of information to confirm the users ability to print.

The reason this issue came up is that we have people using VL01/VL02N that are not allowed to print. If you change the SAP document and try to 'print on save' then the print program is executed in the V1 LUW instead of being called by VL70. So the code works in VL70 just fine. During testing some people were printing on save and since it was written as a negative check (not by me) everyone was failing (getting a subrc = 0, no printing).

Thanks again for your help!