Skip to Content
Technical Articles
Author's profile photo Markus Goebel

SAP S/4HANA Simplification Item Check – How to do it right.

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.

Date Change
October 21st 2021 – Added an explanation on runtime differences between RUN_S4H_SIF_CHECK_INIT and RUN_S4H_SIF_CHECK_EXEC.
– Added a more detailed explanation on the status icons from the consistency check.
October 13th 2021 – Updated release information. Added information on SAP S/4HANA 2021.
April 15th 2021 – Added details on the SAP Readiness Check usecases vs. Simplification Item Check usecases.
March 30th 2021 – Information on additional BP/CVI related checks added.
March 3rd 2021 – Added information on SAP S/4HANA 2020 FPS1.

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 target release 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 a quick comparison between Readiness Check and Simplification Item Check please see the following table.

SAP Readiness Check for SAP S/4HANA Simplification Item Check
Implementation Cloud based customer self service provided by SAP Digital Business Services in the SAP Support Portal. ABAP Report in the customer system.
Included Checks – Simplification Item Relevance
– Simplification Item Consistency NEW as of Readiness Check 2.0
– Custom code
– Recommended Fiori apps
– Add-on compatibility
– SAP Custom Development projects
– SAP S/4HANA sizing
– Business Function compatibility
– Simplification Item Relevance
– Simplification Item Consistency
Called by SUM no yes
Mandatory no, but highly recommended yes
Granularity High level Detailed
Use cases – Conversion to SAP S/4HANA – Conversion to SAP S/4HANA
– Upgrade to a higher SAP S/4HANA release
Available as of target release SAP S/4HANA, on-premise edition 1511 or higher SAP S/4HANA 1709 or higher

While both, SAP Readiness Check and Simplification Item Check are able to display information on Simplification Item relevance and consistency, they serve different purposes and are both required.

  • SAP Readiness Check is mainly a planning tool which you should run already early in a system conversion project in order to get an overview on the required activities – including Simplification Item related tasks. It is also useful for tracking these activities during the project e.g. via the burndown chart of Simplification Item consistency errors found.
  • The Simplification Item Check on the other hand is used on operational level during cleanup of the Simplification Item consistency errors, up to the downtime, before which the SUM tool is doing the final executions of the Simplification Item Check. Hence the Simplification Item Check offers some more fine granular control over running the checks. This includes the option to re-run checks for individual Simplification Items instead of running all checks like SAP Readiness Check does, which can significantly reduce the check runtime, in case you just want to re-check if a specific error which you have just fixed is really gone.
    In addition the Simplification Item Check offers the option to exempt certain type of errors (details see below).

For additional 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 order to understand, what is in scope of the Simplification Item Check and what is out of scope, it’s also important to understand what the purpose of a Simplification Item is. A Simplification Item describes a major, potentially incompatible change between SAP ERP and SAP S/4HANA or between different SAP S/4HANA releases, which might require customers to do some preparation or follow on activities in a system conversion to SAP S/4HANA or in a SAP S/4HANA upgrade.

Therefore the Simplification Item Check is not the right tool if you are looking for new features and innovations in SAP S/4HANA. Please refer to SAP Innovation Discovery and the What’s New Viewer for this purpose.

Also custom code checks – even for changes of potentially incompatible nature – are not in the scope of the Simplification Item Check. For this purpose there is the ABAP Test Cockpit (ATC) as a dedicated custom code check tool.

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

On the source system of the system conversion the Simplification Item Check can be implemented and run on any SAP ERP system, no matter which Enhancement Package, down to SAP ERP 6.0 (ECC600). And on the source system for a release upgrade on any SAP S/4HANA system starting with SAP S/4HANA 1511.
Though if the Support Package Stack installed on your system is too old, this might lead to issues with the the Simplification Item Checks, as it cannot be guaranteed that all prerequisites of the Simplification Item Checks are fulfilled. Hence it’s recommended to have a rather recent Support Package Stack in the source system.
(Please note that in general SAP recommends the application of support package stacks at least once a year.)

While for the system conversion itself three main technical prerequisites are, that the system needs to be on SAP ERP 6.0 or higher, on unicode and single-stack (only ABAP, no Java stack), for the Readiness Check and Simplification Item Check it’s sufficient if the system is on SAP ERP 6.0. Even if your system is still non-Unicode or dual-stack, you can already run Readiness Check and Simplification Item Check. Just keep in mind to later on do the dual-stack split and Unicode conversion before the actual system conversion to SAP S/4HANA.

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. The easiest way to enable a system for TCI implementation is to follow the automated, guided steps in SAP note 2836302 (this note is unrelated to the Simplification Item Checks, but it also includes the TCI enablement and due to support infrastructure changes anyway all customer have to implement this note until January 1st 2020). Alternatively it’s still possible to do the TCI enablement by following the guide in note 2187425, which was the previous recommendation. Though this involves more manual steps and effort.

If your system is already on SAP S/4HANA 1709 (SAP_BASIS 7.52) or higher, the TCI functionality is fully available out of the box and you don’t need to do a TCI enablement.

Though irrespective of how you did do the TCI enablement, or if your system was already on a TCI enabled support package level, you need to follow the steps in SAP note 2502552 from step 5 onward, to actually implement the most recent TCI.

The Simplification Item Check is exclusively intended to be implemented and run on your SAP ERP / SAP S/4HANA backend system. There is no need or possibility to run it on any other system that might be connected to your SAP ERP / SAP S/4HANA backend (e.g. SAP Fiori Frontend Server, SAP Portal, SAP PI…).

Common Issues and Solutions for Implementing the Simplification Item Check

Issues related to the framework note 2399707

  • For common issues and solutions related to implementation of SAP Note 2399707 please refer to this separate blog post by the Simplification Item Check framework development team.

Issues related to TCI implementation / note 2502552

  • 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.
  • If you run into errors like “Delivery event […] is not in your system” or “Unable to find delivery event […]” during TCI implementation, implement SAP note 2671774 and try again.

Issues related to individual check classes / Simplification Items

CLS4SIC_MM_IM_SI1 / SI1: Logistics_MM-IM

  • In case you experience longs runtimes or performance issues with check class CLS4SIC_MM_IM_SI1 please refer to the “Runtime of MM-IM checks” section further down in this blog post.
  • If you experience a CX_SY_OPEN_SQL_DB short dump in check class CLS4SIC_MM_IM_SI1 and increasing the memory does not fix the issues, please open a support incident on support component MM-IM-GF-MIG and request access to pilot note 2761731.
  • If you experience a CX_SY_DYNAMIC_OSQL_SEMANTICS short dump in check class CLS4SIC_MM_IM_SI1, please refer to note 2894923.

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 1809 / 1709 / 1610 / 1511
    • Please note, that system conversions to release lower than SAP S/4HANA 1909 are no longer supported. *
  • SAP S/4HANA 1909 Initial Shipment
    • 2399707: version 125
    • 2502552: version 68
    • TCI #8 – note 2761703
  • SAP S/4HANA 1909 Feature Package 1
    • 2399707: version 129
    • 2502552: version 69
    • TCI #8 – note 2761703 (Feature Package 1 using the same TCI as Initial Shipment)
  • SAP S/4HANA 1909 Feature Package 2
    • 2399707: version 130
    • 2502552: version 76
    • TCI #8 – note 2761703 (Feature Package 2 using the same TCI as Initial Shipment)
  • SAP S/4HANA 2020 Initial Shipment
    • 2399707: version 136
    • 2502552: version 79
    • TCI #9 – note 2910131
  • SAP S/4HANA 2020 Feature Package 1
    • 2399707: version 136
    • 2502552: version 84
    • TCI #9 – note 2910131 (Feature Package 1 using the same TCI as Initial Shipment)
  • SAP S/4HANA 2020 Feature Package 2
    • 2399707: version 136
    • 2502552: version 86
    • TCI #9 – note 2910131 (Feature Package 2 using the same TCI as Initial Shipment)
  • SAP S/4HANA 2021 Initial Shipment
    • 2399707: version 146
    • 2502552: version 90
    • TCI #10 – note 3028788

(* System conversions to a given SAP S/4HANA release are supported until availability of Feature Package 2 of the next but one release, so around 2.5 years.)

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 absolutely crucial 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 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 will run the Simplification Item Check individually in every system that is being converted to SAP S/4HANA, irrespective of the system type (SBX, DEV, QAS, PRD…). Hence as preparation of each of these system conversions, you should also run the Simplification Item Check manually in every system.

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.

Differences in check results

When running the Simplification Item Check in different systems of the same landscape or even repeatedly in the same system, the check results can differ. The most common (expected) reasons for this are:

  • The DEV, QAS, PRD systems in a customer landscape are usually not 100% identical (e.g. different data in the systems, different transactions being used, different business functions being active…). Therefore you will most likely also get different check results and issues to be solved for each system.
  • When re-running the Simplification Item Checks in the same system but with more recent versions of the check framework and content (Simplification Item Catalog), you will most likely get additional results as new checks might have been added in the meantime or existing ones have been improved.
  • When doing a system copy of an existing system (e.g. production to sandbox), the usage (ST03N) data will we not be copied and adapted to the new system. This is per design how ST03N stores it’s data. Hence it often happens, that in a sandbox system copied from production many of those simplification items, which rely on ST03N data in their relevance check, don’t show up as relevant anymore. While they did show up as relevant in the production system. One solution for this is the special report in SAP note 2568736 which copies ST03N data between systems.
  • When running the Simplification Item Check for the first time for a given target stack, there will only be a relevance check result but no consistency check result yet. So don’t forget to press the “Check Consistency for all” button, before comparing this to the check result from some other system or target stack.
  • And last but not least, ongoing operation of a system might lead to new errors. So if you did fix all errors of a certain type some weeks or months before go-live, this does not mean that no new errors might show up. This is the reason why it’s recommended to run the Simplification Item Checks repeatedly per system during the course of your project.

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.

Runtime of MM-IM checks

For customers with huge amounts of data in the material master related tables (MARD, MARC, MBEW, MKPF, MSEG…) the related consistency checks ( CLS4SIC_MM_IM_SI1 / SI1: Logistics_MM-IM ) will contribute significantly to the overall check runtime. The runtime of the MM-IM checks can in such cases be several days. Most of this time is spent checking KALNR (cost estimate number) data. As this is not strictly required in order to do a technically successful system conversion and as many customers don’t need the KALNR data for reporting purposes, please check SAP note 2753888, in case you experience unacceptably long runtimes of the MM-IM checks. With this note you can skip the KALNR checks – at the cost of probably not having full KALNR data later on.

Deleting unused clients

Another way of reducing the check runtime (and of course the effort for fixing and cleaning up inconsistencies) is to delete clients which are no longer required. This applies to obsolete SAP standard clients like 001 or 066 as well as to customer specific clients which are no longer used. Here it’s important to properly delete the clients. An often made mistake is, to just delete the T000 entry of a client, but not the actual data of the client. This way the client will only be hidden but not deleted. The Simplification Item Checks as well as the data migration logic later on will still run on such hidden clients! Which also means that you are required to fix any data inconsistencies in these clients, whether they are hidden or not.

The same holds true for other partitions of data in the system like company codes, sales organizations etc. Even if you are not actively using data (anymore), it still has to be consistent in order to be migrated into the SAP S/4HANA data structures. Hence most check classes analyze all related data in the system and don’t offer the option to exclude certain data in advance from the checks.

Please refer to SAP note 1749142 for how to properly delete a client.

Handling of the check results

Before running the consistency checks for the first time for a given stack, the “Last consistency check result” column in the result overview of /SDF/RC_START_CHECK will show grey icons for all Simplification Items.
After running all consistency checks the icons in this column will

  • Stay grey for all Simplification Items which don’t need and hence don’t have a consistency check. This is the majority of all Simplification Items
  • Turn into a red RC=12 icon, if the check class of the corresponding Simplification Items has not been implemented yet and hence the check cannot run. In the log you will find details, which SAP note needs to be implemented in order to implement the check class.
  • Turn into the icon of the most critical status the check class did return.

Details on the check results can be found in the log file created by the checks (“Display Consistency Check Log” button in /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. In this mode most check classes only search for the first 1 – 100 issues and then stop analysis in order to reduce runtime for the overall check execution.

    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 can have 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. Alternatively you can also use report /SDF/RC_TROUBLE_SHOOT for (re)running individual checks in background.

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.

Different SUM behavior in different phases of check execution

While the check framework knows the return codes 0, 4, 7, 8 ,12, as explained above, the SUM tool only knows the return codes 0 (information), 4 (warning) and 8 (error = SUM will stop). Therefore a mapping between these return codes takes place which is different, depending on whether the framework is called by SUM in phase RUN_S4H_SIF_CHECK_INIT or by SUM in phase RUN_S4H_SIF_CHECK_EXEC.

During first SUM check execution (RUN_S4H_SIF_CHECK_INIT):

Actual return code Return code displayed in the check report and in application log Return code delivered to SUM and shown in SUM log file*
0 0 0
4 4 4
7 7 (or 4 if it has been exempted) 4 in any case, whether it’s exempted or not
8 8 4
12 12 8 (= SUM stops)

During second SUM check execution (RUN_S4H_SIF_CHECK_EXEC):

Actual return code Return code displayed in the check report and in application log Return code delivered to SUM and shown in SUM log file*
0 0 0
4 4 4
7 7 (or 4 if it has been exempted) 4 if exempted or

8 (=SUM stops) if not exempted
8 8 8 (= SUM stops)
12 12 8 (= SUM stops)

Please pay special attention to the two cases marked in bold above, where the SUM does not stop in the first phase (RUN_S4H_SIF_CHECK_INIT) for yet unexempted (RC=7) errors and less critical (RC=8) errors. But SUM will stop for these errors in the second phase (RUN_S4H_SIF_CHECK_EXEC)! This is in order not to block SUM and therefore the whole conversion already in such an early phase, which can happen many days or even weeks before the start of downtime and where there is still plenty of time to exempt of fix these issues. In the first phase (RUN_S4H_SIF_CHECK_INIT) SUM will only stop for the most critical errors (RC=12).

Therefore please always check in the application log of the check runs or the check report itself, if there are any remaining RC=8 to be fixed or RC=7 to be exempted. And don’t just assume that if the check report did not stop SUM in the RUN_S4H_SIF_CHECK_INIT phase, that this will also be the case in the RUN_S4H_SIF_CHECK_EXEC phase.

(* For better transparency in one of the next updates of the framework note this will be changed, so that the message text in the SUM log will also display the real return code from the check framework – so column 2 in the tables above – which is already shown in the application log and the check report, instead of the return code passed to SUM.)

Please be aware that RUN_S4H_SIF_CHECK_INIT and RUN_S4H_SIF_CHECK_EXEC can have different runtimes due to the way the “quick check” mode (see previous paragraph) works, which both phases are using. Example:

  • A check class is scanning a table and the scan is quite expensive in terms of runtime (e.g. full table scan).
  • The check class is implemented in a way, that in “quick mode” it only looks for the first 100 data inconsistencies found in the data.
  • In a given customer system this table has 1.000.000.000 records and at the time RUN_S4H_SIF_CHECK_INIT is executed the first 100 data inconsistencies are located within the first 1.000.000 records of the table.
  • After RUN_S4H_SIF_CHECK_INIT the customer is manually running the detailed check and fixing all data inconsistencies.
  • At the time RUN_S4H_SIF_CHECK_EXEC is executed, no data inconsistenciesare left in the table.

In this example the check class is only checking the first 1.000.000 records during RUN_S4H_SIF_CHECK_INIT but needs to check all 1.000.000.000 records during RUN_S4H_SIF_CHECK_EXEC in order to verify that no new errors have come up, which surely does have an impact on the runtime of the check.

Though how RUN_S4H_SIF_CHECK_INIT and RUN_S4H_SIF_CHECK_EXEC runtime differ in a specific customer system depends on many factors. Including the number of records and data inconsistencies in the scanned tables, how these data inconsistencies are distributed across the data, delta mechanisms and optimizations used by individual check classes etc.

Hence for better predictability of runtimes it’s recommended to clean up most errors already in the (repeated) manual check runs before RUN_S4H_SIF_CHECK_INIT. Then RUN_S4H_SIF_CHECK_INIT and RUN_S4H_SIF_CHECK_EXEC runtimes will be quite similar.

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 consistency checks in FIN area are not yet included in the Simplification Item Check framework.

  • FIN configuration consistency checks
    • GL: Are included in the Simplification Item Checks as of SAP S/4HANA 1709. See SAP note 2245333 for details.
    • AA: Are included in the Simplification Item Checks as of SAP S/4HANA 1809. In SAP S/4HANA releases < 1809 the FI-AA configuration consistency checks are handled via the separate report RASFIN_MIGR_PRECHECK. As described in SAP note 2333236. See also the guide attached to SAP note 2332030 for details.
  • FIN transactional data consistency checks
    • GL: Are still handled outside of the Simplification Item Checks.
    • AA: Are still handled outside of the Simplification Item Checks. These checks can already run on the source ERP system on anyDB. Please refer to SAP note 2755360 for details.
  • These FIN consistency checks for configuration and transactional data are only relevant if you are doing a conversion from SAP ERP to SAP S/4HANA. They are not relevant for release upgrades within SAP S/4HANA (e.g. upgrade from 1709 to 1909). Because once a system is on SAP S/4HANA it’s already using the new FI data model.
  • For more details on the Finance consistency checks please refer to the blog series Conversion to SAP S/4HANA – Consistency checks in Finance from Martin Schmidt.

Also in the area of Business Partner / Customer Vendor Integration additional checks exist, which go beyond the scope of the Simplification Item checks. For further information please see

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

Conclusion

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.

Assigned Tags

      47 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Renaud VAN DEN DAELE
      Renaud VAN DEN DAELE

      Awesome blog colleagues !!!

      Author's profile photo Anindya Chaudhuri
      Anindya Chaudhuri

       

      Very useful. Thanks a lot.

      Author's profile photo Former Member
      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?

       

      Regards,

      Sumit Oberoi

      Author's profile photo Rahul Patki
      Rahul Patki

      Very useful blog! Thank you.

      Have a question here – Along with S/4 HANA 1709 upgrade to S/4 HANA 1809,  also upgrading Fiori for S/4 HANA 1709 to Fiori for S/4 HANA 1809 (Hub deployment). Shall SIC be run in Fiori system as well?

      Author's profile photo Markus Goebel
      Markus Goebel
      Blog Post Author

      Hi Rahul,

      the Simplification Item Check is intended for analyzing the backend. No need to run it on the Fiori frontend server, nor would the check return any useful results there.

      I have now also added this information to the blog post.

      Regards,

      Markus Göbel

      Author's profile photo DAVID ANTON ARIAS GARCIA
      DAVID ANTON ARIAS GARCIA

      Hi Markus, excellent job!

      Please, let me the following question regarding to the and SAP Note 2568736 (SAP Readiness Check for SAP S/4HANA - copy ST03N data). I don't understand the relationship between SI-Check and ST03N so the SI-Check report doesn't show usage information. What is the relationship between then?

      Thanks a lot.

      Author's profile photo Markus Goebel
      Markus Goebel
      Blog Post Author

      Hi David,

      the relevance checks mentioned in my blog post determine, which of the many Simplification Items are relevant for a specific customer system (typically only a small fraction of the Simplification Items is relevant for each customer).

      Technically the relevance checks can check whether a customer has activated a specific business function, whether specific data records exist in tables or if specific transactions or reports are used in the customer system. Based on this data it's then calculated which Simplification Items are relevant in this system.

      For the part of the check which relies on transaction/report usage, ST03N data is required. That's how SI-Checks relate to ST03N data.

      Regards,

      Markus Göbel

       

      Author's profile photo DAVID ANTON ARIAS GARCIA
      DAVID ANTON ARIAS GARCIA

      Thanks a lot Markus.

      Author's profile photo venu gopal
      venu gopal

      Superb document

      Author's profile photo Arik Abulafia
      Arik Abulafia

      Hi Markus,

      Thanks for the marvelous blog post.

      I am wondering on which system should we manually run this check? DEV / QA / PROD / all of them.

      We ran the report on our DEV system, which is obviously easier, but we saw 2 things:

      1. The relevancy check using ST03N data, which may not reflect the real usage data as exists in our PROD env.
      2. The consistency check detects inconsistent entries in some DB tables, which will be different between the DEV and PROD.

       

      Thanks a lot,

      Arik

      Author's profile photo Renaud VAN DEN DAELE
      Renaud VAN DEN DAELE

      Hi Arik,

      Arik Abulafia

      The recommendation for an SAP S/4HANA conversion project is to start with a sandbox copy of production. In this sandbox, you will get meaningful results.

      In any case, the SICs will be called by the SUM tool before you are allowed to start the conversion. So they will be called for DEV, QUA, PROD and you cannot avoid this. Since red status will block conversion process of any of these environment the earlier you launch them, the earlier you understand blockers, the earlier you fix them, the safer your overall planning is.

      Some checks can run for quite a while on some very large tables, so the best is to try on the Sandbox BEFORE you do in PRD

      Hope this helps.

       

       

       

      Author's profile photo Arik Abulafia
      Arik Abulafia

      We also thought this way (because of the SUM) but wasn't sure.

      Thanks a lot

      Author's profile photo Markus Goebel
      Markus Goebel
      Blog Post Author

      Hi Arik,

      I have updated the "where to run the simplification item check" section of my blog post with guidance on in which systems the check needs to be run.

      As Renaud already mentioned, SUM will run the check in every system. So as preparation you also need to run the check manually in every system you are planning to convert.

      As DEV, QAS, PRD systems are usually not exactly identical in their setup and data, you will most likely also get a bit different check results for each systems and might need to solve different types of issues.

      Regards,

      Markus Göbel

      Author's profile photo Markus Doehr
      Markus Doehr

      While I truly appreciate the effort being done to help customers with this blog (I really do), I have to say, that I really wonder, why it always has to be so incredibly messy.

      We ran the SIC with an older version and now ran into the issue SUM messing it up - and the support is not really helping (pointing just here, not reading OSS incidents completely). A lot of confusion and misunderstanding is created and the necessity of having to create a blog, to let the customers and/or their consultants sort it out the very mess being created by SAP, does not really instill confidence in any of the "new things" SAP is doing, this being the third project this year ending in something only to be construed as too-fast-too-buggy.

      Doing this for 25+ years now I'm used to a certain amount of affliction and incoherence - on both sides of the aisle I might add - but this kind of delivering functionality via a combination of notes, manual descriptions in PDFs and TCIs and putting the responsibilities solely to the customers does the opposite of facilitating what it was supposed to.

      Author's profile photo Anindya Chaudhuri
      Anindya Chaudhuri

      Revising the blog - now for S4/HANA 1809 conversion. Found the updated information very useful.

      Author's profile photo Lichee Yu
      Lichee Yu

      This's a fantastic blog! Thank you so much Markus!

      Author's profile photo Saptarshi Sen
      Saptarshi Sen

      Hi Markus,

      Excellent blog! Kindly let us know if you plan to enhance the blog/ create more blogs with latest improvements in the BP/CVI area, would be glad to collaborate and contribute!

      BR

      Rishi.

      Author's profile photo Bhavesh Patel
      Bhavesh Patel

      Hi Markus,

      Very well explained the subject... thanks a lot ... your explanation makes life simpler for many of SAP consultants. Thanks again....!!

      I have a question, please.

      I see below two (A and B) and i get different understanding from them.

      A) In the comparison table, i see that - SIC is "Available as of ... SAP S/4HANA 1709 or higher"

      B) At another para - i see "The Simplification Item Check can be implemented and run on any SAP ERP system"

      Can you please clarify?

      Best Regards,

      Bhavesh Patel

       

      Author's profile photo Markus Goebel
      Markus Goebel
      Blog Post Author

      Hi Bhavesh,

      glad to hear that the blog post is helpful for you.

      Regarding your question:

      B) refers to the source release a customer is coming from (minimum is ERP 600).

      A) refers to the target release a customer is converting / upgrading to. Minimum for the new check framework is SAP S/4HANA 1709.

      Or to phrase it differently:

      The new check framework / SIC can be used for system conversions or upgrades to SAP S/4HANA 1709 and higher, as long as the customer is on a supported source release for the system conversion / upgrade itself - which can be anything down to ECC600.

      I will update the text in order to make this more clear.

      Best Regards,

      Markus

      Author's profile photo Nadeem Mallick
      Nadeem Mallick

      Hi,

      We are executing SI-Check report "/SDF/RC_START_CHECK" and getting the Check result but we are facing issue while executing detailed report for SI1: Logistics_MM-IM. It is taking very long and dumping after few hours.

      Any suggestion.

      Best regards,

      Nadeem

      Author's profile photo Markus Goebel
      Markus Goebel
      Blog Post Author

      Hi Nadeem,

      regarding the long runtime please see the section "Runtime of MM-IM checks" in the blog post. There are some hints how to improve the runtime. Especially disabling the KALNR check (which many customers don't need) can cut down the runtime by over 90%.

      Regarding the dump please open a support incident on component MM-IM-GF-MIG, so the colleagues responsible for the MM-IM check can have a look at this. Thanks.

      Best Regards,

      Markus

      Author's profile photo Narayanasetty Sridhar
      Narayanasetty Sridhar

      Very good article, simplified the understanding. thanks.

      Author's profile photo Pankaj Tyagi
      Pankaj Tyagi

      Hi Markus,

      SIC can be used in S/4HANA for "Support Package or Feature Pack upgrade" ?

       

       

      Author's profile photo Stefan Berndt
      Stefan Berndt

      Hi Pankaj,

      yes, you can use the SI check also for support package or feature package upgrades or updates. Just select the respective target version in the drop down list of the report.

      Best regards,

      Stefan

      Author's profile photo Racherla Vyomakesh Bharadwaj
      Racherla Vyomakesh Bharadwaj

      Hi Markus,

       

      Very nice article!!. Thank you

       

      Regards,

      Vyomakesh Bharadwaj Racherla

      Author's profile photo Basis Team
      Basis Team

      Great Blog...!!

      Author's profile photo Vadivel Appavu
      Vadivel Appavu

      Hi Expert ,

      While running the report SDF/RC_START_CHECK i am facing some issue with RFC SAPOSS .

      Simplification item catalog cannot be fetch SAP from SAPOSS connection .kindly help me on my issue.

       

      Author's profile photo Markus Goebel
      Markus Goebel
      Blog Post Author

      Hi Vadivel,

       

      this is fixed with version 129 of SAP note 2399707

      Please see also the separate blog post

      https://blogs.sap.com/2019/11/10/sap-note-simplification-item-check-implementation-problem/

      from the developer of the framework, where this is explained and which I have also linked above.

      Regards,

      Markus

      Author's profile photo Christoph Ostrop
      Christoph Ostrop

      every blog is welcome and helpful,

      but the integration/implementation of the mentioned sapnotes is a real horror

      (why can’t you (SAP) at least add the manual activities such as add/maintain text elements to programs be included into the sapnotes)?

      and then complicated sapnote-dependencies etc. – this is really not nice!

      Author's profile photo Ivana Seslija
      Ivana Seslija

      Hello,

      We run report and receive following error message:

      Dynamic call of class CLS4SIC_MM_IM_SI1 method CHECK_CONSISTENCY failed: An exception the type CX_SY_DYNAMIC_OSQL_SEMANTICS occurred, but was neither handled locally, nor  declared in a RAISING clause.

      Do you have any idea how to resolve this issue. This is stop message and we not be able to do conversion without resolving issue.

      Thank you in advance for answer.

      BR,

      Ivana

      Author's profile photo Ahmed Elshazly
      Ahmed Elshazly

      As Markus Goebel mentioned, this is resolved by note 2894923.

      Best Regards,

      Ahmed Shazly

      Author's profile photo Markus Goebel
      Markus Goebel
      Blog Post Author

      Note 2894923 is also no longer a pilot note, but released for all customers (I have updated this in the blog post).

      Regards,

      Markus

      Author's profile photo Rupesh Shivathare
      Rupesh Shivathare

      Hi Markus,

      Thanks for this great blog.

      Just wondering why SUM tool interprets differently for reported return codes in phases

      RUN_S4H_SIF_CHECK_INIT and RUN_S4H_SIF_CHECK_EXEC

       

      Regards,

      Rupesh

      Author's profile photo Markus Goebel
      Markus Goebel
      Blog Post Author

      Hi Rupesh,

      phase RUN_S4H_SIF_CHECK_INIT is usually happening long before the actual downtime. So there is plenty of time to still fix things. Hence we decided that RC8 errors which would eventually stop SUM, will not yet stop SUM at this point in time - but of course they still show up as errors in the log.

      This way customers can fix these RC8 errors but still continue other SUM activities. Otherwise they would be blocked already in this phase.

      Though in the RUN_S4H_SIF_CHECK_EXEC phase, which happens immediately before the downtime, such errors would then stop SUM. As this is the last line of defense before SUM goes into downtime.

      Regards,

      Markus

      Author's profile photo Sumit Jaiswal
      Sumit Jaiswal

      Hi Markus,

      Thanks for this article.

      Could you confirm if SAP has stopped the option of executing SAP Readiness Check in Solution Manager from the release of SAP Readiness Check 2.0  ?

      In SAP Readiness Check 1.0, we had two options :

      • Execute from managed system : Report /SDF/RC_START_CHECK
      • Or, Execute from Solution Manager : Report AGSRC_START_ANALYSIS.

      For most of the cases (since SRC 1.0) I have been performing the checks on managed systems ( to be converted) locally, but I don’t see any option of performing this check from Solution manager since Readiness check 2.0.

      Author's profile photo Markus Goebel
      Markus Goebel
      Blog Post Author

      Hi Sumit,

      I double-checked this with the Readiness Check Team.

      Indeed as of RC 2.0 starting RC from Solution Manager is no longer supported, but only starting from the local system. The option to start RC 1.0 from Solution Manager did not really reduce the implementation effort, as most related notes had to be installed in the backend and Solution Manager system.

      Even with RC 1.0 most customers did start RC from the local system. Hence it was decided to remove this option for RC 2.0.

      Best Regards,

      Markus

       

      Author's profile photo Vivek Chaudhary
      Vivek Chaudhary

      Excellent

      Author's profile photo Robert Forster
      Robert Forster

      Hi,

      i have a question.

      Report was fine in the first execution.

      Now i am getting blocking errors during the second SUM execution.

      Fix them require implementing of some notes, but notes can not be installed during the running upgrade.

      What to do now?

       

      Best regards

      Robert

      Author's profile photo Tsz Kin Au
      Tsz Kin Au

      Hi guys,

      After submitting the /SDF/RC_START_CHECK checking in background mode, I found in SM37 that there are 1 x RC_NEW_CHECK_IN_JOB and around 30 RC_NEW_CHECK_IN_JOB jobs...released and running.

      the job RC_NEW_CHECK_IN_JOB cancelled in 1 mins with error "Internal session terminated with runtime error LIST_TOO_MANY_LPROS (see ST22)" in job log.

      while those many others job "RC_NEW_CHECK_IN_JOB " are still running and waiting in released (job queue full and delaying)

      And after some of the RC_NEW_CHECK_IN_JOB  completed, actually i can see the check result from /SDF/RC_START_CHECK > display application log as normally...

      However, the symptom look so abnormal. isnt it? And I'm afraid the SUM tools will be stuck later when it submit the /SDF/RC_START_CHECK job and cancel just like what I see now in SM37....

      Anyone experienced this before?  the sap notes implemented is update to date already.

       

      Regards

      Curry

      Author's profile photo Stefan Berndt
      Stefan Berndt

      Dear Curry,

      this issue normally happens when you start /SDF/RC_START_CHECK in background mode with SE38 via the command program > execute > background.
      Please only execute the program in online mode in SE38 and then select the option ‘new relevance & consistency check as background’.

      Best Regards,

      Stefan

      Author's profile photo Tsz Kin Au
      Tsz Kin Au

      Ops! Tested and you are right. So tricky..

      Thanks, Stefan~

      Author's profile photo ABHIRUP CHATTERJEE
      ABHIRUP CHATTERJEE

      Hi Markus,

      Thanks for great blog!! I have one question regarding SI checks, why we have to run SIC report while converting ERP system to S/4 HANA or upgrading existing S/4 HANA release, but why not during EHP upgrade of ERP systems?

      Author's profile photo Stefan Berndt
      Stefan Berndt

      Hi Abhirup Chatterjee,

      I understand your wish to have a similar change support for SAP ERP maintenance events as for SAP S/4HANA. However, SAP S/4HANA is our strategic product line for enterprise management, thus we decided to focus with any framework or content developments solely on SAP S/4HANA.

      Kind regards,

      Stefan

      Author's profile photo shirley zhou
      shirley zhou

      Hello  Markus,

      We run report and receive following error message:

      Dynamic call of class CLS4SIC_MM_IM_SI1 method CHECK_CONSISTENCY failed: An exception with the type CX_SY_OPEN_SQL_DB occurred, but was neither handled locally, nor declared in a RAISING clause.

      I’m not sure about the specific point of increasing the memory you mentioned. Check note2761731. I think it should refer to whether there is an error in the database disk space and memory size, but I did not find a problem. Therefore, I implemented note 2761731 to try to solve the error. Obviously, it was not able to Help me solve the problem, if you have any suggestions for inspection or solutions to the problem, you can share with us.

      Thank you in advance for answer.

      Author's profile photo Stefan Berndt
      Stefan Berndt

      Dear Shirley Zhou,
      please open a customer case for this issue and send it to SAP support as this may require a detailed system analysis. Please understand that such support tasks cannot be handled in this blog area.
      Many thanks for your understanding.
      Kind regards,

      Stefan

      Author's profile photo shirley zhou
      shirley zhou

      Dear Stefan

      The relevant incident has been opened and the problem has been processed. During the Logistics: MM-IM check, it is necessary to ensure that HANA memory resources are sufficient, perform memory analysis according to the amount of data, and allocate enough memory for SI-check. Thanks again for your recovery!

      Author's profile photo Paul Secunde
      Paul Secunde

      Hello,

      Very useful blog and comments but what happens if we reach RUN_S4H_SIF_CHECK_EXEC phase and did not exempt the return code =7 checks beforehand?  We exempted the check when phase RUN_S4H_SIF_CHECK_EXEC reported the error as return code = 8.  When we repeat the EXEC phase, it still fails with return code = 8, appearing to ignore the exemption we just made in client 000.  We expected the phase to continue since the exemption is now in place.  We were too late?

      Thanks