User exits/BADIs Tutorials
Detailed explanation about BADI and the ways to find the BADI with an example (ME23n transaction)
Skip to end of metadata
Created by Guest, last modified by Bret Halford on Jul 18, 2013 Go to start of metadata
Detailed explanation about BADI with an example (ME23n transaction)
Def:
BADI (Business Add-In) is a new SAP Object Oriented enhancement technique which is used to add our own business functionality to the existing SAP standard functionality.
BADI's are available in SAP R/3 from the system release 4.6c
Why BADI?
In contrast to the earlier enhancement techniques, BADI follows Object Oriented approach to make them reusable. A BADI can be used any number of times where as standard enhancement techniques can be used only once.
For example if we assign an enhancement to one custom project, then that enhancement cannot be assigned to any other custom projects. To overcome this drawback SAP has provided a new enhancement technique called BADI.
Transaction code for BADI Definition:
SE18
When you create a BAdI definition, a class interface will be automatically created and you can define your methods in the interface. The implementation of the methods can be done in SE19 transaction.
When a BAdi is created following are automatically generated:
An interface with 'IF_EX_' inserted between the first and second characters of the BAdi name
An adapter class with 'CL_EX_' inserted between the first and second characters of the BAdi name.
Transaction code to Implement BADI:
SE19
Types of BADI's:
While creating a BADI using the T-code SE18, it provides the pop-up screen to select the type of BADI to be used is as shown below.
There are two types of BADI's.
1) Multi use BADI:
With this option, any number of active implementations can be assigned to the same definition BADI. By default this option is checked.
If we want the BADI for multiple use
If you have multiple-use BADI definitions, the sequence must not play any role.
The drawback in Multiple use BADI is, it is not possible to know which BADI is active especially in country specific version.
2) Filter dependent BADI:
Using this option we can define the BADI's according to the filter values to control the add-in implementation on specific criteria.
Ex: Specific country value.
How to Find BADI's in SAP system:
Method 1:
Steps to find BADI:
1. Go to SE 24 transaction, type CL_EXITHANDLER and then click on display.
2. Double click on GET_INSTANCE method.
3. Put a break-point on class method CL_EXITHANDLER=>GET_CLASS_NAME_BY_INTERFACE.
4. Run any transaction on which we want find the BADI's say VA01.
5. Give the transaction name VA01 and press enter.
6. It will automatically take you to the break-point which we have set the in the SE24 transaction. Each time if you press F8 a list BADI names will be displayed.
7. You can find the BADI name in field EXIT_NAME and if you double click on it, we can get the corresponding BADI name before hit the corresponding screen. Based on the requirement find the BADI name and accordingly implement your functionality using the transaction se19.
Method 2:
Go to transaction SE84 and click on Enhancements. Then double click on Business Add-Ins.
For example, if you want to find the BADI's for the standard transaction ME22n, the procedure is as follows. This example shows, finding the way of BADI names by providing the Package of ME22n.
1) Go to transaction ME22n. Select the System option from the menu and then click on Status. It displays the following information.
2) Double click on the program name i.e. SAPLMEGUI. It will take you into the program and click on Go to tab from the Menu. There we can find the package name of the standard transaction ME22n.Copy and paste it in the package filed.
3) Now Press F8, a list of BADI names will be displayed as shown below. Select the appropriate BADI name and implement it based on the business requirement using the transaction SE19.
Method 3:
Finding the BADI names using SE18 transaction
1) Go to transaction SE 18. Select F4 help for the definition name and click on Information System button as shown below.
2) A pop-up screen will be displayed and give the package name for any standard transaction say VA02. Finding the package is explained above. Please refer above method to find the package name. The package name for VA02 transaction is 'VA.'
3) A list of BADI names will be displayed for the transaction VA02. Select the appropriate BADI name and implement it using T-code SE19.
Example:
This Example explains how to implement BADI's. Here I am trying to show how to add custom screen to the ME23N Transactions using BADI's.
The procedure is as explained below.
- Find the BADI using the method 1 as shown above.
The BADI name to add the custom screen to ME23n is 'ME_GUI_PO_CUST'.
- Go to T-code SE19 and create an implementation ZME_GUI_PO_CUST and then click on create button
- Give the Definition name "ME_GUI_PO_CUST" and continue, give short text, save
- Click on Interface Tab, you can find the implementation class name as ZCL_IM_ME_GUI_PO_CUST2.
- Click on ZCL_IM_ME_GUI_PO_CUST2, which will take you to SE24.
- Add "MMMFD" in the Type Group Section of properties tab.
- Go to Attributes section and declare the following attribute
- SUBSCREEN1 Constant Public Type MEPO_NAME Name of a View
'ITEMSCREEN1 '.
- Go to Methods section, you can find the BADI interface methods.
- Double click on the method "IF_EX_ME_GUI_PO_CUST~SUBSCRIBE", this method is having 3 parameters
Go to the code section of the method and add the following code there.
Code for IF_EX_ME_GUI_PO_CUST~SUBSCRIBE:
DATA: ls_subscriber LIKE LINE OF re_subscribers.
*--FIRST SCREEN POPULATION
*--we want to add a customer subscreen on the item detail tab
CHECK im_application = 'PO'.
CHECK im_element = 'ITEM'.
*--each line in re_subscribers generates a subscreen. We add one subscreen
*--in this example
CLEAR re_subscribers[].
*--the name is a unique identifier for the subscreen and defined in this
*--class definition
ls_subscriber-name = subscreen1.
*--the dynpro number to use
ls_subscriber-dynpro = '0002'.
*--the program where the dynpro can be found
ls_subscriber-program = 'ZME_GUI_PO_CUST_SCREEN'.
*--each subscreen needs itsown DDIC-Structure
ls_subscriber-struct_name = 'ZMARA'.
*--a label can be defined
ls_subscriber-label = 'Cust BADI'.
*--the position within the tabstrib can be defined
ls_subscriber-position = 7.
*--the height of the screen can be defined here. Currently we support two
*--screen sizes:
*--value <= 7 a sevel line subscreen
*--value > 7 a 16 line subscreen
ls_subscriber-height = 7.
APPEND ls_subscriber TO re_subscribers.
Save and check and back
Double click on method IF_EX_ME_GUI_PO_CUST~MAP_DYNPRO_FIELDS".
Add the following code in the method.
*given the field catalog of structure ZMARA we have to
*establish a mapping to metafields which are used for field selection
*purposes and error handling Standard definitions can be found in type
*pool MMMFD. It is important for customer fields to use integer
*constants above 90000000 for the metafield.
FIELD-SYMBOLS: <mapping> LIKE LINE OF ch_mapping.
LOOP AT ch_mapping ASSIGNING <mapping>.
CASE <mapping>-fieldname.
WHEN 'MATNR'. <mapping>-metafield = mmmfd_cust_08.
WHEN 'MTART'. <mapping>-metafield = mmmfd_cust_09.
WHEN 'MATKL'. <mapping>-metafield = mmmfd_cust_10.
ENDCASE.
ENDLOOP.
The metafield mapping important for field selection and error handling purpose.
Save, check and back
Activate the Implementation class.
Activate the BADI Implementation.
Now create a structure in SE11 with the name ZMARA.
Add the following fields in the structure.
Now Create a Program with the Name 'ZME_GUI_PO_CUST_SCREEN' and create a screen with sub screen type with the number 0002.
Add the fields on to screen from ZMARA program 'ZME_GUI_PO_CUST_SCREEN'.
* *
De comment the PBO module in screen flow logic and create the module in above program.
Add the following code in program ZME_GUI_PO_CUST_SCREEN.
TABLES: ZMARA.
DATA: call_subscreen TYPE sy-dynnr,
call_prog TYPE sy-repid,
call_view TYPE REF TO cl_screen_view_mm,
call_view_stack TYPE REF TO cl_screen_view_mm OCCURS 0.
*---------------------------------------------------------------------*
* FORM SET_SUBSCREEN_AND_PROG *
*---------------------------------------------------------------------*
* ........ *
*---------------------------------------------------------------------*
* --> DYNNR *
* --> PROG *
* --> VIEW *
* --> TO *
* --> CL_SCREEN_VIEW_MM *
*---------------------------------------------------------------------*
FORM set_subscreen_and_prog USING dynnr TYPE sy-dynnr
prog TYPE sy-repid
view TYPE REF TO cl_screen_view_mm.
call_subscreen = dynnr.
call_prog = prog.
call_view = view.
ENDFORM.
*&---------------------------------------------------------------------*
*& Module STATUS_0002 OUTPUT
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
MODULE STATUS_0002 OUTPUT.
SELECT SINGLE * FROM MARA
INTO CORRESPONDING FIELDS OF ZMARA
WHERE MATNR = '100-100'.
ENDMODULE. " STATUS_0002 OUTPUT
The sub-routine "set_subscreen_and_prog" is must with the same signature.
This routine is called from BADI to call the sub screen.
Activate the screen & program.
Now Go to T-Code ME23N to test the application.
You can find a new tab is added in the item level with the name CUST BADI.
Final Output:
No labels
5 Comments
User icon: x92kak2
Guest
Table of Contents
1) Overview of this document........................................................
2) User Exit with example............................................................
3) Customer Exit........................................................................
4) Types of Customer Exits..........................................................
5) Function Module exits.............................................................
6) Screen Exist.........................................................................
7) Menu Exits...........................................................................
8) Methods to find out customer Exits...........................................
9) CMOD and SMOD transactions................................................
Overview of this document
The enhancement concept allows you to add your own functionality to SAP's standard business applications without having to modify the original applications. To modify the standard SAP behavior as per customer requirements, we can use enhancement framework.
There are different ways to implement custom functionality in the SAP standard code. ex: User exits, customer exits, BADI etc.
This document explains about User exits and Customer Exits.
User exits
These are implemented in the form of subroutines and hence are also known as FORM EXITs. The user exits are generally collected in includes and attached to the standard program by the SAP.
User exits are a type of system enhancement that was originally developed for the R/3 SD (Sales and distribution) module. User-exits are empty subroutines that SAP Developers have provided for you. You can fill them with your own source code. Technically this is a modification.
All User exits start with the word USEREXIT_...
FORM USEREXIT_XXXX....
INCLUDE ZZUSEREXIT.......
ENDFORM.
User exits can be found in the following ways:
Go to Object Navigator (SE80), select Package and put VMOD (Application development R/3 SD customer modification) and press enter. You will find all the includes for user exits in SD. You will get User exits for Sales order, Delivery, Billing, Pricing etc. Most of the time documentation is maintained for each subroutine which helps developer for better understanding of the subroutine. Select the subroutine according to the requirement and start coding within the subroutine.
Examples:
- In User exits MV45AFZZ(Sales Order Exit), we have subroutine
USEREXIT_PRICING_PREPARE_TKOMK
USEREXIT_PRICING_PREPARE_TKOMP
This user exit can be used to move additional fields into the communication table which is used for pricing. TKOMK for header fields and TKOMG for item fields. The fields which are not in either of the two tables KOMK and KOMP cannot be used in pricing.
zvendpgm (Vendor Program), zpricegrp (Price Group), kvgr5(Airport Code) fields value moving from VBAP to KOMP table.
- In User exits MV50AFZ1(Delivery Exit), you have subroutine
USEREXIT_SAVE_DOCUMENT_PREPARE
This user exit can be used for changes or checks, before a document is saved.
Customer exits
SAP creates customer exits for specific programs, screens, and menus within standard applications. These exits do not contain any functionality. Instead, the customer exits act as hooks. You can hang your own add-on functionality onto these hooks.
Customer exits are nothing but a include in customer name space will be provided in the function module which starts with CALL CUSTOMER. You can fill them with your own source code. Technically this is an enhancement. User exits generally refer to SD module while customer exits refer to all modules like MM, SD, PP, FICO etc.
Advantage:
- They do not affect standard SAP source code
- They do not affect software updates
Disadvantage:
- Customer exits are not available for all programs and screens found in the SAP System. You can only use customer exits if they already exist in the SAP System.
Types of Customer Exits
1. Function Module exits
2. Screen exits
3. Menu exits
1. Function Module exits
Function module exits are exits developed by SAP. The exit is implemented as a call to a function module. The code for the function module is written by the developer. You are not writing the code directly in the function module, but in the include that is implemented in the function module.
Format: CALL CUSTOMER-FUNCTION '910'
The naming standard of function modules for function module exits is:
EXIT_<program name>_<3 digit suffix>
Examples:
Before User exits using: No error comes for any Country code.
Below Function Module Exits: EXIT_SAPMF02K_001.
We are writing our code in the Include ZXF05U01.
After User exits using: Error comes for any Country code like 'IN'. Only permissible country code is 'US'.
2. Screen Exits:
Allow customer to add fields to a screen via a sub screen in an SAP program. The sub screen is called within the standard screen's flow logic.
Format: CALL CUSTOMER-SUBSCREEN CUSTSCR1
3. Menu exits:
Menu exits allow you to add your own functionality to menus. Menu exits are implemented by SAP and are reserved menu entries in the GUI interface. The developer can add his/her own text and logic for the menu.
Function codes for menu exits all start with "+".
Format: +CUS (additional item in GUI status)
Methods to find out customer Exits:
There are numbers of way by using we can find out Customer Exits.
Method # 1: Call customer
If you are searching customer exits based on particular transaction.
Go to Transaction. Ex: VA01.
Then system-> status
Double click on Program(screen).
Find(Cntrl+F)
Then use Call customer and select in main program radio button tab and press Enter.
We can find out all the possible Customer exits based on this transaction.
Method # 2: SMOD
Go to Transaction SMOD (SAP Enhancement).
Then Utilities-> Find
Give Package name and Execute (F8).
For Purchase Order package is ME.
We can find out all the possible Enhancement (Customer exits) based on this package.
Method # 3: SE84
Go to Transaction SE84.
Select Enhancements -> Customer Exits -> Enhancements
Give Package and Execute. We can find out all the possible Enhancement (Customer exits) based on this Package.
Method # 4: SE81
Go to Transaction SE81.
Click on Module name (ex: SD).
Then from top menu select Edit -> Select sub tree +/-.
Select Information System.
A new Screen will appear, it looks like SE84.
Then select Enhancements -> Customer Exits ->Enhancements.
Double click on Enhancements and Execute.
We can find out all the possible Enhancement (Customer exits) based on this Module.
Method # 5: ST05
Go to Transaction ST05. Select Table Buffer Trace & Activate Trace.
Then go to the transaction, based on which you want to see the customer exits.
Come back to ST05, Deactivate Trace & display Trace.
Then go to FIND & write text EXIT_ & press ENTER.
We can find out all the possible Enhancement (Customer exits) based on this Transaction .This is not good technique to find out customer exits because all the possible exits may not be find out using this technique.
SAP Enhancements (SMOD):
This transaction is used to see the list of objects in an enhancement. It is a container which holds many related objects within it.
If you Double click on TEST button, you will get below screen.
From the above screen shot we can say that the Function Exit is already implemented (Green light) but in Inactive stage (Red light).
Project Creation (CMOD):
This Transaction is used to create a project. Project is also a container, which holds several Enhancements. If we identify the User Exits and write down the code only within it, then the functionality will not be worked. That is why we require adding the enhancement into a project & making it active.
CMOD Transaction is used to create a project.
Select Enhancement assignments and you add your Enhancement in this project.
You can add multiple Enhancements in one project. But you can't add one enhancement in multiple projects. Then error message will be generated.
Error message generate, because Enhancement V45A0002 is already exist in other project.
From screen short no: 2 of CMOD description, if we click on Components, we will get the list of Customer exits belongs to these enhancements.
Both green light shows that the exit is already implemented & is Active stage.
USER AND CUSTOMER EXITS .
Skip to end of metadata
Created by Guest, last modified by Craig Cmehil on Dec 28, 2009 Go to start of metadata
USER AND CUSTOMER EXITS ...First of all we must know the difference between user and customer exits .user exits are available only for SD module whereas customer exits are available for
All the modules such as MM,SD,FI , etc.
Technically talking , user exits make use of forms(subroutines) whereas customer
Exits make use of Function modules , So , user exits have the option to access global data but incase of customer exits we can only access the import/export/changing/tables parameters of the Function modules .This makes
User exits are flexible and inconsistent and customer exits are restrictive and consistent.
A user exit is considered a modification , since technically objects in SAP namespace are modified . Customer exits do not affect standard SAP source
Code .
Customer exits can be further classified as 1)Function module exits 2)Screen exits
3)Menu exits .
Function module exits : Allow customer to add code via a function module at a
Specific location in an SAP application program .
Menu Exits : Allow customer to add items to a pull down menu in a standard SAP
Program .
Screen Exits : Allow customer to add fields to a screen in an SAP program via a
Subscreen .
Now , how to locate a customer exit for a standard transaction . We will take the example of transaction VA01 which is used to create sales orders . Open VA01 .
The screen given appears : Now , go to SYSTEM tab on top and choose status . The screen given below will appear :
Now , double click on program named SAPMV45A . It will navigate you to the program . The screen given below appears. Go to the Find option.
After you click on find option a search box appears. Make a search by using " CALL CUSTOMER* " as key words.The following screen appears:
Double clicking on any of the search results takes us to the following screen :
Now , double click on the digits mentioned in green . For instance '002' in this case . The following screen appears :
The screen which you now see contains the function exit for the transaction VA01 . User does the coding part in the INCLUDE mentioned i.e ZXVVAU04.Every Function Exit has an enhancement associated with it . To find that enhancement we will take help of table MODSAP . Go to SE11 and open table MODSAP . Go to its contents . Choose component type E(function exit) and execute .Output would be a lot of entries . Choose the entry corresponding to your function exit by double clicking on it .The following screen appears :
As you can see the output shows the enhancement name and the function exit as enhancement member .All the enhancements are maintained in transaction SMOD .
Go to SMOD and put the enhancement name 0VRF0001 and display its components using the radio button . The following screen appears:
You can see the function exit as a component of the enhancement . Every enhancement is assigned to a project . To find the name of the project to which the enhancement is assigned
we go to SE11 and open table MODACT . Go to the contents and put the enhancement name 0VRF0001 and execute the search . The following screen appears : AS you can see the project name is mentioned which is 101940 . Now , to see the details of a project we go to CMOD . Put the project name and display its components using the radio button . The following screen appears :
As you can see the details contain the names of all the enhancements and function exits corresponding to them.A project should be in activated state .
The other way to locate customer exits is , Go to SE84 . Go to enhancements option and then customer exits . Click again on enhancements . The screen
given below appears :
Results will be filtered according to the application area .
CMOD Vs SMOD :
SMOD provides the list of actual enhancements whereas CMOD provides customers to create custom projects and to activate/deactivate these enhancements.
Using CMOD enhancements are assigned to a project using enhancement assignment option . Each enhancement package may be assigned to only one project .
SCREEN EXIT : In transaction CAT2, HR wishes to include an interactive acknowledgement that knowingly submitting incorrect data is grounds for dismissal.
The TICKBOX mentioning " I understand and agree" is an example of screen exit . The user cannot proceed until acknowledging this message.
MENU EXIT : In transaction SE38 if we go the utilities TAB there is an option mentioned " CUSTOMER EXIT " which can be used to add links to other transactions such as SE80(object navigator). check the screen shot above :
exitscontd
Follow SCN
Contact Us SAP Help Portal
Privacy Terms of Use Le
Enhancement Concept
Definition
The Enhancement Framework provides a technology for enhancing source code units without modifying them. The basic mechanism is to offer the so-called enhancement options in development objects. These enhancement options function like “hooks” where you can attach your enhancements. The enhancement options are part of the development objects which can be enhanced. When you assign an enhancement to an enhancement option, at runtime the enhancement is processed when the control flow reaches the option. At runtime the enhancement behaves as if it belongs to the development object it enhances, while the enhancement as a transport object does not belong to the enhanced object.
Basic Concepts
The basic concepts in the Enhancement Framework are:
● Enhancement options: positions in repository objects where you can make enhancements. Enhancement options can be explicit and implicit.
● Enhancement spots: containers for explicit enhancement options.
● Enhancement implementation elements: these contain the actual enhancement, for example, the source code to be added.
● Enhancement implementations: containers for both enhancement implementation elements of both implicit and explicit enhancement options.
The enhancement options are divided into two classes:
● Implicit enhancement options are provided by the framework and exist without any particular preparation by a developer, they do not have to belong to a container (an enhancement spot).
● Explicit enhancement options have to be inserted explicitly in the source code. They are created in an initial system and must be made known to developers in target systems by means of enhancement spots.
The figure below shows an overview of enhancement spots and enhancement implementations. The left part shows the relevant terminology for enhancement spots and the relationships between them. It only applies to explicit enhancement options. No enhancement spots are required for implicit enhancement options.
The right part shows the relevant terminology for enhancement implementations and the relationships between them. This applies to enhancement implementations of both explicit and implicit enhancement options.
On the implementation side, all implementation elements belong to other containers regardless of whether they enhance implicit or explicit enhancement options. The containers on the definition side and those on the implementation side are assigned to each other with a particular cardinality.
This graphic is explained in the accompanying text
Grouping Enhancements
Enhancement options and their implementations must not be grouped together as they belong to different stages of development. In the Enhancement Framework there are containers for the enhancement options on the definition side and containers for the implementations on the implementation side:
· Simple containers
These can only contain enhancement options or enhancement implementation elements. These containers cannot be nested. One basic container can only hold elements of one type. For example, a simple container cannot hold BAdIs and enhancement options at the same time.
· Composite containers
To make room for a nested structure there are composite containers that can hold basic containers and other composite containers. These composite containers can contain basic containers for different enhancement types. Since these composite containers can be nested, you can build a structure that really fulfills the needs of your project. A simple structure looks like this:
This graphic is explained in the accompanying text
When you create an enhancement from scratch, you always have to create the respective containers first. This is similar to creating a method. A method is always part of a class. In the same way, there is no standalone BAdI. Each BAdI is part of an enhancement spot and it is the spot that functions as a transport object. That is why you cannot build a new BAdI and just forget about the framework in the way you might be accustomed to with classic BAdIs. It is also not possible to build the BAdI first and take care of how it fits in the structure of containers later. When building a BAdI, you have to put the BAdI within the relevant structure from the very beginning. But it is only mandatory to have simple containers. Composite enhancements spots and composite enhancement implementations are not enforced by the tools.
Skip to end of metadata
Created by Guest, last modified by Bret Halford on Jul 18, 2013 Go to start of metadata
Detailed explanation about BADI with an example (ME23n transaction)
Def:
BADI (Business Add-In) is a new SAP Object Oriented enhancement technique which is used to add our own business functionality to the existing SAP standard functionality.
BADI's are available in SAP R/3 from the system release 4.6c
Why BADI?
In contrast to the earlier enhancement techniques, BADI follows Object Oriented approach to make them reusable. A BADI can be used any number of times where as standard enhancement techniques can be used only once.
For example if we assign an enhancement to one custom project, then that enhancement cannot be assigned to any other custom projects. To overcome this drawback SAP has provided a new enhancement technique called BADI.
Transaction code for BADI Definition:
SE18
When you create a BAdI definition, a class interface will be automatically created and you can define your methods in the interface. The implementation of the methods can be done in SE19 transaction.
When a BAdi is created following are automatically generated:
An interface with 'IF_EX_' inserted between the first and second characters of the BAdi name
An adapter class with 'CL_EX_' inserted between the first and second characters of the BAdi name.
Transaction code to Implement BADI:
SE19
Types of BADI's:
While creating a BADI using the T-code SE18, it provides the pop-up screen to select the type of BADI to be used is as shown below.
There are two types of BADI's.
1) Multi use BADI:
With this option, any number of active implementations can be assigned to the same definition BADI. By default this option is checked.
If we want the BADI for multiple use
If you have multiple-use BADI definitions, the sequence must not play any role.
The drawback in Multiple use BADI is, it is not possible to know which BADI is active especially in country specific version.
2) Filter dependent BADI:
Using this option we can define the BADI's according to the filter values to control the add-in implementation on specific criteria.
Ex: Specific country value.
How to Find BADI's in SAP system:
Method 1:
Steps to find BADI:
1. Go to SE 24 transaction, type CL_EXITHANDLER and then click on display.
2. Double click on GET_INSTANCE method.
3. Put a break-point on class method CL_EXITHANDLER=>GET_CLASS_NAME_BY_INTERFACE.
4. Run any transaction on which we want find the BADI's say VA01.
5. Give the transaction name VA01 and press enter.
6. It will automatically take you to the break-point which we have set the in the SE24 transaction. Each time if you press F8 a list BADI names will be displayed.
7. You can find the BADI name in field EXIT_NAME and if you double click on it, we can get the corresponding BADI name before hit the corresponding screen. Based on the requirement find the BADI name and accordingly implement your functionality using the transaction se19.
Method 2:
Go to transaction SE84 and click on Enhancements. Then double click on Business Add-Ins.
For example, if you want to find the BADI's for the standard transaction ME22n, the procedure is as follows. This example shows, finding the way of BADI names by providing the Package of ME22n.
1) Go to transaction ME22n. Select the System option from the menu and then click on Status. It displays the following information.
2) Double click on the program name i.e. SAPLMEGUI. It will take you into the program and click on Go to tab from the Menu. There we can find the package name of the standard transaction ME22n.Copy and paste it in the package filed.
3) Now Press F8, a list of BADI names will be displayed as shown below. Select the appropriate BADI name and implement it based on the business requirement using the transaction SE19.
Method 3:
Finding the BADI names using SE18 transaction
1) Go to transaction SE 18. Select F4 help for the definition name and click on Information System button as shown below.
2) A pop-up screen will be displayed and give the package name for any standard transaction say VA02. Finding the package is explained above. Please refer above method to find the package name. The package name for VA02 transaction is 'VA.'
3) A list of BADI names will be displayed for the transaction VA02. Select the appropriate BADI name and implement it using T-code SE19.
Example:
This Example explains how to implement BADI's. Here I am trying to show how to add custom screen to the ME23N Transactions using BADI's.
The procedure is as explained below.
- Find the BADI using the method 1 as shown above.
The BADI name to add the custom screen to ME23n is 'ME_GUI_PO_CUST'.
- Go to T-code SE19 and create an implementation ZME_GUI_PO_CUST and then click on create button
- Give the Definition name "ME_GUI_PO_CUST" and continue, give short text, save
- Click on Interface Tab, you can find the implementation class name as ZCL_IM_ME_GUI_PO_CUST2.
- Click on ZCL_IM_ME_GUI_PO_CUST2, which will take you to SE24.
- Add "MMMFD" in the Type Group Section of properties tab.
- Go to Attributes section and declare the following attribute
- SUBSCREEN1 Constant Public Type MEPO_NAME Name of a View
'ITEMSCREEN1 '.
- Go to Methods section, you can find the BADI interface methods.
- Double click on the method "IF_EX_ME_GUI_PO_CUST~SUBSCRIBE", this method is having 3 parameters
Go to the code section of the method and add the following code there.
Code for IF_EX_ME_GUI_PO_CUST~SUBSCRIBE:
DATA: ls_subscriber LIKE LINE OF re_subscribers.
*--FIRST SCREEN POPULATION
*--we want to add a customer subscreen on the item detail tab
CHECK im_application = 'PO'.
CHECK im_element = 'ITEM'.
*--each line in re_subscribers generates a subscreen. We add one subscreen
*--in this example
CLEAR re_subscribers[].
*--the name is a unique identifier for the subscreen and defined in this
*--class definition
ls_subscriber-name = subscreen1.
*--the dynpro number to use
ls_subscriber-dynpro = '0002'.
*--the program where the dynpro can be found
ls_subscriber-program = 'ZME_GUI_PO_CUST_SCREEN'.
*--each subscreen needs itsown DDIC-Structure
ls_subscriber-struct_name = 'ZMARA'.
*--a label can be defined
ls_subscriber-label = 'Cust BADI'.
*--the position within the tabstrib can be defined
ls_subscriber-position = 7.
*--the height of the screen can be defined here. Currently we support two
*--screen sizes:
*--value <= 7 a sevel line subscreen
*--value > 7 a 16 line subscreen
ls_subscriber-height = 7.
APPEND ls_subscriber TO re_subscribers.
Save and check and back
Double click on method IF_EX_ME_GUI_PO_CUST~MAP_DYNPRO_FIELDS".
Add the following code in the method.
*given the field catalog of structure ZMARA we have to
*establish a mapping to metafields which are used for field selection
*purposes and error handling Standard definitions can be found in type
*pool MMMFD. It is important for customer fields to use integer
*constants above 90000000 for the metafield.
FIELD-SYMBOLS: <mapping> LIKE LINE OF ch_mapping.
LOOP AT ch_mapping ASSIGNING <mapping>.
CASE <mapping>-fieldname.
WHEN 'MATNR'. <mapping>-metafield = mmmfd_cust_08.
WHEN 'MTART'. <mapping>-metafield = mmmfd_cust_09.
WHEN 'MATKL'. <mapping>-metafield = mmmfd_cust_10.
ENDCASE.
ENDLOOP.
The metafield mapping important for field selection and error handling purpose.
Save, check and back
Activate the Implementation class.
Activate the BADI Implementation.
Now create a structure in SE11 with the name ZMARA.
Add the following fields in the structure.
Now Create a Program with the Name 'ZME_GUI_PO_CUST_SCREEN' and create a screen with sub screen type with the number 0002.
Add the fields on to screen from ZMARA program 'ZME_GUI_PO_CUST_SCREEN'.
* *
De comment the PBO module in screen flow logic and create the module in above program.
Add the following code in program ZME_GUI_PO_CUST_SCREEN.
TABLES: ZMARA.
DATA: call_subscreen TYPE sy-dynnr,
call_prog TYPE sy-repid,
call_view TYPE REF TO cl_screen_view_mm,
call_view_stack TYPE REF TO cl_screen_view_mm OCCURS 0.
*---------------------------------------------------------------------*
* FORM SET_SUBSCREEN_AND_PROG *
*---------------------------------------------------------------------*
* ........ *
*---------------------------------------------------------------------*
* --> DYNNR *
* --> PROG *
* --> VIEW *
* --> TO *
* --> CL_SCREEN_VIEW_MM *
*---------------------------------------------------------------------*
FORM set_subscreen_and_prog USING dynnr TYPE sy-dynnr
prog TYPE sy-repid
view TYPE REF TO cl_screen_view_mm.
call_subscreen = dynnr.
call_prog = prog.
call_view = view.
ENDFORM.
*&---------------------------------------------------------------------*
*& Module STATUS_0002 OUTPUT
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
MODULE STATUS_0002 OUTPUT.
SELECT SINGLE * FROM MARA
INTO CORRESPONDING FIELDS OF ZMARA
WHERE MATNR = '100-100'.
ENDMODULE. " STATUS_0002 OUTPUT
The sub-routine "set_subscreen_and_prog" is must with the same signature.
This routine is called from BADI to call the sub screen.
Activate the screen & program.
Now Go to T-Code ME23N to test the application.
You can find a new tab is added in the item level with the name CUST BADI.
Final Output:
No labels
5 Comments
User icon: x92kak2
Guest
Table of Contents
1) Overview of this document........................................................
2) User Exit with example............................................................
3) Customer Exit........................................................................
4) Types of Customer Exits..........................................................
5) Function Module exits.............................................................
6) Screen Exist.........................................................................
7) Menu Exits...........................................................................
8) Methods to find out customer Exits...........................................
9) CMOD and SMOD transactions................................................
Overview of this document
The enhancement concept allows you to add your own functionality to SAP's standard business applications without having to modify the original applications. To modify the standard SAP behavior as per customer requirements, we can use enhancement framework.
There are different ways to implement custom functionality in the SAP standard code. ex: User exits, customer exits, BADI etc.
This document explains about User exits and Customer Exits.
User exits
These are implemented in the form of subroutines and hence are also known as FORM EXITs. The user exits are generally collected in includes and attached to the standard program by the SAP.
User exits are a type of system enhancement that was originally developed for the R/3 SD (Sales and distribution) module. User-exits are empty subroutines that SAP Developers have provided for you. You can fill them with your own source code. Technically this is a modification.
All User exits start with the word USEREXIT_...
FORM USEREXIT_XXXX....
INCLUDE ZZUSEREXIT.......
ENDFORM.
User exits can be found in the following ways:
Go to Object Navigator (SE80), select Package and put VMOD (Application development R/3 SD customer modification) and press enter. You will find all the includes for user exits in SD. You will get User exits for Sales order, Delivery, Billing, Pricing etc. Most of the time documentation is maintained for each subroutine which helps developer for better understanding of the subroutine. Select the subroutine according to the requirement and start coding within the subroutine.
Examples:
- In User exits MV45AFZZ(Sales Order Exit), we have subroutine
USEREXIT_PRICING_PREPARE_TKOMK
USEREXIT_PRICING_PREPARE_TKOMP
This user exit can be used to move additional fields into the communication table which is used for pricing. TKOMK for header fields and TKOMG for item fields. The fields which are not in either of the two tables KOMK and KOMP cannot be used in pricing.
zvendpgm (Vendor Program), zpricegrp (Price Group), kvgr5(Airport Code) fields value moving from VBAP to KOMP table.
- In User exits MV50AFZ1(Delivery Exit), you have subroutine
USEREXIT_SAVE_DOCUMENT_PREPARE
This user exit can be used for changes or checks, before a document is saved.
Customer exits
SAP creates customer exits for specific programs, screens, and menus within standard applications. These exits do not contain any functionality. Instead, the customer exits act as hooks. You can hang your own add-on functionality onto these hooks.
Customer exits are nothing but a include in customer name space will be provided in the function module which starts with CALL CUSTOMER. You can fill them with your own source code. Technically this is an enhancement. User exits generally refer to SD module while customer exits refer to all modules like MM, SD, PP, FICO etc.
Advantage:
- They do not affect standard SAP source code
- They do not affect software updates
Disadvantage:
- Customer exits are not available for all programs and screens found in the SAP System. You can only use customer exits if they already exist in the SAP System.
Types of Customer Exits
1. Function Module exits
2. Screen exits
3. Menu exits
1. Function Module exits
Function module exits are exits developed by SAP. The exit is implemented as a call to a function module. The code for the function module is written by the developer. You are not writing the code directly in the function module, but in the include that is implemented in the function module.
Format: CALL CUSTOMER-FUNCTION '910'
The naming standard of function modules for function module exits is:
EXIT_<program name>_<3 digit suffix>
Examples:
Before User exits using: No error comes for any Country code.
Below Function Module Exits: EXIT_SAPMF02K_001.
We are writing our code in the Include ZXF05U01.
After User exits using: Error comes for any Country code like 'IN'. Only permissible country code is 'US'.
2. Screen Exits:
Allow customer to add fields to a screen via a sub screen in an SAP program. The sub screen is called within the standard screen's flow logic.
Format: CALL CUSTOMER-SUBSCREEN CUSTSCR1
3. Menu exits:
Menu exits allow you to add your own functionality to menus. Menu exits are implemented by SAP and are reserved menu entries in the GUI interface. The developer can add his/her own text and logic for the menu.
Function codes for menu exits all start with "+".
Format: +CUS (additional item in GUI status)
Methods to find out customer Exits:
There are numbers of way by using we can find out Customer Exits.
Method # 1: Call customer
If you are searching customer exits based on particular transaction.
Go to Transaction. Ex: VA01.
Then system-> status
Double click on Program(screen).
Find(Cntrl+F)
Then use Call customer and select in main program radio button tab and press Enter.
We can find out all the possible Customer exits based on this transaction.
Method # 2: SMOD
Go to Transaction SMOD (SAP Enhancement).
Then Utilities-> Find
Give Package name and Execute (F8).
For Purchase Order package is ME.
We can find out all the possible Enhancement (Customer exits) based on this package.
Method # 3: SE84
Go to Transaction SE84.
Select Enhancements -> Customer Exits -> Enhancements
Give Package and Execute. We can find out all the possible Enhancement (Customer exits) based on this Package.
Method # 4: SE81
Go to Transaction SE81.
Click on Module name (ex: SD).
Then from top menu select Edit -> Select sub tree +/-.
Select Information System.
A new Screen will appear, it looks like SE84.
Then select Enhancements -> Customer Exits ->Enhancements.
Double click on Enhancements and Execute.
We can find out all the possible Enhancement (Customer exits) based on this Module.
Method # 5: ST05
Go to Transaction ST05. Select Table Buffer Trace & Activate Trace.
Then go to the transaction, based on which you want to see the customer exits.
Come back to ST05, Deactivate Trace & display Trace.
Then go to FIND & write text EXIT_ & press ENTER.
We can find out all the possible Enhancement (Customer exits) based on this Transaction .This is not good technique to find out customer exits because all the possible exits may not be find out using this technique.
SAP Enhancements (SMOD):
This transaction is used to see the list of objects in an enhancement. It is a container which holds many related objects within it.
If you Double click on TEST button, you will get below screen.
From the above screen shot we can say that the Function Exit is already implemented (Green light) but in Inactive stage (Red light).
Project Creation (CMOD):
This Transaction is used to create a project. Project is also a container, which holds several Enhancements. If we identify the User Exits and write down the code only within it, then the functionality will not be worked. That is why we require adding the enhancement into a project & making it active.
CMOD Transaction is used to create a project.
Select Enhancement assignments and you add your Enhancement in this project.
You can add multiple Enhancements in one project. But you can't add one enhancement in multiple projects. Then error message will be generated.
Error message generate, because Enhancement V45A0002 is already exist in other project.
From screen short no: 2 of CMOD description, if we click on Components, we will get the list of Customer exits belongs to these enhancements.
Both green light shows that the exit is already implemented & is Active stage.
USER AND CUSTOMER EXITS .
Skip to end of metadata
Created by Guest, last modified by Craig Cmehil on Dec 28, 2009 Go to start of metadata
USER AND CUSTOMER EXITS ...First of all we must know the difference between user and customer exits .user exits are available only for SD module whereas customer exits are available for
All the modules such as MM,SD,FI , etc.
Technically talking , user exits make use of forms(subroutines) whereas customer
Exits make use of Function modules , So , user exits have the option to access global data but incase of customer exits we can only access the import/export/changing/tables parameters of the Function modules .This makes
User exits are flexible and inconsistent and customer exits are restrictive and consistent.
A user exit is considered a modification , since technically objects in SAP namespace are modified . Customer exits do not affect standard SAP source
Code .
Customer exits can be further classified as 1)Function module exits 2)Screen exits
3)Menu exits .
Function module exits : Allow customer to add code via a function module at a
Specific location in an SAP application program .
Menu Exits : Allow customer to add items to a pull down menu in a standard SAP
Program .
Screen Exits : Allow customer to add fields to a screen in an SAP program via a
Subscreen .
Now , how to locate a customer exit for a standard transaction . We will take the example of transaction VA01 which is used to create sales orders . Open VA01 .
The screen given appears : Now , go to SYSTEM tab on top and choose status . The screen given below will appear :
Now , double click on program named SAPMV45A . It will navigate you to the program . The screen given below appears. Go to the Find option.
After you click on find option a search box appears. Make a search by using " CALL CUSTOMER* " as key words.The following screen appears:
Double clicking on any of the search results takes us to the following screen :
Now , double click on the digits mentioned in green . For instance '002' in this case . The following screen appears :
The screen which you now see contains the function exit for the transaction VA01 . User does the coding part in the INCLUDE mentioned i.e ZXVVAU04.Every Function Exit has an enhancement associated with it . To find that enhancement we will take help of table MODSAP . Go to SE11 and open table MODSAP . Go to its contents . Choose component type E(function exit) and execute .Output would be a lot of entries . Choose the entry corresponding to your function exit by double clicking on it .The following screen appears :
As you can see the output shows the enhancement name and the function exit as enhancement member .All the enhancements are maintained in transaction SMOD .
Go to SMOD and put the enhancement name 0VRF0001 and display its components using the radio button . The following screen appears:
You can see the function exit as a component of the enhancement . Every enhancement is assigned to a project . To find the name of the project to which the enhancement is assigned
we go to SE11 and open table MODACT . Go to the contents and put the enhancement name 0VRF0001 and execute the search . The following screen appears : AS you can see the project name is mentioned which is 101940 . Now , to see the details of a project we go to CMOD . Put the project name and display its components using the radio button . The following screen appears :
As you can see the details contain the names of all the enhancements and function exits corresponding to them.A project should be in activated state .
The other way to locate customer exits is , Go to SE84 . Go to enhancements option and then customer exits . Click again on enhancements . The screen
given below appears :
Results will be filtered according to the application area .
CMOD Vs SMOD :
SMOD provides the list of actual enhancements whereas CMOD provides customers to create custom projects and to activate/deactivate these enhancements.
Using CMOD enhancements are assigned to a project using enhancement assignment option . Each enhancement package may be assigned to only one project .
SCREEN EXIT : In transaction CAT2, HR wishes to include an interactive acknowledgement that knowingly submitting incorrect data is grounds for dismissal.
The TICKBOX mentioning " I understand and agree" is an example of screen exit . The user cannot proceed until acknowledging this message.
MENU EXIT : In transaction SE38 if we go the utilities TAB there is an option mentioned " CUSTOMER EXIT " which can be used to add links to other transactions such as SE80(object navigator). check the screen shot above :
exitscontd
Follow SCN
Contact Us SAP Help Portal
Privacy Terms of Use Le
Enhancement Concept
Definition
The Enhancement Framework provides a technology for enhancing source code units without modifying them. The basic mechanism is to offer the so-called enhancement options in development objects. These enhancement options function like “hooks” where you can attach your enhancements. The enhancement options are part of the development objects which can be enhanced. When you assign an enhancement to an enhancement option, at runtime the enhancement is processed when the control flow reaches the option. At runtime the enhancement behaves as if it belongs to the development object it enhances, while the enhancement as a transport object does not belong to the enhanced object.
Basic Concepts
The basic concepts in the Enhancement Framework are:
● Enhancement options: positions in repository objects where you can make enhancements. Enhancement options can be explicit and implicit.
● Enhancement spots: containers for explicit enhancement options.
● Enhancement implementation elements: these contain the actual enhancement, for example, the source code to be added.
● Enhancement implementations: containers for both enhancement implementation elements of both implicit and explicit enhancement options.
The enhancement options are divided into two classes:
● Implicit enhancement options are provided by the framework and exist without any particular preparation by a developer, they do not have to belong to a container (an enhancement spot).
● Explicit enhancement options have to be inserted explicitly in the source code. They are created in an initial system and must be made known to developers in target systems by means of enhancement spots.
The figure below shows an overview of enhancement spots and enhancement implementations. The left part shows the relevant terminology for enhancement spots and the relationships between them. It only applies to explicit enhancement options. No enhancement spots are required for implicit enhancement options.
The right part shows the relevant terminology for enhancement implementations and the relationships between them. This applies to enhancement implementations of both explicit and implicit enhancement options.
On the implementation side, all implementation elements belong to other containers regardless of whether they enhance implicit or explicit enhancement options. The containers on the definition side and those on the implementation side are assigned to each other with a particular cardinality.
This graphic is explained in the accompanying text
Grouping Enhancements
Enhancement options and their implementations must not be grouped together as they belong to different stages of development. In the Enhancement Framework there are containers for the enhancement options on the definition side and containers for the implementations on the implementation side:
· Simple containers
These can only contain enhancement options or enhancement implementation elements. These containers cannot be nested. One basic container can only hold elements of one type. For example, a simple container cannot hold BAdIs and enhancement options at the same time.
· Composite containers
To make room for a nested structure there are composite containers that can hold basic containers and other composite containers. These composite containers can contain basic containers for different enhancement types. Since these composite containers can be nested, you can build a structure that really fulfills the needs of your project. A simple structure looks like this:
This graphic is explained in the accompanying text
When you create an enhancement from scratch, you always have to create the respective containers first. This is similar to creating a method. A method is always part of a class. In the same way, there is no standalone BAdI. Each BAdI is part of an enhancement spot and it is the spot that functions as a transport object. That is why you cannot build a new BAdI and just forget about the framework in the way you might be accustomed to with classic BAdIs. It is also not possible to build the BAdI first and take care of how it fits in the structure of containers later. When building a BAdI, you have to put the BAdI within the relevant structure from the very beginning. But it is only mandatory to have simple containers. Composite enhancements spots and composite enhancement implementations are not enforced by the tools.
