When a condition record is created in transaction VK11, the system automatically uses an end of the validity date with 31.12.9999:

VK11.gif

In case this valid-end-date is kept as such, with 31.12.9999, then in the further process the problem can occur.

When now later another condition record is created for the same customer/material combination, then the originally created one is split.

Here as an example, two more condition records have been created, both are valid for a limited time:

VK11_2.gif

This condition record is valid in the given valid-from  valid-to interval, and in this period the first record with value of 88 EUR is not valid, it can be seen that the new record is intercepting the fist one, which is shown to be valid only until the new record starts, when we check with a valid-on date belonging into the first validitiy period:

Valid_to.gif

Another third record is valid thereafter, in the period of 01.03.2013 until 31.12.2013:

/wp-content/uploads/2014/10/vk_12_3_572613.gif

Now when you check the validity periods of this price condition combination thereafter, by marking the record and clicking on the button “validity” (or press F8) it seems that a fourth record exists:

Validity.gif

But in reality this is not the case. This is one and the same record, which had been initially created. Its validity had been split up, by the two records valid in between. After the third records valid-end date is over, the first record is valid again, due to the fact that it had been created with the unlimited valid-end date 31.12.9999.

This can be seen on the database by looking at the condition records in table KONH, only three exist:

KONH.gif

The fastest and most convenient way to get the condition record numbers (field KNUMH in tables KONH and KONP) is by debugging in the transaction VK12 itself, by entering /h in the command field, and then setting a watch point on field xkonp-knumh:

/wp-content/uploads/2014/10/debug_572616.gif

After debugging is activated, mark the condition record and press the validity button as shown above, then go ahead with checking the values in the watched field:

/wp-content/uploads/2014/10/watchpoint_572617.gif

With the record numbers collected from field XKONP-KNUMH, therafter in transaction SE16 and table KONH, those can be viewed by copying them into KNUMH field, and the same overview appears as in the KONH picture above.

Any changes that are made to the initial record, such as setting the deletion indicator, will affect both periods in which it is valid.

To avoid such splitting up of the validity period, either it should be avoided that the valid-end-date 31.12.9999 is set, or before a new record is created for the same combination, the valid-end date of the original record will have to modified from 31.12.9999 to the day before the new record’s valid-from date starts. So in the example above this would be 30.11.2011.

Useful notes:

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Kavita Suri

    Hello Tobias,

    This is such a pertinent point. Thank you so much for writing about it.
    Sorry about the late appreciation(now in 2017!)  though 🙂

    Thanks.

    (1) 

Leave a Reply