There’s a field Quantity Conversion(V_T685A-KMENG) in the setting for condition type in V/06:

捕获.PNG

When creating new SO, enter in sales quantity as 1 BOX, the conversion factor was determined as 1 BOX <-> 8 PC at the beginning. So the pricing result looks like this:

捕获1.PNG

Afterwards, if the conversion factor gets changed in item Sales A tab:

捕获2.PNG

Then the pricing calculation result would come to be an unexpected value:

捕获3.PNG

This is due to the fact that when this flag is not set, if the sales unit and condition unit are the same and different from base UOM, system carries out quantity conversion twice during condition base value calculation: from sales unit to base unit, then from base unit to condition unit. 
In case that the conversion factor gets changed, this change is not taken into account for the pricing calculation anymore(komv-kumza & komv-kumne will not get updated while the komp-umvkz & komp-umvkn gets updated), therefore the pricing calculation result would look quite strange.

In such case, tick on this flag could avoid the 2 times quantity conversion as described above. If the sales quantity unit and the condition quantity unit are identical, the quantity of the document item is used directly. As a result, there will not be any problem even if the conversion factor gets changed afterwards.

The setting of this flag could also help prevent the rounding issue which might occur during 2 times quantity conversion.

The explanation about the usage of this flag can also be found in the F1 help of this field(V_T685A-KMENG).

To report this post you need to login first.

5 Comments

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

    1. Alex Zheng Post author

      Hi SD,

      Thank you for your suggestion.

      I just thought the example of a specific item pricing condition type screen could show more clearly about how would the calculation result for quantity-based condition types get affected by the setting of this field. This screen contains all the elements for the calculation.

      Regards,

      Alex

      (0) 

Leave a Reply