Currency class?

N

Neill

I'm working on a shopping cart application and need to crunch some currency
numbers. This has been discussed on mailing lists I monitor, and it seems
the recommended way is to create a currency class. Any pointers, examples,
suggestions? TIA
 
T

Tony Morris

Neill said:
I'm working on a shopping cart application and need to crunch some currency
numbers. This has been discussed on mailing lists I monitor, and it seems
the recommended way is to create a currency class. Any pointers, examples,
suggestions? TIA

The only problem I see with that solution is the problem itself.
The problem with the problem is that the problem is not defined.

More specifically, "need to crunch some currency numbers" is hardly a well
specified requirement.
Many people under-estimate the implied consequences when the problem
definition is unclear (as in this case).

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform
 
N

Neill

S

Sudsy

Neill wrote:
BTW, how can you say the applet uses the latest currency conversion rates?
Does the applet load the rates upon each use? From where?

Not meaning to dissuade you, but are you truly prepared for the
complexities you're about to face? If you're performing conversions
then you must appreciate that the rates change daily, if not more
frequently. What are you going to do about reporting in consistent
form? Even more challenging is when circumstances require you to
make a full or partial refund. How do you reconcile the fact that
the rates were different on the day the payment was made and the
refund or credit issued?
These are serious issues, BTW. You end up having to store the daily
rates in a persistent store so that you can go back to a specific
transaction and work from there.
Sounds trivial? Suppose you accepted a payment of CDN$500 on Jan.
1st of this year. Suppose further that you convert to US$ and the
rate for the date was 0.7729, yielding US$386.45. The product was
DOA and you've just received the product back at the warehouse.
But the conversion rate today is 0.7207. Do you use that rate? If
so then the customer will receive CDN$536.21.
The customer will probably be very happy. But what if the rate
changed in the other direction? Suppose the Canadian Dollar has
risen against the greenback and the rate today is 0.7965. Using
the daily rate will result in a refund of CDN$485.19. The customer
could get quite upset, rightfully claiming that they remitted the
full CDN$500, not CDN$485.19.
Now you can try to explain how currency conversion works until
you're blue in the face, but you're likely to end up with some
very unhappy customers.
Been there, done that, didn't even get the t-shirt! :-(
 
L

Liz

Neill said:
I'm working on a shopping cart application and need to crunch some currency
numbers. This has been discussed on mailing lists I monitor, and it seems
the recommended way is to create a currency class. Any pointers, examples,
suggestions? TIA

If you don't want to go insane you will want to tap into a "web service"
that you can "consult", perhaps using SOAP, for each transaction. The
exchange rate changes quickly, so you will need to record the parameters
for each transaction for further processing; you can't go back and do
another
lookup because the value will have changed. Maybe need to store this in a
database.
 
R

Roedy Green

R

Roedy Green

How do you reconcile the fact that
the rates were different on the day the payment was made and the
refund or credit issued?

on my own site the actual payment is done in a US dollars. The
displays are for information only.

It does get a bit strange when you bill people in foreign countries.
You bad better stick to mentioning the billing amount in one currency
only, even if they pay you in other ones. Otherwise it gets very
complicated what you mean by the outstanding balance. It differs
depending on what currencies you use and how they have fluctuated in
the interim.
 
L

Liz

Roedy Green said:
on my own site the actual payment is done in a US dollars. The
displays are for information only.

If you have ever used a credit card in another country you would know
that the exchange rate they use is usually the day when the transaction
is processed. The amount is charged
in the currency of the country where the purchase was made and converted
to the country where the user's account is registered. I did have a
boss once that claimed that most of his foreign transactions were
held for a considerable time before processing to take advantage of
the trend in changing exchange rates. Nowadays, I don't think that
happens.
 
S

Sudsy

Roedy Green wrote:
It does get a bit strange when you bill people in foreign countries.
You bad better stick to mentioning the billing amount in one currency
only, even if they pay you in other ones. Otherwise it gets very
complicated what you mean by the outstanding balance. It differs
depending on what currencies you use and how they have fluctuated in
the interim.

I was merely attempting to hint at the potential pitfalls. You can
record the transaction in either the source or target currency, but
there are always going to be ways to abuse the system.
If you standardize on target then what happens when a country de-
valuates its currency, for example?
Would you agree that it can get complex?
 
L

Liz

Sudsy said:
Roedy Green wrote:


I was merely attempting to hint at the potential pitfalls. You can
record the transaction in either the source or target currency, but
there are always going to be ways to abuse the system.
If you standardize on target then what happens when a country de-
valuates its currency, for example?
Would you agree that it can get complex?

No I don't agree, the "bill" should be completely nailed down at the
time the transaction is processed. If/when the end user decides to pay
there may be other adjustments like penalty interest, devaluation (as
you mention), bankrupcy and a bunch of other stuff.
For example: if I don't pay my bill for 10 years you should not have
to go back and change the original credit card slip.
 
N

Neill

Sudsy said:
Neill wrote:


Not meaning to dissuade you, but are you truly prepared for the
complexities you're about to face?
<snip>

I'm not doing conversions, just simple math. I'm going by an article from
JavaWorld for now,
http://www.javaworld.com/javaworld/jw-06-2001/jw-0601-cents.html

In the article, it states BigDecimal loses accuracy around 13 digits or
more. Just curious what other people are using.

http://www.strikeiron.com provides currency conversion web services if you
need accurate rates in the future.
 
N

Neill

Liz said:
If you don't want to go insane you will want to tap into a "web service"
that you can "consult", perhaps using SOAP, for each transaction. The
exchange rate changes quickly, so you will need to record the parameters
for each transaction for further processing; you can't go back and do
another
lookup because the value will have changed. Maybe need to store this in a
database.


Thanks, in fact, http://www.strikeiron.com offers just that. I'm not doing
conversions, just simple addition and multiplying. BigInteger is working
fine for now, just curious about statements I've heard made about creating
your own currency class to handle financial calculations.
 
N

Neill

Tony Morris said:
The only problem I see with that solution is the problem itself.
The problem with the problem is that the problem is not defined.

More specifically, "need to crunch some currency numbers" is hardly a well
specified requirement.
Many people under-estimate the implied consequences when the problem
definition is unclear (as in this case).

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

Sorry bout that, it's for a shopping cart application that needs simple
multiplication and addition. BigDecimal is working fine, just curious about
statements I've heard from other people about creating your own class to
handle financial calculations.
 
M

Michael Borgwardt

Neill said:
I'm not doing conversions, just simple math. I'm going by an article from
JavaWorld for now,
http://www.javaworld.com/javaworld/jw-06-2001/jw-0601-cents.html

In the article, it states BigDecimal loses accuracy around 13 digits or
more.

No, it doesn't. BigDecimal *never* "loses accuracy". What the article
states correctly is that double has a limited precision and
the sample code uses double as an intermediary for displaying
values via NumberFormat. Unfortunately, while the Java API proviced
a class that allows arbitrary-precision arithmetics, it does not
provide a means for formatting such numbers without imposing
limits of precision.
 
R

Roedy Green

Sorry bout that, it's for a shopping cart application that needs simple
multiplication and addition. BigDecimal is working fine, just curious about
statements I've heard from other people about creating your own class to
handle financial calculations.

You perhaps want something that tracks how many digits past the
decimal each currency wants and display the national budgets to the
penny.
 
L

Liz

The department of commerce provides conversion rates
and they use six decimal places. For example
12/19/2003 1.188733
for euro to usd
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,734
Messages
2,569,441
Members
44,832
Latest member
GlennSmall

Latest Threads

Top