Hi,
Saturday, July 2, 2005, 6:57:07 PM, you wrote:
S> The lack of a specific type to store monetary values is something of a
S> problem with commercial applications. Be it that you have value added tax
S> or sales tax to add per-item to an invoice or any other calculation like
S> commissions, discounts and such, you end up with an endless number of
S> insignificant decimals which cause trouble. If you forget to round off the
S> extra decimals, comparing for equality doesn't always work, if you carry a
S> running total with the whole decimals, the total of the invoice might not
S> always come good, as the rounding of the total might differ from the total
S> of the rounded individual values. Been there, wrecked that. I've been
S> avoiding this traps out of discipline and hard work, but it is really
S> tiresome.
S> Thus, I was thinking, is there a better way? Even Microsoft added a
S> currency data type to its Visual Basic long ago. Shall we wait?
S> In the meantime, how about storing monetary values as integers, and storing
S> them in the database as integers as well. You see, to show them in the
S> screen, I always pass them through a formatting function. Whenever I read
S> them from the user input, I do it through a parsing function. If those
S> functions scale the value the appropriate number of decimal places, nobody
S> cares how it is used internally. And currency values, no matter what you do
S> with them, they always scale the same way. You will never multiply two
S> currency values together. There is no such a thing as dollars-squared. If
S> you have two positions for cents, it will always be so, no matter what you
S> do with them.
S> I guess, it would be prudent to have a scaling factor to allow for, for
S> example, tenths of cents. Several kind of businesses express their unit
S> prices in fraction of cents, because they never actually sell units and the
S> difference does add up in the total. So, you might set that factor to zero,
S> for those currencies that use no cents (as was the case with the Italian
S> Lira or the Spanish Peseta), two, as for the Euro or Dollar, or even three
S> or four, for certain specific business. Anyhow, the only functions that
S> would care about this scaling factor would be the user input/output
S> functions, internally within the application, you wouldn't care. Actually,
S> it would need to values, the scaling factor (which might be three) and the
S> number of decimal places (which might be two).
S> Of course, integers have a range limit, and the type of business has to be
S> the kind that manages with only that.
S> Now, am I missing something in all this? Please comment. Thanks
S> Satyam
I store dollar amounts as integers and use this function to convert
function dollars2cents($value){
$value = sprintf("%0.2f",trim($value));
list($a,$b) = explode('.',$value);
if(floatval($value)<0) $b = $b*-1; //negative amount?
return intval($a)*100 + intval($b);
}
--
regards,
Tom
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
