Entering content frame

This graphic is explained in the accompanying text Example: Master Data That Is Period Managed in Conditions  Locate the document in its SAP Library structure

See also: Structure linkExample: Master Data That Is Period Managed

The following example explains the functional scope of period management for master data in the condition technique. It shows when new versions of condition record are created and how the versions overwrite each other.

Actions that create new condition record versions:

Version

A condition record is created with a processing timestamp of 01/15/02 and effective validity from 01/01/02 to 10/01/02, and with a status of actively valid.

1

A change is made on 02/15/02, which is to become effective on 04/01/02

2

·         A new version of the condition record is created, whereby only the processing timestamp and the effective validity are different from the first version. This partially overlaps the first version.

·         This change becomes effective on 04/01/02 It is supposed to be valid until the end of the validity period.

Another change is made on 09/12/02, which is to be retroactively effective from 08/01/02.

3

·         A third version is thus created. The effective validity date is before the processing date.

In the case below, the condition record was changed on 09/12/02, effective retroactively from 08/01/02. During commission settlement on 09/14/02, the retroactively changed version of the contract was used to determine the remuneration amount, although the change was only made after the start of the commission.

This graphic is explained in the accompanying textIf settlement had been made on 09/10/02, the remuneration would have been calculated based on version 2. A retroactive change to the policy means that commission settlement has to be repeated for all commissions calculated between 08/01/02 and 09/12/02.

 

 

 

Leaving content frame