Drupal 6/Ubercart 2 Version

Yes, this is absolutely going to be done. RC1/2 is so new though I haven't had time to investigate that new feature. I'm hopeful that the context part of the price hook will allow this module to reach into the backend and be able to display historical data correctly, e.g. show prices in the order history converted with the exchange rate in effect at the time of the order. In the beta versions and earlier, there was no way to hook into the order history and no way to pass around the context of the price.

I really don't know what form the refactoring will take, since I haven't looked at uc_price at all, so if you have any ideas or patches let me know. It will probably be at least a week before I can get around to starting on this.

Awesome work! I'll try to take a detailed look at it over the weekend. The context doesn't affect the customer so much, except for the order history page; it's mostly the back-end that sees the change (admin orders and reports). And context is important to make my price-rounding feature work properly since you want to round product prices but you DON'T want to round sums and taxes and other currency numbers.

Then the last step is to see if the price handler can be used to force the right number to be sent to payment gateways, without having to hack the gateway code to understand more than one currency.

I assume it would work since we are basically hooking into the entire store's system and manipulating the price

It's not the numeric price that's the problem, it's the units - say, 150.22 of what ? Dollars? Euros? The gateways don't know about the multicurrency module, so they don't know how to figure out what currency is in use. Instead, they have an admin setting which is used to hardwire the currency that will be sent to the gateway.

Hi All,

Any progress on the patch since April 30th? I see #9, and I'm going to be working on this for a client as well. Just getting up to speed.

Chris.

What is your rounding setting? I turned rounding off, and things looked better, but not perfect. I'm trying to add support to uc_discounts_alt. I'm having trouble because it's displaying subtotals and discount totals that don't quite add up to the order total.

The patch from http://drupal.org/node/475474#comment-1638700 stops prices being doubled in the cart block and cart pane on the checkout page, which affected uc_vat - the module currently contains a workaround for this. If the problem occurs with orders further into checkout, you might have enough information in $context['location'] or $context['subject']['order'] to be able to tell the currency of the price that was passed and that it should not be altered again.

I don't have time to review this fully right now but will try to take a proper look soon, it'd be nice to get multicurrency and VAT working simultaneously!

The patch in #15 seems identical to the patch in #2?

The patch gets things working partly. I have CAD and USD as allowed currencies, and switching between them using the Currency Selection block now allows me to see the increase CAD price. However, the USD price (default price for UC) is now $0.00. Switching the default currency to CAD has no effect, and the CAD price shown is still the higher, converted price (shouldn't it be the display price entered for the product?). I also set the multicurrency price handler as the default.

One other thing, in a table View of the products, with a column for Sell Price, if I have USD as the default currency with the multicurrency price handler, the prices are all $0.00, and switching currency does not change them. If I switch the price handler to the default one, the prices change to the CAD price (and don't change when currency is switched via the block).

incrn8, I think I'd fixed this things in my patch. You should apply it after multcurrency-price-handler.patch. The reason behind the problem was providing three numbers ISO code instead of two letters one at uc_multicurrency_selected_currency function.

BRG, Alexey.

Thanks, but that doesn't seem to help. I checked through the patch, and I don't see where it does anything with 3 letter or 2 letter codes. Its the right patch?

incrn8 the magic is here
$options['country'] = variable_get('uc_multicurrency_default_country', 'US');

returns 3 numbers ISO country code and added
$options['country'] = db_result(db_query("SELECT country_iso_code_2 FROM {uc_countries} WHERE country_id = %d AND version > 0", $options['country']));

translate it to two letters ISO country as it is expected by
$options['currency'] = variable_get('uc_multicurrency_country_currency_'. $options['country'], $default_currency);

Well, may be I did something else with currency.module or ubercart one, not sure. BTW, this patch also fix currency sign position problem.

Thanks for the clarification, Avm. Sometimes I'm a bit dumb on the PHP stuff - still learning it all :)

@TP, I think so too about the default USD thing, however if I switch to CAD as default, it still doesn't work. Maybe its because 'US' is used on some of the variable_get commands...oh, maybe that's what you meant by default. Doh. It seems that 4 hours sleep a night makes one a bit slow :)

Awesome job!! Works like a charm. Thanks a lot.

can someone upload patched uc_multicurrency.module file as i don't have access to ssh and when i modify code manually it gives me errors!

Thanks in advance!

Folks

I have implemented the above patches and still appear to be running into several issues. I could really use some help/advice please
Some useful info about site I am creating:
a. Base currency is EUR.
b. Store currencies are EUR, GBP and Swiss Francs (CHF) (i.e. no USD, which I think, for error one below, is significant
c. Defined conversion rates: EUR to GBP: 1 to 1, EUR to CHF 1:1.6

Error 1
In a nutshell - If I display the price of a product in GBP it correctly shows the same price in GBP (.i.e. it applies correct conversion 1:1 and shows currency symbol). If I switch to EUR a conversion is applied (at the moment that is .7164). 'Coincidentally' this is the EUR:USD exchange rate (taken from www.xe.com). In other words the EUR price is converted to US dollars but the currency symbol displayed is the EUR. I will dig some more on this and find some more info - this one is really a bit bizarre and perhaps it is me doing something VERY stupid.

Error 2
The 'multicurrency price' (i.e. with correct currency symbol) is not displayed all the way through a checkout process. For example, I see a EUR symbol next to my shipping rate pane where it in the checkout process but in the 'totals' area, it appears with GBP symbol. On the 'review' page only the product price at the top of the page appears in GBP, the rest in EUR. Additionally the invoice e-mailed to the customer shows everything in EUR, not GBP. (similar issue discussed here? http://drupal.org/node/475474 )

Gents, I bow to your superior knowledge here and can I ask for a little advice:

I need to get this 'store out the door' within the next week. Should I, in your opinions:
Go back to UC Beta4 and the old multicurrency? (or perhaps that wasn't working either and I just didn't look closely enough at the time?)
Press forward with this code?

Your advice would be greatly appreciated.

Thanks

Adam

Sorry - let me give a better example for Error 1:

(remembering base currency is EUR). Also, I have added USD to help with example
Product A costs 50 EUR
Test exchange rates are EURO:GBP 1:0.5, EURO to USD 1:2
If I show the product in GBP it correctly display 25 GBP as the price
If I show the product in USD it correctly shows the price as 100 USD
If I show the product in EUR it incorrectly shows the price as 35.77 EUR (it has taken the 'spot' rate for USD to EUR of .7154 and used that as a conversion factor

regards

Adam

PS - I will read above again to see if any of the code contribution already remove this issue and apologies if that is the case

OK, may have fixed Error one:
Added:
$default_currency = variable_get('uc_currency_code', 'USD');
At approx line 985, before:
$factor = variable_get('uc_multicurrency_factor_'. $currency,uc_multicurrency_convert($default_currency, $currency, 1.0));

So I guess this is a similar fix to #24

Bit more info on Error 2

(Purchase process, for this example occurs in GBP, again, exchange rate EUR:GBP is 1:2)

- Product A is 50 EUR, it correctly displays as 25 GBP (when viewing the product)
- I add it to the cart - price is correctly displayed
- Proceeding to checkout - price is listed correctly in basket contents at top of page
- I move my way through the various panes and when I get to 'shipping cost' I see that price is displayed, unaltered, in EUR
- In the 'payment method' pane, I see the sub-total and total, both in GBP. The shipping has this time been converted (exchange rate applied) to GBP

I then review the order:
- Cart contents are listed in GBP , price is correct
- Shipping rate is listed unconverted in EUR
- Under payment method, subtotal, shipping and total and back in EUR

I submit the order and review e-mailed invoice:
- All prices are in EUR

If I 'play' with lines 1063 and 1064 (unrem case 'cart-checkout-item' and/or case 'cart-preview-subtotal-item' I do get an effect on prices - but not a desirable one.

Hope this makes sense

Adam

FYI On a separate virtual machine, I have 'hacked' a downgrade to UC 2 Beta 6 and used the 'old' uc_multicurrency. All prices were showed correctly, including the invoice. I don't really want to go 'backwards' but do I have an option?

Regards

Adam

As I move through the system and start looking at the actual order history, both under the current multicurrency (patched) on UC 2 RC3 and the old multicurrency I see that all aspects of order history will need some work:
Order history reflects currency of admin viewing the site, not the currency of each purchase
The 'invoice' reflects the current currency of the admin too - not the currency of the purchaser. The figures are the figures paid by the purchaser

Could anyone shed some light on this? Does it operate differently in Drupal 5? (i.e. display purchasers' currency in the invoice or historic exchange rate calculated amounts in the order history?

Regards

Adam

OK, so in latest version (correcting myself above) orders are recorded in the site's currency, with the exchange rate of the transaction? So I had better rephrase the statement above:

Order history HAS HAD a great deal of work. The comments above refer to UC Beta 6 (sorry - very stressful couple of days)

TorgosPizza

Thanks for the info and advice and for taking the time to read my often-confused 'blog', LOL. Here's another one for your amusement.

Due to the changes between Beta and RC releases in the area of multicurrency I have been giving this a fair amount of thought (most of it while desperately trying to sleep!). Now that I have been through this whole process I am starting to think not only of the customer's view but also of the client's bookkeeping exercise. 'Today' (and I mean today), my Beta 6 implementation is better from the customer perspective.

Let me paint a picture that may help shape some flexibility in the future final design of how this will all work:
The website I am working on sells womens apparel, throughout Europe. The client requires that she can not only target a country with a specific 'marketing price' (like 49.95) but also that that price appears in the currency of that country (and that is the bit OBVIOUSLY that makes this all the more difficult). Additionally it is required that the currency and country specific price are provided automatically to the customer, i.e. a UK customer arrives at the site and they get the UK 'marketing price' in GBP. Next, the customer is charged (on their credit card) in their currency. Oh, and lastly, all this is done for an anonymous visitor (i.e. the cusomter does not have to log on to see the price)

What is the overall goal here? Essentially each country/group of countries sees a 'marketing price', not a price calculated from a realistic exchange rate. The customer sees a price that is appealing. Jeez, I sound like a marketing exec! :-)

My approach there suggests to me that the base currency is not the base currency from which all other product prices are calculated but rather the currency INTO which another country's price is converted for internal system reporting. It is kind of backwards to the current model. It is kind of an extension of the uc_multiprice system that would allow you to specify a currency and a product price for each country. (in case you haven't seen it, uc_multiprice lets you specify different prices but they are all in the base currency. I achieve the above by having 1 to 1 exchange rates for all currencies and then enter a country-specific price. That base-currency price for that country is converted (1 to 1) to the target price when the page is visited from that country. This approach, while great for the customer tagreting, is completely lousy for any sort of accurate sales figures in the back end. Hence my desire to enter a different targeted price for a country in its currency, then the internal reporting would be accurate enough for rough sales figures and projections.

When I turn my thoughts to the backend and think through the fact that money will be received in different currencies (into separate currency accounts) and perhaps once a month those monies will be moved into the 'base' currency (with likely a floating exchange rate). So ... that would mean from a bookkeeping perspective, I think (in my case only perhaps) you would want the transaction currency (and of course the amount of the transaction in that currency) preserved in the system's records and displayed when viewing an order, or list of orders. Why? All accounting functionality cannot be achieved through UC as it stands (in my case anyway). I will need a way to pull out all orders and then translate those figures (having first subtracted the credit card company commissions and merchant account fees!!!!) to the base currency with the rates that were achieved at he end of the month. i.e. transactions occurring in another currency would sit in an account for that currency until moved to base currency.

TODAY, how do I think I would achieve this? Probably some database export routine to take the data to a spreadsheet and do a bit of maths there. I see from looking at the DB schema that the info is there (uc_order_currency' has a history of the currency of each transaction)

So where does this leave me on day three?
- Single currency site, priced to suit the country with the most customers and wait for UC/multicurrency to offer a working solution?
- Implement two+ sites (gasp). One in GBP, one in EUR and later, one in USD
- Implement UC Beta 6 with old multicurrency and upgrade when UC/multicurrency have a solution?
- Sell everything in terms of 'grams of gold' :-) . After this financial crisis is all over that is surely the best place to be (but that's another story!)

All of these will need some sort of data export mechanism (UC seems to be light on this). I'll probably hack the current UC reports to give me what I want. I looked at uc_edi but on first look I can't see how I am going to get that data into Excel

Regards

Adam

TorgosPizza

Sorry, I did mean to reply to your advice to use latest RC. That is my preferred approach; always. But as can be seen in #31 unfortunately it is not suitable, from a customer perspective (today, anyway). I suspect I need to do option 3 from #36 until multicurrency is a little more stable. :-( .

Regards and thanks again for listening and I do think that all the 'price alteration work' (multiprice, multcurrency, VAT etc) will help increase the global reach of UC. I think these units of work should be viewed collectively too (IMO end result will be better)

Adam

Adam, have you looked at the multiprice module (http://drupal.org/project/uc_multiprice)? This sounds more along the lines of what you want - a fixed price for each currency. IMO, multicurrency is great for when you are actually only selling in one currency, but want people to see what they are paying in their currency. I used multiprice for a client who physically sells in two currencies, and it works fine. The only caveat is that you need to have a country select block to change currencies for anonymous users - something about caching affecting automatic price generation.

incrn8

Thanks heaps for the feedback. Have another read above (sorry, there is a bit). I am using uc_multiprice in conjunction with uc_multicurrency. Essentially, this is how I have 'hacked' it together on my test system as I try to find the ideal solution:

- ip2cc to provide country/location detection
- countries API to provide additional country info (country codes)
- uc_multiprice to provide different costs for different countries (remember that these alternative prices are priced in the base currency)
- uc_multicurrency to perform currency conversion from base to customer currency and provide correct currency symbol. Here I am actually experiementing with 1:1 exchange rates

PLUS - I have to change the gateway code to bill in the customers currency NOT store currency.

In order to get around the anonymous issue you mention, I switch off caching (site is < 100 products) and pass relevant country info that uc_multicurrency requires via $SESSION variables. This removes the need for any country block for currency changing

In beta 6 of UC this was all working, but as uc_price() has been implemented in RC1 onwards (obviously for all the right reasons) things have stopped working (#28 and #31). In attempting to uncover the issue I did uncover one fix #30 but as you can see from #31 things just aren't quite there yet.

Hence my thinking of going back to Beta 6 and use that for DAY ONE until a stable alternative under UC RCx appears.

I am VERY interested in your comments above the two currency store you built. Could you expand on that a little? Do you mean you used (as I have done, both multprice and multicurrency) or did you do something else?

Thanks again for the feedback

Regards

Adam

PS just found a very simple Excel CSV export module that I should be able to modify to export the order data that I need (as per requirement mentioned above - uc_excel

Ah, I missed the bit about using both modules, my bad. That's an interesting way to do things, by the way, but it does seem overly complex. Disabling the cache is not really an option for me, as the client will be getting lots of traffic, and it would be bad for his performance.

I initially did use multicurrency, but seeing as prices varied on a daily basis, and the client wanted fixed pricing for Canada and US, I switched to uc_multiprice. I use only that module, along with a patch to fix Views support (http://drupal.org/node/512160) and another patch to uc_paypal to allow Paypal to process in the selected currency (http://drupal.org/node/512186). The default currency is US, and I add a Canadian price override. Then I stick up the country select block and boom, we're done.

I would love to have auto-switching currencies for anonymous users, but it doesn't seem possible, so for now the block stays. Not really a huge deal, as maybe some users want to switch currencies even if they're not physically in that country. And people seem to be OK with doing that - I've seen it on many other sites where you choose your country, so its an acceptable practice.

Thanks incrn8

I will see how I get on. I have, unfortunately performed the dreaded downgrade :-( . I'll let you know how it turns out. The currency switch is, I agree, acceptable, if your client doesn't mind 'slightly out of your marketing hands' pricing. I may speak with theclient about this and maybe just the uc_multicurrency and some rounding may do what they ask.

Regards

Adam

How soon will the new release of this module?

I have patched fresh downloadeded uc_multicurrency.module with http://drupal.org/files/issues/multcurrency-price-handler.patch.
It works strange a lot. Currencies is calculating but formats from multicurrency settings is not using by code. Only main shop format settings works.
Is it right? And now only this version is ready?
When we can get new version for 6 Drupal?

Thx for the good module! We need it strong! =)

subscribe

I hate to ask for more clarification on this, but here seems preferable to starting a new issue.

So, I have a site I'm configuring where I'm trying to have a product users can buy that has price/currency per country. I'm OK having the user pick (via the UC Multiprice-provided block) what country they want to pay in. Planning to accept GBP (preferred default), USD and possibly EUR. I'm OK not having automatic exchange rate calculation.

However, when I view the site, I'm seeing the USD amount but the currency symbol is the store default (pounds). If I change country via the block to UK, it's right. What's the best way to make the symbol match up with price? Has someone sorted this out, or do I have dive into code?

Thanks for any advice.

This might be part of my problem. I started out trying the MultiCurrency module, but then saw #40 above and followed its steps completely thinking it was a shortcut to the desired outcome. At this point I've run into what I presume is that code's assumption, that I want to only sell in one currency (GBP), so even though I've setup a US entry with a different price, its still showing the pound symbol. I assume thanks to the PayPal patch to set the currency according to the country, that I will end up with a USD sale at PP, but I haven't made it that far in my testing yet.

Maybe I'm supposed to work in the multicurrency module here, to get the desired behavior? I have added to my site, but not turned on, multi-currency 6.x-1.x-dev, with Currency 6.x-1.1. UC_Multiprice is 6.x-1.0, patched as I mentioned in #40.

Feel free to send me elsewhere if this is really a multiprice module question, but I have a feeling the answer might lie in the combination, but I feel a bit lost without a hint. I didn't quite understand what Roman was getting at in #43. I'm very grateful for your time and any guidance.

Sorry - poor explanation. Partly because I'm trying to fast track figuring out Ubercart to get payments working AND figure out requirements all in one breath...thanks for sticking with me...

I'm trying to sell a product that has a price in GBP and a different price in USD. I think when I ran into discussions like this one, I got a little spooked that I would be able to get what would likely be a 'typical' multicurrency exchange rate solution working easily enough for the time I have, and tried to punt to Multiprice, but ran into the fact that, despite the face that it lets you choose country (and #40 tells you how to make paypal charge a currency based on country choice), my users are seeing the pound symbol on my US price instead of a dollar sign when they use the multiprice-provided region block to select US.

It looks like some people (see #39, example) are doing something like I'm describing, but I was unclear whether this was an intended use of Multiprice+Multicurrency, possibly one supported if I have the right patches to the modules, or maybe I have to dive into the code to get what I'm looking for.

Thanks (again!).

Please someone could provide a patch or the file patched for the current development version? (1st of July). I couldn't patch this version with this patch. Or the 1st of July version is the patched one? If that's the case, I will continue looking forward because the uc_currency_format function is not called by Drupal/Ubercart.

Thank you.

I guess 1st July version is not patched. Im also looking forward for "normal" patch. Would be glad.

Emil

subscribing

@PetePete
I think your're served with multiprice module and the following patch: http://drupal.org/node/546084
Then you can change the currency symbol for each country.

Tried to apply first patch multcurrency-price-handler.patch to dev and it said it was already applied
Tried to apply second patch multcurrency-price-handler2.patch and it gave me this

patching file uc_multicurrency.module
Hunk #1 FAILED at 1106.
Hunk #2 FAILED at 1114.
Hunk #3 FAILED at 1147.
3 out of 3 hunks FAILED -- saving rejects to file uc_multicurrency.module.rej

Any idea when these patches will be rolled into the Dev?

Thanks
Gregg

First off, gotta say this does EXACTLY what i'm after and thank you guys for the upgrade and patches. I have used patches from #17 and #19 plus the snippet from #24.

I have a site which has it's input price as dollars ($) but shows in the catalog in Swedish Kronor (kr)

But have stumbled across a couple of errors .....

1. Incorrect prices shown
I have altered the price handler settings to accept multicurrency and when logged in i see the kr prices fine. However, when anonymous, i see no prices at all (with multi currency selected in price handler) or still in dollars (multicurrency delselected). I would like kr shown to both anonymous and users

2. Error on format settings tab

When i go to 'format settings' , i now have the following error :

Fatal error: Call to undefined function uc_currency_format() in /home/mjrcc/domains/localbiz.se/public_html/gbicoutlet/sites/all/modules/multicurrency/uc_multicurrency.module on line 580

the snippet around line 580 is as follows:

     /* Form to display how this currency will be formatted */
      $form['uc_multicurrency_formats_'. $currency_code]['uc_multicurrency_format_'. $currency_code] = array(
        '#type'        => 'textfield',
        '#title'       => t('Current format'),
        '#value'       => uc_currency_format(1000.1234, TRUE, TRUE, NULL, $currency_code),       [line 580 here]
        '#description' => t('Prices in this currency will display as shown above.'),
        '#disabled'    => TRUE,
        '#size'        => 10,
      );

This affects the comma separator in kr as it shows the comma instead of a space

Any ideas?

Many thanks in advance

UPDATE:
It seems upon further testing that i cannot get an anonymous user to view the prices in kr. Does anyone have a suggestion on how to get multicurrency working for all users rather than just logged in users?

howdy queue, is there a chance someone can post his full working version of the module, commented with the patches he/she applied?

Seems things are getting a bit tangled, so this might help who's after this functionality.. thanks a lot in advance ;)

I second this request... also a little clarification as to whether the original readme is still relevant with D6.

thanks for the work so far torgosPizza.
I really need this module, any news on updates, any patches that need testing?

Subscribing

Subscribing

Update to post #55
Well, after a lot of messing with the settings i have managed to get the multicurrency module doing what i need it to do on a D6/U2 installation
.
The brief was to have product prices input in US$ (as the client buys their product from the US) and displayed to ALL in Swedish Kronor.

I used the patches/snippets from #17, #19 & #24 and am using the IP2CC module.

In my store settings, i have all countries enabled. The settings i have used are as follows:

All countries are set to show SEK regardless of their currency. The setting that threw me was in the multicurrency setup where the default currency was originally set to Swedish Kronor. This didn't work for anonymous users. To make it work, i changed the default currency to US$ and hey presto!, i have Swedish currency showing. I have no currency switcher or country switcher blocks enabled at all.

The last bit of the puzzle was to remove the thousand separator which i did in store setup for the default currency and then a bit of CSS to make the values line up on the right.

Just as a note, the 'format settings' tab in multicurrency still returns an error. I don't know if that is a code error or my input error when applying the patches. I'm no expert when it comes to coding :(

What i also don't know yet, is what currency shows when viewed from another country ( although i will check it on a UK IP address later when i have time )

I have attached the .module file for info although i take no responsibility if it doesn't work for anyone else.

Lastly, thanks to TR and torgosPizza for the great module :)

Site: www.gbicoutlet.se

Thanks for all the great work people, this module fills a hole in the great feature set of ubercart :)
If you are looking for inspiration of a solid workflow with multi currency have a peak at whats being developed for Xero. http://blog.xero.com/2009/05/multi-currency-sneak-peek/

I tried your .zip cside and I did not get an error on the 'format settings' tab.

FYI - this module takes a new approach with multi currency, by leveraging the power of CCK
http://drupal.org/project/uc_cck_currency

There's a slight bug in uc_multicurrency_price_handler_format() in post #62 ... the 'return $output;' is inside an IF statement, so it only actually returns anything if there's a sign and the sign should be displayed after the amount:

 function uc_multicurrency_price_handler_format($price, $options) {
   [....]
   // Add the currency sign last if specified.
   if ($options['sign'] && variable_get('uc_sign_after_amount_'. $options['currency'], FALSE)) {

     $output .= $options['sign'];
return $output;
}
  }

I'm guessing that should be AFTER the closing bracket:

 function uc_multicurrency_price_handler_format($price, $options) {
   [....]
   // Add the currency sign last if specified.
   if ($options['sign'] && variable_get('uc_sign_after_amount_'. $options['currency'], FALSE)) {
     $output .= $options['sign'];
  }
  return $output;
}

While I'm here - personally I'd reduce the amount of logic going on in this function, by only evaluating the sign business once - after the price has been number_formatted. Then of course the positive/negative signifier has to be shuffled ... and I think that logic's a bit skew as well, there's a check for abs($price) < 0? Surely that'l never happen...

Anyway, after all my faff, I've ended up with this:

/**
 * Default price handler formatter; formats the price using the store currency
 *   display settings.
 */
function uc_multicurrency_price_handler_format($price, $options) {
  
  $polarity = $output = '';
  global $user;

  // Decide how to format prices for anonymous users
  if (!$user->uid) {  // Anonymous
    if (variable_get('uc_multicurrency_anonymous_behavior', 0)) {
      return variable_get('uc_multicurrency_price_message', t('Please log in to see prices'));
    }
  }

  // Force the price to a positive value and add a negative sign if necessary.
  if ($price < 0) {
    $price = abs($price);
    $polarity = '-';
  }

  // Format the number, like 1234.567 => 1,234.57
  $output .= number_format($price, $options['prec'], $options['dec'], $options['thou']);
 
  // Add the currency sign last if specified.
  if ($options['sign']) {
    $output = variable_get('uc_sign_after_amount_'. $options['currency'], FALSE)
            ? $output . $options['sign'] // sign_after_amount is TRUE
            : $options['sign'] . $output; // sign_after_amount is FALSE
  }

  return $polarity . $output;
}

Actually, on reflection, the formatter doesn't seem to do anything that the default formatter does already, so it could probably be removed from the module altogether...

I'm looking at www.gbicoutlet.se from New Zealand. The prices are in Kronor. I'm viewing the site in English. I can't see any way to change the currency-- not in catalog view, not in cart, not in checkout.
Cheers
Miriam

Site crashed big time last week whilst moving site from one server to another .... have had to remove the multi currency feature for the time being as it was throwing pages of errors. It may or may not be related to the module but needed a quick fix.

Have gone back to a simple manual db upload for pricing for the time being. ie the client has a db with product prices in US$ .... he then enters the exchange rate into a db calculator which drives out the price in sek. He then uploads the db to the website using a php import script which updates the prices.

At the moment this works as 95% of the customers are in Sweden. I don't actually need the facility to show different currencies in different countries just now.

However, will be trying the patches again in the next couple of weeks and will let you know what happens.

Subscribe

Subscribe

Subscribe.

subscribe

subscribe

Subscribe

subscribe

Subscribe and Bump.
Any updates on this issue?

How about some collective found raising to sponsor a developer to get this module to work?

@ torgosPizza

Hey, at least one for the idea :)
How should we proceed?
We need to define one who can code it (you?)
and find some sponsors (me?)
and collect money (here?: http://www.chipin.com)

Hi
I'm actively working on an Ubercart project that requires:
*Price set in base currency
*Prices displayed in user's currency with conversion via current exchange rates (using currency_api from currency module)
*Orders submitted to paypal/other merchants using user's currency
*User can change currency in block by selecting from drop down which shows configured currency codes
*Exchange rate that was used to complete the order is recorded against the order
*Admin Reports are displayed in the base currency
*Customer reports are displayed in the user's currency with conversion using the rate recorded against the order (ie does not change over time)

I'm assuming much of this is intent of this module.
If so, I'm putting my hand up to pitch in to get this over the line.
My deadline is a month away so I'm not looking for a quick fix, but rather a thorough and stable module.
I've done various Ubercart customisations before, including co-writing the uc_hotel suite of modules.
If you're interested in a coordinated effort, please get in touch at www.rowlands-bcs.com/contact.
Regardless, I'll be working on this project so we may as well work together!
Lee

@lalowran
Thank you for your task list. I think that is exactly what we need!
Especially recording the currency together with the order, to get a sane order (income) tracking.

I am looking forward to it and assist you where I can!
Below my comments and wish list :)

* In addition to the currency block you describe above, the users default currency selector should be available in the user profile (respectively user account page), to save the currency setting (per user) permanently. Like the ability to choose the language, the user should be able to set his default currency there, when they register their account.

Changing the currency in the block, could also change the setting in the user account. So, the currency is remembered and also used the next time when the user comes back.

* A "nice to have" would be an integration with ip2cc. http://drupal.org/project/ip2cc
To get the ability to determine the visitors default currency through his ip, and set the correct language and currency right from the beginning.

* Also a rounding feature would also be appreciated, to avoid "unattractive" prices after the conversion. For example to round prices like 21.86 to 20.00.

* integration with http://drupal.org/project/uc_vat especially to display conversed prices inclusive vat

subscribe......

I'm still trying to get the currency change block to function for an anonymous user. Any help appreciated

@lalowran
Thanks for pitching in, let me know if you need any help with frontend code

Subscribing

A "nice to have" would be an integration with ip2cc. http://drupal.org/project/ip2cc
To get the ability to determine the visitors default currency through his ip, and set the correct language and currency right from the beginning.

I am wondering if we are there yet ?

I have an online store and want two currencies, one is Australian and USD for other countries apart from Australia.

How do I implement this please ?

Thanks

Hi All
Please find attached another set of patches.
These seem to tick all of the boxes for multi currency payments in the users currency (including anonymous users) and integrate with the ip2cc module.
Historic transactions appear at their historic rate and an order comment records the native amount of the sale (i.e. default currency).
To get it to work needs three small patches to Ubercart core – there were a couple of order panes from uc_payment and uc_order that did not pass the order object in the context[‘subject’] variable to uc_price (even though they related to an order object) and a further patch to get uc_paypal to store the currency of the sale.
This will only work with uc_paypal. If you have a different gateway it will require changes to the uc_multicurrency_form_alter function to override the currency field in the payment form.
I’ve logged the patch for the three Ubercart issues as issue #727404: Various order pane functions need to pass order in uc_price context['subject'] variable.
This modules gives you a price handler, you need to go to admin->store->settings->price handlers and enable the handler (no changes here).
You need to configure your currencies using the admin->store->settings->multi currency settings (no changes here).
If you want anonymous currency conversion - you need to disable ubercart price caching (from price handler screen).
Happy testing!
PS: Please cc all comments via www.rowlands-bcs.com/contact as I won't get back here to check for replies

send to contact form of larowlan, but I describe the problem here too :

Hello,

OIt seems there is a problem with shipping calculation... If I let the same currency (CHF or swiss franc for my products and shipping cost) there is no problem. But if I change country (ie France to apply the Euro currency) the shipping cost are not calculated correctly...

In the "calculate shipping cost" fieldset I have a value, and in the total amount of order I have another value, but this twices values aren't correct. And total amount is not correct too.

IE :
- my product cost is 10 CHF
- my shipping cost is 8 CHF
- the rate between CHF and Euro is 0.6842

Normally, I must have :
- product cost : 6.84 Euro
- shipping cost : 5.47 Euro
- total cost : 12.31 Euro

In the calculation fieldset, I have 3.52 instead of 5.47 Euro

In the total amount fieldset, I have :
- product cost : 6.84 Euro
- shipping cost : 5.15 Euro
- total cost : 10.37 Euros

even the total cost isn't correct... It seems that it take the product cost + the shipping cost in the calculation fieldset.

I will see if I found a solution but if you have a quick patch to add I'm interested.

Cheers.

Thierry aka titouille

EDIT : amount fieldset, I have 5.15 Euro on shipping cost... I don't know how this amount is calculated... because 8 * 0.6842 = 5.47. But in shipping calculation fieldset, I have 3.52 = 5.15 * 0.6842. So the rate is applied a second time on the initial 5.15. But how this initial cost is calculated ? 5.15 / 0.6842 = 7.52.

My flatrate is :
- base price : 6.50CHF,
- per unit price : 1.50CHF

to have a total of 8CHF for one product, 9.50CHF for two products, etc... (increment of 1.50 per product)

The mystery is about the 5.15...

Another bug I found : the review order simply doesn't work. connection stopped by server... If I disable multicurrency module all is ok, but with multicurrency support, when I click on "control order" button I can't see the review. I tried with a fresh install and it crashes.

If I comment uc_multicurrency_price_handler_alter and uc_multicurrency_apply_conversion, the review pane appears. The problem is in the price_handler_alter function :

On the middle of the function, this is a long if( ... ) like :

<?php
      if (($context['revision'] == 'themed-original' ||
           $context['revision'] == 'formatted-original' ||
           $context['revision'] == 'themed' ||
           $context['revision'] == 'altered') &&
          ($order = $context['subject']['order'])) {              // problem is on this line
          $order = uc_order_load($order->order_id);
        //set the currency for the formatter
        $options['currency'] = $order->currency['sale_currency'];
      }
?>

the $context['subject']['order'] is a stdClass, so we must access it with $context['subject']->order in php5.2, like this :

<?php
      if (($context['revision'] == 'themed-original' ||
           $context['revision'] == 'formatted-original' ||
           $context['revision'] == 'themed' ||
           $context['revision'] == 'altered') &&
          ($order = $context['subject']->order)) {
          $order = uc_order_load($order->order_id);
        //set the currency for the formatter
        $options['currency'] = $order->currency['sale_currency'];
      }
?>

I think it's my php version and configuration in cause, but this is a possibly bug for some people. Now I can't find solution for my earlier problem about shipping cost, but I continue searching a possible solution...

Hi
I can confirm that shipping costs are not calculating correctly and that support for ip2country does not extend to anonymous users.
Re #88, will investigate to see where the $context['subject'] variable is an object because it should always be an array?
Patch to come in coming fortnight.
Lee

subscribing

Hi, this module looks great! I was wondering how far along this module is from development release? Is there currently a bounty I can contribute to? It's needed for a site i'm working on.

Thanks for all the hardwork that's gone into it!

Hope all is well,

Evelyn

subscribing

larowlan,
Tax is also broken, unfortunately.

I desperately need this module to work...

+1

subscribing

Some more patches
Note uc_flatrate and uc_weightquote appear to call uc_price incorrectly.
These have been logged as #790028: Uc Flat rate and Uc Weight Quote call uc_price incorrectly and are included in the ubercart.patch.
Also issue #727404: Various order pane functions need to pass order in uc_price context['subject'] variable still remains and is included in the attached patch.
These are cumulative patches and include the previous ones.
Kudos to Idan Arbel (http://www.arbel-designs.com) for sponsoring my work on this.
Give his site a visit, he is an awesome graphic designer.
I now believe this is close to ready. If you do use the patch and it works, please make comments as such below.

Hi larowlan,
First of all thank you providing those patches, I have tested those patches, it converts the amount, however it doesn't changes currency symbol. I have tested your patches against ubercart 6.x.2.2 and multicurrency 6.x1.x-dev.
Could you please guide me what i am doing wrong?

subs

subscribe

Please note that there is an issue with the above patches and paypal, patch attached below. This patch is for multicurrency only so you still need the Ubercart ones above. This is a cumulative patch.

hi guys,
i applied the patch for muticurrency from #100 and the ubercart patch from #96.
As it seems while I use the country block the price will be re-calculate.
But as I wanna change the currency formats and go to the page
admin/store/settings/multicurrency/formats
I get this errror:
array(4) { ["type"]=> int(1) ["message"]=> string(48) "Call to undefined function uc_currency_format()" ["file"]=> string(95) "/home/rob/public_html/opentrabi.de/test/sites/all/modules/multicurrency/uc_multicurrency.module" ["line"]=> int(586) } n/a

Any ideas how to fix it?

Thanks a lot.
/rob

UPDATE: after a complete reinstall of the drupal system incl ubercart and all modules i'm able to access this page without any problems.
BUT!!!
the changes i make to the currency formats are not working.
seems a problem of permissions to overwrite the default currency format as if i change them the change is working but not the one from the multicurrency module

pls help :)
/rob

I just applied the patch and it works!

Thanks for this.

My prices change automatically depending on country settings that a user makes from a drop down.

The implementation has however killed using Userpoints as a payment system.

The userpoints don't show on the product pages but are available as a payment option.

Any help?

Hello,

I believe I've followed all the directions above and applied all the proper patches, but I still have two problems:

1. Product nodes (with or without attributes) do not reflect the converted prices, but they do show a change in currency symbol.

2. The shopping cart block converts all prices correctly, but does not change the currency symbol on the line items - it does in the total, however.

#2 has been "fixed" by simply choosing not to show the line items in the cart, so I'm mainly concerned about #1. I need to fix this one before I can go live with multicurrency.

Is anyone else experiencing something like this, or does anyone know why this might be happening?

Thanks in advance!

subscribing

subscribe

subscribing

edit:
Please can someone confirm the correct list of patches that need to be applied to the latest dev version of multicurrency and ubercart, or alternatively post fully patched versions. Thanks for your help.

subscribe

Here is a new version of the Ubercart patch at 96 rolled against Ubercart 6.x-2.x-dev.
You still need the patch at #100 for multicurrency.

@larowlan - Thanks for your patch. Trying it out with ubercart "6.x-2.x-dev" from 2010-08-13, and drupal 6.14

Tried it out and looks good.
- one thing I found so far is that currency symbol still shows default for store, even though I have the right ones in admin/store/settings/multicurrency/formats and also country changed via the country block. Please is there another patch to apply? I saw an old one further up the list but is from 2009.

- briefly tired out order history - shipping value was still shown in non-default currency, so order looked wrong. Noticed that this is mentioned in #89. Please is there any additional setting or patch?

Thanks for your help.

Sub

subscribing

First off, thanks to all the contributors!
I'm drupal and ubercart newbie, learning on the fly.

I tried patches at #100 and #108 on drupal 6.19, ubercart2-dev and multicurrency -- and it seems to be working.
Is there a way to limit the choices for the country selection block? I only want to have two, CAN and US for the rest.

Could somebody please checked the attached if it behave the same on your setup. It's a hack job with the inclusion of currency block found here: http://drupal.org/node/470650 I'm testing it locally offline with php-5.3.1, mysql 5.1.46 .
patches used: #100 #108, some part of #13 from http://drupal.org/node/470650
These are the behaviour I get:

uc_multicurrency_get_country() ---- this one always return AU for US

anonymous user can make the selection from the dropdown and the price gets converted after applied but the currently selected reverts back to the default, logged user doesn't have that problem.

paypal sandbox doesn't get the conversion, If I use CAD the price handler is good upto the submit order but paypal gets it, for example $83.05 USD instead of $76.47 USD.

edit1: forgot to mention I also used ubercart.patch from #96
edit2: I'm using paypal express checkout (if that matters)

yes, i also facing the currency symbol not change, just the amount only.

@larowlan, can you help us solve this problem. thank you

Make sure you choose the multicurrency module as the price formatter from the Ubercart admin screens, not the default formatter.

thanks for the reply.

by the way, i found your patch that you removed function uc_currency_format(). it cause Fatal error: Call to undefined function uc_currency_format() when i click Format Setting at Multicurrency Setting.

+
/**
- * Format an amount for display with the store's currency settings.
- *
- * This is a modified version of the core Ubercart function uc_currency_format()
- * The core function must be renamed so that this one can be used.
+ * Implementation of hook_uc_price_handler().
*/
-function uc_currency_format($value, $sign = TRUE, $thou = TRUE, $dec = NULL, $currency_code = NULL) {

I followed the instrucstion when installed multicurrency module to rename the function uc_currency_format() at modules/ubercart/uc_store/uc_store.module

Do i need to restore back function uc_currency_format() at uc_store.module or uc_multicurrency.module?

Hope can hear from you soon. thank you

Hi, sorry this wasn't my patch, I'm not sure what you are referring to here. I definitely didn't patch anything in core Ubercart relating to a uc_currency_format function. The only patches I made to Ubercart core were to do with passing around the order object to uc_price and another to get uc_paypal to save the currency of the payment to the database.

hi,

maybe there is some understanding. what i mean i followed the instruction from install.txt from the multicurrency module that i downloaded just now. It says need to rename the uc_currency_format at uc_store.module as there is function uc_currency_format in multicurrency module. so i renamed the uc_currency_format to uc_currency_format_original at uc_store.module.

then i update your patch at the comment #100 and #108. For the patch #100, i saw the code below. i'm not sure - is to remove the line of code. if is remove the function uc_currency_format($value, $sign = TRUE, $thou = TRUE, $dec = NULL, $currency_code = NULL) {, then will got Fatal error: Call to undefined function uc_currency_format() because no more function uc_currency_format.

i think i'm facing the problem same with the comment #116.

+ * Implementation of hook_uc_price_handler().
*/
-function uc_currency_format($value, $sign = TRUE, $thou = TRUE, $dec = NULL, $currency_code = NULL) {
+function uc_multicurrency_uc_price_handler() {
+ return array(
+ 'alter' => array(
+ 'title' => t('Multicurrency price handler'),

multicurrency not support attibutes options price?

I've applyed #100 and #108 patch. These are works (except currency format handling - read above) but the taxes modul calculates the VAT (or other taxes) from the original currency price. Additonal patches needed.

@kepesv - see #115
You also need to choose the multicurrency module as the price formatter via:
admin/store/settings/price-handlers

Regarding attribute options not being converted but only having their symbol changed, I think the attached patch fixes that.

I'm a relative newcomer to Ubercart, but going through the code, it looks like uc_attribute.module's setting of $context['revision'] to "formatted" causes uc_multicurrency.module's uc_multicurrency_price_handler_alter() to return early (line 1001).

The attached patch checks there for attributes and if it finds them, doesn't return. This seems to perform conversions properly and make the orders come out alright in my basic testing.

Any progress with extending ip2country support to anonymous users?

If not, I was about to jump on it, just tell me.

Best regards

Just what I've been looking for! Works fine so far, have not checked it as anonymous user yet. Will be doing further tests on it and see how things go.

Hi,
Does anyone have a working multicurrency module with the new uc_price?
I searched for hours..and I am not able to get it to work.
Could it please be winzipped in this thread please, a working version with all patches stated here?
Thanks a lot in advance!

greetings,
Martijn

I'm interested too, because I have patched some times the module but converting from anonymous user will not work for me

converting for anonymous users tends to work (for me anyway) when disabling drupal's caching mode

Subscribed.

Subscribed

subcribe

Current version of the patches etc tracked here: http://drupal.org/sandbox/larowlan/1213514

subscribing

larowlan, you have forgotten to add correction for sign after option, like in comment #62 or #65. Here is patch based on your git version.

sunscribing

subscribing.

When I clone this, I only get 2 files. uc_coupon_mc.info and uc_coupon_mc.module. I assume I'm doing something wrong.

With multicurrency enabled I get this error on the Review Order screen

warning: mysql_real_escape_string() expects parameter 1 to be string, array given in /includes/database.mysql.inc on line 329.

with address ad UNKOWN and Paying by blank.

If I go back and try again it works fine. This does not happen with multicurrency disabled. Any ideas what this might be, as not sure where to start looking

Ok I found that changing function uc_multicurrency_order($op, $order, $arg2) { to

function uc_multicurrency_order($op, $order, $arg2) {

  switch ($op) {

      
    case 'save':
      // Save currency conversion information

        uc_multicurrency_init_order_currency($order);
      
      db_query("UPDATE {uc_order_currency} SET store_currency = '%s', sale_currency = '%s', conversion_factor = %f, conversion_multiplier = %f, rounding = %d, rounding_decimal = %d WHERE order_id = %d",
               $order->currency['store_currency'],
               $order->currency['sale_currency'],
               $order->currency['conversion_factor'],
               $order->currency['conversion_multiplier'],
               $order->currency['rounding'],
               $order->currency['rounding_decimal'],
               $order->order_id
      );
      if (db_affected_rows() == 0) {
        db_query("INSERT INTO {uc_order_currency} (order_id, store_currency, sale_currency, conversion_factor, conversion_multiplier, rounding, rounding_decimal) VALUES (%d, '%s', '%s', %f, %f, %d, %d)",
                 $order->order_id,
                 $order->currency['store_currency'],
                 $order->currency['sale_currency'],
                 $order->currency['conversion_factor'],
                 $order->currency['conversion_multiplier'],
                 $order->currency['rounding'],
                 $order->currency['rounding_decimal']
        );
      }
      break;
      
    case 'load':
      // Load currency conversion information for this order
      $result = db_query("SELECT * FROM {uc_order_currency} WHERE order_id = %d", $order->order_id);
      if ($data = db_fetch_object($result)) {
        $order->currency                          = array();
        $order->currency['store_currency']        = $data->store_currency;
        $order->currency['sale_currency']         = $data->sale_currency;
        $order->currency['conversion_factor']     = $data->conversion_factor;
        $order->currency['conversion_multiplier'] = $data->conversion_multiplier;
        $order->currency['rounding']              = $data->rounding;
        $order->currency['rounding_decimal']      = $data->rounding_decimal;
      }
      else {
        // No currency data for this order.
        // Assume store currency = sale currency and multiplier = 1.0
        $store_currency = variable_get('uc_currency_code', 'GBP');

        $order->currency                          = array();
        $order->currency['store_currency']        = $store_currency;
        $order->currency['sale_currency']         = $store_currency;
        $order->currency['conversion_factor']     = 1.0;
        $order->currency['conversion_multiplier'] = 1.0;
        $order->currency['rounding']              = 0;  // No rounding
        $order->currency['rounding_decimal']      = 0;
      }
      break;

    case 'delete':
      // Remove currency conversion data associated with this order
      db_query("DELETE FROM {uc_order_currency} WHERE order_id = %d", $order->order_id);
      break;
  }
}

got rid of that error