Setting Up Advanced Features

Objective

After completing this lesson, you will be able to describe the advanced query features

Analytical Queries: Advanced Features

The figure gives an overview of the settings in the Display tab of the Dimension as well as the results in the Analytical Query report after the enablement of a hierarchy for G/L accounts.

Following the example in the figure, Enablement of Hierarchies, the business user can preselect a hierarchy - for example, for a dimension field in rows like G/L Account. This is accomplished in the Display tab. No filter selection is entered for G/L Account in the Filters tab.

When the Analytical Query is executed, the hierarchy for this field is automatically shown and expanded to the Level entered in the Display tab.

The user can set a different hierarchy of their choice at any time of execution by just selecting the G/L Account field in the Query layout header and choosing the hierarchy button as shown in the previous figure.

Note

Even without hierarchy enablement, it is possible to select a hierarchy when the Analytical Query is executed.
The figure displays two configuration screens for setting up restricted measures, in the Hierarchy field. The left screen shows hierarchy settings with the hierarchy enabled and a parent measure specified. Fixed values for G/L Account and Plan Category are also included. The right screen hasn't the hierarchy enabled. The hierarchy section is collapsed, and no fixed values are shown.

The parent for a measure defines the parent-child relationship in a hierarchy. The collapsed field defines whether the measure is initially collapsed or expanded.

The figure displays the result of a query with a Hierarchy implemented for measures. Using a small arrow, it is possible to expand the details of the measure.

When you execute the query, you can expand your hierarchy for measures.

The figure illustrates the process of using derivation functions in the Filters tab of a Custom Analytical Query. It begins with the creation of the derivation function, as explained later. Accessing the View Browser and selecting Alternative Search. , in the search options, Annotations is chosen, and the specific annotation OBJECTMODEL.MODELINGPATTERN with the value #DERIVATION_FUNCTION is entered. This leads to the identification of the F_MyCostCenters view, which includes columns like ControllingArea and CostCenter. The figure also shows the configuration of an analytical query, highlighting the use of derivation functions in the filter settings. Finally, it displays the CDS database view details, including table fields and selection conditions, emphasizing the use of session variables like &SESSION.USER and &SESSION.SYSTEM_DATE for dynamic data retrieval.

Derivation functions derive context-specific values that can be used to restrict result data in Analytical Queries.

For many business-related reports, it can be advantageous to tailor a report to the context of the user who executes the report. With derivation functions, you can derive context-specific values to restrict data in CDS queries.

For example, depending on which derivation function you use, the context can be the current date, the logged-on user, or even the language currently selected. Here are some examples of common derivation functions:

  • Time-related functions, such as Today or Current Fiscal Period
  • Responsibility-related functions, such as My Cost Centers
  • Business semantic-related functions, such as Leading Ledger.

To get a list of all derivation functions and their definitions, you can use the View Browser.

In the app, use Alternative Search  and select the  Annotation option. For the Name field, enter OBJECTMODEL.MODELINGPATTERN, and for the Value field, enter #DERIVATION_FUNCTION.

The previous figure shows the F_MYCOSTCENTERS derivation function, which derives the cost center(s) of the responsible user who executes the Analytical Query.

The figure shows, through screenshots, how the previous derivation function F_MYCOSTCENTERS is then automatically filled in during the Analytical Query execution, as explained hereafter, with the Cost Center master data User responsible information, as well as the Derivation function assigned to the query, in the Filter tab.

In the previous figure, the user S4F07-20 is assigned to cost center, TEST_DERIV, as the User Responsible. Postings on this cost center exist.

In the Filter tab of the Analytical Query configuration, the F_MYCOSTCENTERS derivation function is assigned.

When the S4F07-20 user executes the Analytical Query:

  • They will find the Cost Center field as a mandatory variable field in the Filter section.
  • Cost center TEST_DERIV for which user S4F07-20 is the User Responsible, will automatically be selected as the only cost center for which S4F07-20 is responsible.

When this user chooses Go, the Query layout is filled with data posted to this cost center.

If you use the drill-down functionality for the Cost Center, you can select the User Responsible to verify that the log-on user S4F07-20 really is the User Responsible for this cost center.

The figure explains the concept of Exception Aggregation in data analysis, specifically focusing on the LAST function for the dimension CALENDAR MONTH. It shows how to configure a calculated measure with Exception Aggregation and lists the supported functions (AVG, COUNT, FIRST, LAST, MAX, MIN, NHA, STD, SUM). An example is provided where the measure Quantity with Exception Aggr is configured with the LAST function. For one customer, only the value from the last booked calendar month (month 10) is considered, resulting in a quantity of 1,000 KG, whereas the measure Quantity without exception aggregation sums up to 2,000 KG (for month 3 and.

For a calculated measure, you can define exception aggregation.

The previous figure, Display Tab - Calculated Measure - Exception Aggregation, shows which functions for exception aggregation are available. Choose Exception Aggregation in scenarios when you do not want to show the result as a simple aggregation of all the values. Choose a field and apply the appropriate aggregate function.

The figure illustrates the process of adding a User Input Filter in Custom Analytical Queries. Here the example is a numeric value that can then be entered by the user. In the User Input Filter settings of the query, User Input Values is selected, and a default value of 0.1 can be specified. This setup allows users to input numeric values for filtering data in the query.

You can create parameters of one of these three types - Numeric, Date, or Date function.

The previous figure, Creation of a User Input Filter, gives an example of how to set up a User Input Filter of type Numeric and where to maintain the Filter value for it.

The figure illustrates the process of using a User Input Filter in Calculated Measure. A new calculated measure is created. Then, in the expression editor of it, the User input Filter is used for the calculation. Finally, once a value for the filter is input, it will be applied in the calculation and displayed in the query result.

In the previous figure, Use of a User Input Filter in a Calculated Measure, a calculated measure is set up referring in its formula to the User Input Filter created.

According to the formula, the Calculated Measure value results in a multiplication of the Actuals in EUR times the User Input Filter value.

When the query is executed, you will find the (default) User Input Filter value of 0.1 in the Filter section and could change this variable value. If you choose Go, the calculation is done at runtime and the result is shown in the Calculated Measure column.

The figure shows the different steps to create a converted measure that can be added in the query results: even Exchange rate date and Type information).

Using the Converted Measure feature, you can run a currency translation at runtime.

Note

Accounting in SAP S/4HANA on Premise already stores data in parallel in ten currencies, so the question is whether a further currency translation at runtime is needed.

If you have the Accounting Document Number Field in your custom CDS view as well as in your Analytical Query, but you do not execute a drill-down to the Accounting Document Number, data is aggregated and the currency translation works with aggregated data.

If you have the Accounting Document Number Field in your custom CDS view as well as in your Analytical Query and you execute a drill-down to the Accounting Document Number, the currency translation is executed for each single set of data.

The performance of currency translation depends on whether you aggregate data or not:

  • If every single data set has to be translated, the currency translation costs performance.
  • If you work with aggregated data, the currency translation is not performance relevant.
The figure shows the different steps to create a counter that can be added in the query results as explained hereafter).

You can use Add Counter to retrieve a distinct count of the combination of dimensions. The list of dimensions can vary based on the data source from which it is derived.

The figure shows the use of the counter in the query results for the different levels of information).

The previous figure, Add Counter 2/2, shows the posted combinations of Customer-Division-Material.

The figure illustrates a scenario of formula collision in a table where two different formulas are applied for rows AND for columns: Row 1 + Row 2 and Column 1 * Column 2. The table shows values in two columns and two rows, with additional rows and columns derived from these formulas. The collision occurs in the cell where both formulas intersect, leading to ambiguity in calculation. The figure presents two possible interpretations for resolving the collision: either summing the products of individual cells ((A * B) + (C * D)) or multiplying the sums of the rows and columns ((A + C) * (B + D)). The bottom part of the figure suggests using a characteristic structure element to handle the collision.

When you define two structures (one in the rows, one in the columns), that both contain formulas, it is unclear to the system how to calculate the formulas at the point where both formulas intersect.

In this example, there are two rows and two columns with simple values, the third row is a simple summation formula and the third column is a simple multiplication.

In the cell in which the row and column formulas meet, it is not clear which calculation should be made.

If you calculate according to the column formula in this cell, the cell contains (A + C) * (B + D).

If you calculate according to the rows formula in this cell, the cell contains (A * B) + (C * D).

The result gives a different value.

The figure illustrates the process of adding a characteristic structure element to solve this collision. In the subsequent dialog box where the user can input a label and name for the new element as well as the selection of the type of structure element (Restricted Structure Element and Calculated Structure Element.).

If a formula collision occurs, as described in the example, you can determine the formula that has to be used in the calculation by creating a structure using the Characteristic Structure Element functionality.

There are two types of structure elements:

  • Restricted Structure Elements
  • Calculated Structure Elements
The figure presents in the Display tab of the Query, 4 Characteristic Structure Elements that are already created: 2 as Restricted Structure Elements (Actuals and Plan Data in EUR) and 2 as Calculated Structure Elements (Deviation Absolute and in Percent).

The previous figure, Formula Collision and Characteristic Structure Elements 3/6, shows a Characteristic Structure positioned in the rows with four structure elements. Two of them are restricted structure elements, the other two are calculated structure elements.

The figure displays the example of the Restricted Structure Element Actuals in EUR settings. It fixes values to EUR and Plan Category ACT01. A collision handling is available with default activation.

When you set up a restricted structure element like Actuals in EUR, you will find the Collision Handling section.

The figure displays the example of the Calculated Structure Element Deviation Absolute in EUR settings. It calculated values as =Actuals - Plan Data. A collision handling is available with default activation.

When you set up a calculated structure element like Deviation Absolute in EUR, you will also find the Collision Handling section.

The figure show the Collision Handling different possibilities: Default, This or Concurrent. The details are explained hereafter.

In the Collision Handling section of the characteristic structure element, you can set three collision specific fields:

  • Formula Collision
  • Decimal Collision
  • Scaling Collision

For example, when there is a collision between two structures that contain formulas, you can specify the formula that is going to be used in the calculation.

You can set either of these three values:

  • Default: The formula that was first created takes priority by default
  • This: The result of this formula has priority in a collision
  • Concurrent: The result of the other formula takes priority in a collision
The figure describes how to create dynamic labels - for example, for restricted measures. In this case, a user input filter is needed. A concatenation of the results will be applied.

The previous figure, Dynamic Labels 1/2, describes how you can create dynamic labels - for example, when you work with restricted measures.

Within the restricted measure, you first have to create a User Input Filter (variable) for the restricting dimension.

In our scenario, the CATEGORY_VARIABLE was created for the restricting dimension Planning Category.

When you choose Create Dynamic Label within your restricted measure, the Dynamic Label Editor opens and you can enter a label text and add the User Input Filter (CATEGORY_VARIABLE), which can be selected using the User Input Filter button.

The figure shows the previous CATEGORY _VARIABLE Filter tab applied to the query, and the consequent User Input Values requested. It also presents a Preview of the dynamic result in the column header Plan Data in EUR - Category PLAN20.

On the Filters tab of the query designer, you can select a default variable value for your User Input Filter (CATEGORY_VARIABLE).

When you open the Query Preview, you will find the User Input Filter:

  • In the Filter section, you can keep or change the default value
  • In the Column, insert Plan Data in EUR - Category …. as the Header Label text of this column
The figure illustrates the process of enabling runtime extensibility. It begins with setting the Runtime Extensibility option in the Additional Properties section of the General tab. After publishing the changes, users can access additional dimensions and measures from the query using the extended list of additional fields and measures that can be shown or hidden as needed.

With the help of the Runtime Extensibility for an Analytical Query, the business user is enabled to add all additional dimensions and all measures from the underlying CDS View data source to the Analytical query in the Web Dynpro app that had not been selected in the Analytical Query.

This offers the following advantages:

  • The queries don't increase in size, which improves system performance
  • There is no need for transport changes because they are done directly in the production system
  • Business users can enhance queries very flexibly in the production system

Note

If needed, you can exclude a dimension or measure from the Runtime Extensibility. This is done in the CDS View definition, that is, in the Custom CDS Views app in the Element Properties tab.

Set up an Analytical Query for Target Costs and Variance Analysis - Part 2

Log in to track your progress & complete quizzes