Child pages
  • BW-BEX-OT-NC Validity Interval
Skip to end of metadata
Go to start of metadata

Introduction

As described in SAP Note 1548125, a query can compute stock values for every point in time within the boundaries of the validity interval. By default, the minimum and maximum loaded values of the time-reference characteristic are used to define this validity interval. The validity interval plays an important role for BW queries and can also be adjusted by hand using the transaction RSDV. Review chapter [II.e] of note 1548125 which gives a very good overview to this topic and also discusses many technical details which might be important to understand the impact of the validity on query results. In the following you can find a list of all relevant SAP consulting notes and some examples explaining some aspects of this topic.

Documentation

SAP Notes
  • 1548125 Interesting Facts about Non-Cumulatives - see [II.e] Validity Table
  • 1921893 Error Message "The validity interval has the initial value as lower limit"
  • 2062029 Maintaining the Validity Period using transaction RSDV
  • 2223058 BW Non-Cumulatives: Initial/Maximum Value for Time is not allowed in NCUM Provider
SAP Online Documentation

Examples

Query Result when there is no Time Restriction

If there is no time restriction at all in the query and the time characteristic in the drilldown, then the requested non-cumulative key figures are calculated(and displayed) for all values of the validity time interval. 

E.g. the validity of an ADSO with non-cumulative key figures is as follows:

When we e.g. run the Adhoc Query in Transaction RSRT and leave the calender day variable empty,

and then add 0CALDAY to the drilldown, the first day displayed in the result set is the day before the lower bound of the validity interval.

This isn't a error, due to technical reasons the day before the lower limit of the validity interval is needed to calculate the stock value(exception aggregation LAST) of the first day of the validity interval. In case this is disturbing, you need to define a proper time restriction in the query.

HCPR/Multiprovider based on more than one ncum Partprovider

As described in SAP Note 1548125(chapter [II.e]), in case you have in addition to the time reference characteristic e.g. the Infoobject 0plant as an validity object, the processing and of the query gets more complicated. If there are more than one partprovider with non-cumulative key figures in a HCPR/Multiprovider, we have a similar situation where it can happen that values are displayed for dates outside the validity interval. Such values are displayed in brackets[..].

Our HCPR is based on two ADSOs with the technical names STPE_NC_5 and STPE_NC_6. The validity intervals are as follows:

So, the intervals are not identical, basically the ADSO STPE_NC_5 contains data from 2019, the ADSO STPE_NC_6 contains data from 2019 and 2020. When a query is based on this HCPR where both partproviders are accessed, the system calculates the superset of both validity intervals and then determines the intersection with the time restriction of the query. 

Our sample query has the time restriction 11.2019-02.2020 and the key figure Quantity Total Stock once unrestricted, and twice restricted to the respective partprovider:

If there is only 0calmonth in the drilldown, the result is as follows:

Now we set the filter 0plant=DFEG and add 0plant to the drilldown:

We can see that the value 139 PC is displayed in brackets for the months 01/02 2020 since this plant comes only from the ADSO STPE_NC_5 where the validity ends at the end of 2019.

Error Message "The validity interval has the initial value as lower limit"

As described in SAP note 1921893, you need to avoid that data records are loaded into the cube where the time-reference characteristic is initial (please review SAP note 1548125 in order to get more general information to the topic 'Handling of non-cumulative Key Figures').  Let's discuss this with the help of an simple example:

LISTCUBE

There are only two materials (M91,M47) in the cube and the requests are not compressed. Since there was no ncum initialization, the total stock can be determined by calculating the difference of 'total inflow' and 'total outflow': 852 - 2224 = - 1372. You can see that there is a data record where 0CALDAY is initial. In particular when the cube contains non-cumulative key figures, such a record does not make sense. The first problem is that the validity interval gets initial as the lower limit which leads to a huge range of valid days!

VALIDITY TABLE

If you run a query you get the warning message DBMAN 283 displayed:


You can see (by comparing the query with the LISTCUBE result from above) that the total stock of -1372 ST takes into account the data record where 0calday is initial. But the corresponding 'movement' has no reasonable time reference and hence a query with time restrictions does never read it. If you put 0calday into the drilldown and remove the filter 0calday=[03.03.2011 - 15.11.2012], the system would calculate the stock value for the time interval from 01.01.0001 up to 14.11.2012 which contains 734823 days !! It is obvious that this would cause various problems as memory related terminations. Please note that you may run into problems even when the 'wrong' data records refer to a material which is never accesed in queries (dummy material) since the validity interval gets inlarged anyway. 

You need to delete this data record (request) and reload the data (with the appropriate time) into the InfoCube. Afterwards it is necessary to adjust the validity table. Please use the function RSDV_VALID_RECREATE as described in note 1548125.