S/4HANA Clean Core Code Check

A snippet is enough — the scanner looks for object names and statement patterns, not a complete program.

Most remediation work in a conversion comes back to a short list of data-model changes. These are the ones that appear in nearly every custom-code assessment.

Many removed tables still answer a SELECT, because SAP ships a compatibility view with the old name and the old fields. That is deliberate: it keeps a system running through a conversion instead of producing thousands of syntax errors on day one. It is not a destination.

A compatibility view reads from the new model and reshapes the result on the fly. Reading it once in a report is unremarkable. Reading it inside a loop, or joining it to three other tables, turns a cheap query into an aggregation that runs every time. This is the usual explanation when a program that behaved fine in the sandbox becomes unusable under production volume after go-live. The view also cannot be written to, so any code that modified the old table has to be rewritten regardless.

The two clear-cut cases are inventory and pricing. Stock quantities are no longer stored as aggregates — every read recomputes them from the material document, which is exactly why a nightly job that reads stock per material in a loop can go from minutes to hours. And pricing conditions moved out of a cluster table into a transparent one, so the access pattern, not just the table name, has to change.

The material number can be extended to forty characters. Code that declares a local field as character eighteen, or takes an offset of a key field, does not produce a finding that looks urgent — until the extension is switched on and the field either truncates silently or the program short dumps. Silent truncation is worse than the dump, because it writes wrong data that looks plausible.

The remediation is mechanical and worth doing early: declare with the dictionary type rather than a literal length, and remove character arithmetic on key fields. Anything that builds a concatenated key by position has to be rewritten around the actual field.

Clean core is often heard as a demand to delete custom code. In practice it asks a narrower question: is this extension attached to SAP through something SAP has released and will keep stable, or is it attached to something internal that will move. Reading a released CDS view is clean. Calling a released API is clean. Modifying standard code, writing to a standard table, or automating a screen is not, because all three break the moment SAP changes something it never promised to keep.

That framing makes the work tractable. Most custom programs do not need to be deleted or rebuilt as side-by-side extensions; they need their data access moved onto released objects and their writes moved onto APIs. What genuinely has no released path is worth recording as a gap rather than solving with a modification, because the gap is what you take to SAP or to a side-by-side design later.

The S/4HANA migration simulator works real conversion decisions on customer-vendor integration, compatibility views and clean core. The readiness check covers the project side, and the S/4HANA change library documents individual simplifications. For practice, there is Code Lab and the ABAP on HANA question bank.