[ic] No code for currency in orderlines or transactions

[Marc Villeneuve]

Hi,

I do agree that there are a lot of useful features in Interchange to handle 
currency, and the fact that I am making this work for my point of view on 
currency handling, is a testimony to how flexible this software is.

I have taken the middle road on this, I'm trying to disturb the system as 
little as possible:

- Added a field in transactions to save the locale (order_locale) in which 
the client has posted the order.
- Added a default var in catalog.cfg called "DefaultAdminUILocale" to set 
the default locale for the Admin interface to whichever currency/language 
suits you.

- Modified order, order_view, customer view etc (wherever there is an 
amount of $ related to an order, to show $ CAN or US $ as defined in 
locale.txt )

- Modifying (in progress) the sales reports for the month, affiliates etc 
to convert currencies so that the total is represented in the 
"DefaultAdminUILocale" currency (converting amounts as iis needed).

Todo:
- Add the currency rate at the time of the transaction to the transaction 
table for future reference (like the reports, so the amount is not 
recalculated based on the new rate, which it does now in my code).

- Make all the modification dependant on a var in catalog.cfg, so they can 
be switched on/off. They are not that complex, but there are too many files 
to go through to just reapply patches every time there is a new version of 
Interchange on the horizon.

I hope to make this whole thing transparent, so that we could achieve many 
modes of handling of cases for that kind of problem without disburbing 
every catalog that has been built on it.

Thanks!!!

Marc Villeneuve
Inuzite inc.




At 04:16 PM 2/16/2001 -0500, you wrote:
>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.
>
><PERSONAL-OPINION>
>
>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.
>
></PERSONAL-OPINION>
>
> > 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
>
>_______________________________________________
>Interchange-users mailing list
>Interchange-users@lists.akopia.com
>http://lists.akopia.com/mailman/listinfo/interchange-users