SAP ABAP Enhancement Framework — User Exits, BADIs, and Enhancement Points

Every SAP project I’ve worked on has had this conversation within the first two weeks.

The business analyst walks into the room and says: “When a user saves a Purchase Order in ME21N, we need to automatically check if the vendor’s trade license has expired. If it has, block the PO and show an error.”

Standard SAP does not perform this check. SAP’s code does not know about your company’s custom trade license table. So you need to inject your custom logic into SAP’s standard transaction.

There are two approaches: Modification and Enhancement.

Modification means directly editing SAP’s source code. This is almost always the wrong approach. When SAP releases an upgrade or support pack, their code overwrites your changes. You lose your custom logic. Your Basis team then spends weeks resolving modification conflicts during every upgrade cycle.

Enhancement means inserting your custom logic into predefined hooks (exit points) that SAP deliberately left in their programs. Your code runs at the right moment during the standard transaction, but it lives in a separate object. SAP’s original source code remains untouched. Upgrades don’t overwrite your work.

This guide covers every enhancement technique in ABAP, from the oldest (User Exits) to the newest (BAdIs and Enhancement Spots).

---

Evolution of ABAP Enhancements

SAP didn’t build one enhancement mechanism and stop. They evolved the approach over 25 years across multiple releases:

1990s              Early 2000s           2004+                  2006+
┌──────────┐     ┌───────────────┐    ┌──────────────────┐   ┌────────────────────┐
│ User Exits│────►│ Customer Exits│───►│ Classic BAdIs    │──►│ New BAdIs          │
│ (USEREXIT)│     │ (CMOD/SMOD)  │    │ (SE18/SE19)      │   │ (Enhancement Spots)│
└──────────┘     └───────────────┘    └──────────────────┘   └────────────────────┘
         Oldest                                                        Newest

Each generation improved on the last. But all generations still exist in live S/4HANA systems today, so you need to understand all of them.

---

1. User Exits (the oldest approach)

User Exits are empty ABAP subroutines (FORMs) that SAP placed inside standard programs during the R/3 era.

They follow a naming pattern like:

FORM USEREXIT_SAVE_DOCUMENT_PREPARE.
  " Your custom code goes here
ENDFORM.

SAP’s standard program calls this FORM at a specific point (e.g., right before saving a document). The subroutine body is empty by default. You add your custom validation or data manipulation code inside it.

How to find User Exits

1. Open the standard program in transaction SE38 (e.g., the include programs for transaction ME21N).
2. Search for USEREXIT using Ctrl+F.
3. You’ll find subroutines like USEREXIT_SAVE_DOCUMENT_PREPARE, USEREXIT_FIELD_MODIFICATION, etc.

The problem with User Exits

User Exits require you to edit SAP’s standard include program directly. Technically, this counts as a modification. The include belongs to SAP’s namespace. During system upgrades, SAP might deliver a new version of that include, and your changes could conflict.

Because of this drawback, SAP introduced a cleaner mechanism: Customer Exits.

---

2. Customer Exits (SMOD / CMOD)

Customer Exits separate your custom code into a dedicated container that SAP upgrades never touch.

SAP creates Exit components (function module exits, screen exits, menu exits) and packages them inside an Enhancement defined in transaction SMOD.

You activate these exits by creating a Project in transaction CMOD.

Architecture

SAP Standard Code                    Your Custom Code
─────────────────                    ─────────────────
CALL CUSTOMER-FUNCTION '001'  ──►    INCLUDE ZXM06U01
  (Inside ME21N standard code)         ├─ Your custom ABAP logic
                                       └─ Completely separate namespace

Step-by-step: Implementing a Customer Exit

Step 1: Find the Enhancement

You need to discover which SAP Enhancement contains exit points for your transaction.

Go to the standard transaction (e.g., ME21N). In the menu: System → Status. Note the program name (e.g., SAPLMEPO). Then search SMOD for enhancements linked to that package.

Or use a shortcut: Transaction SMOD, click Utilities → Find, enter the program or package name.

For ME21N, you’ll find enhancements like MM06E005, MM06E004, MM06E003.

Step 2: Examine the Enhancement in SMOD

Open transaction SMOD. Enter MM06E005. Click Display.

You’ll see component exits like:

EXIT_SAPMM06E_012  (Function Module Exit — Save document check)
EXIT_SAPMM06E_013  (Function Module Exit — Data enrichment)

Step 3: Create a Project in CMOD

Open transaction CMOD. Enter a project name (e.g., ZME21N_VENDOR_CHECK). Click Create.

In the project, add your Enhancement (MM06E005). Double-click the function module exit (e.g., EXIT_SAPMM06E_012).

Inside the function module, you’ll find an INCLUDE statement like INCLUDE ZXM06U12. Double-click it to create the include and write your custom code:

*----------------------------------------------------------------------
* INCLUDE ZXM06U12 — Custom Vendor License Check for ME21N
*----------------------------------------------------------------------

DATA: lv_license_expiry TYPE dats.

" Check vendor trade license from custom table
SELECT SINGLE license_expiry
  FROM ztrade_license
  INTO lv_license_expiry
  WHERE lifnr = i_ekko-lifnr.

IF sy-subrc = 0 AND lv_license_expiry < sy-datum.
  MESSAGE e001(z_mm_msg) WITH i_ekko-lifnr.
  " Error message blocks PO save
ENDIF.

Step 4: Activate the Project

Back in CMOD, click Activate on your project. The customer exit is now live.

---

3. Classic BAdIs (Business Add-Ins) — SE18 / SE19

Customer Exits had a limitation: only one implementation per exit across the entire system. If two separate development teams needed the same exit point, they had to share one include file — leading to merge conflicts.

SAP introduced BAdIs (Business Add-Ins) to solve this. BAdIs are based on ABAP Objects (interfaces and classes) instead of function modules.

Key advantages of BAdIs over Customer Exits

• Multiple implementations: Multiple BAdI implementations can be active simultaneously.
• Filter-dependent: Implementations can be filtered by criteria (e.g., only trigger for Plant 1000, ignore Plant 2000).
• Object-oriented: BAdIs use interfaces and classes instead of procedural function modules.

Architecture

SAP Standard Code                                 Your Custom Code
─────────────────                                  ─────────────────
GET BADI lo_badi.                                 CLASS ZCL_IM_VENDOR_CHECK
CALL BADI lo_badi->check_document( ... ).  ──►      METHOD if_ex_me_process_po~check
                                                       " Your custom validation logic
                                                     ENDMETHOD.

Step-by-step: Implementing a Classic BAdI

Step 1: Find the BAdI Definition

Transaction SE18 — BAdI Definition browser.

Enter a BAdI name (e.g., ME_PROCESS_PO for Purchase Order processing). Click Display.

You’ll see:

• The Interface (e.g., IF_EX_ME_PROCESS_PO) defining available methods.
• Methods like CHECK, FIELDSELECTION_ITEM, PROCESS_HEADER.

Step 2: Create a BAdI Implementation

Transaction SE19 — BAdI Implementation.

1. Click Create Implementation.
2. Enter the BAdI Definition name: ME_PROCESS_PO.
3. Enter your implementation name: ZIM_VENDOR_LICENSE_CHECK.
4. SE19 generates a class implementing the interface.
5. Double-click the method you want to customize (e.g., CHECK).
6. Write your ABAP code inside the method.

METHOD if_ex_me_process_po~check.
  " Custom vendor license validation during PO save
  DATA: lv_expiry TYPE dats.

  SELECT SINGLE license_expiry
    FROM ztrade_license
    INTO lv_expiry
    WHERE lifnr = im_header-lifnr.

  IF sy-subrc = 0 AND lv_expiry < sy-datum.
    " Add error message to the message collector
    CALL METHOD im_message_handler->add_message
      EXPORTING
        iv_message = 'Vendor trade license has expired'
        iv_msgty   = 'E'.
  ENDIF.
ENDMETHOD.

Step 3: Activate

Activate the implementation. Your custom check now fires during every PO save in ME21N.

---

4. New BAdIs (Enhancement Spot Framework) — Post 2006

Starting with EHP releases, SAP introduced the Enhancement Spot Framework. This is the modern architecture and the recommended approach for all new development.

Key concepts

• Enhancement Spot: A container that groups related BAdI definitions.
• Enhancement Implementation: A container for your custom BAdI implementations.
• Fallback Class: A default implementation SAP provides if no custom implementation is active.

Finding New BAdIs

In Eclipse ADT, right-click on any standard ABAP code line and select Show Enhancement Options. Eclipse highlights all available enhancement spots and BAdIs in the current program.

In SAP GUI, use transaction SE18 or search table SXS_ATTR for BAdI definitions related to a specific program or package.

---

5. Implicit and Explicit Enhancement Points

The newest enhancement technique doesn’t require SAP to pre-define any exit point. You can inject custom code at almost any line in any standard SAP program.

Explicit Enhancement Points

SAP marks specific locations in standard programs with ENHANCEMENT-POINT statements:

" SAP's standard code:
ENHANCEMENT-POINT ep_before_save SPOTS es_purchase_order.
" Your code can be injected here

You create an Enhancement Implementation in SE18/SE19 that targets this specific point.

Implicit Enhancement Points

Even if SAP didn’t place an explicit ENHANCEMENT-POINT, every ABAP program automatically has implicit enhancement points at:

• The very beginning of any include/program
• The very end of any include/program
• Before and after every FORM routine
• Before and after every method

To use an implicit enhancement:

1. Open the standard program in SE38 or SE80.
2. Go to Edit → Enhancement Operations → Show Implicit Enhancement Options.
3. Gray enhancement icons appear at the beginning and end of includes.
4. Right-click → Create Enhancement Implementation.
5. Write your code.

" Implicit enhancement at end of an SAP include:
ENHANCEMENT 1 ZEN_VENDOR_CHECK.
  " Custom code injected here — SAP never touches this block during upgrades
  IF lv_vendor_blocked = abap_true.
    MESSAGE e099(z_custom) WITH lv_vendor_id.
  ENDIF.
ENDENHANCEMENT.

Warning about Implicit Enhancements

Implicit enhancements are powerful but risky. You can inject code virtually anywhere in SAP’s standard programs. If you inject code in the wrong place (e.g., inside a tight database loop), you can cause severe performance degradation across the entire system. Use implicit enhancements only when no BAdI or Customer Exit exists for your use case.

---

Decision Matrix: Which Enhancement to Use

Scenario	Recommended Approach
BAdI exists for your use case	New BAdI Implementation (SE18/SE19)
No BAdI, but Customer Exit exists	Customer Exit (SMOD/CMOD)
No BAdI, no Customer Exit, explicit point exists	Explicit Enhancement Point
Absolutely no exit point exists	Implicit Enhancement (last resort)
You need to add a screen field to a standard screen	Screen Exit (via Customer Exit project)
You need to add a menu item to a standard transaction	Menu Exit (via Customer Exit project)

---

Quick checkpoint

Question 1: What is the fundamental difference between a Modification and an Enhancement in SAP?

Answer: A Modification directly edits SAP’s source code (gets overwritten during upgrades). An Enhancement injects custom code into predefined hooks while leaving SAP’s original source untouched (survives upgrades).

Question 2: Which transactions are used to define and implement Classic BAdIs?

Answer: SE18 (BAdI Definition) and SE19 (BAdI Implementation).

Question 3: Where do implicit enhancement points automatically exist in every ABAP program?

Answer: At the beginning and end of every include/program, and before and after every FORM routine and method.

---

Common mistakes

Mistake 1: Using modifications when enhancements exist. Always search for BAdIs, Customer Exits, and Enhancement Points before modifying standard SAP code. Modifications create upgrade nightmares.

Mistake 2: Not deactivating old Customer Exit implementations. If you migrate from a Customer Exit to a new BAdI for the same logic, remember to deactivate the old CMOD project. Running both simultaneously causes duplicate processing.

Mistake 3: Heavy database operations inside enhancement code. Your enhancement code runs inside SAP’s standard processing flow. If you add a SELECT statement that scans a million-row table without proper WHERE conditions, you slow down the standard transaction for every user in the system.

Mistake 4: Not documenting your enhancements. Six months from now, nobody will remember which BAdI implementation controls the vendor license check. Maintain a central tracking document or custom table listing all active enhancements, their purpose, and the responsible developer.

---

Related reads on this site:

• ABAP OOP — Classes, Methods, and Interfaces — OOP concepts used by BAdIs
• Function Modules in ABAP — understanding Customer Exit function modules
• SAP ABAP Debugging Guide — debugging enhancement implementations at runtime