Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Currency data type, BUG or FEATURE?
Message
From
13/03/2006 14:26:12
Dragan Nedeljkovich (Online)
Now officially retired
Zrenjanin, Serbia
 
 
To
11/03/2006 08:16:25
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Environment versions
Visual FoxPro:
VFP 9 SP1
OS:
Windows XP SP2
Network:
Windows 2003 Server
Database:
Visual FoxPro
Miscellaneous
Thread ID:
01102959
Message ID:
01103898
Views:
23
>I don't mean the function itself is complicated, it is the decision on when and what to round that makes things more complex (do you round to how many decimal places? at the line level or at the totals level? are there different currencies involved in different lines of the same order? how are taxes rounded? are there different kind of taxes with different roundings?)

I've had a case where I had to go for a less acurate procedure. Why? Because the accountants, who were to give the final OK on the whole thing, were calculating so, and they'd want to check my results. For one, I was supposed to calculate the original amount from an amount which contained 12% tax. First I calculated it by
nAmount=round(nOrigAmount*(100/112),2)
...which actually meant multiplying by 0.892857. Which then turned out to be wrong, because they never did it that way - they had the value of 12/112 written down as 10% (and no damn decimals), so my result would differ by 0.007143 - which is a lot, when applied to a sum of few thousand. So I had to rewrite it to be
nAmount=round(nOrigAmount*(1-round(12/112,2),2)
... which is quite wrong, IMO, but it gave them the expected result.

So, it all depends on your users. Accuracy may hurt sometimes :).

back to same old

the first online autobiography, unfinished by design
What, me reckless? I'm full of recks!
Balkans, eh? Count them.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform