The maintenance of user exits often becomes a time-consuming chore. The author shows a simple way to manage your company's user exits through a custom control table. He enhances his solution with an example.
In an ideal SAP world, standard SAP fills all your needs and you never write user exits. The reality, however, is that
almost all sites have requirements not supported by standard SAP. This is why SAP created user exits as placeholders for
custom code.
It is common for companies to have many user exits, some of which can be long and complex. Managing the
development and maintenance of these user exits is a challenge. For example, one of the most common user exits in the R/3
Sales and Distribution (SD) module is MV45AFZZ, which is
provided for modifications in sales document processing. Especially in larger corporations, so many custom
requirements in sales processing are needed that the code for MV45AFZZ can run into thousands of lines.
In addition, an organization might have many different sales initiatives in various development stages
with different go-live dates. To meet these varied requirements, code must be written to accommodate all the possible
scenarios.
Figure 1 shows a common way of writing user-exit code. The code is written for three
initiatives: Europe Drop-Ship Project, Asia Go-Live Project for Local Deliveries, and Free-of-
Charge Orders. Typically, the code is recognized by specific objects in your company such as sales document types
or organizational objects.

Figure 1
A typical way of writing user-exit code for different projects
I want to share an easier way to manage user exits. Although my example is from SD, the methodology is
applicable to any module. First, let me review the problems associated with the typical way of writing user exits.
Business Problem
Let's take a common situation: What if Asia Go-Live Project is delayed? You can't move
the code through the development-to-quality assurance-to-production pipeline, and you can't delay other projects. The
obvious answer is to remove the code specific to that initiative and move the remaining user-exit code to the quality
assurance-to-production environment.
The difficulty with this solution is that testing different sales business processes, especially
integrated scenarios, becomes extremely difficult. During the testing phase, the individual project teams can adversely
affect each other and must coordinate their efforts. This sometimes becomes a bottleneck. Once Asia Go-Live
Project is back on schedule, the developers must reapply the code that they removed and other project teams have
to retest their
scenarios to make sure they pass regression tests. This
situation becomes very complicated to manage.
Simple Solution
A simple solution is to create a custom control table that maintains lists of various initiatives within
your organization. Each initiative is identified by a Proj_Id indicator representing whether the project
is active in your current SAP environment. Active means the user-exit code is
developed and the business process is ready to be tested. Figure 2 shows this control
table. Note that five of the
initiatives are active in this SAP environment.
EUR_DROP |
Europe Drop-Ship |
X |
EUR_REPAIR |
European Repair Processing |
X |
ASIA_LOCAL |
Asia Go-Live |
X |
ASIA_SUB |
Asia Sub-Contracting |
|
FREE |
Free-of-Charge Orders |
X |
NA_REPAIR |
North America Repair Processing |
|
NA_ACC |
North America Account-Based CO-PA |
|
NA_SUB |
North America Sub-Contract Processing |
X |
|
|
Figure 2 |
Sample table (ZPROJECTS) listing
initiatives |
|
When you write the user-exit code, qualify it so that it is triggered only when that particular project is
active in the environment, as Figure 3 shows. You trigger your user-exit code for a specific project only
if its flag is set to Active in the control table. For example, if the Europe Drop-Ship
project is active in your environment, then the user exit is triggered. Otherwise, it is skipped.

Figure 3
A better way of managing custom user exits
If the Asia-Go-Live Project in my earlier example is delayed, you can still move the
whole user exit to your quality assurance environment by clearing the Active flag in the custom table. When that project
is ready, simply turn on the switch to activate the user-exit code. Note that this solution is not my magic. SAP uses this
methodology when it writes its programming code.
The biggest advantage to this method is the flexibility it gives the project management team to deal with
different and sometimes conflicting initiatives. Another advantage is that it gives you enough time to manage. Say your
project, which needs a user exit, is going live on January 1. Before the processes starting January 1 call the new user
exit, you have to make sure that the code moves on the night of December 31. The advantage of using this methodology is
that you can move your code much earlier and be ready. On December 31, all you have to do is set the active indicator on.
This methodology helps the project team troubleshoot problems while debugging. By setting and clearing the
active flags, you can easily point out the cause of the incorrect process and then, if required, dig deeper for specific
code.
Finally, let's say that you later no longer wish to process Free-of-Charge Orders in your
organization and want to remove the associated user exit code. To do so, just turn off the active flag. You don't have to
actually remove the code from the user exit.
I am sure that this solution can be further fine-tuned — for example, by controlling further
parameters. This tip will also work with Business Add-ins (BAdIs).

Mitresh Kundalia
Mitresh Kundalia heads the SAP practice at Quality Systems & Software (www.QSandS.com), a consulting firm specializing in SAP S/4HANA, SAP General Ledger, and complex System Landscape Optimization (SLO)-type reorganizations. Mitresh is widely acknowledged as a leading SAP expert, with multiple publications and an SAP-PRESS book to his credit. He has published more than 50 peer-reviewed articles and white papers, and he has given presentations at various SAP conferences and events. Mitresh is the chief solutions architect of General Ledger Migration Optimizer (GLMO), a leading product to accelerate and jump-start the SAP S/4HANA and SAP General Ledger initiatives; SAP Data Reorganization Optimizer (SDRO), an SLO-type product for managing complex system landscape reorganizations; and Group Currency Activation and Conversion (GCAC), a product suite to manage introduction of parallel currencies and conversion of data in a live SAP system.
You may contact the author at Mitresh@QSandS.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.