Most R/3 standard reports are time-based. They show you the status of a financial object over time — the revenue variance from budget at the end of May, or the cumulative indirect expenses up to the end of June, for example. In some cases, however, event-oriented reporting is a more useful option, particularly for monitoring and controlling cost and assuring smooth performance by a business model. Potential event-reporting requirements for a business might be:

• List all materials that were received late or by their due date.

• List all projects that exceeded budget.

• List all activities that did not complete by their early finish date.

Although the requirements are simple, the translation to the SAP world can be complex. For example, how do you determine that an activity is not finished by its due date? Would you check the forecast hours, if actual hours are confirmed after the early finish date, the percentage of work completed, or all of the above? SAP R/3 does not currently have many standard reports that are event-driven or event-based, but one example is the Exception Reporting tool in CO’s Project Systems (PS) module. It is also possible to create what you need with ABAP. I’ll give you some ideas about implementing event-oriented reports, but first let me provide a little background.

What Is Event-Oriented Reporting?

To understand event-oriented reporting, let’s look at two reports. Figure 1 shows the selection screen from a customer overdue report. This time-based report provides an aging analysis of all receivables that are due as of the current system date. It uses a time-based filter through the Open Item at Key Date field. Figure 2 shows another selection screen from a project report that is based on an event. It displays all projects that have been completed using a status-driven filter (system status = TECO). This report represents an event: the completion of the project.     The fundamental difference between the two screens is the availability of an event variable in the second example. The first screen has the usual selection fields such as Customer Account, Company Code, and a time-based variable (Key Date). The second one has typical selection fields such as Project Number and Network Number. In addition it has a button called "Status." Through this button, you choose a status profile that includes only System Status TECO (Technical Completion). This is the event variable that enables you to report the status of your project based on an event. The event-oriented report, which has been around since the Old Testament days of information processing, can be one of three categories. 1. Driven by an event. These reports arise out of something happening, such as when a batch process fails to open an account balance and aborts. At this point a report is generated with the information about the failure. This report might be sent by e-mail to a technical support person, or sit in a repository to be reviewed by a group of people. 2. About an event. These reports are simply informational about an important occurrence. For example, say you have a budget of $1,000 for a cost center. When you hit $1,000 in actual expenses, you have exhausted budget. This is an event. A project-related example might be where you have a task planned to take place from January 1 to January 8. On January 8, you have not finished. This is an event. And a materials-related example would be where you have ordered an item to fulfill a requirement that is due on March 3. It arrives on March 5. Ordering the item and the item failing to arrive are each events. 3. Triggers an event. Reports that (sort of) read themselves and take an action that is important to the organization represent the third category. Say that several errors occur in a collective month-end processing. These errors are logged in a report, and one is a high severity error that requires immediate attention (the last day of the financial month has been modified without due diligence). An action is taken by the system and a pager number of a support person is dialed automatically. All other processes waiting to be executed are held back. As the above examples show, event-oriented reports often "push" information to another location or user rather than "pull" it from another source. You might have heard that push functionality is out of favor in the IT world, but it has an important place. In fact, manufacturing automation and other real-time information system applications depend more on push rather than pull. Pull is great for research and analysis. Push is great for stabilization and automation. SAP has not really had an event-reporting strategy across R/3 modules. I am excluding objects in R/3 that are already declared as an event — for example, the hiring of an employee. I’m also excluding the Event Management module. I am referring to events that occur in the core modules such as FI, CO, MM, or PS. Similarly, R/3 does not have many standard reports that apply the push strategy. Take, for instance, month-end closing activities. SAP delivers no standard alert system that reports on exceptions when they occur. In fact, the lack of event-based standard reports has been one of the most common complaints about R/3 reporting. Although it is possible to write reports using ABAP that are event-based (see below), it would be nice to have a basic toolset of standard reports and an event-driven report writer.

Event Reports Using the CO-PS Exception Reporting Tool

However, some R/3 reports are event-based and are useful under certain circumstances. One is the Exception Reporting tool, part of the cost reports in CO-PS. It provides you with a facility to flag exceptions. Using these exceptions, you could model important events in your organization. Let me walk you through one example of how you might do that. Say that you want to have a figure in a Planned/Actual/Variance report display in a different color if it exceeds $50,000:  Step 1. Follow the menu path Project System>Information System>Financials> Cost>Plan-Based>Hierarchical>Plan/Actual/ Variance (transaction code S_ALR_87013532). Launch the report with a project number. This is the Plan/Actual/Variance Report.  Step 2. Click on a cell and then click on the Extras menu item, as shown in Figure 3.  Step 3. Click on the Exceptions option.  Step 4. In the lower right of that window (Figure 4), enter 50,000 in the Threshold field and select the desired color below it. Make sure that the color is sufficiently different from that selected for the lower threshold, and that the proper condition items are selected. With this feature you could easily set up a "value exceeded" event that would serve as a warning while spending against a cost object. Note that almost all cost reports in CO-PS also have a Status Selection option. Since a status is based on an event, these qualify as event-oriented reports, too.    

ABAP for Event-Oriented Reporting

Writing ABAP to do event-oriented reporting is always a good idea. When used for reporting, ABAP does not introduce any risk to the fundamental processing characteristics of the SAP module. However, it delivers a high level of acceptance with the user community. Here are some tips to follow when doing this. They will apply no matter what R/3 module you are working with:

• Begin with making a list of events. What events are important to your organization? What needs to be done before, during and after the events? The answers to these questions set a good foundation for your event-oriented report requirements.

• First try to use a standard report with filter capabilities. Remember, reports can be set up to run in the background and can be timed in advance to run every day if necessary to trap an event by a filter condition.

• Write ABAP functions that identify simple events in your system. This will ensure that you can reuse them for different reporting requirements.

• Category 3 requirements almost certainly need some ABAP code.

• Consider the delivery mechanism; push makes the event-oriented report far more effective than pull.

Let’s apply these guidelines to an example. Say you want to make the popular report 1SIP_001, "Plan versus Actual Report for Cost Center," event-oriented. You begin with making a list of events. Events that are useful for tracking could be:

• Cost Center exceeds budget.

• Cost Center gets within 80 percent of budget.

• Spending against plan for a month falls short by over 20 percent in the last week of the month.

Next, try to use a standard report filter. Unfortunately, filters available for this report do not lend themselves well for modeling the events you have chosen. So, you decide to use ABAP. Using ABAP, you write code that compares the key figures you are interested in. Use this code as a filter over the standard report. You also define this code as a reusable function so that you can use it in other reports. Next, consider the delivery mechanism. You do not want the cost center manager to pull the report. Instead, you want to push the report to him or her when these events occur. This is considered a category 3 requirement. You achieve this by configuring a workflow task. The ABAP code calls this workflow task, evaluates the agent (the cost center manager’s user ID must be identifiable in the system) and delivers the report to the manager. Event-oriented reporting is a useful and sometimes essential alternative to conventional reporting techniques. The Exception Reporting tool in CO-PS is one of the few standard means of creating event-based reports that SAP offers. However, you or your technical cohorts can easily create event-oriented reports using ABAP and the guidelines given in this article.