Validity Area

Use

Only the currently valid end non-cumulative and the non-cumulative changes are stored in the database. To be able to evaluate the non-cumulative (for example, to calculate mean values or to execute a drilldown according to period), you need to know for which time interval you can calculate the non-cumulative.

The time-based validity of non-cumulatives is mapped using a validity area. The validity area describes in which time period non-cumulatives have been managed. The minimum and maximum loaded values of the time reference characteristic (for every feature of the validity table) are thus used as standard as a threshold for the validity area.

Normally this time interval is valid for all records for the InfoCube, for example for all cost centers, materials, etc. The validity interval is comprised of the minimum and the maximum of all postings.

Example

If the first values are posted for a product group on 12.31.1999 and a non-cumulative change was posted for the last time on 3.10.2000, the validity area is the time interval from 12.31.1999 until 3.10.2000.

For a detailed description of how the area is calculated where a query displays data on a non-cumulative InfoCube, see: Determining the Effective Time Filter

However, in certain cases it may be necessary to manually adjust the validity, for example, when a characteristic value is only valid for a restricted time period. In this case, you should define a validity area, especially to be able to guarantee correct calculation of averages.

More information: Maintaining the Validity Area

Another example: If the data from various sources systems has been loaded into the InfoCube at different times, it can be useful to keep the relevant validity area for each different subarea.

Example

Source system 1: Returns values for the current month

Source system 2: Returns values for the previous month

If the source systems deliver values at different times, aggregation can become affected over a period of time and contain inaccurate values. The calculated monthly average is too high, for example (see example at the end of this section).

All validity areas for a non-cumulative InfoCube are stored in a validity table. This validity table automatically contains the most detailed, selected time characteristic of the InfoCube, the time-reference characteristic.

Features

Validity-Determining Characteristics

Validity-determining characteristics:‏ Characteristics that define the time-based validity area of the non-cumulative in an InfoCube.

Validity-specific characteristics are, for example, characteristics that specify the assignment to a source system.

More information: Non-Cumulative Parameter Maintenance.

Aggregation Using Validity-Determining Characteristics

With aggregations that do not calculate an average (MIN, MAX, FIRST, LAST), virtual entries are added in the validity interval margin so that all intervals have the same start and end points. The aggregation is then executed. These virtual entries are highlighted in a special way in the results view. Without these virtual entries, the totals row would deliver inaccurate results. This is not valid for the aggregation type AVERAGE.

Example

In the following example, the receipts for plants A, B, and C are displayed. The virtual entries are indicated in a special way in the query. Looking at plant B, then there are only receipts in March and April. For January and February, the virtual entry 120 is set, because this is the non-cumulative excluding the receipts from March. For May the virtual entry 150 is set, which is the final non-cumulative for April. In the totals row, the total of virtual entries and the actual non-cumulatives is calculated.

Receipts:

	Jan	Feb	March	April	May	Marker
Plant A	+30		+20	+40	+10	100
Plant B			+10	+20		150
Plant C				+20	+30	50

Query:

						LAST
Plant A	30	30	50	90	100	100
Plant B	[120]	[120]	130	150	[150]	150
Plant C	[0]	[0]	[0]	20	50	50
SUM	150	170	180	260	300	300

Caution

SAP recommends that when you create a non-cumulative InfoCube, you use validity-determining characteristics only in the specified cases. If you have too many validity-determining characteristics or a validity-determining characteristic with a lot of characteristic values, performance decreases considerably.

If you decide later that you require more validity-determining characteristics, you can modify the selection using the report RSDG_CUBE_VALT_MODIFY. In this report, the non-cumulative InfoCube is only changed to the extent that the new validity-determining characteristics are selected and the validity table is reconstructed. The structure of the non-cumulative InfoCube remains the same. You do not have to reload the transaction data for it.

For each combination of characteristic values for the validity-determining characteristics, the validity area is, by default, the interval between initialization (or the first change in non-cumulative) and the last posted non-cumulative change for this combination. That is, the validity area is created from the posting data from when the data was loaded.

When evaluating in reporting, the non-cumulative for the requested time period is evaluated using the current final non-cumulative and the corresponding non-cumulative changes (meaning that the non-cumulative is defined at every moment within the validity area). In this way, the non-cumulatives for time periods for which no change was posted are also identified.

Example

Assuming that every plant separately delivers its data to the BW system at different times, the characteristic Plant has to be validity-determining. If you also assume that the characteristic values are Boston Plant, Dallas Plant, and San Francisco Plant, the validity intervals appear as follows:

Example

For the Dallas plant and the San Francisco plant, the validity table is maintained as follows:

Plant	From (fixed)	To (fixed)
Dallas	001.2000	003.2000
San Francisco	001.2000	002.2000

The following data is then displayed in the query:

Plant	January	February	March	Result	Comment
Dallas: Material Stock	700	700	900	766,66	(Ø per month)
Dallas: Goods Receipts	200	0	200	400	(SUM)
San Francisco: Material Stock	200	300	[300]	250	(Not 266.66!)
San Francisco: Goods Receipts	50	100	[0]	150	(SUM)

In the query, the average amount from January and February is given as the result for the San Francisco plant since only these time periods have been defined as valid. If a validity area had not been defined, the average given would have been too high (266.66).