!--a11y-->
Example: Master Data That Is Period Managed
in Conditions 
See
also:
Example:
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.
If 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.
