>Hi Handoko,
>
>This is an interesting problem which is common to many countries,
>Italy with the Lira and Spain with the Peseta come to mind, Turkey,
>many countries in Africa too, and in South America.
>
>In my many travels around the world what I have usually found is that
>while at "street level" it is possible to deal in tens and small hundreds
>of the local currency, for example when buying something in a market,
>at "business level" in 90% of businesses one almost never ever buys anything that is priced lower than, say, one thousand units of the local currency.
>
>Therefore, depending on whether that suits you or not, you could always
>decide that what you will be holding will be purely units of thousands.
>For instance, if your numeric field holds 1,357, then you would
>display on screen 1,357,000 IDR.
>
>This is just one solution. I would be extremely interested in learning
>how the Italian, Spanish, Turkish, etc..., Universal Thread members
>handle their local currencies given that, often, prices could
>exceed the FoxPro limitations.

Ahhh, the memories of the bad old days. Welcome to my favorite nightmare - check the Guinness' book for the greatest inflation ever.

Two tricks have done it most of the time (in FPD days). First, assign a global variable, like g_round=2 and use it wherever a rounding occurs, like lnInvoiceTotal=round(lnInvoiceTotal, g_round). Save this variable in an invoice's field. When the state says "no more decimals", say g_round=0. We've had it going up to -6 (when our currency unit was one million dinars).

Another trick was to assign pictures (aka InputMask) from another global variable (usually had two of them - one for the prices, one for totals). It worked with @ ... GET whatever picture g_pic; nowadays we should have .InputMask=(g_pic), probably (didn't try yet). This variable was a cute thing to edit over a modem, but then we had to write most of the reports using the ? and ?? ... picture g_pic AT [a calculated var comes here], so they expanded and collapsed as needed.

Third layer of maintaining things like that was the denomination routines, which actually took summing everything up into a cursor, writing it back with a negative value, and writing it back once more with a positive value divided by 10, 100, 1000 or 1000000 (depending on the denomination length). It differed from app to app, though - many times some things actually lost their values completely, so they were artificially assigned a value of 1.

As for tables, we had to keep the value fields at n(20,2) so they'd accomodate the wildest combinations. Watch out, IEEE numbers support only about 15 digits of precision, so an arithmetic goes like this:

125+1e18-1e18=0

This happens because the rightmost digits get lost.

I'm glad it's over now (we're back into the "below 100% annual inflation" club), and I wish all the best to anybody who may have to go through it.