Вы находитесь на странице: 1из 8


Enhancement Types
Enhancement types in SAP:
Customer Enhancements (CMOD/SMOD)
BADI (SE18/SE19)

1.1 Customer Enhancements (CMOD/SMOD)

3 types customer enhancement:
Function Module Exit
Menu Exit
Customer Exit Subscreen

The main draw back of customer exits is they do not comply with publish-and-subscribe (P&S) paradigm.
This means you can only define a single include for the whole logic.

1.1.1 Function Module Exit

Called in SAP in the form CALL CUSTOMER-FUNCTION NNN statement, where NNN is a number suffix.
And converted into function module EXIT_<PROGRAM NAME>_NNN where <PROGRAM NAME> is the
name currently running main program. For example, the statement call function CALL CUSTOMER-
FUNCTION '001' in program SAPMM06E is converted into CALL FUNCTION 'EXIT_SAPMM06E_001'.

1.1.2 Menu Exit

Menu exits are hidden function codes included in SAP GUI statuses of SAP standard program. The
function codes start with "+". For example, SAP enhancement CATS001 includes several function codes:
+CU2, +CU3, +CU4. You can assign icon and texts to the menu entry.
The enhancement should include a customer function module component where you implement the
customer function code processing logic.

1.1.3 Customer Exit Subscreen

Included in function module exit, for example, enhancement CATS0012 (in screen areas).

1.1.4 Finding Customer Enhancements

Using workbench information system or the F4 search help in transaction SMOD.
Placing breakpoint at ABAP statement CALL CUSTOMER-FUNCTION
Placing breakpoint at function module MODX_FUNCTION_ACTIVE_CHECK

1.2 BTE (FIBF)

Implemented as publish-and-subscribe (P&S) interface. That means BTE allows one or more functions to
be called.
Note: BTE frameworks can be used to establish synchronous communication between remote systems
using the SAP RFC (Remote Function Call) protocol.

Full directory of BTEs is stored in configuration table TBE01. And full directory of BTE process is stored in
configuration table TPS01.

Configuration activity in BTE is divided into 3 groups:

SAP Internal

Menu path in FIBF->Settings:

Publish and Subscribe
Process Interface

There are 2 types of interfaces available for implementing BTE's:

Publish and Subscribe Interface
Process Interface

1.2.1 Finding BTE

Via Transaction FIBF -> Environment -> Info System (P/S) or Info System (Processes).
The BTE Information System includes event or process documentation and the sample function
module. Not all BTEs are provided with documentation. And there are also some events or
processes that have sample function modules incompatible with interfaces. To make sure it is
compatible, double-check the sample function and the calling point.
Placing breakpoint at function BF_FUNCTIONS_READ for finding events and
PC_FUNCTIONS_READ for processes.
1.2.2 BTE Summary
Some BTEs and processes are interdependent; for example, if one BTE is used for setting additional
function codes in a GUI status and another is used for processing such function codes, the latter will
likely not work without the former. Sometimes such interdependencies are not so obvious and can be
found only by investigating source code or while debugging. Also, not all BTEs or processes seen in the
source code are maintained in BTE configuration tables (you will see such examples later in this book),
and thus they are not available for implementation unless you decide to modify Tables TBE01 and/or
TPS01 yourself.
1.3 Business Add-In (BAdI)
BAdI using P&S technique, that allow multiple implementation (depending on BAdI attributes, flag
Multiple Use).
There are 2 types of BAdI:
Kernel Based

1.3.1 Classic BAdI

The classing BAdI runtime framework is implemented in the global class CL_EXITHANDLER. To instantiate
BAdI, the static method GET_INSTANCE of the class CL_EXITHANDLER is used.

In the example below, the name of BAdI definition (in this example it is EHS_PS_002) is passed to the
GET_INSTANCE method via parameter EXIT_NAME. The BAdI instance is passed to variable
Method parameters ENTRY_INQUIERY of BAdI EHS_PS_002.

1.3.2 Kernel-Based BAdI

Statement GET_BADI is used to instantiate a kernel-based BAdI definition, and the CALL_BADI statement
is used to call BAdI interface method.

First, declare L_BADI type CUSTOMER_ADD_DATA. After instantiation using GET_BADI, the BAdI method
READ_ADD_ON_DATA call follows.

Kernel-based BAdI example.

1.3.3 Finding BAdI
There are 2 ways to find BAdI:
Defining breakpoint at CL_EXITHANDLER=>GET_INSTANCE method.
Defining breakpoint at GET_BADI statement.

1.3.4 Summary BAdI

A BAdI is the most flexible enhancement tool but at the same time, a BAdI isn't capable of remote
functionality (unlike BTE Framework).

1.4 Implicit Enhancement

SAP introduced the implicit enhancement concept in SAP Netweaver 7.0 together with the new
Enhancement Framework. You can modify any standard code without requesting a modification key.
However, there are some restrictions, for example, you can't enhance dynpro screens and system
programs with Program Status = "S".
Implicit enhancement can't be implanted anywhere in the source code, but only at the beginning or at
the end module (function, subroutine or class method), class declaration sections, structure
declarations, and some other places.

2. Master Data Enhancement

In this section we'll discuss general ledger account master data enhancement, common features of
vendor and customer master data enhancement, and customer credit control data enhancement.
2.1 General Ledger Accounts
In this section we discuss 3 elements of general ledger accounts:
The main transaction.
Data enhancements of GL account master data tables.
Data enhancements of UIs.

2.1.1 Main Transaction Codes of GL Account Master Data