Enhancements Part 7: Implicit Enhancements — Power and Risk

📌 KEY POINTS
✅ Implicit enhancements let you add code at the start/end of almost any FORM, FM or method — even where SAP planned no extension.
✅ For global class methods: pre-exit, post-exit and overwrite-exit methods.
✅ Powerful, but they depend on SAP's internal code, which can change in any support package.
⚠️ An overwrite exit or an implicit enhancement in a core SAP routine can silently break standard behaviour — treat it like a modification.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 3 introduced implicit options. This lesson shows how to use them — and when not to.

━━━━━━━━━━━━━━━━━━━━
▶ 1. WHERE THEY ARE

• Start and end of FORM routines and function modules.
• Start and end of methods; for global classes as separate pre/post/overwrite methods.
• End of includes and programs; end of structure definitions and class sections.
• Additional optional parameters for FMs and methods.

━━━━━━━━━━━━━━━━━━━━
▶ 2. IMPLEMENTING (FORM / FM)
Editor → Enhance → Edit → Enhancement Operations → Show Implicit Enhancement Options → cursor on the marker line → Create Implementation → Code. Your code sees the FORM/FM's parameters and global data of the program at that point.

━━━━━━━━━━━━━━━━━━━━
▶ 3. IMPLEMENTING (CLASS METHODS)
SE24/SE80 → Enhance → Insert pre-method / post-method / overwrite-method.

• Pre: runs before; gets importing parameters.
• Post: runs after; can change exporting/changing/returning parameters.
• Overwrite: replaces the whole method — you own it completely.

Access to private attributes goes through CORE_OBJECT (only public components unless the enhancement class gets special access in newer releases).

━━━━━━━━━━━━━━━━━━━━
▶ 4. RISKS

• Internal code and variable names may change in support packages → syntax errors or wrong behaviour.
• Invisible to functional teams; hard to find when debugging (look for ENHANCEMENT blocks).
• Runs in every path using that FORM/FM — including background, BAPIs and other transactions.
• Performance: code in frequently called routines runs millions of times.

━━━━━━━━━━━━━━━━━━━━
▶ 5. APPROVAL CHECKLIST

1. No BAdI, exit, BTE or explicit point fits? (documented search)
2. Code is minimal and calls a class?
3. Guarded by conditions (program, transaction, org unit)?
4. Tested in all processing paths?
5. Registered with owner and regression test for upgrades?

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

1. In a sandbox, add an implicit enhancement at the end of a Z function module copy and log its call.
2. Add a post-method to a Z class method and change its returning value.
3. Write the checklist answers for a real implicit enhancement in your system.

✅ CHECKPOINT: you can implement implicit enhancements and decide when they are justified.

A project added an implicit enhancement at the end of a pricing-related function module to round prices for one customer group. After a support package, SAP renamed an internal variable used in the enhancement; the program got a syntax error and order entry stopped in production for 40 minutes until the enhancement was deactivated.
The team moved the rounding to a pricing routine (VOFM) intended for such logic, and introduced an approval checklist and regression tests for all remaining implicit enhancements.

• Using internal SAP variables that may change.
• Overwrite methods replacing complete SAP logic.
• No guard conditions — code runs in unrelated transactions.
• No documentation, so nobody finds the logic when debugging.
• Skipping regression tests after support packages.

• Search and document alternatives first.
• Keep code minimal, guarded and delegated to classes.
• Prefer post-exits over overwrite exits.
• Register every implicit enhancement with owner and tests.
• Include them in upgrade and support package test plans.

Questions: "What are implicit enhancements and when do you use them?", "Pre/post/overwrite methods?", "Risks?"
Strong answer: implicit options at start/end of FORMs/FMs/methods, end of includes, extra parameters; for classes pre-, post- and overwrite-exits via CORE_OBJECT; they depend on SAP internals, run in all paths, are hidden and may break in upgrades; use only when no BAdI/exit/explicit point exists, keep minimal and guarded, document and regression-test.