KNUMH value in KONV and KONP tables. Wrong values?

[Former Member]

Hi gurus,

I'm writing a SD custom report and I need to read pricing conditions from invoices. Everithing was going right until I've found an unexpected scenario which is causing wrong numbers in my report.

Let's say I have the following logic:

From A650 table, I'm reading a custom princing condition for the KUNNR. This gives me a KNUMH value.

According to the image, for tis KUNNR and Z320 condicion I can find two differente KNUMH values, validity dependent. This is OK.

KONP tables gives me the value to take into account for calculations for each KNUMH:

So I'll calculate based on 33,10% for 9032 and 34,10 for 39292. This is also OK for me.

However, here comes my problem. In KONV table I can find the following:

- Records for 9032 condition number and the value from KONP (33,10%). OK.

- Records for 39292 condition number and the value from KONP (34,10%). OK.

- And finally, records for 9032 condition number BUT 34,10%, which is not the value from KONP for this condition.

How is this possible? In my understanding, if the value is 34,10% the condition number should be 39292, right?
Is there a way to fix this? Am I wrong?

Thanks in advance.

Message was edited by: AAH _ES

[Former Member · Accepted solution]

See don't get confused with this and just try to understand the difference of KONV and KONP which has been explained quiet well in below mentioned links.

difference between KONP and KONV | SCN

<Link removed by Moderator>

If you still find any ambiguity you can ask freely. Thanks.

Message was edited by: Jyoti Prakash - Please refer SCN RoE, refer "More about Copyright" section.

[Former Member · Accepted solution]

Hi Rehman,

I understand the differences, but what confuses me is why the rate in KONV is not the same as the rate in KONP for the same condition number KNUMH.

Regards.

[Former Member · Accepted solution]

This is because KONV store the condition data based on transaction and KONV-KNUMV is the document condition number of VBAK-KNUMV or VBRK-KNUMV and if you try to search this KNUMV to KONP then system will show you no record because it's a condition record based on transactions only.

Now coming to KONP, it'll display condition records for all the condition tables like A304, A305, A089 etc.

I'm sharing snapshots for better clarification.

1. For my table A910, i've got 2 condition records against 9001 material group.

2. I'm going to search this in KONP first based on above mentioned 2 KNUMH's and here i'm getting results as per maintenance of condition record using VK11.

3. Now i'll pass same 2 KNUMH's in KONV and here i'm getting results against one KNUMH and with different values, Question arises here why is this so? This is because its related to transaction data not the one which has been maintained via VK11.

4. If you'll search this KNUMV into VBAK-KNUMV then you'll get the number of sales order against which document condition number has been stored.

Hope i've made myself clear to you. In case if still you find any confusion, you can ask without any hesitation. Thanks.

[Former Member · Accepted solution]

Hi again,

I understand your example and appreciate your time and explanations. If you enter to the KONV table using the KONP-KNUMH value as the filter for KONV-KNUMV, you'll get different rates and values. This is OK.

But the thing is if you enter to the KONV table using the KONP-KNUMV value as the filter for KONV-KNUMH. (KONV has both fields KNUMV and KNUMH).

What I'm expecting is to find the same rate (KBETR) in both KONV and KONP tables when filtering by the same KNUMH condition number. See my example.

Regards.

[Former Member · Accepted solution]

Right so is this happening for every condition type? Can you please share the stats of your particular condition type for which you're facing the issue? Did you tried after creating new condition record? I'm afraid there's some inconsistency for your database table KONV as in my case KBETR and KWERT is updating properly and are you really sure that KONV values are getting updated properly at your end? Please try to create a new condition master for the same key by creating a fresh condition type in development server, reproducing the issue might led to you towards resolution of your issue. Do revert with your findings after trying this. Thanks.

[Former Member · Accepted solution]

Only happened for the custom condition I've posted in the snapshot. Currently, each update of KONV is correct, but I've found some previous records with incorrect KNUMV number.

The KBETR rate is correct, but not the KONV-KNUMV number. Do you think is there a way to fix this? I would like to change the KNUMV number in the KONV to make the data consistent.

Regards.

[Former Member · Accepted solution]

Only happened for the custom condition I've posted in the snapshot. Currently, each update of KONV is correct, but I've found some previous records with incorrect KNUMV number.

You are matching KNUMV with what? VBRK-KNUMV? i assume like you said that you're fetching pricing conditions for invoices. Also if i refer to the last snapshot of your very first post then here KBETR is not getting updated properly. I'm not sure as if to what extent below mentioned notes will gonna help you to dig out those inconsistencies but i hope they are of great help. Rest let me try reproducing this issue in my DEV server, will get back to you shortly with my findings. Thanks.

2045167 - Inconsistencies in table KONV

141121 - SD documents - Table KONV is inconsistent

[Former Member · Accepted solution]

I'm matching KONV-KNUMV with VBRK-KNUMV, and KONV-KNUMH with KONP-KNUMH.

Thanks!

[Former Member · Accepted solution]

Please bear with me for late response. I'm not sure as if you've a functional or a techno-functional role but like you said that this behavior is currently happening for only one condition type then you need to confirm as if you're using any BAPI for pricing update at sales order level, what are the attributes for your this condition type if possible share V/06 stats i mean is this a header or a manual condition as the behavior would be different for such cases which i've checked at my end, what's the condition category i.e tax, freight or what? Any requirement/calculation type has been assigned to your pricing schema against this condition type step? You need to go through every possible thing at functional and technical side both i believe that something is getting overlooked which needs to be rectified. It would be better if you ask your functional consultant to create a new condition type by copying the existing one for which KONV-KNUMV is updating correctly and then share the results.

You can use FM KONV_UPDATE in order to modify, insert or delete records from KONV but before doing that do check up the implications as here questions arises that what about KONP, KONH and other pricing communication structures and it's really not recommendable unless or until extremely required so before taking any step please go through the notes that i've shared in my earlier post particularly 141121.

Rest if you further need any info or clarification on this, you can ask me freely

[Former Member · Accepted solution]

Hi Rehman,

Finally, I've discovered that the issue was caused by a sequence of changes in the condition master data. Let's say:

- Condition is created from 01/01/2015 to 31/12/999 with value 'A'.

- Condition value is modified. So from 01/01/2015 to 31/12/999 the new value is 'B'.

- Inicial value 'A' is restored for 2015 and new period is opened for value 'B'.

So the current status is:

From 01/01/2015 to 31/12/2015 value 'A'.

From 01/01/2016 to 31/12/9999 value 'B'.

So this is the reason of why billing documents in 2016 have the same condition as from 2015, because of this sequence of changes.

The only solution I saw is to update the KONV and that's what I've done via SQL and carefully. Data is consistent now.

Thanks a lot for your all your help.

[Former Member · Accepted solution]

Thank you for the explanation and sharing the results but if you don't mind can you please elaborate this statement?

So this is the reason of why billing documents in 2016 have the same condition as from 2015, because of this sequence of changes.

Rest you got that right about inconsistencies in KONV and glad to know that you've been able to update it properly. Appreciate the way you dig this out . Thanks.