Re: Currency stored as cents

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux