Why a program with a classic screen stops at Level B
Level A requires ABAP Cloud, and ABAP Cloud does not accept SAP GUI screens. What this means for Z reports and transactions, and when it is worth going all the way to A.
Those starting a Clean Core adaptation are often surprised by one detail of the SAP Cloud ALM dashboard: a Z report that has been fully fixed, with no findings left, is still at Level B. This is not a measurement error. It is a rule, and understanding that rule changes the way the work is planned.
Level A requires ABAP Cloud
An object in Standard ABAP, even without any findings, shows up as Level B. To reach A, it must be in the ABAP Cloud language version, which only allows APIs released by SAP. The conversion is a separate step of the work: besides bringing the debt to zero, everything ABAP Cloud does not accept has to be removed, even if it does not count as debt.
What ABAP Cloud does not accept
ABAP Cloud was born in the public cloud, where SAP updates every customer's system without testing each customer's code. That is why it is much more than "using only released APIs": it is a lean version of the language, in which whatever does not exist simply does not activate. The main differences:
| Area | In classic ABAP | In ABAP Cloud |
|---|---|---|
| User interface | Dynpro, selection screen, lists with WRITE, ALV, GUI status |
Fiori on top of RAP, with an OData service. Development is in ADT only, without SAP GUI |
| Programs | REPORT, INCLUDE, module pool, SUBMIT, CALL TRANSACTION |
Only classes, interfaces and function groups. Background processing becomes an application job |
| SAP objects | Any | Only released ones: an SAP table gives way to the released CDS view, and a BAPI to the successor RAP interface, when there is one |
| Files | OPEN DATASET, upload and download through SAP GUI |
No access to the application server file system |
| Database | Native SQL (EXEC SQL), cursors, access to another client |
ABAP SQL and AMDP, always in the current client only |
| Transactions | Update task, PERFORM ON COMMIT |
Updates are always local. Inside RAP, the framework itself commits the save |
| Parallel processing | STARTING NEW TASK, tRFC |
Released frameworks: CL_ABAP_PARALLEL and the Background Processing Framework |
| Enhancements | User exit, implicit or explicit enhancement, modification | Only released BAdIs |
| Technical services | Classic function modules for logging, number ranges, email and locking; Smart Forms and SAPscript; SM59 destinations | Released APIs for each service, Adobe Forms and communication scenarios |
| Language | Macros, header lines, MOVE, DESCRIBE and other obsolete statements |
No macros and no obsolete statements. Messages only through exceptions, RAP or the application log |
And what is often said to be forbidden, but is not: creating and calling custom function modules, synchronous RFC, COMMIT WORK outside RAP, AMDP, dynamic programming (with the release check done at runtime), AUTHORITY-CHECK, and reading and writing the company's own custom tables.
For a program with a classic (SAP GUI) screen, the first row of the table already settles it: it cannot be ABAP Cloud. So the best it can reach is Level B. Taking it to A means rebuilding the user interface in Fiori, which is a separate project.
The complete list, with the statements in each area and what replaces each of them, is in ABAP Cloud: what changes compared to classic ABAP.
A and B are not the same thing
Both levels are on the side accepted by Clean Core. The difference lies in who guarantees it:
| Level B (Standard ABAP) | Level A (ABAP Cloud) | |
|---|---|---|
| Stability | In practice: a BAPI almost never changes, but SAP makes no formal commitment | By contract: a released object only changes with notice and a designated successor |
| Who guarantees it | The ATC, when it is run | The system itself: code with non-released usage is not activated |
| Can it get worse later | Yes: a future change may read an SAP table again | No: the syntax check rejects it |
| Where it works | SAP S/4HANA on-premise and Private Edition | The same model applies in all editions; the code goes wherever the same APIs are released, such as Public Edition |
How far each object can go
Before promising a level, it is worth classifying each object:
| Object type | How to recognize it | How far it can go |
|---|---|---|
| Classic by nature | Has a screen: selection screen, dynpro, WRITE or ALV list |
B |
| Convertible to ABAP Cloud | Has no screen: business rule classes, calculation function modules, interfaces | A, if every SAP usage has a released alternative or a wrapper |
In an object that is classic by nature, replacing a B finding with a released API reduces the debt, but the level stays B. Classic statements that do not generate findings, such as FORM, WRITE and screens, can stay as they are: they change neither the debt nor the level.
So is it worth working on a program with a screen?
Yes, very much so. The real risk in an upgrade lies in C and D findings: direct reads of SAP tables, which SAP treats as internal, and usage outside Clean Core, which may break when SAP changes the system. An object with no C or D findings already eliminates almost all of that risk, and that is what the dashboard shows as a gain in the score.
Level A pays off where the code will keep evolving: shared business rules, wrappers and new development. In those cases, the guarantee that the code will not get worse again pays for the conversion. To understand how these points enter the dashboard calculation, read How SAP Cloud ALM calculates Clean Core debt.
Sources
- SAP Help, ABAP Keyword Documentation, Language Elements in ABAP Versions (S/4HANA 2025) and the ABAP for Cloud Development documentation.
- SAP Community, ABAP Cloud FAQ.
- Thomas Schneider (SAP), ABAP Language Versions – FAQs, SAP Community.
- SAP, Cloudification Repository (GitHub SAP/abap-atc-cr-cv-s4hc), with the released successors of classic objects.