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