2010 Jan 08 1:24 PM
Hello gurus,
in my requirement, I simply have to work on the transaction ME54 in this way: every Purchase Requisition position must be checked in order to verify if strategy release process is allowed for the user currently executing the transaction.
The control is quite simple; there's a Z table in which are stored the authorized users, coupled with a society code to which they refer. So, if a PR position "belongs" to the society XYZ and in this Z table the user is present coupled with the society XYZ, then the release of the step is allowed.
Please consider the following scenario: an unauthorized user try to release strategy for a Purchase Req with 10 positions. He then select all the positions in ME54, and click on the "Release" button. The user exit involved in this process is EXIT_SAPLBBPK_001 (include ZXBBPU04); the process flow should trigger this exit for every selected position of the Purchase Requisition.
The problem is that, if the release is not allowed for a certain position, an error message is returned. In such a scenario, the execution of the process stops without checking the remaining positions.
In our scenario, suppose the second position of the PR could not be released; then all the remaining position (from 3 to 10) are then not checked nor released. We wonder if it's possible to guarantee, for every position in the selection that:
- positions for which the user is authorized -> release the strategy step;
- positions for which the user is NOT authorized -> no release, and message.
This seems actually not possible since the code 'E' for MESSAGE seems to represent a blocking error, and then once it's triggered, the release process itself stops.
Is there any way to obtain such a behaviour? Thanks in advance.
2010 Jan 08 8:08 PM
positions for which the user is authorized -> release the strategy step;
- positions for which the user is NOT authorized -> no release, and message.
I think so both are not possible simultaneously.
Only one at a time.
Or by using enhancement spots, you can delete the error records from the data ... some thing like that...But its more complicated to get it done, also there is a possibilty that the error records can be accumulated and can be displayed as a log at last.
positions for which the user is authorized -> release the strategy step;
- positions for which the user is NOT authorized -> no release, and message.
I think so both are not possible simultaneously.
Only one at a time.
Or by using enhancement spots, you can delete the error records from the data ... some thing like that...But its more complicated to get it done, also there is a possibilty that the error records can be accumulated and can be displayed as a log at last.
2010 Jan 08 8:08 PM
positions for which the user is authorized -> release the strategy step;
- positions for which the user is NOT authorized -> no release, and message.
I think so both are not possible simultaneously.
Only one at a time.
Or by using enhancement spots, you can delete the error records from the data ... some thing like that...But its more complicated to get it done, also there is a possibilty that the error records can be accumulated and can be displayed as a log at last.
2010 Jan 08 11:28 PM
Hi Matteo,
the problem is you can not display more than one message in one process step. You could issue a success message with addition DISPLAY LIKE 'E' but the user will then see only the last message issued because after success message the program flow is continued.
You should consider to create an application log. Check function group SBAL. I don't remember all the details. We created a class with some methods. So all users just crete an object of the class, that creates the application log. Then for every message, we use message ... INTO <string variable>. The INTO clause will put the message text into the string. program flow is not interrupted but SY-MSGID, ~TY, ~NO, ~V1 - ~V4 are filled. Our method prot->add_sy-msg uses the values to add the message to the protocol. At the end of the process we call method display and get a popup with all messages.
This way you can exclude the unauthorized lnes and inform the user in the application log display. Finally you SAVE the log and can check it anytime using transaction SLG1.
Regards,
Clemens
| User | Count |
|---|---|
| 4 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |