Skip to Content

This is not a one-shot blog post, but will be regularly updated with the most recent information concerning SAP S/4HANA Simplification Item Checks.

Last update: October 8th 2018.

While a system conversion to SAP S/4HANA or a release upgrade within SAP S/4HANA is technically similar to a release upgrade within SAP ERP, there are some steps and tools which are new and specific to SAP S/4HANA system conversions or release upgrades. One of these SAP S/4HANA specific tools is the so called “Simplification Item Check” which is available as of SAP S/4HANA 1709.

The Simplification Item Check consists of a report /SDF/RC_START_CHECK and a related check framework which you shall run

  • on your SAP ERP system as preparation for a system conversion to SAP S/4HANA.
  • on your SAP S/4HANA system as preparation for a release upgrade to a higher SAP S/4HANA release.

Though the Simplification Item Check is not required or applicable when doing a Support Package or Feature Package update within a SAP S/4HANA release.

The Simplification Item Check serves two purposes:

  • Relevance check: Determine which Simplification Items are relevant for the specific system in which you are running the Simplification Item Check. This shall help you to assess the functional and technical impact of the system conversion on your system.
  • Consistency check: During the conversion process your system will be migrated to the new data structures and new processes. The conversion routines rely on consistent data in the system in order for this to happen automatically. If the Simplification Item Check identifies data inconsistencies or missing mandatory preparation activities which could cause the system conversion to fail, it will make you aware of these issues so you can correct or exempt them before the actual system conversion starts.

The Simplification Item Check report /SDF/RC_START_CHECK supersedes the report R_S4_PRE_TRANSITION_CHECKS which was available in SAP S/4HANA 1511 and 1610 with a similar, though much more limited functionality.

For details on how the Simplification Item Check relates to the Simplification Item Catalog and the SAP Readiness Check for SAP S/4HANA please refer to the blog post Simplification Item Catalog, Simplification Item Check and SAP Readiness Check for SAP S/4HANA.

In this blog post I will focus on the consistency check part of the Simplification Item Check. How to successfully prepare and run the consistency checks and how to avoid common mistakes in execution.

Implementing the Simplification Item Check

How to implement the Simplification Item Check is described in SAP notes 2399707 and 2502552. In order to minimize the number of notes customers have to implement for the Simplification Item Check, the individual, application specific check classes are not delivered as individual SAP notes. Instead they are delivered as a new type of note/correction called “Transport Based Correction Instruction” (TCI). In order to be able to implement a TCI, customers on older support package levels have to do a one-time enablement for TCIs. Please ensure to precisely follow the instructions in SAP note 2502552 and 2187425 for doing the TCI enablement!

If your system is already on SAP S/4HANA 1709 (SAP_BASIS 7.52) or higher and you are planning an upgrade to a higher SAP S/4HANA release, you don’t need to do the TCI enablement steps 1-4 from SAP note 2502552 and hence don’t need to implement SAP note 2187425. The TCI functionality is fully available out of the box in SAP_BASIS 7.52 and higher.
Though the steps in SAP note 2502552 from step 5 onward, to actually implement the most recent TCI, are also applicable in SAP S/4HANA 1709 and higher.

Common Issues and Solutions for Implementing the Simplification Item Check

  • A common mistake is to do the TCI enablement not correctly – as described in SAP notes 2502552 and 2187425 – or not at all and just implement these notes like regular SAP notes. This will lead to further issues when trying to implement the Simplification Item Check.
  • In case you have changed this setting, restore the SPAM setting for “ABAP/Dynpro Generation” to it’s default value of “Never”, before importing the TCI. You can do this in transaction SPAM => menu “Extras” => “Settings”. The reason for this is, that there are additional SAP notes containing corrections for objects in the TCI (as listed in SAP note 2502552).
    If you have ABAP/Dynpro Generation activated in SPAM you might run into syntax errors while installing the TCI, which can only be fixed by the additional SAP notes with the TCI corrections on top. Though these notes cannot be installed before the TCI itself is installed, resulting in a deadlock situation.
  • When implementing a TCI, SPAM will create a backup transport of the objects within the TCI. This requires that STMS is properly setup in the system, so creating and releasing of workbench requests is possible. Hence, please ensure a proper STMS setup before implementing the TCI, otherwise TCI implementation will fail.
  • Also ensure to implement the latest corrections for the SNOTE tool (SAP note 1668882) before implementing SAP notes 2399707 and 2502552.
  • In case you experience issues when transporting the implemented TCIs to follow-on systems (error message: “Object … requires a directory entry”), have a look at and implement SAP note 2569813.
  • In case you experience issues in a system where SAP note 2399707 was already implemented, then you did do a SP update or release upgrade via SUM and afterwards try to implement SAP note 2399707 again (error message: “Format of correction instructions … unable to read corr. instruct.”).

    This is an issue in the SUM tool which will be fixed in upcoming SUM versions. Until then, as a workaround, you can transport the objects of SAP note 2399707 implementation from a system which is not affected by this issue into the system which is affected by the issue. This will restore the TADIR entries of the objects. Afterwards (de)implementation of SAP note 2399707 is possible again.

Simplification Item Check in the freeze period of your project

The Simplification Item Check technically consists of three parts

  • The check framework (SAP note 2399707)
  • Application specific check classes (SAP note 2502552)
  • The check content from the Simplification Item Catalog. The check framework will download the content automatically from SAP servers.

SAP will regularly deliver corrections and improvements on the check framework, check classes and check content. E.g. in order to reduce false positives in the checks, to add new features or to support new Simplification Items. Though it’s important not to negatively affect already ongoing SAP S/4HANA projects by changing or introducing new checks.

Therefore each SAP S/4HANA release or feature package/support package has a specific minimum version of SAP notes 2399707 and 2502552 which need to be installed in order to do the Simplification Item Check and the system conversion. This minimum SAP note versions are defined upon general availability of each SAP S/4HANA release or feature package/support package and will afterwards not be changed anymore.

The minimum versions so far are:

  • SAP S/4HANA 1709 Initial Shipment
    • 2399707: version 30
    • 2502552: version 1
  • SAP S/4HANA 1709 Feature Package 1
    • 2399707: version 82
    • 2502552: version 29
  • SAP S/4HANA 1709 Feature Package 2
    • 2399707: version 82
    • 2502552: version 38
  • SAP S/4HANA 1809 Initial Shipment
    • 2399707: version 82
    • 2502552: version 46

Corrections of these notes will still be released. However, to allow for a smooth conversion or upgrade the following update strategy is recommended for these two notes.

While you are still in an early phase of your project don’t stay on the minimum note versions, but always use the most recent versions of SAP notes 2399707 and 2502552 as well as the most recent version of the check content.

Though after the final conversion of your DEV system, it is highly recommended to freeze the versions of these notes as well as the version of the check content on the level which was used for the final DEV conversion.

For your follow on systems like QAS and PRD use the transport of the final note implementations 2399707 and 2502552 done in your DEV system.

In order to save the check content used for your DEV conversion, download it via the “Download Local Simplification Item Catalog” button in report /SDF/RC_START_CHECK. Download it before your start the conversion of the DEV system. It’s general good practice for every system conversion you do, to download the check content before the conversion and keep track of which system was converted with which version of the content.

The downloaded content from your last DEV conversion you can then upload with /SDF/RC_START_CHECK for conversion of all your follow on systems like QAS and PRD. In order to do this, on the start screen of /SDF/RC_START_CHECK switch to “Local version uploaded manually” and upload the content via button “Upload Simplification Item Catalog”.

When to run the Simplification Item Check

There are two modes in which you can run the consistency checks of the the Simplification Item Check.

Manually running report /SDF/RC_START_CHECK

You can do this any time in your SAP ERP system when planning a system conversion to SAP S/4HANA (or in your SAP S/4HANA system when planning a release upgrade). Run the checks as early as possible in your project in order to get an overview early in advance, which inconsistencies you need to fix before the system conversion/upgrade. You can also run the checks long before the actual conversion project – long before starting SUM.

When manually running the checks, ensure that you select the correct target stack for your system conversion / upgrade. Per default the /SDF/RC_START_CHECK report always has the most recent target stack pre-selected. As the check results are target stack dependent, when running the check against the wrong target stack you might miss some important Simplification Items and issues. Or see additional ones which are actually not relevant for your target stack.

When starting report /SDF/RC_START_CHECK manually, only the relevance checks are run automatically in order to determine which Simplification Items are probably relevant and which are not. In order to reduce the runtime of the report in cases where it’s not required to run all consistency checks, the consistency checks will not be started automatically. From the result screen of /SDF/RC_START_CHECK you can then start the consistency checks for all relevant Simplification Items with the “Check Consistency for all” button.

Depending on the number of inconsistencies found, fixing them might take some time or might even need a pre-project for data-cleanup. Also even when you have initially fixed all errors found, re-run the checks during the duration of your project in order to ensure that no new inconsistencies come up.

Though experience from SAP S/4HANA projects shows, that most of the inconsistencies found by the checks did not arise recently, but are of historic nature (e.g. inconsistent archiving, failed data conversions, wrong configurations, incomplete data maintenance, error in application logic… which did occur many years ago). Once you have initially cleanup up all issues found by the checks, it’s therefore not expected that many new issues will be found during the duration of your project, but you should check this.

Be careful when doing further archiving during your project and ensure that the archiving is done consistently. One category of inconsistencies which need to be fixed is caused by wrong archiving, breaking foreign key relations. E.g. archiving a material for which still material documents exists. If archiving is done improperly during your project, you could easily introduce new inconsistencies even after the initial cleanup.

Software Update Manager calling /SDF/RC_START_CHECK

The SUM tool will run the relevance and consistency checks before starting the actual system conversion/upgrade and before going into the technical downtime (phases RUN_S4H_SIF_CHECK_INIT of the “extraction” step and RUN_S4H_SIF_CHECK_EXEC of the “preprocessing” step). This is the last time the checks are run and if you did properly fix all issues before, here no new issues should come up. This check execution is mandatory and cannot be skipped.

When run via the SUM tool, the report will automatically get the correct target stack from SUM, based on the stack.xml file you did upload to SUM.

Where to run the Simplification Item Check

The SUM tool is always running the Simplification Item Check in client 000 of a system. Only running the checks in client 000 will ensure, that data in all clients is checked for inconsistencies. If you run the check in any other client, some of the checks will only return check results for this specific client.

Therefore it’s crucial that, when manually running the checks during the preparation phase of your project, that you run the Simplification Item Check in client 000.

Simplification Item Check runtime

Most of the consistency checks verify customizing settings and run quite fast. However, a few of the consistency checks also proof transaction data. The runtime of such checks depends mostly on the amount of data in the system. Specifically in the areas of inventory management (MM-IM) and material ledger (CO-PC-ACT) some customers have rather large amounts of historic transactional data which could result in longer check runtimes.

Therefore it’s recommended to do a strict archiving, especially in the application areas mentioned above, before starting your system conversion project and before running the Simplification Item Check. This will not only help to reduce the runtime of the checks, but also to reduce the effort for cleanup up of possible inconsistencies.

So you should consider, whether you really need the last 15 years of operational data in the system, requiring cleanup of inconsistencies in this data. Or if it is sufficient to keep the last 2-3 years of data and archive the rest.

Handling of the check results

After running the Simplification Item Checks, you can look up any potential issues found in the log file created by the checks (you can view the results and log file with report /SDF/RC_START_CHECK).

The following three categories of log entries are important:

  • Yellow warning messages (return code 4)
    • These you should be aware of and read the corresponding SAP note, but they are no show stoppers for the system conversion/upgrade. Therefore no mandatory action is required to solve these before the conversion. Though there might be activities required after the conversion, or activities where you can decide whether you do them before or after the conversion.
  • Red error messages (return code 7):
    • Messages with return code 7 will block the system conversion. So you need to take some action to solve them. One possibility to address return code 7 errors is, to set an exemption for the error. This can be done in the report /SDF/RC_START_CHECK in client 000. In the ALV with the overview of all Simplification Items see the column “Exemption Possible” to see items which are exemptable or which have already been exempted.
    • Exemptable error before setting the exemption:
    • Exemptable error after setting the exemption:
    • Before exempting a return code 7 error please be sure to understand the ramifications this has. The details are described in the corresponding, application specific SAP note in the log of the Simplification Item Check. While return code 7 errors will not cause the system conversion to fail, they can have a serious impact on the system, which you accept by exempting the error.
    • Please note that setting exemptions is target stack specific. So if you have exempted a return code 7 error for a given target stack (e.g. SAP S/4HANA 1709) and decide during the duration of your project to change to a higher target stack (e.g. SAP S/4HANA 1809) the previously exempted return code 7 errors will come up again. and you need to exempt them again, if appropriate. this is intentional, as the ramification of exempting an error be different, depending on the target stack of your system conversion or upgrade.
  • Red error messages (return code 8 or 12):
    • Messages with return code 8 or 12 will block the system conversion. It’s mandatory that you fix these return code 8 or 12 errors before starting a system conversion. How exactly the errors can be solved is highly application specific and is described in the corresponding, application specific SAP note in the log of the Simplification Item Check or in the business impact note of the corresponding Simplification Item. For many of these errors there are further, application specific tools for checking the issue in more details or for fixing the error. In case you need further information or have doubts regarding a specific error in the logs of the Simplification Item Check, open an incident on the support component to which the corresponding SAP note (business impact note) is assigned.

Detailing and updating the check results

The consistency checks can be run in two modes:

  • A quick mode, which checks if there are any critical issues for a given Simplification Item. This is sufficient for determining whether there are any blockers for the system conversion / upgrade. But it will not give you a detailed list of issues per Simplification Item.

    This mode is used when running the consistency checks for all Simplification Items, either manually or via SUM.
    The main advantage of this mode is, that it has an overall shorter run-time than the detailed mode explained next.

  • A detailed mode, which is doing a more in-depth analysis for individual Simplification Items. This will give you a list of all issues found per Simplification Item as well as more details on the type of issue and how to solve them. If and to what extent the level of detail differs between the quick mode and the detailed mode varies between Simplification Items. This mode is useful when building a work-list for solving all consistency issues related to a specific Simplification Item. This mode can have a longer run-time compared to the quick mode.

    You can trigger a detailed check for one or more Simplification Items by selecting the Simplification Items you are interested in in the ALV result view of /SDF/RC_START_CHECK and then pressing the “Check Consistency Details” button.

After fixing a specific error, this will not immediately reflect in the consistency check results shown by /SDF/RC_START_CHECK. In order to see the updated check results, re-run “Check Consistency Details” for the specific Simplification Item where you did fix the inconsistencies.

When manually running the consistency checks from within the result view of /SDF/RC_START_CHECK, they will currently run in dialog mode.

If you have set the timeout value for dialog processes ( rdisp/scheduler/prio_[high|normal|low]/max_runtime or rdisp/max_wprun_time ) to a very low value or have a high data volume in your system which might lead to longer run-times of this specific check, you need to increase the timeout value in dialog mode.

Up to and including version 88 of SAP note 2399707, even when starting the checks in background, under certain circumstances follow on processes could be spawned running in dialog work processes. Thereby making the timeout mentioned above also applicable in this case. This was improved with version 89 of SAP note 2399707, where all related processes are run in background work processes when starting the checks in background.

When repeatedly running the consistency checks, the results are written continuously to log file /usr/sap/SID/SUM/abap/tmp/S4_SIF_TRANSITION_CHECKS.SID.

So the results from more than one check execution might be included in this log file. Therefore it’s important to always look at the latest check execution in this log, in order to see which errors are actually left and which need to be fixed before the conversion. You can search for “BEGIN OF RUN_S4H_SIF_CHECK” in the log file in order to identify the start of a check execution.

Checks not included in the Simplification Item Check

Any new consistency checks related to SAP S/4HANA conversions or upgrades are build directly in the Simplification Item Check framework. Also most previously existing standalone consistency checks have been moved into the Simplification Item Check framework.

Though some standalone consistency checks, for technical reasons, could not yet be moved into the Simplification Item Check framework . These are:

  • In SAP S/4HANA releases < 1809 the configuration consistency checks in FI-AA area (RASFIN_MIGR_PRECHECK). As described in SAP note 2333236. See also the guide attached to SAP note 2332030 for details. From SAP S/4HANA 1809 onward, the checks from RASFIN_MIGR_PRECHECK are included in the Simplification Item Check framework.
  • The transactional data consistency checks in Finance area. For details on the Finance consistency checks please refer to the blog series Conversion to SAP S/4HANA – Consistency checks in Finance from Martin Schmidt.

Don’t forget to run these checks in addition to the Simplification Item Check!


In order to successfully use the Simplification Item Check as preparation for your system conversion/upgrade project

  • Start running the Simplification Item Check and fixing the issues found by the checks as early as possible in your project.
  • Stay up-to-date with the latest check and check content versions early in your project. But don’t miss to freeze the check notes and check content versions after converting your DEV system.
  • Archive any data which you don’t strictly need in your SAP S/4HANA system in order to minimize the check runtime and the data cleanup effort.
  • Don’t forget to run those Finance specific checks which are not included in the consistency checks of the Simplification Item Check yet.
To report this post you need to login first.


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

  1. Former Member

    Hello Markus,



    Thanks you for a wonderful blog.  I have a question related to skipped simplification list items. When we run RC_START_CHECK, I see few items have been “skipped” as their relevance could not be determined.

    Does that means there will be no impact or we need to manyally check each of those items?



    Sumit Oberoi


Leave a Reply