Implementing SAP BPC Embedded 11

Being able to automatically move and copy data is very useful, but at some point human intervention in the plan is required. For this an interface between the InfoProvider and the user is required. The input ready query performs that function, by providing the user with a point of entry for planning data.

We will create several input ready queries in the course of this course. We will go through the settings step-by-step for the first query and layout and settings of the rest of the queries will be provided at the end of the relevant chapters of the guide. The first query we will build will be to enter price data. Recall that we have no actual data on which to base our prices, which in a real world application is unlikely, but it provides a useful way to demonstrate the initial entry of data.

Analysis for Office (A4O), is SAP’s easy-to-use Excel based application that delivers very powerful integration with BW Queries and other Datasource. It will be the primary tool used to manually enter planning data and to run planning sequences.

The features of A4O is vast and it can take a book on its own to cover all the functionality available, so this book will cover only those functions that are necessary for planning. We will go through the following features of A4O:

• Add queries to a workbook

• Add planning sequences to a workbook

• Add buttons to a workbook

Planning functions manipulate data in InfoProviders. We have already created a basic copy function, but now we will move on to more planning functions to create a complete planning application. Some of the functions that will be covered in this chapter as functions to clear, move and revaluate data. We will also cover basic fox, where we will rewrite the copy function.

From the simple copy function we created in the previous chapter, we are now going to dive deeper into FOX. In this lecture we are going to look at variables, loops internal tables and how to debug fox.

One of the main benefits of BPC Embedded is that there is virtually no restriction on the number of characteristics that can be included in a panning application. However, from a user’s point of view, it is neither practical nor desired to manually plan on every characteristic. Just imagine how many columns a user need to scroll through if there are 30 characteristics on the screen – the application would become unusable!

Several other problems are also common in planning applications:

• Valid planning combinations may not be intuitively known by the user. For example, certain products may only be available to specific customers and we only want those combinations to be calculated and displayed in the input ready query.

• The planning application may require fields that the user may not know at the time of entry, but must be calculated based on a complex set of rules.

• Planning may have been performed on combinations in a previous iteration that are no longer valid and we want to delete those invalid combinations.

Characteristic Relationships (or CR for short) is a powerful tool to get around this problem and several others. In this chapter we are going to do quite a lot with CR. At the moment, volumes planning are performed on material level, but the requirement is that Material Group is also populated. As stated above, the user may not know what the material group is when they enter the information or may not care, so we do not necessarily want to display the material group in the volumes planning input schedule. We will use CR to derive the Material Group in all manual planning and planning functions.

In the previous chapter we have seen CR in action thought attribute lookup. However, it is not very flexible as the attribute and target InfoObjects must be the same. There are many instances where we need to perform much more complex CR, such as the case we find ourselves in where the InfoObjects do not agree or even where we need to perform data mining of historical combinations to determine the most appropriate value.

In this chapter we will have our first look at amdp (ABAP Managed Database Procedures). An amdp allow developers to write database procedures directly in ABAP. You can think of a Database Procedure as a function stored and executed in the database. The implementation language varies from one database system to another. In SAP HANA it is SQL Script. Using amdp allows developers to create and execute those database procedures in the ABAP environment using ABAP methods and ABAP data types.

The following steps must be follow to create an amdp for CR:

• Create an ABAP class inheriting from CL_RSPLS_CR_EXIT_BASE

• Implement Interfaces IF_RSPLS_CR_EXIT_HDB & IF_AMDP_MARKER_HDB

• Create ABAP types

• Create method & sql script

• Add methods to ~get_sqlscript_info

• Create the CR in RSPLAN

• Create HANA procedure using SE38 (First Execution rule)

We will now look at each of these steps in more detail. Note that we will also move the attribute lookup to our amdp class for illustration purposes.

Receiving data on an aggregated level is quite common, for example, a 3rd party system may give us production or sales volumes on material level only, while we need it on material and customer level for planning. A standard planning function that distributes the planned volumes on material level to customer available in BPC Embedded. There are two options available for top-down distributions:

• Distribute by Reference

Data is distributed based on reference data. This could be historical data in the same of different aDSO.

• Distribution by Key

Factors are used to distribute data.

We will cover the top-down distribution of the planned volumes to customer based on the ratios in reference data. The reference data will be the last few periods of actual data in the TVOL_V00 aDSO.

In the quest to complete the requirements from our customer, we are now going to move on to calculating the revenues. We are first going to write the function in FOX and then in later chapters refine the calculation by writing it in an amdp (ABAP-managed Database Procedure). In this chapter we will look at a few new statements in FOX and we will look at:

• InfoObject Attribute lookups

• Accessing the value of a characteristic in a block

• Conditional statements

• Referencing characteristics in the aggregation level, not specific to the block value

In the previous chapter, we calculated revenue using FOX. However, it does not provide us with a very scalable solution. In this chapter, we will convert the FOX into an amdp and calculate the revenue using sql. The sql code performs the same calculations as the FOX but with the benefit of being scalable and that it does not need to be adjusted as often as the FOX code for small changes to the application, e.g. new account and account groups being added to the mapping table. The sql will be able to handle the changes as they arise

During any planning process, planning data must be protected against changes, especially once a plan has been approved. Data Slices provides the mechanism to enable this locking and can either manually set, based on exit class variables or set through an exit class specifically for Data Slices. In our case, we are going to configure a process whereby the planning administrator can set the data region to be locked via a query and upon saving, an exit class will set the data slice parameters for the InfoProvider. We will lock the Volumes Planning aDSO TVOL_A20 by Version and Sales Organisation.

In SP05, SAP introduced the ability to plan against master data attributes. In this chapter we will look at planning against an attribute of 0SALESORG. The new attribute, which will be a lock indicator, can be used as an alternative to the scenario in the previous chapter. For example, the user can plan this lock indicator and lock a specific Sales Organisation for all versions.

Financial planning always involves currencies and in a lot of instances translating from one currency to another may be required. For example, prices for goods may be prices in various currencies based on the location of the sales office or customer while the financials must be in the currency of the company code, controlling area or operating concern. Currency translation requires several steps and objects:

· Currency Translation Type (Tx RSCUR)

· Maintain TCURR (Tx S_BCE_68000174)

· Filter, Planning Function, Planning Sequence

In our scenario, we are going to translate the calculated revenues to EUR from the source USD. While the aDSO in our example is relatively simple, you may probably require another characteristic to separate the various currency definitions. The ideal InfoObject will be 0CURTYPE, however, in order to keep things simple and just demonstrate the principles, we will keep the Planned Revenues aDSO as is and just write a EUR record to the InfoProvider.