How To ... Work Around The Single Key Date' Limitation
How To ... Work Around The Single Key Date' Limitation
How To ... Work Around The Single Key Date' Limitation
SAP (SAP America, Inc. and SAP AG) assumes no responsibility for errors or omissions in these materials.
These materials are provided “as is” without a warranty of any kind, either express or implied, including but not limited to, the
implied warranties of merchantability, fitness for a particular purpose, or non-infringement.
SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that
may result from the use of these materials.
SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these
materials. SAP has no control over the information that you may access through the use of hot links contained in these materials
and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages.
HOW TO ... WORK AROUND THE ‘SINGLE KEY DATE’ LIMITATION FOR TIME DEPENDENT MASTER DATA
July 2001
1 Introduction
The BW architecture allows for time dependent master data attributes, which are linked dynamically
to the relevant fact table characteristics (typically transaction data) at query execution time. This
approach of modeling the master data attributes externally to the InfoCubes offers great flexibility.
Data changes can be immediately reflected (after master data load and master data activation /
realignment), without even touching the InfoCubes. Moreover, historical views on the data remain
available on demand.
Just to give a few typical examples of time dependent master data attributes:
• The responsible person (owner) for a cost center.
• The annual salary of an employee.
• The retail price of an article for sale.
The specific point of time, for which the master data attributes should be selected, is identified via the
parameter ‘key date’ in the query properties screen:
(Alternatively, the key date could also be selected via a variable popup by the end-user).
While the approach outlined above covers most requirements, it does not account for ‘dynamic key
dates’, that means situations where you want to link the master data attribute time selection to some
drilldown criteria in your query (e.g. to the calendar day 0CALDAY). Including the attribute values
directly in the infocubes would help to mitigate this limitation, however with the drawback of limited
flexibility on future changes (realignments). In the following, this paper will explain a practical work-
around, at the example of a typical business requirement in the retail industry. Also, some limitations
of the work-around will be highlighted.
2 Business Scenario
In retail business, for a specific article in a BW query the respective retail price should be displayed.
The retail price of an article is generally determined by conditioning technique on the R/3 side. From
the BW perspective, the retail price has many properties of an (time-dependent) attribute:
• The retail price is specific for the article (or e.g. article / site combinations).
• The retail price for an article can change over time.
• The retail price should be tracked over time.
• The retail price might need to be restated for any point back in time.
However, as compared to master data attributes, there is one major difference in how the retail price
should be treated in reporting: It should be linked dynamically to the calendar day, i.e. for any given
point in time within the query, the valid retail price current at that specific point in time should be
displayed.
3 Solution Approach
In the following, a practical (and tested) solution approach is introduced. It takes advantage of virtual
key figures, which are populated at query execution time by the respective master data attributes,
based on the drilldown state of the query.
Note however, that there are some limitations to this approach, primarily in terms of performance:
• Master data a read via custom ABAPs at query execution time. This can have some
performance impact, especially in cases of large master data tables, and inefficient custom
ABAP developments.
• More important, once the virtual key figure is included in the query, the OLAP processor will
be required to read on the detail level, which is needed to determine the respective value. For
example, should the value be determined based on the material number and the calendar
day, the OLAP processor will make sure to read data on (at least) that detail level from the
database – even if the user did decide not to drilldown to that level, and even if aggregates
do exist on the level which the user wants to report against. (The reason for this is quite
simple: Since virtual key figures are calculated dynamically at run-time, they cannot be
included in aggregates).
following InfoObjects:
0SALESORG
0DISTR_CHAN
ZGENERIC
ZCOLORCD
0CALDAY
ZVRRETAIL
ZRPCOUNT
*----------------------------------------------------------------------*
11. In the next step, you decide * INCLUDE ZXRSRU02 *
*----------------------------------------------------------------------*
on whether an InfoObject
should be read or populated data: l_s_chanm type rrke_s_chanm.
during data execution. DATA: L_SUBRC1 TYPE SY-SUBRC. "execute only, if key figure really used
endif.
*----------------------------------------------------------------------*
tables: ZVIRTUAL_RETAIL.
First, some variables need field-symbols <l_0salesorg>.
to be declared (using field field-symbols <l_0distr_chan>.
field-symbols <l_zgeneric>.
symbols) as well as any field-symbols <l_zcolorcd>.
field-symbols <l_0calday>.
database table to be field-symbols <l_zvrretail>.
field-symbols <l_zrpcount>.
referenced in the exit.
Again, if you are unsure on *break-point.
if sy-subrc eq 0.
In the final step, the virtual <l_zvrretail> = ZVIRTUAL_RETAIL-/BIC/ZVRRETAIL.
<l_zrpcount> = 1.
key figures are calculated. endif.
endform.
In the final step, you create and execute a query using the virtual key figures. In the query definition
and execution, you can treat the virtual key figures just like any other key figure. Note, that in order to
arrive at the individual retail price, you will need to create a calculated key figure (formula):
Retail Price = ZVRRETAIL / ZRPCOUNT.