Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Currency data type, BUG or FEATURE?
Message
De
13/03/2006 14:26:12
Dragan Nedeljkovich (En ligne)
Now officially retired
Zrenjanin, Serbia
 
 
À
11/03/2006 08:16:25
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Versions des environnements
Visual FoxPro:
VFP 9 SP1
OS:
Windows XP SP2
Network:
Windows 2003 Server
Database:
Visual FoxPro
Divers
Thread ID:
01102959
Message ID:
01103898
Vues:
22
>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.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform