SAP provides several useful opportunities to insert custom code within SAP Strategic Enterprise Management, Business Planning and Simulation (SEM-BPS). For example, it might be useful to populate the object currency characteristic automatically based on the value of a cost center variable. Documentation is available for most of these opportunities for custom code, but it is scattered and does not necessarily address when to use each type of exit. The examples I discuss here illustrate how you might use variables, exit functions, Status Tracker sequences, and characteristic relationships (Table 1).

The screenprints I use are based on SAP SEM Release 3.2, which runs on SAP Business Information Warehouse (BW) Release 3.1. The information I provide here, however, applies to all recent releases of SEM, including Release 3.5. Note that similar business planning functionality is now offered as a standard component of BW beginning with Release 3.5.

While functional analysts will require assistance from technical team members with the function modules I describe, they should be able to complete the configuration required to activate the exits and specify their appropriate use after read-ing this article. The function module must be created first, because it is a key input value for configuration. I'll show key components of sample function modules that I developed throughout the article. Full code is available for download at the bottom of this article. I assume that the reader has training or basic experience with configuring BPS.

User-Exit Variables

Perhaps the most frequently used exit in SEM-BPS, a user-exit variable is a type of variable that relies on a function module to define its value or a set of values from which users make their selection. Call transaction BPS0 to access the Business Planning Workbench. (Use this transaction to reach the other Business Planning Workbench screens in this article.) Create a variable by accessing the Variables tab within your planning area in change mode. This exit approach works for all types of variables — characteristic values, hierarchy nodes, numeric values, and attributes — although the function module parameters vary slightly. When creating your variable, select User Exit Replacement Type and enter your function module name (Figure 1).

Figure 1

Meet Complex Business Requirements with User Exits in SEM BPS

This type of exit is commonly used to read the current value of one variable and derive the value of another variable. For example, perhaps you need to specify the object currency in your planning level, but it could change as the user moves among cost centers. First, determine the value of the cost center variable. Then you can access the master data table to determine the appropriate object currency and pass this value back to your user-exit variable. Figure 2 shows the important segments of the function module your ABAP team members would create to accomplish this task. SAP offers an excellent white paper, "SEM-BPS Variables of Type Exit," regarding this approach. You can find it at service.sap.com/sem under Media Library>Help to Use SEM>How to... .

Figure 2

Coding sections from user-exit variable

This same approach is useful to maintain variable values across planning areas. Perhaps the same user completes cost center planning in one planning area and capital budgeting in another planning area. Both areas require the limitation of the fiscal year so they are reused each planning cycle. Variables are defined by planning area, so the same fiscal year variable cannot be reused between these planning areas.

Rather than forcing the user to select the year twice, one variable can be used as the master and the other can be derived. The master variable would appear in all planning folders or Web interfaces, but the derived variable could be used in limitations behind the scenes.

While referencing another variable is certainly a valuable option, there is no limitation to the logic that can be included in a user-exit variable. I have used this option as an alternative to complex roles-based security. Rather than configuring a huge number of roles (to cover each organizational unit), you can use a variable that reads a custom underlying table to determine which organizational units users can access and present them with this limited list of values. Likewise, you could write a Numeric Value variable to read the planned selling price for a material master from an InfoProvider that is not part of the planning area.

Another extension of this same concept is to provide a Business Explorer (BEx) variable of type Customer Exit that reads an underlying variable value from BPS. For example, perhaps the version used to represent the current forecast changes each quarter. An end user can update the value of a Fixed Variable in the BPS Workbench and BEx reports using the special variable and immediately reference the new forecast version. This example is also covered in detail in SAP's previously mentioned white paper.

Exit Functions

Fox formulas are a key function within SEM-BPS that enable the manipulation of data based on coding logic. They are intentionally limited in complexity and functionality. Exit functions are available to manipulate data when encountering Fox formula limitations. Exit functions can also accomplish retraction functionality, whereby planning results from SEM are sent back to R/3 through configurable Remote Function Call (RFC) functionality. You can configure this type of planning function just as other functions within the Business Planning Workbench. Create a new Planning function and choose type EXIT. Specify the function modules at the function level and specify parameters within the required parameter group (Figure 3).

Figure 3

Sample of exit function configuration

The FM initialization runs once each time the function is executed regardless of the presence or volume of data. The Function module runs once for every unique combination of data produced by the characteristics to be changed. As such, it may not run at all if no data is available to process, but it may run many times if a number of characteristics are specified to change or many combinations of the specified characteristics exist.

An exit function can retract actual data into R/3 similarly to the standard features that retract plan data. For example, perhaps you want to use SEM to accomplish a cost center allocation that was not possible within R/3. Later, you decide that the results of the allocation should be posted into R/3 through the manual allocation process. The first step is to develop a remote-enabled function module in the R/3 system that would accept external data and create a transaction. It is a good idea to include logic in this function to account for existing allocation balances. This logic would enable the retraction function to run multiple times without duplicating entries. Finally, an exit function, such as the one found in Figure 4, can call this remote function module and hand off data found in SEM for posting.

Figure 4

Key code used to call remote function

Exit functions can also accomplish non-data tasks triggered through SEM as functions within planning folders or buttons on the Web. Perhaps you want the end user to trigger a business workflow or kick off a background job from the Web interface. You could write the background job to run a planning function that has a long runtime. This logic can be built into an exit function. In scenarios like these, it might make sense to use the initialization function module to remove the dependency upon transactional data and avoid running the same function multiple times for a single request from the user.

Status Tracking System Planning Sequences

The Status Tracking System is a Web-based tool configured in transaction BPS_TC that facilitates improved communication throughout the planning process. It is based on a hierarchy of characteristics and tracks a status associated with each individual node in the hierarchy. You can configure a global planning sequence to run each time that a status is changed for a given node. For example, the sequence could run an allocation automatically once total fringe benefits have been planned and approved. These functions can either run in the background or synchronously. If the synchronous option is chosen in the Attributes for Planning Session option within configuration (Figure 5), the planning sequence runs while the user waits for the status to change.

Figure 5

Planning session attributes configured in transaction BPS_TC

By including an exit function with logic that checks for unacceptable data and issues appropriate error messages, it is possible to prevent undesirable status changes from occurring. A classic example of this is ensuring that all dollars budgeted for a cost center are assigned to a detailed cost element. Figure 6 shows the assignment of a global planning sequence to a status change. Access this configuration by choosing the configuration option Determine Date, Person Resp., Layouts within transaction BPS_TC. Double-click on each node of the hierarchy to set the appropriate planning sequence for that org unit.

Figure 6

Assign a global planning sequence to a status change for a single node

Figure 7 shows an exit function that determines which node to change, checks for an unassigned value, and issues an appropriate error message. See Figure 8 for an example of the result when a user attempts to approve a cost center with a budget that is unassigned to a cost element.

Figure 7

Function module logic that checks current cost center for unassigned values

Figure 8

Error message received in Internet Explorer when submitting for approval

Characteristic Relationships

User-exit characteristic relationships have three characteristics. They can derive one characteristic from another, propose a list of valid combinations, or validate input values. Many of these capabilities are available through the use of characteristic relationships based on InfoObject attributes, but a user exit can enhance each area considerably.

To configure a user-exit relationship, open the Business Planning Workbench and enter your planning area in change mode. Navigate to the Characteristic Relationship tab. Create a new entry with Exit in the Type column. Select the appropriate characteristics that will be included in your logic and enter function module names (Figure 9). Note that you can include blank function modules if you are only looking to use certain aspects of this feature.

Figure 9

Characteristic relationship configuration within the planning area

Some simple logic may be necessary to derive the value of one variable from another. A common example is determining a fiscal quarter from a fiscal period. No attribute relationship exists between these InfoObjects, so you need a simple routine to read the fiscal period and determine the fiscal quarter. Figure 10 shows the key logic components of this function module. Remember, a characteristic derivation will run without the characteristic belonging within the planning level. Thus, a user may plan revenue by fiscal period and a function module automatically derives the quarter when the data is saved.

Figure 10

Meet Complex Business Requirements with User Exits in SEM BPS

When defining a planning layout, you must choose between displaying existing characteristic combinations and all possible combinations of characteristics. While it is possible to define restrictions that make all possible combinations more reasonable, these options can be difficult to maintain. Using a function module to determine possible characteristic combinations is an attractive alternative. For example, perhaps you want to provide certain cost elements for planning in combination with cost centers based upon the functional area assigned to the cost center. First, analyze the current cost center's functional area and then provide corresponding cost elements to populate a table with legitimate combinations. See Figure 11 for an example of this logic.

Figure 11

Sample code to propose a list of cost center/cost element combinations

You can use Fox formulas to issue messages when you encounter invalid combinations of characteristics, but they are only executed after the data has already been committed to the buffer. This leaves you in a position where the only recourse is to delete the offensive record or issue a warning and trust the user to resolve it prior to saving. Characteristic combination checks, on the other hand, are run upon user input and can apply validations to the characteristic combinations prior to accepting the entry. For example, you can protect a particular cost element for executive bonuses to a set of three cost centers. Figure 12 shows the code that issues an error message if a user attempts to use this cost element with another cost center.

Figure 12

Sample code to check for a certain combination of characteristic values and send an error message

Matt Christensen

Matt Christensen is the director of Enterprise Performance Management at PRAGMATEK Consulting Group in Minneapolis. He has more than seven years of experience implementing a broad set of SAP financial modules, including configuration and development in R/3, Business Information Warehouse, and Strategic Enterprise Management. Matt holds an undergraduate degree in computer science and an MBA in finance.

You may contact the author at matt.christensen@pragmatek.com.

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