Chapter 5 - Our first Planning Function

Introduction to planning functions

Planning functions are used to manipulate the planning data. This manipulation could be in the form of basic functions such as copy, move or clear data to more complex functions such as top-down distribution or custom calculations.

 Become a Patron! 

BPC Embedded have several standard planning functions included. We will cover some of them but spend more time on the custom calculations, using FOX, ABAP and sql.

Our first planning function will consist of a copy function, where actual volumes is copied from the Actual Volume aDSO TVOL_V00, to the planning aDSO TVOL_A20.

Implementing Planning Functions

Let’s look at the settings and options available while creating our first planning function by way on an example. Let’s create the following planning function based on the aggregation level created in the previous chapters.

First, we select the name and function type, aggregation level for the function:

Next, select the characteristic usage. All the characteristics in the aggregation level will be listed, but we need to select only those characteristics which will change. In our case, we are copying between versions. We know are actual data is stored in version/value type 0/10 and we want to coy to version/value type 100/20. As we are partitioning actual and plan data in separate InfoProviders, the InfoProvider also changes. We will select the following fields as fields to be changed:

Under parameters, we can either choose specific key figures to copy or copy all key figures. In our case, the aggregation level contains a single key figure, so we can go with either option:

Next we enter the copy from-to parameters. The copy from parameters will be our reference data and will contain the source version, value type and InfoProvider:

Our copy to parameters should equal to the values in our filter, to the extent that they are contained in the to-be-changed list.

To keep the number of entry variables to the minimum, it is essential to keep the variables the same as far as possible. Don’t use TRG_VERSION in the filter and TAR_VERSION in the copy to parameter of the copy function. Doing that will give the use two target variables, and a mismatch between the two will result an error.

Implementing Planning Sequences

Implementing planning sequences are really simple and is simply the combining the objects we created to date. Create the planning sequence with the following settings:

And then allocate the aggregation level, filter and planning function to it and then save.

We can now execute the planning function. First we will execute it in trace mode, which executes the planning function on the application server but gives us a trace of the records. Select the relevant variables by pressing the  (Variables) button, for example:

Press the

 (execute step with trace) button.        

A trace tab  will appear and we should be able to see a list of records.

The records are organised according to blocks. All the block characteristics are the characteristics we have not selected to be changed. The concept of blocks are important, especially when we start writing HANA sql routines. For each block, the system tells us the record count in the target area before and after running the planning function. In this case, 1 new record has been created and no messages were issued.

Selecting a block and clicking on display contents will display the result of the copy. Here the fields-to-be-changed are displayed showing the source data as Reference as well as the record written to the target area as New. If a record was found in the target area, but its value was changed, it will be displayed as type Changed.

Looking at the messages issued for this function:

The records read are the records selected by the filter, i.e. the target area. Since we start off with an empty area, the number of records are expected to be nil. The second message confirms the fact that trace mode runs the function on the application server, which means that the execution logic is not pushed down to the HANA server.

Data can now be saved data by pressing Save Planning Buffer. If we immediately run the function again, the messages should now change to:

Since we have just copied the same data again, no records read from the target area were generated or changed.

It is possible to string many planning functions together in a planning sequence. These planning functions do not need to be based on the same aggregation level.

The Planning Buffer

The planning buffer is an important concept in working with SAP BPC. Planning functions work with the data stored in the planning buffer and the data is represented by the selection made in the filter. Each user that runs a function, writes to their own planning buffer, and each user’s personal planning buffer is locked against changes by other users. 

As functions are executed in a sequence, it continually uses and updates the planning buffer. This alleviates the need to continually save the data and thus helps with performance.

Each time a planning function is executed, the system first checks if the data is available in the planning buffer. If not, the information is read from the required planning object.

Conclusion

We now have all the planning objects available to do basic planning. We also have a planning function to be able to coy data from actual information to our planning cube. This copy function is very limited, as it only copies from one version to another in the same time periods. This in itself is not very useful. We want to copy the data into the future periods, defined as our planning horizon. This new copy function, the ability to adjust planned data in Excel as well as several other planning functions will be the main topic of the next few chapters. But first, we need to be able to manually adjust the planned values, which is where we will be heading in the next chapter.

If you like this chapter, please donate so that I can continue creating great content: