Re: [mv] How to internationalize pricing properly?

[Mike Heins <mikeh@minivend.com>]

******    message to minivend-users from Mike Heins <mikeh@minivend.com>     ******

Quoting Toni Mueller (support-minivend@oeko.net):
> Hello,
> 
> I think about displaying a price-per-user for items in a highly
> dynamic manner. Example: You are looking at Item "T" and see
> a price of 100 USD. Now you want that in DEM and display eg.
> 100*2.14435 as the DEM value. Tomorrow exchange rates have
> changed, and it should rather be 100*2.11937. If you actually
> buy, the item should cost you 5% more if you buy here, and
> some 55% more if you are at the other side of the globe (or
> similar).
> 
> How does you tackle this problem? How do you model the
> different tax laws, customs, currency problems, and
> transport costs around pricing?
> 
> How do you integrate products of mixed currencies in a
> reasonable manner in one shopping basket? Is everyone
> forced to pay in USD, or do you offer paying in a local
> currency?
> 
> Am I too far off for what Minivend or Interchange is about?
> 
> 
> I could try to maintain a large table for locales and maybe
> invent some to solve these problems partly, but that seems
> to be a major maintenance headache with nasty legal
> implications. I also read how to display DEM and EUR
> concurrently, but that doesn't seem to fit my bill.
> 
> My other ideas are to (try to) re-design the [item-price]
> and assorted tags to do this or to demand a unit item
> price in the products data base and plug in an external
> program that does this sort of recalculations. I must
> say that I would like to avoid that kind of effort.
> 

You mentioned Locale, so I assume you have looked at setting
PriceDivide and PriceField per locale.

I still don't get how you plan on modeling the rules, but you can
always put your own little routine in line in the CommonAdjust
string:

CommonAdjust   :price, "& $Tag->locale_adjust()"

(You could equally put [locale-adjust], but the direct calc call
will be more efficient.)

That will pull a base price out of the appropriate products table, then
run your adjust UserTag which is expected to return a CommonAdjust
atom adjusting, not setting, the price. The current base price is
available as $s, the quantity as $q, and the item hash as $item. That
last is important, because if you wanted to display each item's price
in a separate currency you could.

Then you run your own little adjustor program to do that.

UserTag locale-adjust Routine <<EOR
sub {
	my $total;
	$Variable->{ADJ_USD_TO_DM} ||= 2.244;
	if($item->{currency} eq 'DM') {
		$total = $s * $Variable->{ADJ_USD_TO_DM};
		return $total - $s;
	}
	else {
		return 0;
	}
}
EOR

You can use the $Tag->usertag interface to make external calls, though
of course I would caution against anything expensive like a URL get on
every price calculation.  When I have done this, I usually do a once-a-day
setting of PriceDivide in a locale table.

All of this messes up the subtotals and total_costs. But it would
not be too difficult to define order Route definitions to charge
each type separately.

Once you have defined your process, as usual it is nothing but a
programming exercise. I believe all of the hooks are there in 
CommonAdjust to do most anything you want. The hard part is figuring
out exactly what you want to do. 8-)

-- 
Akopia, Inc., 131 Willow Lane, Floor 2, Oxford, OH  45056
phone +1.513.523.8220 fax 7501 <heins@akopia.com>

Friends don't let friends use Outlook. -- Bob Blaylock
-
To unsubscribe from the list, DO NOT REPLY to this message.  Instead, send
email with 'UNSUBSCRIBE minivend-users' in the body to Majordomo@minivend.com.
Archive of past messages: http://www.minivend.com/minivend/minivend-list