Were you a little surprised by the headline?
Until now, you assumed that with the introduction of the Universal Journal, the principle of the single-source-of-truth has been implemented and that your life as a controller will become easier and, above all, more interesting as a result? Gone are the days when you had to waste a large part of your working time searching for the causes of differences in results and data inconsistencies.
Instead, after the successful implementation of SAP S/4HANA, you wanted to spend a lot of time creating meaningful analyses and interpreting monthly earnings figures? Did you want to provide management with an improved range of information so that relevant decisions can be made more quickly and on the basis of reliable figures? You have also already sufficiently informed yourself about the possibilities of creating your own query and reports with KPIs?
Your hopes are justified and the realization of your goals is also in no way endangered. There are only minor stumbling blocks that might briefly dampen your enjoyment of the new "reporting world". This article will show you what to consider when setting up the new "reporting world". The focus is on the possibilities in the Fiori Launchpad. Without a doubt, SAP SAC opens up a huge spectrum of possibilities. Compared to the reporting offering in R/3, the Fiori Launchpad is already a huge improvement.
How do the stumbling blocks come about? Simply put, the issue is that a single data source will produce different result numbers due to different data accesses. The two screenshots impressively show the result of a different data access (contribution margin 2 of customer group 02 with different values in the row-based report and in the key figure reporting):
How can uniform data access be ensured? To answer this question, we need to take a closer look at the Universal Journal. In the R/3 world, there were multiple documents for each business transaction and these documents were stored in different tables. SAP S/4HANA does away with the multitude of documents and tables: A business transaction generates a document in the Universal Journal, and all FI and CO evaluations use the documents in this table.
I would like to use a simple example to illustrate the data access problem: The salary posting for a sales employee is posted to the employee's sales cost center using the G/L account for salaries. From a contribution margin accounting perspective, the amount must be reported in the "Sales Costs" report row. A functional area or a cost center group could be used to define the report row, but both variants involve greater effort that is not necessarily justified by greater benefit.
The simplest solution, which is also the basis of the standard apps delivered by SAP, is to use a financial statement version for the row structure of the contribution margin report. The special feature of the financial statement version used for this report is that only the G/L account used to settle the cost center is assigned to the "Sales costs" node. This means that the document for the salary posting to the cost center is not accessed. This was also the case in R/3, because the data access for creating a contribution margin report was only to the table with the CO-PA data, and this table only contained the payroll document for the cost center.
The financial statement version is the first important element for uniform data access to the Universal Journal and for creating row-based reports. In the future, you will create these reports using the Custom Analytical Queries (Query) app. If you have already spent some time with the report creation options in the Fiori Launchpad, then you know that you can now also create KPI-based charts without much effort ("Manage KPIs and Reports" app).
In the future, KPI-based charts are likely to become more important than line-based reports, as decision-makers will be able to grasp the information relevant to them at a glance. It is therefore all the more important that these charts are not only visually appealing, but also provide reliable information (unfortunately, this was not achieved in the case of the chart in the first figure).
To create the charts, you need key figures. These key figures are provided by the previously created analytical queries. There are several variants and precisely this creates the danger that different values are shown in the charts for the same key figure. For example, you can define the key figure "Gross sales" as the sum of accounts 8010, 8020 and 8030. Since you have already been made aware of the central importance of the financial statement version, you would certainly not create such a formula. Instead, you would look for ways to access the financial statement version. Unfortunately, you will not find what you are looking for. Direct access to the financial statement version is not possible. Access to the financial statement version is via semantic tags. The semantic tags are first linked to the nodes of the financial statement version and then you can define any key figures in your analytical query by accessing these semantic tags.
To ensure that all row-based reports and all key figure-based charts provide identical values, you should use only one financial statement version for your contribution margin scheme and provide this financial statement version with the relevant semantic tags. This ensures consistent data access to the unified data source, and you'll have lasting enjoyment of the new reporting world (and decision makers).
