Prerequisite: SAP Enhancements

Introduction

Customer Exits are one of the most important enhancement techniques every ABAP consultant must understand—especially when working with legacy SAP systems or supporting long-running productive landscapes.

Even though SAP now prefers BADIs, customer exits are still:

• Actively used

• Heavily tested in interviews

• Critical for understanding SAP’s enhancement evolution

This blog explains customer exits end-to-end.

What Is a Customer Exit?

A Customer Exit is a SAP-provided enhancement that allows customers to add their own logic at predefined points in standard SAP processing.

Key characteristics:

• No modification of standard code

• Logic written in customer includes

• Controlled using enhancement projects

Customer exits are implemented using function modules, not direct code changes.

What Can Be Enhanced Using Customer Exits?

Customer exits allow three types of enhancements:

1. Function Exits

Used for:

• Validations

• Checks

• Conditional business rules

Example:

• Making a field mandatory based on country or company code.

To gain a detailed understanding of Function Exit, please refer to the following blog.

2. Screen Exits

Used for:

• Adding additional fields

• Displaying customer-specific data

Important:

• SAP provides a subscreen area

• Developer creates a subscreen

• Table enhancement is mandatory

To gain a detailed understanding of Screen Exit, please refer to the following blog.

3. Menu Exits

Used for:

• Adding extra menu options

• Plugging custom actions into SAP menus

Restrictions:

• Only predefined menu locations

• Cannot add menus arbitrarily

To gain a detailed understanding of Menu Exit, please refer to the following blog.

Tools Used in Customer Exits

Two transactions are mandatory:

Transaction Purpose

SMOD Display exit components & documentation

CMOD Implement and control the exit

Without CMOD, customer exits will never trigger.

Customer Exit Identification – The Real Skill

Most beginners think coding is the hard part.

Reality: 90% of the work is identifying the correct exit.

Identification steps

1. Find transaction main program

2. Identify its package

3. Search exits using SE84

4. Analyze documentation and components

5. Match exit purpose with requirement

Coding is usually just a few lines.

How Customer Exit Implementation Works

1. Create CMOD project

2. Assign enhancement

3. Open exit components

4. Write logic in Z-include

5. Activate:

o Include

o Function module

o CMOD project

Missing any activation = exit does not work.

When Are Customer Exits Triggered?

SAP controls the trigger point.

Depending on exit type:

• SAVE action

• Screen load

• Menu click

• Navigation events

Developers cannot change trigger timing.

Major Limitation of Customer Exits 🚨

❌ Only one implementation allowed

Meaning:

• One exit → one project

• Cannot split logic

• Cannot selectively activate functionality

Activate project → all logic active

Deactivate project → everything inactive

No fine-grained control.

Real-Life Problem Example

Suppose business wants:

• Winter logic → 10% discount

• Summer logic → 15% discount

• Monsoon logic → 8% discount

With Customer Exit:

❌ Either all active

❌ Or none active

This is the biggest reason SAP moved to BAdIs.

Customer Exits vs BAdIs

Feature Customer Exit BAdI

Multiple implementations ❌ ✅

Switchable logic ❌ ✅

Flexibility Low High

Programming style Procedural Object-Oriented

Upgrade Safety Limited Better

SAP recommendation Legacy Preferred

Golden Rule: If both Customer Exit and BAdI exist → ALWAYS choose BAdI.

Conclusion

Use customer exits when:

• Maintaining legacy ECC systems

• Enhancing old transactions

• No BAdI or enhancement point exists

• Supporting existing customer logic

Avoid customer exits for:

• New developments

• S/4HANA greenfield projects