Enhancements Part 10: Enhancements in S/4HANA and Clean Core

📌 KEY POINTS
✅ Clean core = keep SAP code unchanged and extend only through released, upgrade-stable interfaces.
✅ Three extension styles: key user (in-app, Fiori apps for custom fields and logic), developer extensibility (ABAP Cloud with released BAdIs/APIs), side-by-side (SAP BTP).
✅ Classic user exits, customer exits and implicit enhancements still work in S/4HANA on-premise/private cloud, but they are not clean core.
⚠️ In S/4HANA Cloud public edition, only released extension points are available — no classic exits or modifications.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–9 covered the classic toolbox. Most customers run existing ECC enhancements in S/4HANA and must decide what to keep, move or remove.

━━━━━━━━━━━━━━━━━━━━
▶ 1. KEY USER EXTENSIBILITY

• Custom Fields app — add fields to business contexts (e.g. sales order header) including UI, OData, CDS and some forms.
• Custom Logic app — implement released BAdIs in a restricted ABAP in the browser (e.g. field validation, defaults).
• Suitable for simple rules; managed and upgrade-stable.

━━━━━━━━━━━━━━━━━━━━
▶ 2. DEVELOPER EXTENSIBILITY (ABAP CLOUD)

• Develop in ADT with ABAP language version "ABAP for Cloud Development".
• Only released objects (C1 contract): released BAdIs, CDS views, classes.
• New BAdIs for S/4HANA processes (e.g. sales document checks) are released for cloud development.

━━━━━━━━━━━━━━━━━━━━
▶ 3. SIDE-BY-SIDE
Separate apps on SAP BTP using released APIs/events — for new processes that don't need to run inside the transaction.

━━━━━━━━━━━━━━━━━━━━
▶ 4. EXISTING ENHANCEMENTS IN A CONVERSION

• Custom code migration (ATC with S/4HANA checks) shows affected code (simplification items, changed tables).
• Classify each enhancement: still needed? replaced by standard? replaceable by a released BAdI or key user extension?
• Tier model (on-premise/private cloud): tier 1 ABAP Cloud, tier 2 wrappers for unreleased APIs, tier 3 classic (user exits, implicit enhancements, modifications) — to be reduced over time.

━━━━━━━━━━━━━━━━━━━━
▶ 5. PRACTICAL RULES FOR NEW REQUIREMENTS

1. Standard or configuration?
2. Key user extensibility?
3. Released BAdI with developer extensibility?
4. Side-by-side?
5. Only then classic exits (tier 3), documented with a plan to replace.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. Open the Custom Fields app (or its documentation) and see which business contexts exist for sales orders.
2. In ADT, search released BAdIs for your area (e.g. filter by API state "Released").
3. Classify three of your system's enhancements into tier 1/2/3 and suggest the target.

✅ CHECKPOINT: you can apply clean core rules to new and existing enhancements.

During an ECC to S/4HANA conversion, a company had 180 enhancements. The team classified them: 45 were obsolete (standard now covered the need), 60 moved to key user custom fields and custom logic or released BAdIs, 50 remained in tier 3 with documented replacement plans, and 25 stayed as tier 2 wrappers.
For every new requirement after go-live, the architecture board required the clean core decision sequence, which stopped the growth of new implicit enhancements.

• Converting all old exits 1:1 without checking if standard covers them.
• Using unreleased objects in ABAP Cloud code.
• Assuming classic exits exist in S/4HANA Cloud public edition.
• Ignoring ATC custom code migration results.
• No plan to reduce tier 3 enhancements.

• Follow the decision order: standard → key user → released BAdI → side-by-side → classic.
• Classify existing enhancements into tiers with targets.
• Use ATC with cloud readiness checks.
• Wrap unreleased functionality in tier 2 classes.
• Keep an enhancement register with owners.

Questions: "What is clean core?", "How do you extend S/4HANA?", "What happens to user exits in S/4HANA?"
Strong answer: extend only via released interfaces; key user extensibility (custom fields/logic), developer extensibility in ABAP Cloud with released BAdIs/APIs, side-by-side on BTP; classic exits/implicit enhancements work on-premise/private cloud (tier 3) but should be reduced; public cloud allows only released extension points; classify existing enhancements with ATC.