One of the primary questions that arises when considering or developing a Business Planning and Simulation (BPS) solution is “How does it fit with my transactional systems?” This should indeed be a key consideration, as the stated goal is the reduction of cost and effort by streamlining processes, centralizing data, and simplifying the user experience.

When transactional processes use the results of the planning process, it is a great advantage to be able to push information from SAP NetWeaver Business Intelligence (BI) back to an SAP transactional system, such as R/3, mySAP ERP, or mySAP CRM. This process is called retraction. Some examples of this include pushing labor activity costs back to Cost Center Accounting (CO-CCA) for ongoing product cost controlling, creating newly approved capital projects automatically in Project System (PS), and enriching CRM Business Partners with additional marketing attributes.

SAP provides several standard retractors for planned financial expenses. However, to retract plan expenses into modules such as CO-CCA or PS, you may need to build a custom retractor to gain the functionality you require. This will likely be the case if you are retracting master data or transactions that affect actual financial results. You can easily develop custom programs to enhance the retraction of plan data or retract the results of your BPS data collection into master data or actual accounting modules as well.

I’ll show you how to configure the standard retractors, and then go on to explain how you can add customized retractors for scenarios that the standard delivery doesn’t cover. I’ll examine the common planning function setup as it is required for standard and custom solutions using the example of cost center planning. You can follow similar steps for the other functional applications supported by SAP. Note this example is based on a BI 3.5 system that includes BPS functionality. In previous versions of BI, you would need to install Strategic Enterprise Management (SEM) to use BPS functionality for any module. The majority of work described in this article would typically be completed by a functional BPS implementer. Some assistance from development resources may be required to write or modify function modules for custom retraction requirements.

Standard Cost Center Retraction

A typical method of moving transactional data from a BI system back to an ERP instance is through a planning function of type Exit in BPS. The function type tells you what kind of module performs the function — Exit indicates an ABAP function module. You select the function type as you configure planning functionality in the Planning Workbench.

Call transaction BPS0 to access the Planning Workbench within your BI system. Double-click to select the planning level from which you would like to retract data. Right-click on the name of the planning level in the lower left Planning functions area and choose Create planning function. In the ensuing dialog box, provide a suitable name and description, select the option for Exit Function, and click on the green check mark to proceed.

Note that SAP delivers the planning area in this example, 4EXPPL01 (Figure 1), as part of the SEM content. So even though with BI 3.5 you don’t need SEM to use BPS in general, SEM is required to access this particular standard planning area – even with a BI 3.5 installation. This planning area contains a complete preconfigured set of retraction capability.

Figure 1

Start with standard SAP-delivered planning area 4EXPPL01 with retraction capabilities

Note
You may need to import planning area 4EXPPL01 from client 000. Access transaction UPB_APPL_IMPORT, and then choose the Cost Center Planning application. You can use this as a model or full solution depending on your customization requirements.

You need to set a few important parameters in the planning function. The system calls the FM initialization function module once whenever you trigger the Exit planning function. The standard function for this call is UPR_COST_PLAN_INIT for the purposes of cost center retraction. The Function module field specifies where the logic resides that is to be executed once for each unique combination of characteristics that is not being changed in the formula. Cost center planning uses function module UPR_COST_PLAN_EXEC, which expects the fields selected for the list of Fields to Be Changed to include Activity Type, Cost center, Cost Element, Partner Activity, Partner Cost Center, Posting Period, and Statistical Key Figure. All characteristic fields from the planning level are initially displayed in the Field List. You can move them into the Fields to Be Changed list. 

The parameters shown in Figure 1 are also critical for using the standard retractor. The function module expects these parameters and they must be explicitly populated via a planning parameter group. Create the parameter group by right-clicking on the planning function in the lower left corner of the workbench, Choose Create Parameter Group. Figure 2 shows the standard-delivered parameter group to retract primary planned cost center expenses.

Figure 2

Note standard configuration for planning Parameter Group primary cost center retraction

The Retr. R/3 Comp. identifies which application is being targeted in R/3. Figure 3 shows a complete list. The Retractor Control further defines the specific transactional data being retracted.

Figure 3

R/3 components available in a BW 3.5 system

You can view a list of Retractor Control values in Figure 4. Delta Update defines whether the retraction is to overwrite or add to existing figures in the transactional system. The Destination identifies a specific ERP client in which the updates should be made.

Figure 4

Available retractor targets for CCA in a BW 3.5 system

Now that you have configured your complete planning function, you can double-click on the 0-ADHOC planning package and then the parameter group just created to run it within the Planning Workbench. You may also include the function in SAPGUI-based planning folders or Web interfaces just as you would any other planning function. End users can request their own immediate retraction of data from the BPS system into the transactional system by clicking on a button within the Web- or SAPGUI-based interface where they perform other planning tasks. Note data locking can be an issue with retraction, as the system attempts to lock any data being retracted to ensure it is not being actively updated during the retraction attempt. Make sure your planning level is sufficiently restricted to limited data or your planning process is such that planning and retraction are not taking place simultaneously.

Custom Retractors

Information beyond the standard planned financial expenses, for which retraction is accommodated by SAP, may also be of use in the transactional system. You must create custom retractors for any information you’d like in your transactional system for which SAP does not provide a standard retractor. For example, you may ant to create a manual cost allocation transaction that transfers expenses from a cost center to an internal order or project. You can accomplish this with the following steps:

Step 1. Create a remote function module in the operational system. Use this module to perform the actual cost transfer transactions – such as KB21N (activity allocation) – based on data provided by your BPS solution. Ideally, the function module would take advantage of a standard SAP BAPI to perform the actual transaction, but it may be necessary to include further logic prior to the actual transaction. For example, you may need to check existing account totals to accommodate repeated retraction within a single financial period. See Figure 5 for an example of a function module you could implement in the transactional system.

Figure 5

Sample R/3 retraction target

This function module receives an internal table of parameters from the BPS system, including fields representing the fiscal period, target internal order, source cost center, allocation amount, and allocation cost element. The logic first checks for existing transfers between the cost center and internal order within the fiscal period of interest. The system passes along any difference between the value received from BPS and that stored within the ERP system to a subroutine that creates and posts a manual allocation transaction.

Step 2. Create an exit function module in the BPS system. Create a new function module, such as the one shown in Figure 6, that can send tables of data back to the transactional system for posting. This example loops through the table of data passed along from the BPS application and moves it into a structured table that fits the required definition on the transactional system. It then places a call directly to the remote-enabled function module created in step 1. To accommodate error handling, you should include exceptions in the function module interface to enhance this sample code. Determine the destination system through a lookup or some form of customization instead of this hard-coded solution that explicitly names ERP_REMOTE as the target.

Figure 6

Sample BPS code for sending retraction data

I have hard-coded field names of the internal table lt_retract in Figure 6. If you use a consistent client number in all of your BPS instances, you then can reference a table structure generated for your specific planning area without hard-coding. This provides greater flexibility and reduces maintenance effort, as your planning area definition is modified through Planning Workbench configuration. If you have multiple client numbers, this does not work, as the system takes the client number into consideration when it names the generated table structure. Therefore, code created in your development environment may no longer pass a syntax check when you transport it to a testing system. Figure 7 shows the standard SAP code you can use to identify the appropriate table name.

Figure 7

Code used to identify the generated table structure for planning area TEST

The table is typically named /1SEM/_YTH_DATA_<client><area>, where <client> is replaced by the SAP client number and <area> is replaced by the short name of the planning area.

Step 3. Create a new function of type Exit in the planning workbench. This is virtually identical to the steps followed for retracting standard cost center data above, with a couple of special considerations. The initialization function module identified in the planning function is called once whenever you trigger the Exit planning function. This module can be empty if no activities are required. A blank example is displayed in Figure 8 for your reference. The Function module planning parameter should reference the function module you developed in step 2. This function module is called once for each unique combination of characteristics that are not being changed in the formula. With that consideration in mind, it often makes sense to add characteristics to the list of fields being changed to optimize performance by minimizing the number of unique Remote Function Calls (RFCs) made back to the transactional system.

Figure 8

Blank initialization function module showing necessary parameters

As you can see, using standard or custom retractors to link planning results back to transactional systems can be relatively straightforward. The examples shown here are only a couple of many possible applications. Most follow a very similar path of combining detailed requirement gathering with a bit of technical implementation. In my implementation experience, I have done everything from copying the standard retractor function modules to accommodate slight enhancements all the way to complete custom development that fully empowers users.

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.