Description
This report supports you in re-generating and extending authorizationsand authorization profiles in connection with the new authorizationobjects W_VKPR_VTL, W_VKPR_WRK and W_VKPR_PLT valid as of Release 4.5Afor authorization checks in sales price calculations. The updating ofauthorizations and authorization profiles is restricted toauthorizations and single profiles that were maintained manually. Adifferent procedure has to be followed for updating generatedauthorizations and profiles.
For information on the business background to the redesign of theauthorization check, please refer to theRelease Information.
The report carries out certain checks and then, for every non-generatedauthorization of the old authorization object W_VKPR_VKO, the reportthen generates a new authorization of the same name for the three newauthorization objects. The new fields in the new authorization objectare assigned the value '*'. Entries for the new authorizations are madein control table USR12 (user master: authorization values) and intransparent table UST12 (user master: authorizations). The name of thenew authorization object is entered as the name of the newly createdauthorization in table USR13 (short text for authorizations).
If a non-generated authorization exists for the old authorizationobject and an authorization already exists of the same name for any ofthe three new authorization objects, no new authorizations are created(entry in table USR12 or UST12). This means that the authorization hasalready been processed. Similarly, no new authorizations are generatedif an error occurs during generation of any of the three newauthorizations. This would be the case, for example, as the size of anauthorization is limited for technical purposes. This limit may bereached as a result of the addition of new fields in the authorization.
In all non-generated single profiles containing non-generatedauthorizations for the old authorization object for which newauthorizations were created in the course of running the report, thenewly generated authorizations are added to the new authorizationobjects. See the example. The single profiles are changed in controltable USR10 (user master: authorization profile) and in transparenttable USR10S (user master: single profile). The changes made are alsodocumented in the usual way in table USH10 (change history forauthorization profiles).
A single profile is not changed if there is asynchrony between thecontrol table and the transparent table in terms of the authorizationsinvolved or if this is technically not possible. Here, too, the size ofthe single profile is limited and this can be exceeded by the newentries.
Non-generated single profiles containing authorizations for the oldauthorization object W_VKPR_VKO for which there was no regeneration dueto the above reasons are listed in the second log. (See the outputsection.) These single profiles must be subsequently maintained. Youhave to enter the required authorizations for the new authorizationobjects. Non-generated single profiles are also listed that containgenerated authorizations for which there was no new generation. Theseprofiles also have to be manually maintained. If a single profilecontaining non-updated or generated authorizations also containsauthorizations that were re-generated, a message is issued in the logfor these single profiles, indicating that the update was incomplete.

Output
Two logs are generated documenting the program run. In the first log,you can call up long texts for certain messages describing in detailhow to react to the errors. You have to select an indicator on theselection screen if you want to see the log. The messages contained inthe second log are more detailed, but have no long text. Both logs canbe printed.
The logs document the following:

• Program start.


• Error messages, if authorizations could not be generated for the new
authorization objects.

• List of the generated authorizations (second log only).


• Error messages, if single profiles could not be changed.


• Messages, if there was an error when the database was being updated for
the tables mentioned.

• Message indicating successful database update.


• List of non-generated single profiles containing non-generated
authorizations for the old authorization object for which there was nonew generation in the current run of the program (second log only).

• List of generated single profiles with generated authorizations for the
old authorization object (second log only).

Example
Section of non-generated single profile K_WWS_TEST:
Authorization object Authorization
.... ....
W_VKPR_VKO K_BER_TEST1
K_BER_TEST2
.... ....
When the program was run, for authorization K_BER_TEST1 newauthorizations were generated for the new authorization objects. Thiswas not the case for authorization K_BER_TEST2. The single profileK_WWS_TEST was as follows after the report was run if there were notechnical restrictions:
Authorization object Authorization
.... ....
W_VKPR_VTL K_BER_TEST1
W_VKPR_PLT K_BER_TEST1
W_VKPR_WRK K_BER_TEST1
W_VKPR_VKO K_BER_TEST1
K_BER_TEST2
.... ....