Disclaimer: Please note that this document does not represent any official statement from SAP and is subject to change at any time without notice. The examples here contained are provided without a warranty of any kind.
In this blog post you will see how to build HANA content on top of the payroll results declustering tables and how to consume them with analytic tools.
This kind of analysis allows business users to quickly obtain aggregated sums (example: total withholding tax due by company code in a given period), to dynamically filter, sort and group-by data with drag-and-drop features with very short iteration intervals and also to drill down to employee specific data for deeper investigation (such as to look into payroll retroactive differences). These queries can easily run over productive data instead of replicated data on BW.
Just for illustration, here are a couple of examples of which kind of analysis can be made possible:
Aggregated sums per wagetype and period:
Drill down to wagetype on employee level:
The required software for building this scenario is: an installation of SP HR with declustering tools, a HANA box (or Business suite on HANA) and the Business objects enterprise server (alternative reports can be built with Microsoft excel connecting directly to the HANA content, but this is not part of the scope of this “how to”).
The overall setup will look like this:
We need to build an analytic view (a virtual cube) on top of the tables discussed here. The BO application “analysis edition for OLAP” will directly connect to the analytic view and it will produce SQL statements under the hood to extract data from the analytic view. The SQL statements will depend on the filters and fields the user selected as rows and columns on the application.
Let's start by building the required attribute views first:
Create a new attribute view with the name (for example) “ATV_WPBP_INDEX”:
Add tables P2RX_WPBP_INDEX and P2RX_WPBP to the data foundation. Add all fields of table P2RX_WPBP_INDEX to the output (right-click on them, add to output) and add the relevant fields you need from table P2RX_WPBP to the output as well (you can follow the example below; the outputted fields appear in orange below). Join both tables as the picture shows and set the cardinality so that the arrow’s head points to the P2RX_WPBP_INDEX (one record in P2RX_WPBP can have many in P2RX_WPBP_INDEX)
On the semantics part you can hide the MANDT field (will make things easier later) and set the fields shown below as key fields (MANDT, DCT_PERNR, DCT_SEQNR, RT_APZNR)
Activate the attribute view.
Now let’s create an attribute view for the table P2RX_EVAL_PERIOD. You can call it ATV_EVAL_PERIOD:
Just add all fields to the output.
On the semantics part, hide the MANDT field and set the following fields to key fields (the ones shown below from MANDT to SRTZA with a “key” icon on the left:
Activate the attribute view.
Now we can create the analytic view. Let’s call it ANV_PAYROLL_REPORTING.
The first step is to add table P2RX_RT to the data foundation. Add the following fields (in orange below) to the output. Note that some fields might be renamed due to conflicts in the “Logical join” part where the attribute views are added. The conflicts come from the fact that the attribute views have fields (key fields) with the same name as the P2RX_RT. Anyway these naming conflicts can be simply ignored.
Then click on “Logical join” part and add the two attribute views you created. Join them with the data foundation as shown in the picture below. set the cardinality so that the arrow head points to the data foundation (attribute view N X 1 data foundation).
Go to window->preferences->modeler->validation rules and deactivate the check “Large object data type check rule” in Folder “Data_Foundation” (this is necessary since fields *APZNR are originally binary fields)
Then, to enable retro-calculation analysis, add a couple of calculated attributes as follows:
Right-click on calculated columns -> new
Add field SBETRG as in the picture below. pay attention to data type, length, scale, column type, and expression:
And similarly, add field SANZHL:
Now on the semantics part of the analytic view, you can rename the label of the fields so that they appear meaningful to business users on the exploration tools. You can add also input parameters in this part so that they serve as filters on some tools (usually it will trigger the value to be input in design time, or it will prompt the user with a input value pop-up, depending on the tool)
Some fields can be left hidden:
Activate the view. Now the analytic view is ready to be consumed.
Now let's have a look on how to connect the Analysis edition for OLAP to the analytic view. The first step is the setup of the OLAP connection on the CMC. Here you create a connection to the HANA system where the Analytic view is:
After that, log on to the BI Launch pad and open a new “Analysis for OLAP”, then add a Datasource and select it form the OLAP connection you just created:
Go to folders tab and select the analytic view:
When done, the list of available fields will be listed on the left side. These fields can be drag-and-dropped to the “rows” and “columns” containers. The displacement of these fields will determine how the Tool queries the analytic view.
Recommended queries
Now it comes to the part where it is important to know which kinds of queries make sense to build with this tool. Queries that return a large number of rows should be avoided. Aggregates can be calculated very quickly with this tool requiring very little filtering. Basically the way this tool works is by collecting (group-by) the selected fields to be displayed and summing up the numeric fields, this means that the more fields selected (they appear on the “Rows” panel, see picture below) the more rows will be returned, since more distinguish values will occur.
A good strategy is to first build queries that return aggregates and then to focus on a specific aggregate and drill-in into it. The drill-in will require more filters to be set. In other words, the drill-in means to add more columns to the query (which increases the number of returned rows).
A simple but useful aggregate example is the total of given wagetypes by a company code (or other organizational structure) for a certain period(s). To achieve this you can select the in-period and for-period fields as rows, in addition add a few organizational fields such as Company code, personnel area, payroll area also to the rows panel. Then right click on in-period and select the periods in which you want to filter. Note that the order in which they appear will determine the sort order criteria. Then add the wagetype field to the columns panel and right click on it and apply filter to indicate which wagetypes you want to see as columns (don’t forget this step or you will have really several columns. Wagetypes can also be displayed on rows if more suitable for the query). By default, the Measures fields are already in the Columns panel, you can remove some of them by right-click on measures and apply filter.
One option is also to add the field “SRTZA” which will cause the amounts to be "splitted" according to Actual and Previous result of a payroll period. In this way you can explore the delta of retro-calculation and see how they are formed:
If you right click on a row and select “Pivot with” you can choose other fields to be added as column (for example the Person number). This will cause a new filter to be added to the query as well, which is composed by the cell which you clicked.
Note: the analytic view created in this example can easily be accessed by your ABAP reports as well by using ADBC objects. You can find information about how to achieve this in other SCN posts.