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

[markus_goebel]

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
May 30th 2022	- Added information on SAP S/4HANA 2021 FPS 1 + 2.
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.

Please refer to SAP note 2399707 for the list of minimum note versions for each SAP S/4HANA release and feature package to which a system conversion is supported. (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

• NEW: Customer Vendor Integration Analysis (CVIA) check in SAP Readiness Check


• CVI Cookbook

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.