bi ip modeling key figures

MODELING KEY FIGURES

A DEEP DIVE INTO MODELING KEY FIGURES

S A P B W C O N S U L T I N G , I N C .www.SAPBWConsult ing.com

A u t h o r s : L o n n i e Ay e r s , D o u g Ay e r s , Vi c t o r Ay e r s

7 2 5 6 K e i t h D o n a l d s o n R d , F r e e t o w n , I N 4 7 2 3 5 t e l e p h o n e : 8 1 2 . 3 4 0 . 5 5 8 1 w w w. S A P B W C o n s u l t i n g . c o m

Table of Contents

Model Key Figures! 1Overview! 1

Aircraft Industry-Common BW User! 1

Knowledge! 1

BW Consulting Skillsets! 1

About SAP BW Consulting, Inc.! 1

Introduction to Key Figures! 3

Key Figure Values! 3

Inherent Meaning! 3

Design Decisions Required! 3

Currency Translation! 4

Currency Translation! 5

Factless Key Figures! 6

Factless Key Figures! 6

Fact or Attribute! 7

Distinguishing Attributes from Facts! 7

Define Key Figure Transaction! 8

Defining a Key Figure InfoObject! 8

O r g a n i z a t i o n N a m e! P r o p o s a l Ti t l e

i

Defining Key Figure-Number! 9

Exception Aggretion! 10

Defining Exception Aggregation! 10

Defining Cumulative vs Non-Cumulative Key Figure! 11

Cumulative vs. Non-Cumulative Key Figures! 11

When Should You Use Non-Cumulative Key Figures?! 11

Non-Cumulative Key Figure Example! 12

Handling Inventory! 13

How Do You Handle Inventory in SAP BW! 13

Inventory Reference Points! 14

Validity Tables! 15

What Values are Stored in the database? ! 15

Internal Business Volume! 16

Elimination of Internal Business Volume! 16

Reference characteristics! 18

Reference Key Figures! 19

Elimination Business Rule! 20

Establishing Elimination Key Figures! 21

Elimination of Internal Business Volume Via Query! 22

Glossary! 25

O r g a n i z a t i o n N a m e! P r o p o s a l Ti t l e

ii

Model Key FiguresOverviewAs part of our series on SAP BW Data Modeling, we next cover the subject of how to Model Key Figures. In this guide we cover:

Modeling Options for Key Figures

Dynamic/Persistent Key Figures

Factless Key Figures

Fact or Attribute

Transactions

Exception Aggregation

Cumulative vs. Non-Cumulatives

Elimination of Internal Business Volume

In order to get the greatest value from this short guide, you need knowledge of a specific industry, such as the aircraft industry, knowledge of datawarehouse concepts, and a variety of SAP Business Warehouse Skillsets.

Aircraft Industry-Common BW User Knowledge

BW Consulting Skillsets

About SAP BW Consulting, Inc.SAP BW Consulting, Inc. is one of the fastest growing Business Intelligence consultancies. Our focus is on delivering value to our customers and providing a challenging set of projects for consultants. Our approach is based upon con-tinuous education, of our consultants, ourselves, and our customers.

Industry Focus

Modeling Key Figures

S A P B W C o n s u l t i n g , I n c .

S h a r e o n F a c e b o o k P o s t o n L i n k e d Tw e e t T h i s G u i d e! !

1

We bring more than 70 years of combined Industry Experience spanning the Military Logistics arena, Automotive Real Time embedded system, High-Tech Manufacturing, NASA and other government organizations, Rail, Airlines, Manufacturing, Consumer Packaged Goods (CPG), Airports and pharmaceuticals.




2

Introduction to Key FiguresKey Figures are the central facts stored in the SAP Business Warehouse (BW) system, and are the answer a business user is typically seeking. They are loaded into the Fact Table of an InfoCube during data loading and represent the results of the underlying transaction in the linked source system. These sources may or may not be SAP systems

Key Figure Values

Inherent MeaningIn many cases, Key Figures are derived from the results of a process versus being a direct result of the underlying source system process. For instance, a Source System could provide the Key Figures for Order Entry Quantity and Delivery Quantity, explicitly and will be represented by specific Key Figure InfoObjects in BW. If you know these two pieces of data, then you can derive the Delivery Fulfillment Rate which can be expressed as the percentage (%) delivery quantity represents of Order Entry Quantity.

Design Decisions Required

This sort of derived Key Figure requires a modeling decision to be made:

1. Create it in the transformation process and store it permanently in the Fact Table of the InfoCube

2. Compute it each time in the query using a formula




3

Each of these approaches have advantages and disadvantages and are influenced by various factors, including, sur-prisingly, when you decide to create them.

If you decide to create them during the transformation process, and store them permanently, and you are on a version of SAP BW prior to SAP 7.X, you have to first dump all the data from your InfoCube in order to add it. If you do it during the initial design build/phase, then there is less problem. However, by adding it as a permanent Key Figure, you are creating a larger InfoCube, which may impact performance.

If you decide to compute it on-the-fly, it may require fairly complex mathematical formulas. The more complex these formulas, the more likely you are to experience sluggish query performance. In addition, you dont have a perma-nent record of the Calculated Key Figure (CKF).

Making the decision as to which way to model this comes down to the trade-off between query performance versus Fact Table size (and the projected growth rate over time).

Currency Translation




4

Currency TranslationOne of the most common task is the translation of currencies. Currency translation can take place during the initial transaction data load and/or during query execution. Your choice will be guided by the benefits and drawbacks of each approach.

When are currency values Lost?

If you chose to convert currencies during the data update, the resultant currency values are physically stored with the chosen currency-resulting in faster processing of reports. Unfortunately, the original currency values and currencies are lost.

When are currency values kept?

If you convert currencies during reporting, at query execution time, you can report on various currency values. The original currency values are not lost in this case, however, the currency conversion process has to be done repeatedly and may result in undesirable query performance.

Required Prerequisites for currency conversion during data updates:

A Key Figure (data type AMOUNT) with either a fixed or variable currency specified, must be defined in the Info-Source.

The Key Figure (data type AMOUNT) must be mirrored within the InfoCube with either fixed or variable currency type definition

The Currency Translation Type must be defined properly defined for the conversion.

Required Prerequisites for currency conversion accomplished during reporting:

The Key Figure (data type AMOUNT) must be mirrored within the InfoCube with either fixed or variable currency type definition

The Currency Translation Type must be defined properly defined for the conversion.




5



Sometimes, Key Figure is empty, or without a true fact. They typically result from the presence of intersection enti-ties.

The values for these facts must be created during data staging with user-created code.

It would be best to fill these values using routines in update rules.

A Key Figure would be created in the data model to represent attendance or count as depicted above.

The Update Rules for this new Key Figure would then load the fact related each incoming record by means of a rou-tine.




6

Fact or Attribute

Distinguishing Attributes from Facts

Although it usually easy to determine whether a piece of information is an Attribute or Fact, there will be times when the difference is not obvious. Prices are good example. From one perspective, price describes the article as the manu-facturer attribute does and therefore it seems that it should be in the master data table. In this situation, you should model the price as an attribute in a Master Data Table.

To do this, you will need to use a formula variable with Replacement Path, the price navigational attribute can be used to calculate Net Sales=Price * Number of Pieces Sold. This allows calculations within queries using this formula variable.

From a different perspective, the price remains constant over time which means it doesnt make sense to calculate discounts on the basis of Sales Amount and Quantity in a fact record using the Actual Price from the master data table with fact records that are, for example, one year old. In this case, the discount has to be calculated during load time in an update rule using a lookup for the Actual Price from the master data table.

If price changes only occasionally, then a time dependent navigational attribute would be the right approach to model this.

You might also consider a categorical dimension such as high, low or medium price to perform analysis.

If you are planning on performing Promotion Analysis, then do not use price as a navigational attribute.




7

Define Key Figure Transaction

Defining a Key Figure InfoObject

In order to define a Key Figure, several settings must be made the InfoObject Definition screen.

You must select characteristics for a new InfoObject from a series of tab-strips. The settings you make here have di-rect influence on the capabilities of the InfoObject and how it is used throughout the BW system.

These setting determine the metadata for the InfoObjects. They are stored in the Metadata repository.

Performance will be maximized if Key Figures are stored as NUMBER or INTEGER data types instead of amount/quantity fields that are stored as CHAR data type fields on the database.

Amount and Quantity Key Figures require accessing the UNIT dimension table




8

Defining Key Figure-Number




9

Exception Aggretion

Defining Exception AggregationKey Figures may require aggregation, meaning consolidation or adding up. You should keep the following points in mind when defining an aggregation level.

Non-cumulative Key Figures are evaluated by non-cumulative values. Non-cumulative value are special Key Figures that are different from other Key Figures (cumulative values) in data transfers and saving, as well as in aggregation behavior.

Non-cumulative values are those key Key Figures that measured in relation to a period in time. They cannot be summed over time. Non-cumulative values are summarized over time using exception aggregation. Inventory would be an example of a Key Figure that doesnt make sense to add up over time as it varies from time-to-time.

Non-cumulative values such as number of employees, cumulated using characteristics such as Cost Center. It would not make any sense to cumulate the number of employees using different periods. You might, however, want to know an average number for other purposes. The result at the end of any particular period would be the sum total of number of Employees for each posting during the period. This wouldnt make any sense.




10

To answer the question of how many employees a cost center had for any calendar year and month, you would use the last value of 0HEADCOUNT along with 0CALMONTH. You would define the Aggregation Key Figure as an exception aggregation to tell BW which value to use during the period.

Defining Cumulative vs Non-Cumulative Key Figure

Cumulative vs. Non-Cumulative Key Figures

Non-Cumulative Key Figures are used to optimize the data transfer process in SAP Business Warehouse, data reten-tion and database access. When transferring data from the underlying OLTP (OnLine Transaction Processing) system to SAP BW, only meaningful data is saved and process.

When Should You Use Non-Cumulative Key Figures?You should use non-cumulative values for areas that dont change often such as warehouse stock or number of em-ployees.

Non-cumulative Key Figures are modeled in SAP BW using a non-cumulative value with the fields belonging to it for storing the non-cumulative figures or for inflows and outflows of data.




11

Non-cumulative values are stored with special key figures that differ in terms of data transfers and aggregation be-havior.

ISSUES RECEIPT RUNNING TOTALS

10 10 0

10 20 +10

30 10 -20

Non-Cumulative Key Figure Example

Features of Non-Cumulative Key Figure Values: Transferring and Saving Data:

Non-Cumulative values are mapped using one Key Figure for non-cumulative changes or two Key Figures for data inflows and outflows.

Non-cumulative Key Figures are transferred in an initialization run and the change runs that follow (you can also omit initializations here).

Non-cumulative values always have a time-related exception aggregation




12

Handling Inventory

How Do You Handle Inventory in SAP BWInventory scenarios in SAP BW require a Reference Point from all other calculations are made. A Reference Point in an inventory scenario is typically the opening inventory balance. It is technically defined as the value per characteris-tic combination after you have compressed your InfoCube. When compressing an InfoCube containing non-cumulative Key Figures, the Reference Point is (by default) updated.




13

Inventory Reference Points

Keep in Mind

Opening Balance

The opening balance can also be loaded into SAP BW using a Flat File (which you need to flag in the trans-fer rules)

No opening balance is created when compressing an InfoCube

The opening balance can be loaded into BW via a specific R/3 DataSource (UPDMODE=B).

Queries for the current non-cumulative Key Figure can be answered very quickly since the current non-cumulative is created as a directly accessible value. There is only one marker that is always updated when the non-cumulative InfoCube is compressed. To make access to queries as quick as possible, compress non-cumulative InfoCubes regularly to keep the markers up-to-date.




14

For example, in month 3 the marker is read with three non-cumulative changes for a query. In month 4, the marker is updated so that the current marker has to be read with only one non-cumulative change for a query in month 5. If the marker is not updated, it still has four non-cumulative changes to read.

The technical storage of non-cumulative Key Figures takes place using a marker for the current time (current non-cumulative) and the storage of non-cumulative changes, or inflows and outflows. The current, valid end non-cumulative (to 31.12.9999) Key Figure is stored in the marker. You can determine the current inventory bal-ance from non-cumulative values or you can take the last periods balance and sum up the changes.

Validity Tables

What Values are Stored in the database?Only the current Non-Cumulative value and the Non-Cumulative changes are stored in the database.

In order to be able to evaluate a Non-Cumulative Key Figure (for example, to calculate mean values or to execute a drill-down by period) it is necessary that you know for which time interval you can calculate the Non-Cumulative Key Figure. Otherwise, a Non-Cumulative Key Figure from 1/1/1000 to 12/31/1999 will be dis-played.




15

The time based validity of Non-Cumulative Key Figure is mapped using a validity period. This describes the time period Non-Cumulative Key Figures have been managed

A Non-Cumulative InfoCube has to contain a time reference characteristic. This means that the system has to be able to convert all time characteristics of the Non-Cumulative InfoCube automatically from this time characteris-tic.

If you use a user-specific validity table, the table is adjusted when you load it.

Other characteristics can be used to determine validity as well. Characteristics that specify which source system the Non-Cumulative belongs to, or which value type that is relevant. It is recommended to use validity deter-mining characteristics only in special situations

Internal Business Volume

Elimination of Internal Business VolumeWhat is Internal Business Volume Elimination.. More specifically, what is meant by internal business volume? In the context of SAP BW Internal Business Volume Elimination, it means two business areas, typically either Cost Centers or Business Areas, share the same Master Data and, located on the same Hierarchy, exchange transactions. For ex-




16

ample, a food packaging manufacturer in France may buy intermediate products from another factory in another country, but from the same company and cost center/hierarchy.

With this function you can eliminate the internal business volume by executing a BEx query. Internal business volume is then no longer displayed in the report.

This solution has existed since SAP BW Release 3.0z and provides a unique opportunity to do eliminations be-tween partner objects in SAP BW, as an example. As part of an OLAP (OnLine Analytical Processing) scenario, this ad-hoc consolidation is highly flexible.

SAP SEM BCS stands for Business Consolidation System and is essentially the same as EC-CS (Enterprise Con-trolling and Consolidation System tup to version 4.0 of the SEM (Strategic Enterprise Management) solution. SAP also now offers Business Consolidation functionality within the SAP BusinessObjects Business Planning & Consolidation (BPC) solution.

Eliminations are performed when both the object and partner object belong to the same node of the Hierarchy. In our example for center PC0301 and partner profit center PC0101 internal revenue shown in record #3.

Based on the profit center hierarchy, revenue must be eliminated at the ProfitCtr Hierarchy profit center node.

Based on the region hierarchy, revenue must be eliminated at the Europe node and the Country Node




17

Reference characteristics

You have an InfoProvider that contains two InfoObjects (sender and receiver) that have the same master data




18

Reference Key Figures

To eliminate internal business volume in an InfoProvider, you have to create a key figure with a reference. You then must include these in the InfoProvider

When creating a key figure, you can also select Key Figure with Reference. In the InfoObject maintenance you have an additional tab page, Elimination. Enter one or more characteristic pairs here regarding the key figure to be eliminated. The characteristics of such a pair must have the same reference characteristic. You can also enter the names of the navigation attributes here.

You can display permitted characteristics for an elimination characteristic by using the input help.

If several characteristic pairs are maintained, you still have to specify one of the following, using the selection buttons:

all characteristic pairs need to be eliminated (then the key figure value is only eliminated if the elimination condition described above is fulfilled for all characteristic pairs)=> AND

each individual characteristic pair needs to be eliminated (then the key figure value is already eliminated as soon as the elimination condition for a characteristic pair is fulfilled)=>OR




19

Elimination Business Rule

In this example, four eliminations are being performed:

ICE_REV1 eliminates revenue between a profit center/partner profit center that are assigned to the same node of the profit center hierarchy.

ICE_REV1 eliminates revenue between a country/partner country that are assigned to the same node of the country hierarchy

ICE_REV3 eliminates revenue between a profit center/partner profit center where EITHER the profit centers are assigned to the same node of the profit center hierarchy OR the countries are assigned to the same node of the country hierarchy.

ICE_REV4 eliminates revenue between a profit center/partner profit center where BOTH the profit centers are assigned to the same node of the profit center hierarchy AND the countries are assigned to the same node of the country hierarchy.

The last step is to add the special key figure to the InfoCube. In this way, it is included in the data model, but not in the database table.




20

To see the data model: Goto the Administrator Workbench (T-Code RSA1)>InfoProvider>Search for the ICE In-foCube>Right Mouse Click>Display Data Model.

To confirm that only the basic key figure ICE_REV in the fact table, goto transaction LISTSCHEMA>Enter B for type if InfoCube>Enter ICE for the InfoCube name and Execute>Display table contents for the fact table.

Establishing Elimination Key Figures

Use SE16 to view the table RSDIOBJCMP as well as the fact table for the ICE InfoCube. (Remember, you will NOT see any of the artificial key figures!)

ICE_REV1->4 are artificial key figures referenced to ICE_REV and use business logic to eliminate transactions between partners for example.

The values for ICE_REV1->4 are not stored in the db but are calculated by the query.




21

Elimination of Internal Business Volume Via Query

The elimination is performed when the query is run with the special key figures. The queries above illustrate:

ICE_QUERY1: Rev Profit Ctr is eliminated at the first common node for profit center PC0301 and partner profit center PC0102, which is the ProfitCtr Hierarchy node.

ICE_QUERY2: Rev Country is eliminated at the first common node for country UK and partner country DE, which is the Europe node, and all higher level nodes (Country).

ICE_QUERY3: Rev PCtr OR Ctry is eliminated if EITHER the profit center or country rule applies.

ICE_QUERY4: Rev PCtr AND Ctry is eliminated if BOTH the profit center and country rules apply




22

Summary:

You have now learned a variety of Key Figure modeling techniques

You understand the difference between dynamic and persistent key figures

You know how leverage a factless fact type key figure

You understand how and when to store a Key Figure as an attribute

You can identify Key Figures with or without units

You can explain and understand the settings for exception aggregation

You know when to use Non-Cumulative Key Figures

You know how to eliminate Internal Business Volume




23




24

Glossary

A) Calculated Key FigureA Key Figure which is calculated or derived other Key Figures.

B) Cumulative Values

Cumulative Value Key Figures are those Key Figures that are cumulated using all characteristics, thus also using time.

C) Factless Key FiguresA key figure that is the intersection value of two tables. For instance, you can count the number of occurrences of a value that is present in the two tables.

D) InfoCubeAn InfoCube is the central data storage object in SAP Business Warehouse. Its structure is set up to allow op-timized query performance. It uses the SAP Extended Star Schema. There are several types of InfoCubes, some contain data, and some do not.

E) InfoSetsDifferent from the SAP query/InfoSet tool in that they are accessed via the SAP BW BEx.

F) Internal Business VolumeWhen two or more transactions occur between units, typically profit or cost centers, within a company, you need to net them out in order to avoid double counting them.

G) InfoProviderAn element that is visible via BEx Query designer and can thus be reported on.

H) Key FiguresThe answer you are trying to find when performing analysis. Examples include: Sales Totals, Sales by Cus-tomer, Profit and Loss, and many others.

I) Inner JoinResult contains all records that are common to both Info-Providers (with respect to the join condition).

J) Left Outer JoinA join condition that will return all the records contained in the first table, and any matching records in the second table that forms part of the join.

K) Master DataMaster Data is data that does not change very often (with some exceptions depending on the Industry), and in-cludes, for example, Customer Names, Product Codes, or Material Safety Data Sheets.

L) MultiProvider

A MultiProvider is a special InfoProvider that combines data from several InfoProviders. It does not contain any data.

M) Non-Cumulative Key Figure ValuesNon-Cumulative Key Figure Values are those key figures that are measured in relation to a period of time; they cannot be meaningfully cumulated over time. Non-cumulative values are summarized over time using ex-ception aggregation.

N) OLAP

An On-Line Analytical Processing or OLAP system is a system such as SAP Business Warehouse, which is, as its title implies, optimized for analysis, and is not intended to perform business transactions, such as execute Sales Orders.




25

O) OLTPAn On-Line Transaction Processing or OLTP system is a system such as SAP R/3 (ECC) that performs business transactions, such as issue and process purchase orders.

P) Transitive AttributesTransitive attributes are attributes at the secondary level. Suppose, for example, you have an InfoObject called Customer that has an attribute of Region, and that attrib-ute, Region, has an attribute of Country. You can set up a process that you can report on Country via Customer.

Q) Temporal JoinUsed to show time dependent records.

R) UnionsWhereas a Join is used to find the intersection two groups of items have in common, a Union is used when creating a MultiProvider, and allows you join informa-tion from various InfoProvider




26

bi ip modeling key figures

Documents

o n n i e

t i o n n

p o s t o n

e p h o n e

c e b o o

r e o n f

e i t h d o n

t i n g