Skip to Content

To avoid dataloss, unexpected results, some actions have to be performed as preparation already before starting the upgrade.

Before the Upgrade:

  • First repair any inconsistent data still in the old release: Use report SU24_AUTO_REPAIR with all available options (documentation can be found in SAP note 1539556).
  • Initialize timestamps with report SU25_INITIALIZE_TSTMP (SAP note 1599128)
  • Create a backup transport of SU24 data after each step (you can use SU25, step 3 for that creation of the transport) and export it
  • Make sure, that the authorizations of your roles are actual. That means, that the existing authorizations should ‘fit’ to the existing SU24-proposals (i.e. Authorizations with status ‘Standard’ and/or ‘Maintained’). To do that, start the ‘Expert Mode for Profile Generation’ in PFCG on the Authorizations tab and use the option ‘ Read old status and merge with new data’. This will start the merge function and will probably update the existing authorizations according the rules listed in note #113290. If you do not do that, you may be surprised about changes happening to existing authorizations after the upgrade during execution of SU25, where the merge function is used as well.
  • Create a backup transport of your roles and export it

Now after the Upgrade:

Apply all notes listed in note 440231. This note is kept actual with the latest notes.

Run SU25 2a-2c, alternatively you can use also the expert mode combining 2a and 2b by starting SU24->button ‘Default Values Comparison’. As of 7.40 this expert mode is included in the SU25 action-list after step 2b.

<start of update 3rd Sep.2014:

The expert mode button is available in SU25 as of sapkb73112 in the button line of SU25 on the top.

Timestamp of step 2a:

Using the Expert mode, no timestamp for 2a is written automatically (so 2b, 2c won’t work afterwards). Nevertheless you can set the timestamp with the corresponding button in the result list of the expert mode (as of note 2042284).

Attention: if you are using the ‘normal’ step 2a, do not leave the result screen with ‘cancel’ or closing the session, but rather use the back button to navigate to the su25 main screen. In some old correction levels no 2a-timestamp will be written, if you do not navigate back. (you can use the expert mode optne then mentioned above to set the timestamp then manually…)

end of update 3rd Sep.2014>

If everything is fine, create a final transport in step 3 of SU25 and transport the new proposals through your system landscape.

Then transport your already adapted roles as well.

Update June 19th, 2013:

If you have missed the first step of  ‘Before the Upgrade’ (SU24_AUTO_REPAIR ->Repair Modification flags), note #1850378 provides a correction which corrects at least the SU24-entries with incorrect modification flags. Missing modification flags cannot be repaired anymore at this moment, as the old SU22-content before Upgrade is required to repair the missing ones.

Update December, 2013:

Please see also KBA 1954558

Update August, 2015:

Additional point ‘Make sure, that the authorizations of your roles are actual.’  added to section Before the Upgrade’.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Former Member

    Hi Bernhard, thank you for the details above. I have however noticed the report SU24_AUTO_REPAIR does not correct all corrupt SU24 entries. As an example I have a system which has corrupted SU24 entries as you can see in table below. In this case the object K_PCAR_REP has a proposed value of $KSTAR in the activity field. This is after I had run the SU24 repair program with all options selected. It corrected some entries but left some behind. Just thought I’d mention this in case there’s an update that needs to be done on the program.



      1. Former Member

        Hi Julius,

        I found the system in this state after ECC EHP5 upgrade was done. Not sure what steps were done at the time but there’s an awful lot of these corrupted fields. I also suspect part of the problem occurred because a lot of roles have auth objects in changed and manual statuses and an inconsistency arose during upgrade or possibly the upgrade was aborted prematurely. The funny thing though is the auto repair program corrected some instances, maybe I’ll debug the program later to see why it did a partial repair.



        1. Former Member

          What is in the roles should have no affect on SU24.

          Perhaps some one tried to load auths maintained in roles (AGR_1251) back into SU24 (USOBT_C) directly? Or they fiddled with the download files and then uploaded them again? The internal function modules which update SU24 don’t make these type of validations – at least not in earlier releases.

          I once found an SU24 proposal for an object which did not exist and was in lower-case. There is only one way that something like that gets into a table field which is converted to UPPER_CASE -> updates directly to the database.

          So also go to SE11 and from USOBT_C do a where-used-list search for Z-programs. Some invention might be hitting the table..



          1. Former Member

            I checked if the table is being updated by any custom programs as you suggested but this is not the case. Thanks for your suggestions and input, I’ll keep working at it.

          2. Bernhard Hochreiter Post author

            found some similar entries in an internal refernce system as well…. (but not for the tcodes of the above screenshot). As usobt kept alos that nonsense, the applications have to provide a solution.


            AB01L                      TR   A_B_ANLKL ACTVT  $BUKRS
            ABIFL                      TR   A_B_ANLKL ACTVT  $BUKRS
            CMM_PEV_WL                 TR   CMM_MEV_WL   ACTVT  $BUKRS
            FEB_BSPROC                 TR   F_FEBB_BUK   ACTVT  $BUKRS
            IDCNFB03                   TR   F_BKPF_BUK   ACTVT  $BUKRS
            IDCN_ADJDISP               TR   F_ADJ_DOC ACTVT  $BUKRS
            IDCN_ADJEDIT               TR   F_ADJ_DOC ACTVT  $BUKRS
            IDCN_ADJNEW                TR   F_ADJ_DOC ACTVT  $BUKRS
            J1INPRREV                  TR   J_1IEWTPR ACTVT  $BUKRS

            so just in case you find such values again in other systesms. Seems to be pretty old false data….

            b.rgds, Bernhard


Leave a Reply