Lesson 3 of 5
Running and interpreting the Simplification Item Check
11 min
Listen to this lesson
The Simplification Item Check (SI check) is a report in the source system, /SDF/RC_START_CHECK, with a check framework behind it. It does two things: a relevance check that determines which items probably apply, and a consistency check that finds data inconsistencies or missing mandatory preparation that would make the conversion fail. It is mandatory: Software Update Manager (SUM) runs it again during the conversion.
Implementing it
- SAP Note 2399707 delivers the check report and framework; SAP Note 2502552 delivers the application check classes through transport-based correction instructions (TCI).
- Enable TCI first if your release needs it (SAP Note 2187425 or the guided steps in 2836302); the Conversion Guide lists releases where TCI is already enabled.
- Follow the steps in SAP Note 2502552 exactly; implementing it like a normal note without TCI enablement leads to missing check class errors.
- Implement in development and transport onward, like any correction.
Running it
Start the report in transaction SA38, choose the target SAP S/4HANA version under the check options, and run online or as a background job. The relevance check runs automatically; consistency checks start only when you choose Check Consistency for All. Make sure the target stack is right: results depend on it, and the report preselects the latest one. Run it in client 000, because that is where SUM runs it and only there do the checks cover data in all clients.
| Return code | Color | Meaning | What to do |
|---|---|---|---|
| 0 | Green | No inconsistencies | Nothing |
| 4 | Yellow | Warning or information; no technical problem for the conversion | Read carefully; there may be data changes or tasks after conversion |
| 7 | Red | Skippable error: confirm you have read and understood it | Exempt after understanding the impact, or fix |
| 8 or 12 | Red | Inconsistency that blocks later SUM phases | Fix before conversion |
SI check message severities, as described in the Conversion Guide for SAP S/4HANA 2025.
Do not underestimate yellow messages. The Conversion Guide gives an example: by default no custom table appends are retained during the conversion, so the data in those fields is lost. A yellow message can carry that kind of news.
- EarlyManual runsRelevance and consistency in each system (sandbox, ED1, EQ1, EP1) to build the cleanup list
- During prepDetailed checks"Check Consistency Details" per item to build work lists; re-run after each fix
- SUM startFirst SUM runPhase RUN_S4H_SIF_CHECK_INIT; SUM stops only for return code 12
- Before downtimeSecond SUM runPhase RUN_S4H_SIF_CHECK_EXEC; SUM stops for return code 8 or higher, including unexempted 7
Run the check manually in every system you will convert: sandbox, development, quality and production. SUM runs it in each of them anyway, and results differ because data, usage and active business functions differ. A clean result in development says little about production.
Worked example: reading Contoso's EP1 results
Sam runs the check in client 000 of a fresh EP1 copy with target SAP S/4HANA 2025. The relevance check marks the items it expects to apply; the quick consistency run returns a code per item. Part of the result list looks like this (illustrative course data):
| Item | Return code | What Sam sees | Next step |
|---|---|---|---|
| Business Partner Approach | 12 | Customers and suppliers without a business partner | CVI synchronization in the pre-project (lesson 4) |
| Storage Location MRP | 7 | Plant 1710 uses storage location MRP; settings will not be carried over as they are | Decide MRP areas for 171S and 171L; run the migration report the note requires |
| SD status tables | 4 | Custom append found on VBUK | Kenji moves the fields before conversion |
| Material ledger | 0 | No inconsistencies | Nothing; keep re-running |
| Inventory management | 8 | Inconsistent stock records for archived materials | Correction report per the item's note, then detailed re-run |
Part of a quick consistency run on an EP1 copy (illustrative; codes depend on the item and check version). Red codes become work; yellow ones still get read.
Quick and detailed modes
Check Consistency for All runs a quick mode that looks for blockers and may stop after the first issues per item. For a full work list, select items and run Check Consistency Details. After fixing an issue, re-run the detailed check for that item to see the updated result; the overview does not refresh by itself. Report /SDF/RC_TROUBLE_SHOOT can re-run individual checks in the background.
- Different results in EQ1 and EP1?Expected: systems differ in data, usage and active business functions · Check each system on its own
- Fewer relevant items in a production copy?Likely missing usage statistics in the copy; SAP Note 2568736 offers a report to copy them
- New errors after a re-run?Newer check content or ongoing operations; review before assuming a regression
- Red RC 12 with "check class missing"?A required note is not implemented; see the log for which one
What would you do?
Sam ran the SI check in client 100 of EQ1 and found no consistency errors. He proposes reporting "SI check clean" to the steering committee. What is the problem?
- Report /SDF/RC_START_CHECK: notes 2399707 (framework) and 2502552 (check classes via TCI).
- Relevance runs automatically; start consistency with Check Consistency for All; run in client 000.
- Return codes: 4 read, 7 exempt or fix, 8 and 12 fix.
- SUM runs it twice and is stricter just before downtime.
- Re-run the check in every cycle and in the final week on EP1; production keeps creating new data.
Check your understanding · not graded
Lesson check
1. Which note delivers the SI check classes via TCI?
2. Which return code marks an error that can be exempted?
3. In which client should the consistency checks run?
4. When does SUM stop for an unexempted return code 7?
5. The SI check was clean in an EP1 copy, but new errors appear in EP1 a week before go-live. What is the most likely cause?