[ic] No code for currency in orderlines or transactions

Mike Heins mikeh@minivend.com
Fri, 16 Feb 2001 16:16:50 -0500

Quoting Marc Villeneuve (marc@inuzite.com):
> Thanks for the hint Stefan, I applied it and I am on my way to solving the 
> whole thing in a week or two.
> I will contact Akopia`s  team to try to submit these patches for currency 
> handling. As a non-american (german ?) yourself, do you disagree from the 
> way I want to solve this whole mess? I really would like your opinion on 
> this. 'ricans have great qualities, but they have such a huge internal 
> market ready to buy (280 M people), that handling 2-3 different currencies, 
> is not their priority. Being Canadian, and even worse, being a Quebecer 
> (latin people, read frenchman like) where we as a people are really pissed 
> when we don't get served in our own language and money, I have got to solve 
> this whole thing before I can push Interchange as a solution.
It is really a process definition issue. There is no "correct" way to
do it that I know of.

If you are to display the order amounts to the user in their currency,
it would be nice to have that on record. You can't really derive it from
PriceDivide, for the exchange rate may change.

Probabaly the only "correct" way to do it is to double-log the price in
orderline and transaction -- the actual dollar (or drachma) price at the
time of order and the amount that the user was shown. Actually Interchange
is quite well-suited to that -- just add a few fields to the database
tables, use [item-field price] for one and [item-price] for the other,
and away you go. Even if your price has discounts to where that would
not work, you can do a [setlocale currency=foo].

I think it *would* be nice to log the currency locale used at the time
of purchase, and I will have that field added to the next version's
demo. But anyone can do that themselves.


I take just a teeny-tiny bit of offense at the American bashing (since
it was the teeniest and tiniest of bashes). 8-)

I tried very, very, hard to put good internationalization features in
Interchange. Certainly much more than I received benefit from when I did
consulting and produced most of them -- the great majority of my clients
were US-based. I did it because I wanted Interchange to be international
in scope. I believe it has proved to succeed at that to a pretty good
degree. So in short, I paid LOTS of attention to it and I did not think
of only the US.

I cannot, however, be familiar with the customs of every country and
the details of every business process. That is why I tried to make
it flexible enough so that if you apply yourself you can do virtually
anything you need to do with Interchange.


> What I am trying to figure out, is: is this a general problem? Or mine 
> only? If it is mine only I will not bother Akopia with it, and I will keep 
> these patches for myself.
> Otherwise:
> I will add a variable to catalog.cfg to set handling multi-currency on/off, 
> and modify every currency handling for orders to be properly addressed and 
> submit diff file to the Akopia team.

If anyone has any constructive suggestions or work that applies to all
locales, I am very ready to listen to what we can do to make Interchange
even better in this regard.

Customizing to one country and one business process is not that, but it
is useful. The most useful thing would be a white paper on customizing
Interchange to your country/locale and your business process. That can serve
as a guide to people who have to go through the same thing. I believe that
most of the industrialized countries in the world have had at least one
Interchange catalog produced for them, and it would be nice to build a
library of little documents that speak to them. I will certainly put
them in the FAQ if they appear. 8-)

Red Hat, Inc., 131 Willow Lane, Floor 2, Oxford, OH  45056
phone +1.513.523.7621 fax 7501 <mheins@redhat.com>

Experience is what allows you to recognize a mistake the second
time you make it. -- unknown