View Full Version : Multiple Currency Support
I think it would be great if you added multiple currency support to WHMCS, about 50% of my customers pay in £GBP and the other 50% pay in $USD, so at the moment WHMCS can only track half of my customers payments.
Thanks Matt. :)
You can already support multipul currencies via PayPal Invoices and PayPal Subscriptions
You can already support multipul currencies via PayPal Invoices and PayPal Subscriptions
Yes, PayPal supports multiple currencies but WHMCS can only track one type of currency at the same time...
It's a difficult one but I'll definately consider it.
Matt
Greetings,
I also want reforce this request... it is a good one.
On my case I have customes in Brazil, US and Canada... 2 currencies and 2 languages.
I'm using another system that has all of that but I'm liking whmcs way better so, Im suggesting this too.
So... here is what I see out there:
1) Each customer has a language and a currency.
2) Each currency has a default language... client can change that when purchasing.
3) Each instalation has a default language and default currency.
4) All currencies have a conversion rate to the default instalation currency.
5) Each order stores a currency and a rate for the installation currency.
6) all products and services are stored with the default instalation currency.
7) when purchasing, if client changes the currency, system will use the rating conversions to calculate the prices in the new currency.
8) All system emails need text for each language.
9) All products need description on all installed languages.
I guess that is about it.
Cheers,
Marcelo
Hey,
I would like this to, or maybe have it like different lanuage? I would like to offer a UK price to my site and currently I only offer it in the US $ standard since WHMCS can't show the UK on the order form with out chaning everything. Maybe have like the order URL
order.php?cur=UK&blah blah blah
Thanks,
Adam
That is it Adam!
The system only need to know how much is 1UK in relation of 1US so it can convert the prices.
See guys? Im sure more people will find this useful too.
:wink:
Yep, ok, someone submit it to the tracker, I think we could get this into V2.6 and if its a customer based setting it shouldn't be too difficult. Could also save the users language aswell if this will help.
Matt
Yep, ok, someone submit it to the tracker, I think we could get this into V2.6 and if its a customer based setting it shouldn't be too difficult. Could also save the users language aswell if this will help.
Matt
Just added it to the tracker Matt: http://tracker.whmcs.com/?do=details&id=176 :D
Just like to express my interest in this. It would really help service international clients. Could any one provide an estimate as to when it may be available?
Will be within the next 2-3 months I would expect.
Matt
Will be within the next 2-3 months I would expect.
Excellent Matt! I am very excited about this, it will really bring WHMCS upto the next level. :D
Its good news.
Just a thought. Something that would be great for Worldpay users would be if you could integrate with the page Worldpay make available to their clients that details the exchange rate they are adopting. It means the exchange rate applied would be the same as that used by Worldpay. Let me know if you would like any furhter info on this.
Hi
I wonder if someone (Matt!?) could provide an update on this one? Its quite an important one for me strategically and I'd be interested to know if its still likely to be appearing in WHMCS?
Thanks.
I wonder if someone (Matt!?) could provide an update on this one?
Yeah, an update on this would be great. :)
im looking forward to an update on this one too :)
Hey,
Same here. I mean most of the time PayPal handles this but it would be nice if we could show a different URL like
order.php?cur=UK&pid=2... so it would change the default value of the system to pounds. However then we will need to have different prices.
IE: Something in the US might cost like $5.00
But in the UK be like BGP3.00
(just an example)
So not sure if we have to enter in different payments or have a currancy exchange rate system updated daily.
From,
Adam
Personally I'd like to enter the prices for the supported currencies independantly.
Paypal do not have an API for automatic exchange rate updates, although Worldpay does. That said, I prefer to keep prices rounded to things like 9.95 rather than the odd amounts exchange rate updates could offer - 6.87
thebyp2
01-30-07, 08:25 PM
I don't know why, but i thought whmcs was multicurrency. Doh!
I don't know why, but i thought whmcs was multicurrency. Doh!
It is, but one currency at a time. The interest is in the system supporting multi-currency so clients in different countries see local currency pricing.
Dominic
01-30-07, 09:06 PM
I don't know why, but i thought whmcs was multicurrency. Doh!
It is, but one currency at a time. The interest is in the system supporting multi-currency so clients in different countries see local currency pricing.
Thing is that makes accounting really hard....you have to have everything settled in your native currency, and let the payment gateways handle the currency conversions...such as a foreign users' bank doing the conversion, or Paypal, etc :)
Thing is that makes accounting really hard....you have to have everything settled in your native currency, and let the payment gateways handle the currency conversions...such as a foreign users' bank doing the conversion, or Paypal, etc :)
Dominic is correct here. The main issue is accounting. It would no longer be possible to have the transactions list provide totals, financial reports would all need to be split into each individual currency, a currency would need to be selected each time you create an invoice or add a transaction. It just adds complication to every aspect of the system is one of the reasons for it not being implemented to date.
At the current time, we offer discounted additional licenses for users in a position where they require multiple installations of WHMCS - one for each currency they offer.
I think there is a bit of an 'it depends' answer, depending on the actual solution implemented.
For example, I would be very happy with a solution that you enter the prices in as your default currency - as at the moment - but give clients the ability to select a different currency for them to see the prices converted into their local currency if they wish. Reporting could then continue in the base currency.
Worldpay enable their exchange rates (which change once daily) to be imported from a php page and enable clients to pay in a local currency whilst you receive payment in your standard currency.
People want to be able to specify the price for a product in each different currency though so it doesn't display as odd amounts like it would if converted using an exchange rate. Which means the payments would need to be logged in that currency.
Its a shame, but I can see where your coming from. I guess multiple installations is the way to go for the time being, but that option is obviously less than ideal and in reality can only be appropriate for a limited number of currencies/countries.
Dominic
01-30-07, 10:55 PM
Editing the templates could probably sort the currency issue, at least for display purposes only. Dunno how flexible Smarty is, but I believe it's possible to run code within the template system :)
Yup, I also want this, its the only thing missing within WHMCS.
Its just a shame I have to get it from MB.
Francisco
02-03-07, 06:45 PM
I would like this implemented very much! :D As well as Google Checkout
Multiple Currency support is a huge feature but one of the hardest to implement.
It's hard because billing systems want to do all this accounting for us which is annoying.
the fact of the matter is I'm sure we all use 3rd party accounting systems. I know we track everything here locally after an invoice is sent.
I hate having to run 2 installations. It's confusing to customers and a real pain for support.
All you need to do is assign a customer to a currency. These currencies are set in the admin area and when we setup products we setup a price per currency for each product. When a client places an order for the first time they select their currency.
For reports, the report can put the currency code next to the $ figure and group by currency. In the next version, the system can ask which currency is your main currency, and then either automatically or manually get the proper rate and convert on the fly.
While Modernbill is the only system to truly support MC, it's a horrible implementation. Because MB decided they wanted to implement a full accounting system the system doesnt' properly report on MC. It's a flawed system. I'd wish someone would make billing software and not accounting software.
Hopefully this helps you because this product seems incredible and we'd like to make the jump from MB.
Multi-currency support is something I am hoping to be able to implement this year but you are right in that it is one of the hardest features to implement.
At the moment, the way I see it is you would setup each currency you want to offer in a new configuration section. When setting up products/services, configurable options, addons and domains, there would then be fields for each of the currencies you have enabled - rather than just using conversion rates from the default currency as that could result in messy un-rounded figures.
The order form would then have a dropdown menu on step one where the client chooses their currency for the order - if not logged in already. Currency would be set on a per client basis, so they wouldn't be able to have some invoices in one currency and some in another. One client would have one currency only.
For the earnings summary on the homepage, and overdue invoices totals, etc... I think these would have to just show a unit figure without any currency, or else there would have to be different stats for each currency which could be messy. What do you think?
The transactions list would be able to list all transactions, in all the different currencies, but there would need to be seperate totals for each of the different currencies that were active.
I don't think WHMCS tries to do too much accounting, transactions are of course logged but this is required to show when and how an invoice was paid.
Matt
At the current time, we offer discounted additional licenses for users in a position where they require multiple installations of WHMCS - one for each currency they offer.
Hello,
How can I make use of the offer? I have problems dealing with invoices/messages in free languages and with 2 currenies...
Sincerely
Just open a ticket requesting it.
Matt,
That's exactly the implementation we need. What we do now is we have 2 accounts Web Hosting CAD and web hosting USD. At the end of the year, we simply convert the USD figure to CAD and file our taxes.
I really liked the look of your system, and as a current use of MB, I would make the switch if you can implement MC...but until then it doesn't make much sense to make the move with all the effort involved.
I'll be watching your product closely. I think with this feature you could really target a huge niche and generate a lot of extra revenue.
Mike
Multi-currency support is something I am hoping to be able to implement this year but you are right in that it is one of the hardest features to implement.
At the moment, the way I see it is you would setup each currency you want to offer in a new configuration section. When setting up products/services, configurable options, addons and domains, there would then be fields for each of the currencies you have enabled - rather than just using conversion rates from the default currency as that could result in messy un-rounded figures.
The order form would then have a dropdown menu on step one where the client chooses their currency for the order - if not logged in already. Currency would be set on a per client basis, so they wouldn't be able to have some invoices in one currency and some in another. One client would have one currency only.
For the earnings summary on the homepage, and overdue invoices totals, etc... I think these would have to just show a unit figure without any currency, or else there would have to be different stats for each currency which could be messy. What do you think?
The transactions list would be able to list all transactions, in all the different currencies, but there would need to be seperate totals for each of the different currencies that were active.
I don't think WHMCS tries to do too much accounting, transactions are of course logged but this is required to show when and how an invoice was paid.
Matt
Wouldnt someone have to pay to use live market currency prices? I dont think you can legally get these in an automated fashion without some type of paid subscription with a provider.
Guys,
I think what you're asking for and what I'm asking for are two different things.
I have a merchant account. One is USD and one is CAD. I set my prices per product and assign them to a currency (either usd or cad). When my customer selects a package and a currency, that currency is assigned to their account for all future billings and is directed to the payment gateway setup for that currency. There is no exchange rate math done on our end, only on the credit cards end when payment is settled (kinda like if you're an American and you buy something from a Canadian site, your CC company will settle and convert your funds, and the Canadian site still gets it's $20).
Any other way overcomplicates things and will require a huge rewrite of any app. If you follow the way I have advised above, you get a system that properly displays and charges your customers accordingly.
Once that is implemented, extra features can be added to stuff like reports to convert those values on the fly to give you an idea of how much revenue/profit, etc you are making.
There is no need to convert values on the fly, otherwise you're just overcomplicating a simple implementation of this feature.
But when WHMCS takes a subscriptions, then they can spread this info across their customers.
Thats not legal.
jesseosmer
05-23-07, 08:14 PM
I would like to chime in and add encouragemet to develop a multiple currency module. Perhaps it is something that could be a check box and activated for those of us who need it so it does not add any complication to those who are only needing one currency.
I am currently billing in 4 currencies and payments are sent to an account in the respective country (unfortunately, not everyone likes to pay with credit card yet). I have 2 installs of whmcs presently to deal with 2 currencies and I have to bill the other ones manually.
But customers using the other 2 currencies are growing and I do not really want to have 4 separate installs of whmcs if I can avoid it. I then have to login to 4 windows to manage my accounts and am not able to have a true overview.
So, again, though I know it is complicated to implement, this is my #1 feature request at the moment.
Thanks,
Jesse
Multi-currency support is something I am hoping to be able to implement this year but you are right in that it is one of the hardest features to implement.
...
Matt
Matt that all is nice, but I think you have complicated it.
1. In my opinion, doing multiple currencies should take into account that a particular company has ONE (and only 1) currency accounting method.
Offering products with different currency options may seem like a nice solution, but it will become a beast -- and namely unmanageable from an accounting standpoint.
2. In my opinion, the base currency should be selected by the admin, and user should be able to set their own currency which uses the admin's FOR-EX/exchange rate for any enabled currencies to enable conversions.
Again the idea here is to keep accounting in one currency.
When a user enters a page or is logged in, a currency other than the default may be written to the session, and used by WHMCS to lookup the FOR-EX rate and apply it in real-time.
Of course these rates may vary over time. (note: They cannot be updated automatically without a paid business type subscription for a data provider, in other words, no s.c.r.a.p.i.n.g from yahoo).
Since they vary over time, the subscription cost should be allowed either to be:
1. locked into a for-ex rate at time of signup
2. use a variable rate based on the for-ex rate stored in the admin area
The admin should have this choice.
At checkout or creation of subscription, the preferred method, 1 or 2 above is stored with the subscription info, in the database as serialized array or separate columns.
Each invoice will also need to store the currency information, since if it is variable or the subscription rate changes, we can pull from the invoice to calculate it correctly.
With each currency, the need for rounding will come into play. For instance JPY uses no decimals, CHF uses is in increments of .05, and you don't want fractions of more than 1/100ths for the Euro or Dollar.
So, the serialized array or columns also need a rounding factor. This way, if I want to offer something in Pounds Sterling and round everything to the .00, or offer everything in dollars at X.99 (that 99 cents is omni present), or in Swiss Francs everything in .50 .. it could be done -- neatly and by storing this info -- ALL WITHOUT the need for separate currency entries for each product.
here comes the beauty of doing it like this:
For accounting, the procedure can simply be reversed, giving the admin an ACCURATE view of the actual AR/AP (accounts receivable/accounts payable) in their OWN CURRENCY -- and without the need to calculate and adjust for each currency used.
For each invoice or overdue notice, you can pull on the exact information that was store in the array or columns, and even when using variable for-ex rates, calculate the amount accurately to the penny -- or pence.
All invoices would be accompanied by the ISO Currency Code used and include some type of standard disclaimer, if the rate is variable.
If it is variable, best would to also include the original base currency billing rate for the subscription in question.
As far as the user presentation of currencies, WHMCS should just use some type of function that uses a number_format($value,"STR","STR") or currency_format ... Admins along with the currency code, currency name, for-ex rate, should be able to specify the rounding, as stated above, and the default format, if your number formatting functions don't support all currencies.
One last thing. For admins, they will also need to specify the appropriate gateway or payment method(s) for each currency specified. This could also be stored in the currency table. Here is an example: Authorize.NET does not accept foreign currency any longer, and all amounts sent to it must be in USD only.
This said, this is the way to do it, IMHO.
One accounting currency with multiple currency support!
(by the way this forum doesn't like for-ex without the dash ... :()
Dominic
05-23-07, 09:11 PM
Trine - I like your idea, but a problem with the psuedo-multi-currency method of using a For-ex lookup to show the customer the equivalent price in their currency is that customers might see heavy fees from their card provider for foreign currency transactions.
What we do is provide the customer a link to pay however they like in our primary currency (eg card, Paypal etc), but if their country doesn't match ours then we provide them another button to pay through Paypal in their own currency. Paypal then convert the transaction to our accounting currency and we enter the transaction.
Quite a bit of work for people with a significant number of foreign currency transactions, but we only do a minimal amount so it's fine for us :)
Of course Dominic!!! That is very true about the fees, hence why being able to specify the gateway or payment method(s) for each currency is a required necessity in my opinion!
What I want to stay away from is having to do multiple currency accounting. I think the idea alleviates that, and simplifies alternate currency based product management.
Trine, the reason you can't do that is because $10 USD today is not $11 CAD tomorrow. Plus now you've done what is counter productive and created an accounting program, which is the big issue with billing systems today.
You should be using a 3rd party app specifically for this (ie. quickbooks, etc)...but anyhow, we need to able to set static prices for each currency. Converting stuff will just get you random decimal #s like $14.37.
Trine,
Your business should be converting or settling currencies at the end of your quarter or year, and with the amount of smaller transactions in this business, it makes sense to do one big conversion at the end of the year then for each transaction.
Trine, the reason you can't do that is because $10 USD today is not $11 CAD tomorrow. Plus now you've done what is counter productive and created an accounting program, which is the big issue with billing systems today.
You should be using a 3rd party app specifically for this (ie. quickbooks, etc)...but anyhow, we need to able to set static prices for each currency. Converting stuff will just get you random decimal #s like $14.37.
um, you missed the point. the whole thing will allow static pricing or variable pricing, but not require you to set each individually.
and additionally, I also covered rounding.
Of course 10 CAD is not 10 CAD tomorrow against the USD, but that is why what I proposed will in fact give you and your customers an accurate representation of what an actual invoice was billed at.
Say, you have static values for each product setup. The currency rate fluctuates, and now you have to adjust ALL of your products.
okay, not a big deal if you have 5 or 10 products.
But also, this means that you moved the price on a product today, because last month the exchange rate was more advantageous, but this month, the new rate will be applied.
How and When .. will you know when it changed?
And, lastly, your business should be settling for-ex gains or losses periodically, but what I proposed actually helps you calculate it better, and more accurately.
I don't know about you, but with my business, if you are doing large volumes and your for-ex rate is of by even a tenth of a percent, that can amount to LARGE figures in the end.
There must be a better way, than what Matt proposed. I am only suggesting what I feel is better, and **without** turning this program into an accounting program.
The objective is a smooth multi-currency possibility, whilst keeping somewhat accurate numbers.
Trine..100% all this talk will eventually make for the best product.
What we do is we set a price for each currency and only maybe every 6 months we evaluate the change in currency and adjust accordingly for new customers.
I like ModernBills implementation but their accounting system just ruins it.
If using the forex method, how would it take into account changes in the exchange rate? Rebill existing customers at the old rate or the new? If you list a price in someones native currency, they would expect the monthly bill to be the same and may not like fluctuations but if the customers amount remained the same then we as the merchant would have our product prices vary by the exchange rate.
It only makes sense from the way I am looking at it is to charge in your currency and have the consumer worry about exchange rates.
Hi Trine,
From what I've been told by discussing this with users, and others it seems in this topic, the way you suggest isn't the way most want it done. Accounting is always going to be difficult when dealing with multiple currencies so that should really be handled seperately. All people want WHMCS for is to accept payments from their customers in each of those currencies, and rather than changing $13.95 to £7.03 using the current exchange rate, most would prefer to do $13.95 to £7.00 by entering seperate prices for each.
Matt
Matt, I do understand. This is just a point of view. Allowing both static and variable rates would be nice and actually offer more flexibility and easier management in the end.
As for PPH point, that is well stated, but if you are going to need to change the static rate, that will happen anyway. And as far as variable rates, that would be up to individual admins to decide, which products would be based on a variable rate.
Either way it turns out, I think it will be at least a step in the right direction, at least in part. ;)
But when WHMCS takes a subscriptions, then they can spread this info across their customers.
Thats not legal.
It's, just check any newspaper, or website with financial information, you find that their sources (when mentioned) are Reuters, Bloomberg etc... they just pay for the feed.
They also have to pay for each person they distribute it to. I used to be an IT Director for a brokerage firm, so i am pretty familiar with these type of policies.
If i remember correctly, a delayed feed was about 02 cents per quote, so lets say we do 1000 quotes per day. Which would equal $7200 a year. I would consider that a decent amount of money.
Also, all those sites listed can not be used freely for commercial use. I bet you didnt even know that you have to have permission to even link to a site in general.
Or, European Central Bank XML Feed - $0.00
http://www.ecb.int/stats/exchange/eurofxref/html/index.en.html
Used by Moneybookers for their pricing (plus a stated margin).
h4f, the ecb site also clearly states that you need permission to use the rates, outside quoting them. The xignite you linked to is for internal use by the company and not for *external* distribution. We actually subscribe to some of the xignite feeds and know this as a fact for many of their feeds.
However, strikeiron.com offers some for.ex feeds which distribution is allowed.
MACscr is 100% correct in what he stated. Everyone pays for exchange data. This is simply because of the way exchanges themselves have structured their fees. Those fees are then passed on to the content aggregators. Aggregators will usually charge you per estimated distribution or per hit.
Government sites that offer interbank exchange rates, usually allow you to quote them and even use their data. However, once you modify it to drive an application, you fall outside the free usage. For instance xignite and strikeiron pay the federal government for their interbank and even their edgar/sec data.
Typically, even though some information may be "free" for republishing, you will find that you are not permitted to programatically grab and reuse them.
When in doubt, shoot of an email describing exactly what it is you are doing with their data, and see what they respond.
Typically, even though some information may be "free" for republishing, you will find that you are not permitted to programatically grab and reuse them.
Rather a strange use for an XML feed then?
Strange, nope, absolutely not.
Most xml feeds provided "for free" are meant to be incorporated without further modification into another document or application, for display, along with full attribution, as required by the feed provider.
For instance, the google maps api's xml can actually be used to grab all the map tiles individually, but that is a copyright violation. Yahoo's news xml, can be incorporated to another page at your site, but if you modify the text ever so slightly or use it to grab the full story, you are violating their terms. Yahoo stock feeds can be used for personal needs, but not used for any commercial needs without agreement. In these instances, you are also violating the original copyright holder terms, the map GIS copyright, or copyright from the publisher, (ie AP, UPI, Reuters, NASDAQ, EDGAR, NYSE etc).
Just to interject one last thing, these rates are all interbank, so you need to add a spread to them. Your actual rates will be a lot different, also depending on settlement.
Anyway, this is a bit off-topic.
Thing is that makes accounting really hard....you have to have everything settled in your native currency, and let the payment gateways handle the currency conversions...such as a foreign users' bank doing the conversion, or Paypal, etc :)
Dominic is correct here. The main issue is accounting. It would no longer be possible to have the transactions list provide totals, financial reports would all need to be split into each individual currency, a currency would need to be selected each time you create an invoice or add a transaction. It just adds complication to every aspect of the system is one of the reasons for it not being implemented to date.
At the current time, we offer discounted additional licenses for users in a position where they require multiple installations of WHMCS - one for each currency they offer.
Thinking about the numerous features of whmcs it is imaginable how difficult it is to support multiple currencies, even if some other competitors did.
I would like to see whmcs support multi-currency in the future (far or near) but at the mean time I am grateful for all other features that whmcs provide.
Hi,
I'm signing up for this request. I'm with the "enter individual price per product and currency" group of people :)
/E
Definately interested ..... I agree with the enter seperate prices for each currency if possible.
If separate currencies should be the method developed, and a deviation or fluctuation in the currency exchange rate which would necessitate changing your product's billing rate, WHMCS would need to be able to update all current subscriptions to the new rate. Currently I don't think that is possible without manual intervention. (Or is it?)
Actually on second thought, there should also be an option of locking in a rate depending on product, so that it will never fluctuate, even if others do. (I think this is kind of like it is now, you increase the new product signup but older ones remain unaffected).
Also, since many companies need to notify the end-user of billing changes in advance, the adopted WHMCS system should also include some sort of notice or scheduling system to notify the users of the increase or decrease X days in advance of their next billing cycle. I think most companies use a 30-day period, but that depends largely on your company's TOS. This is in anticipation of avoiding charge backs and also excessive billing inquiries due to such changes.
I personally wouldn't change the prices on fluctuations, I mean they don't alter that much to notice the difference, especially on hosting etc, hardware based items might be different, to automatically vary prices etc is too complicated. It should be kept as simple as possible.
Another system has a rather nice feature that can be used for multiple currencies.
Almost like WHMCS Product Groups they have Profiles that enable separate currency, pricing, products, paygateways etc.
It is like one program installation but two (or more) sets of profiles.
You can for example create a profile with USD as your currency for normal business and other profile for ZAR.
The report system simply report per profile so you can get the totals per profile 1 (USD) and profile 2 (ZAR).
This is a billing system and not accounting system so above totals is sufficient for management purposes.
(The billing system will say you generated USD 1000 and ZAR 600 while an ACCOUNTING system will show the actual amounts that was deposit into banking account (Actual converted amount of ZAR 600 minus bankwire and such fees)
I am no programmer but the way how I see the implementation of a multi currency system is.
- Create two installations with different currencies.
- Compare the two to see where what differ. (product prices etc)
- Add extra (profile) field to those database fields that differ
- Change reports, invoices etc to call this (profiel) field first.
The results will be a multi currency system based on profile 1, profile 2 etc.
Where the current system call for example the currency symbol from database, the new system call the currency symbol by profile ID.
Product1 > Price > Profile1 > USD
Product2 > Price > Profile 2 > ZAR
Invoice1 > (Profile1 or 2?) Price > USD or ZAR
Report1 > Profile1 > select from xxx where profile id = 1
Report 2 > Profile2 > select from xxx where profile id = 2
The same way as what Product 1 are assigned to group ProductGroup 1 or 2 or 3, but just one category further to include a Profile
simple is a good thing. but I am just thinking outside the box for a second.
how would you approach the billing adjustments if you have fixed billing? Let's say 5 years ago, you charge $1 or 1 Euro, not a problem. Today, you have 2000 customers, and your $1 is only valued at 0.75 Euros -- a 500 Euro discrepancy. There needs to be a way, no?
I personally wouldn't change the prices on fluctuations, I mean they don't alter that much to notice the difference, especially on hosting etc, hardware based items might be different, to automatically vary prices etc is too complicated. It should be kept as simple as possible.
I also agree that the fluctations is too small to have a big impact.
It is not as if we have FIXED costs such as for tangable products and I can simply charge customers $15 or R90 for a domain name, not because $15 precise match R90 but because it is approcimately the same.
I can as well charge our local customers R200 and int customers $15 (massive difference) simply because I want to. (Due to for example difference between local and international competitor prices)
In this regard, would you believe me that VERIZON (South Africa) quoted me R400 000 for 2000 GB Bandwidth?
R400,000 South African Rand = $54,894 US Dollar
(I can get 2500GB bandwidth in USA for $200)
If we were a bank or talk about products that COST $1000's then the currency fluctations would be a factor yes but otherwise not.
othellotech
08-21-07, 06:18 PM
[quote=VISL]
R400,000 South African Rand = $54,894 US Dollar
$55,000 for 2000Gb of *BANDWIDTH* is peanuts - very very very cheap. Thats only $27.50/Gb - best pricing on a 1Gb BW connection even in the US is closer to $3000/month/Gb
Of course you *probably* meant TRANSFER which is a totally different thing entirely ;)
Anyway back to multi-ccy it would be simple enough to write some PHP to copy your pricing from CCY-A to CCY-B converted by rate and rounded to whatever accuracy you wanted to initially populate the values, and then you could make manual adjustments from there.
For example if you want to go from GBP 2.95 (about $6) to USD a formula like
((amount * rate), trunc to 0dp) +.95 would get you $5.95 :D
I don't really use multiple currencies except for about 5% of customers to whom I send 2checkout invoice in USD. (And the price that I charge in USD is the same past 2 or more years)
I meant data transfer yes. (My server include 2T bandwidth for $280 something)
When I talk about more than 1 gb bandwidth, it IS for sure data transfer. Our MAXIMUM ADSL line in SA is 1gb but operate at about 300 kb so it's almost impossible to define our bandwidth speeds at GB's or TB.
This topic has got pretty out there in terms of complication and features. Taking back to basics, would we all be happy with the following?
1. A currency setting per user
2. Prices entered in default currency
3. Currencies set by conversion rate
Now I know this isn't ideal for everyone, and is going to result in some odd amounts sometimes, but better than nothing?
Without this conversion method, there are many problems with reports, totals, summaries, affiliate earnings, etc... I don't think it would be possible.
With this proposed method, each transaction would be stored with the true value and the rate of conversion on that day and then this would be used in calculations. Invoices would obviously show the true amount paid in the currency it was paid. And for affiliates, the amount paid would be converted on the day and then credited at that.
Matt
othellotech
08-26-07, 08:17 AM
unless you're going to allow the admins to specify the amounts for each product/domain etc in each currency, then there is no point to having multiple ccys - the "conversion" to base etc is already handled by all the card processors.
unless you're going to allow the admins to specify the amounts for each product/domain etc in each currency, then there is no point to having multiple ccys - the "conversion" to base etc is already handled by all the card processors.
Not entirely, there's also the fact that clients like to be billed in their own currency and that hosts want to be able to have their order form in multiple currencies.
While considering what people who want multi-currency need, I also have to consider what those who don't use multiple currency need and in order for the system to remain as simple and easy to use as it is, I see this as the best way. It gives multiple currencies to those who need it and no noticeable changes for those that don't.
Would it be possible for the conversion to be rounded up/down to say the nearest pound? For example i set my package at £10 per month - this would then convert to $ 20.05... For consistancy id much prefer it if you could make it £10 and $20 for example, i think thats where othellotech's idea of being able to set them manually would work.
Id rather has whole prices such as £10 and $20 and maybe lose a few pence on conversion than have a price that doesnt look sensible.
Just my input :)
othellotech
08-26-07, 10:52 AM
Would it be possible for the conversion to be rounded up/down to say the nearest pound? For example i set my package at £10 per month - this would then convert to $ 20.05... For consistancy id much prefer it if you could make it £10 and $20 for example, i think thats where othellotech's idea of being able to set them manually would work
This is why you need to have the pricing in a separate table by product/ccy ;)
Rounded for you would be fine, but not for us, as all our pricing is x.95.
On the fly conversions dont work as we're obliged to give clients 28 days notice of price changes, and anyone paying in USD would get a different price every month if converted from GBP.
This is why we've left the US and EU sites using another system at the moment, because we have the functionality to do pricing by ccy/product :twisted:
While considering what people who want multi-currency need, I also have to consider what those who don't use multiple currency need and in order for the system to remain as simple and easy to use as it is, I see this as the best way. It gives multiple currencies to those who need it and no noticeable changes for those that don't.
Maybe i'm just too used to payment gateways which allow me to specify the amount/base currency and whatdc cy to charge the clients, so dont see issue regarding charging.
I can understand your proposed mod for *display* of teh pricing in different currencies, but it woudl have to always charge that client that amount, not convert it each time. If someone signs up for something at £4.21/month (from $8.50) they expect to pay £4.21/month ;)
Of course the customers price they signup at will never change. It's the amount they pay that will be converted using the rate on the day for transaction reports.
Matt
othellotech
08-26-07, 11:58 AM
Of course the customers price they signup at will never change. It's the amount they pay that will be converted using the rate on the day for transaction reports.
Then its a good 1st step, especially if combined with giving the admin the ability to set the rate, even better if a "formulae" could be used.
allynne
09-07-07, 11:09 PM
While considering what people who want multi-currency need, I also have to consider what those who don't use multiple currency need and in order for the system to remain as simple and easy to use as it is, I see this as the best way. It gives multiple currencies to those who need it and no noticeable changes for those that don't.While considering both those who want multi-currency and those who want single-currency, wouldn't it be simplest to do the same as ModernBill.
That is -
Each product has a price set for each currency
ie Hosting Package 1 costs $9.95 or £4.50 or AUD$8.75
inyerface
11-26-08, 05:06 PM
I read a post somewhere in archives about adding a converted currency on an invoice... I'm looking to put a notice on my invoices that let my Canadian customers know what the approx. total would be after the exchange. I currently use the following and it displays info... however the CAD total is the same as the USD total...
{if $client_country eq "Canada"}
{$invoice_total|replace:"USD":"CAD"}
{else}
{/if}
Would you know how to calculate say 0.8000 on the invoice total tag? Or I would cushion the exchange to 0.7500 to allow for fluctuation.
{$invoice_total|replace:"USD":"CAD"} / 0.8000
The output would look something like this...
$10 USD
$12.50 CAD
Thanks!!
inyerface
11-27-08, 02:46 AM
Sorry this is what I was using...
{if $client_country eq "CA"}
{$invoice_total|replace:"USD":"CAD"}
{/if}
I also tried {math equation="x * y" x=$invoice_total y=1.22828 format="%.2f"}
{math equation="x * y" x=$invoice_total y=1.22828 format="%.2f"}
Mitch
This looks familiar, have you checked your ticket with me for the solution to your problem. I gave you that code above for in a tpl file. You forgot to tell me that you were putting this in your email templates, $invoice_total in the email templates is not all numeric. It is in the format of "$45.00 USD" and therefore the math won't work.
Since you asked me about how to display and convert a price to a different currency, I have improved on what I gave you to convert the currency in real time (with the latest conversion rates).
You can test it out if you like
http://tshosting.com.au/currencyapi.php?amt=100.00&from=AUD&to=USD
change the "amt", "from", and "to" values to what you like
"amt" value must be numeric
"from" and "to" values must be valid currency values
Multi-Currency support - available in version 4.0 woohoo! :D
Powered by vBulletin® Version 4.2.1 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.