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.