Enhancements in S/4HANA and Clean Core

Explanation

In S/4HANA, enhancement strategy should align with clean core. Clean core means minimizing risky modifications and using released extension options where possible. Depending on scenario, this can include key-user extensibility, developer extensibility, released BAdIs, APIs, CDS extensions, RAP behavior extensions or side-by-side extensions on BTP. Classical implicit enhancements may still exist in on-premise systems, but they should be carefully reviewed for upgrade impact. A senior consultant should not blindly apply ECC-style enhancements in S/4HANA without checking released extensibility and upgrade-safe options.

Code example

* Clean-core decision thinking* 1. Check if requirement can be solved by configuration* 2. Check key-user extensibility or custom fields/logic* 3. Check released BAdI or extension point* 4. Check released API/CDS/RAP extension option* 5. Use source-code enhancement only after technical review * Goal:* Keep the core upgrade-safe and reduce custom code risk.

Real project scenario

A customer wants to add a custom validation in S/4HANA sales process. Instead of directly adding an implicit enhancement, the team checks released BAdIs, in-app extensibility and available APIs before deciding the solution.

Common mistakes

- Using ECC-style implicit enhancements without clean-core review. - Ignoring released BAdIs and APIs. - Building source-code dependency on unreleased objects. - Not documenting upgrade risk.

Best practices

- Check released extensibility options first. - Avoid unreleased object dependency where possible. - Document clean-core decision. - Review custom enhancements during upgrade planning.

Interview angle

For S/4HANA interviews, explain clean-core preference: released extensibility first, source-code enhancement only when justified.