How many user exits are working in your R/3 environment? What is the objective of a particular VOFM (Maintain: Requirements and Formulas) routine? When was a customer exit last modified and why?

When I ask these questions of new clients, I'm greeted with everything from blank stares to a resounding, "I don't know." I'm not surprised at the answers, because user exits are considered "deep areas" of SAP and often pass under the radar of even the most vigilant and documented implementations. Why? There are a couple reasons.

First, consultants or programmers who developed user exit functionality may have left either the project or the company with little knowledge transfer. Second, the level of technical granularity required to understand and stay on top of user exit development is out of scope for most project managers. As a result, programmers did what was necessary to make a business process work. While the process was documented, the necessary bits of custom code to hold the process together escaped management's attention.

What I do find surprising, however, is that with the growing awareness and concern over new regulations such as the Sarbanes-Oxley Act and the increasing focus on managing internal controls, the areas of a company's ERP system that exist for no other purpose than to modify the standard behavior of SAP receive little or no attention by Sarbanes-Oxley audit committees. If all businesses ran with "out-of-the-box" preconfigured versions of SAP, Sarbanes- Oxley would be a moot point. The accounts would reconcile. Data integrity would be unquestionable. Financial transparency? No problem.

But the fact is that companies need to customize SAP. As much as they want to heed the project manager's call to "change the process, not the system," they find it impossible to run their businesses without customizing SAP to some extent. Most of the customization takes place in the IMG. This is understood. IMG changes are interwoven in project plans, incorporated into process terminology, and managed by team leads. But user exits ...

User exits are sporadic. They are different for every company. The custom ABAP code in a user exit differs with each idiosyncratic problem that cannot be solved with standard SAP functionality. Do user exits present a control risk? Absolutely. Is there something you can do in SAP to mitigate the risk? You bet. You can design a control dashboard.

The Control Dashboard

"Control dashboard" is the term I use to describe an interactive, custom program that identifies, documents, and helps audit the use of user exits in your system. Like the dashboard in your car or the cockpit in a plane, the control dashboard presents information in a manner that communicates a vast amount of knowledge with a quick glance. Achieving real-time, real-world clarity on key modifications that pose a control risk in your R/3 environment is what makes the control dashboard so compelling.

A control dashboard consists of four overlapping elements: a user-exit repository, documentation, audit history, and status control. (Each of these is highlighted in the section, "How to Create a Control Dashboard.") The goal of a control dashboard is to provide a level of transparency into the areas of your R/3 environment that contain custom ABAP code. For a Sarbanes-Oxley initiative, you may want to narrow the scope to all custom ABAP code that affects financial data or processes.

Figure 1 shows a control dashboard that I created in a 4.6D system. The main R/3 screen is divided into three windows. The first window on the left presents a tree structure listing all the user exits/custom programs in the control dashboard data repository. The tree structure allows users to create nodes so they can organize the program controls according to topic — much the same as you organize files into directories within Microsoft Windows. In this example, I have nodes representing controls within finance, Logistics Information System (LIS), Materials Management (MM), output, pricing, etc.

Figure 1

Sample control dashboard

The first control in the tree structure is a Z program called ZSUMMARYINVOICE. Notice the status stoplight preceding each control. The status indicators let users know at a glance whether a particular control has been tested after the most recent change. A green light indicates the control has been tested and approved after the most recent change. A yellow light indicates a control has been changed and is scheduled to be tested. A red light indicates a control has been changed but has yet to be scheduled or tested.

If a user double-clicks on ZSUMMARYINVOICE, the second and third windows appear. The second window contains all the detailed information underlying the ZSUMMARYINVOICE control. This includes the control objective, miscellaneous notes related to the control, user information, change and testing dates, and the ability to view the code within the user exit or the most recent change transport. The second window also contains a series of buttons that allows the user to configure the dashboard (i.e., create new nodes) and add master data (i.e., testing dates, objectives, etc.).

One button that is particularly useful is the Dashboard Change Report (Figure 2). The change report can highlight changes that have occurred to custom programs and user exits during a specified period of time. In this example, 15 user exits were changed between 9/10/2003 and 11/10/2003. The change report highlights the name of the user exit that was changed, the transport request that contained the changes, the transport description, and the date of the change as well as the user responsible. This information can assist the internal audit and Sarbanes–Oxley audit teams when they compile their quarterly internal control change reports.

Figure 2

Dashboard change report

The third window displays browser-based information. In this example, I created a transparent table that associates each control in the dashboard with an Internet URL. The ZSUMMARYINVOICE control triggers www.Sarbanes-Oxley.com. This link relationship can just as easily associate third-party HTML-based documentation tools with the dashboard controls.

The control dashboard is unique from most other Sarbanes–Oxley tools because it is built right into your R/3 system and assigned a transaction code (typically ZCONTROL). Once it is in your system, it operates according to the same rules and restrictions (i.e., transports, security, accessibility, etc.) as your other R/3 programs. See the sidebar, "A Manager's Guide to Control Dashboards," for helpful tips and information about the scope of the project.

How to Create a Control Dashboard

The following five steps will help you create a control dashboard in your R/3 system.

1. Identify and create a single data repository for all exits that may pose a control risk to your financial data. To find these exits, I recommend deconstructing the financial statements. (See the sidebar "Deconstructing the Financials.")
   
   
2. Document the purpose of each exit.
   
   
3. Integrate each exit in the repository with the transport management system.
   
   
4. For testing purposes, create on/off toggle functionality for each exit.
   
   
5. In 4.6C and later systems, link the exits in the dashboard to internal Sabanes-Oxley documentation.

Step 1: Identify and create a single data repository for all exits that may pose a control risk to your financial data. Imagine that a review of transport logs, OSS-registered objects, and internal team discussions led you to conclude that there are approximately 100 user exits being used in your R/3 environment. Let's further assume that after deconstructing the financials, you have identified 30 (of the 100) user exits that have an impact on critical financial processes and reports. These 30 user exits should comprise the basis of your dashboard data repository. They are points of risk — areas where system functionality deviates from normal SAP R/3 behavior. Consequently, they may affect the accuracy and reliability of financial reporting.

To begin building your data repository, use transaction SE11 to create a Z table, which I named ZCONTROL (Figure 3). This transparent table should contain the name of each user exit, the date it was created, the name of the programmer who created it, and other information related to the user exit. It houses the majority of information contained in the dashboard. This table provides the foundation for the information contained in your control dashboard. For more help on creating tables, refer to SAP's online help.

Figure 3

Create a ZCONTROL table

Step 2: Document the purpose of each exit. Create a "control objective" for each exit. I recommend accomplishing this task by creating a new field in your Z table. The new custom field should be defined as a text field with enough characters to permit a descriptive control objective.

A key question to ask yourself is, "What is the purpose of the user exit and what, if any, controls exist to ensure the desired functionality is carried out?" For example, one client relied on a custom-designed ABAP report to generate customer invoices. After months of operation, the accounts receivable department noticed customers were consistently underpaying their invoices. It turned out that some of the invoices printed total amounts that were less than the actual invoice amount passed to accounting. The customers were paying the full amount of the invoice, which just happened to be less than the amount accounts receivable was expecting.

After fixing the problem, additional code was placed in the invoice program to reconcile the total amount about to be printed on the invoice with the amounts passed to the BSEG and BSUG accounting tables. This control code eliminates erroneous invoice amounts by reconciling the printed total amount with the amount passed to accounting. It should be documented in the dashboard in the control objective field.

In this example, the control code is a separate section of ABAP code (a sub-module) that exists within the larger custom ABAP print program. It has no other purpose than ensuring a final reconciliation is performed before printing invoices. The control objective of program ZSUMMARYINVOICE in Figure 1 is to ensure that the totals in the invoice output match the totals in accounting.

Step 3: Integrate each user exit in the repository with the transport management system. Integrate the objects in the dashboard data repository with the transport management tables. Tables E071 and E070 can help with this process. E071 can help you find the transports associated with your user exit or custom program. E070 can help you find dates associated with the transports. Figure 4 shows some sample ABAP code accessing these tables taken from the control dashboard.

Figure 4

Sample ABAP code to access tables

As the example indicates, the important fields to identify are TRKORR and OBJ_NAME in E071 and TRKORR and TMSDATE in E070. Integrating objects in your dashboard with the transport management system allows your dashboard to reveal when critical user exits are changed and who changed them. In this sense, the dashboard provides an additional auditing tool to monitor changes made to custom programs and user exits. A report on this information may help the audit committee when it does its quarterly internal control assessment by summarizing critical internal controls that have been changed over a specified period of time, as well as the users who changed them.

Step 4: For testing purposes, create on/off toggle functionality for each exit. The idea for this functionality came from a collective SAP note describing ideal user exit design. The note described the challenge faced by OSS in separating legitimate system problems from problems caused by customer modifications (i.e., user exits). The OSS recommendation is to create a repository (Z table) that contains two fields. The first field is the name of the user exit. The second is a corresponding check box that contains one of two possible values (on/off). To accompany the Z table, each user exit in the system is qualified so that it is only triggered when the check box in the Z table indicated that the user exit is on. For example, you might want to preface the audit reconciliation control code mentioned earlier with a conditional statement that checks the Z table to see if the user exit is on or off. If the Z table indicates the user exit is off, then the code is not executed. Since the ZCONTROL table contains a repository of user exits, toggle functionality can be added to the dashboard's list of features without much difficulty. Basically, just add a check field to the ZCONTROL table.

Step 5: In 4.6C and later systems, link the exits in the dashboard to internal Sarbanes-Oxley documentation. If your version of SAP is 4.6C or greater, you can take advantage of object-oriented programming and incorporate browser-based functionality in the R/3 environment. The specifics of how to do this are beyond the scope of this article, but I would recommend reading the November/December 2001 SAP Professional Journal article, "SAP Controls Programming Essentials—What Every ABAP Developer Needs To Know," by Rehan Zaidi. I would also recommend the book ABAP Objects, by Horst Keller and Joachim Jacobitz (SAP Press, 2002). Incorporating a unique browser window into your dashboard allows you to link user exits to HTML-based documentation tools, the Internet, or corporate intranet. The content of the browser window can be different for each control and thus, work in tandem with many other documentation tools.

Taylor Erickson

Taylor Erickson has more than 12 years of experience with ERP systems. He has worked with SAP for eight years, specializing in SD/SCM, reporting, and compliance. Taylor is a member of the Institute of Internal Auditors and has facilitated global SAP system implementations and trained numerous SAP customers. He is currently a manager at BearingPoint. Prior to that, he was a consultant for SAP America, and later, practice director of corporate compliance and security for Virtuoso, LLC, an SAP FI/CO consultancy. His latest research is on the effects that Sarbanes-Oxley will have on IT departments running SAP, and leveraging existing R/3 functionality to achieve compliance.

You may contact the author at taylor.erickson@bearingpoint.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.