KONP table

[Former Member]

Hi

I have a question regarding the KONP table in SD which stores condition records.

In the condition record, we have stored the Sales TAX as 6.5%. However in KONP table it is showing up as 65%.

When i create a Sales Order it is applying the tax correctly.

So I was just curious to know why is the entry in the table *10 for TAX condition records.

However the same doesnt apply for condition type calculating the base price.

The amount in the condition record is $12 & its shows up as $12.

Can anyone suggest why is it doing so ?

Thanks in advance

vinit

[Former Member]

Solved

[Former Member]

HI Vinit,

I know this issue is common to show up the values in KONP table. But my problem is related to the V/LD report, do you see the same % age shows up there also. When I run the report the same value is showing up from KONP, I mean to say in multiples of 10, did you have the same problem? I am looking for an answer for this, your response is appreciated.

Thank you

Pradeep

[Former Member]

Hi Vinit,

Please let us knw how you solved this. We have the same issue.

KONP table shows an extra zero for the discount condition

Thank you

Rajini

[Former Member]

Dear Vinit,

Your Observation is right, in SAP it is not only Tax but all the Percentage value is stored as value multiplied by 10 for the Data type CURR. The value appears properly because the output to the screen is always value divided by 10.

This can be explained much better by an ABAPer.

Regards,

Karthik.

[Former Member]

>Can anyone suggest why is it doing so ?

Good observation,I have noticed this as well.As you have stated there are no problems or issues due to the way this value is stored in KONP.

I think the reason is purely technical, the field that is being used to save the value in KONP does not have a data type that can hold decimal values and it can hold only numerical values.

And since KONP is being used from past several releases and the observation noted here does not have any impact on the functionality it has been the way it is.

These are just my thoughts(do not have system access right now,and I am not even sure if the actual field is numerical data type and cant take decimal values),but this is the best reason I could think of.

May be you can take a look at the data type of this field in question and confirm the same.