I know what you mean about the help on SET DECIMALS. It does seem to imply it's only a display function but somewhere a long time ago I wrote some testing code, triggered by a currency data type discussion IIRC, that demonstrated different results occurring based on some combination of multiplication vs division, currency data types, rounding and set decimals. The conclusion I came to at the time is when a more precise value is required, add more precision to the factors and make sure all factors have the same precision. IOW if one of your factors has 4 decimal places then express all your factors to 4 decimal places before you do your math because VFP may do something funny to your calculated value. Again this is really only a potential concern when dealing with larger numbers predicated on a large number of transactions. A penny on a single $100 transaction is usually not any cause for concern. A $1000 cumulative error on hundreds or thousands of transactions may not be a real worl d issue but it will probably raise a flag that requires investigation and then you're headed down the rabbit hole. And if that flag was raised by your local tax/VAT authority the fun will be even greater...
-- rk -----Original Message----- From: ProfoxTech [mailto:[email protected]] On Behalf Of Peter Cushing Sent: Wednesday, June 18, 2014 12:17 PM To: [email protected] Subject: Re: VAT Rates Richard Kaye wrote: > With larger numbers the rounding error can be more significant so it > depends on your tolerance for those kinds of differences. Accounting > types tend to be picky about that kind of stuff. :-) > As long as it is right to the nearest 0.01 then that is good enough for a bean counter ;-) You may need more places when using exchange rates where more than 4 places may be required. So for calculations you could set up your currency vars (net, vat, gross etc) as currency, then exchange rates as numeric then use NTOM to convert the calculation to the nearest 0.01 in currency. > One solution I've used in VFP is to change SET DECIMALS to some larger > value such as 8 AFAIK that is only the number of decimals displayed (with SET FIXED ON) and makes no difference to the accuracy of the calculation. Had a look at the help but it is not specific but sure I've read it somewhere. > before doing the rounding as this will push the ambiguity further out to the > right side of the decimal point. I also found out that using multiplication > vs division (i.e. x*.01 vs x/100) can return different results so I started > to always use multiplication. > Interesting, will watch for that. Peter _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/DF1EEF11E586A64FB54A97F22A8BD044239C2AC223@ACKBWDDQH1.artfact.local ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
