Also, take a look to SET DECIMALS. Basically, it's the same thing as your rounding setting.
Vlad
>> Ok, so how do I do all calcs with the same precision? The currency
>> data type always returns things out to 4 decimals, but I have not
>> seen a fractional penny as of late. How do I keep all answers to be
>> at no more precision than pennies - with ROUND()? Why do I want
>> currency to be at four digits? Can I change it to only 2 to eliminate
>> the issue?
>
>Just do it :)
>The accountants are weird people, as we all can witness. VFP keeps the
>numbers in IEEE double format internally, so it means 15.5 digits of
>precision when you calculate something and store the result into a
>memory variable or object property. When you Replace or Insert into a
>table field, it gets rounded to the field's precision - in case of Y
>fields, it's 4 digits.
>The only known way (AFAIK) to override this is to round the results
>BEFORE storing them into a table field, i.e.
> lnResult=some_value*0.003434+other_value*some_field
> lnResult=Round(some_value, gnMantissa)
>I recommend you set gnMantissa as a global variable - in your case it
>equals 2, so it can be configured independent of the app (somewhere in
>an .ini, or registry, or some config.dbf), because you never know when
>you'll sell it into some high inflation country, where the rounding
>rules change every few months. I remember I had set such a variable to
>-6 in some days, than had to reset it to 2, then 0, then -3, then -6,
>then 0 again.
>
>Another point to consider is the moment when you round it. General rule
>of thumb states that if it will be totalled, then it should be rounded.
>Simple case of this is tax on the invoices. I used to keep only the
>price, quantity and the tax rate in the child record, and round it up
>only in the master record. This fitted well with the theory, normalizing
>and minimizing redundance.
>
>Then they wanted to have tax total per item code, so I recalculated the
>tax once more, and got some silly little roundoff error (say 3.25 for a
>total of 90,000), and it was only the difference between tax calculated
>per invoice and then rounded vs tax calculated per item code total and
>then rounded. This sounds like a negligible minor problem, but the
>accountants won't let you out if these two figures are not completely
>equal.
>
>So I had to switch to rounding the tax for each child record, and
>writing it into a new field in the child record (it was three fields,
>really - at the time we had federal, state and city tax). The total
>roundoff error was probably grossly increased, but nobody cared: the
>totals were equal, and I never had to recalculate :)
Previous
Next
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only