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 :)