If a client requests us to switch their currency on their account, that all previous invoicing remain in the old currency and new invoices will be shown in the new currency. From an accounting purpose, this is a huge issue with the archived information not matching what currency they paid in, and this should be retained for perpetuity.
It would also be helpful if the client could set on a product level, not on a client level, what currency they wish to pay in.
Merged Ideas
currency per invoice - add field to database determine the payment currency type
Hello,We have customers that they pay sometimes with eur, sometimes with usd. To set the currency to the invoice, not to the customer will be best update and will finish the currency problemsThank you
71 Comments
Login to post a comment.
1) Option in admin area to change currency and WHMCS changes all currency for future invoices (so services/domains should become the amount in new currency, using pricing)
2) Old invoice/revenue record should be kept in old currency for legal accounting reasons.
At this moment if you need to change customer currency (in case of merging 2 whmcs installs)
You need to change currency in Customer profile, payment amount per service.
But changing currency in customer profile means that all already issued (and old) invoices are changed also.
Amounts as Paypal fees can't be changed and will give a strange high of low figure.
Issued invoices shouldn't be able to altered by this. And as suggested above : " [u]Freeze past and old transactions[/u]. [u]Do not change the currency"[/u]
No address change, no amount and no currecny change. If people have a reason to alter old invoices they can use phpMyadmin to do so.
can’t use multi currency in WHMCS. Asking a customer to create a new account
and lose all the past transactions, tickets and other data is not reasonable.
And how it works today in WHMCS is an account mess because all it does is
change the currency symbol and leave the same numbering/amounts when it should not be changing any past transactions, only new ones from that point on which is what probably everyone assumes would happen when they switch the currency. Past invoices and
transactions should be freeze and this would solve all the problems. So answer
the questions this is my suggestion:
1. There could be more than one solution here. The first one
is WHMCS gives an error if you try to change the currency if someone has
positive credits in the account. So you should tell the users to use his credits
first or he will lose them. Simple solution.
Better solution: Current credits are converted to the new
currency, if the amount is less, a negative transaction can be recorded with
the description currency conversion exchange. If it’s the opposite, increase the credits
to counter act the balance. I would say that most customers will understand
they will or can lose money with a currency conversion, so they will agree with
this. What should never happen here is for WHMCS to record a negative balance
against the company because the whole accounting balance will then not match with
the past years (if it was reported already).
Credits are tricky to handle, so maybe not even allow currency
conversion if there are positive credits. If the question was about past
transactions, the answer should be the same as with invoices. Do not touch past
transactions. Any transactions, invoices generated, invoice paid, credits used,
all of them should not be touched past the date where the user decided to
switch currency.
2. I think I answered this above. Do not convert accounts if
there are credits, or credits can be converted to the new currency recording.
For example if the user has $50 credits and wants to switch to Euros, you
need to convert $50 to 47 Euros, in such a case, it would be as easy as switching the
currency and then adding a negative transaction to the credits for -3 for the
exchange. Now the user has 47 but euros. He can then see he lost 3 in the currency exchange.
If it’s the opposite. A user that has 50 euros and wants to
switch to USD dollars, which would result in $53 then WHMCS should maybe block
this with a warning and not allow it, or inform the admin he is going to lose
money in the exchange switch. Then a user has a choice to use his credits first or
lose them. In this case just switch the 50 euros to 50 dollars and the user
lost $3. If he does not want that. Then he should have no credits in order
to a currency change first. An account currency change is a big change, so it is not something someone would request unless he is aware of the implications.
3. I don’t understand this question. Past
transactions are not touched. New promotions and orders would work just like they
do today in the new currency for that customer. Do you mean active ones?
4. Same as above. Past transactions are frozen. Nothing is
changed. New currency only applies to transactions past the date where the
conversion was done.
5. [u]I don’t think this is what people asked here at all[/u]. I didn’t
saw anyone here asking to have a customer in 2 currencies at the same time, that would indeed be
a mess. Nobody is asking (and I don’t know why would someone want this) to have
a customer with both USD or Euro invoices at the same time. What most people
want is to switch the currency for that customer. Example, someone moving from
Europe to the America or the other way around. All past transactions are stuck
with the currency they were originally, new transactions are in the new currency.
The customer can’t use the older currency anymore, unless he is switched again
manually by a WHCMS admin.
6. Again, see 5. I don’t think this is what users are asking. I don’t even know a billing system that can do this. What we want is just to be
able to switch currency properly. Today if a customer paid $245 invoices, and
you switch him to Euros, WHCMS just switches the currency symbol on all
transactions, so now suddenly that user paid 245 euros which is wrong. What
people are asking is to fix this. I don’t think people asking to use 2
currencies simultaneously. That would indeed require a major WHMCS change and I
don’t see this as reasonable. What I do see something which can be fixed is the
currency bug I and others mentioned before.
Almost all the problems here can be solved by just doing
what I suggested. [u]Freeze past and old transactions[/u]. [u]Do not change the currency[/u]
on them. Only new transactions are in the new currency. I’m surprised you
mentioned this. Did you read what others have posted here? They are not asking
about having several currencies at the same time for a customer. They are asking not to change the currency on previous transactions.
There are however a number of other technical challenges that we must consider and we would be interested in your feedback and thoughts on them:
1. How do you suggest we handle credit balances which are maintained in the customers primary currency?
2. How would credit which is stored in the clients primary currency work for an invoice that is in a different currency? What would the credit balance show and how would the amount be calculated?
3. How would you suggest we handle monetary discount promotion codes that are assigned to a clients products & services?
4. How would you suggest we handle affiliate commissions and withdrawals history which are also stored in the clients currency?
5. How would you suggest we display the customers invoices and income totals when they have invoices & transactions in multiple different currencies?
6. How would you suggest we handle allowing a customer requesting to mass pay invoices in different currencies? Only one currency can be used per transaction.
We are having problems with multicurrencies at this moment and you can check this thread https://forums.whmcs.com/showthread.php?126075-Stripe-incomplete-payments&p=505143#post505143
2. solution for point 1 negates this as an issue.
3. That is irrelevant, once the recurring price is set, it is set, so the recurring price it gets converted as per point 1.
4. The history and pending commissions remains in the original currency, the new commissions are in the new currency, alternatively, they are essentially archived or converted and brought forward in to a new affiliate ID under the correct currency.
5. display a second balance when a base currency has been changed.
6. Do not allow it, I cant see a situation where by this would be possible when common sense is applied i.e. convert existing invoices prior to payment or only switch currency when no invoices are unpaid/open
I appreciate this was 2 years ago however I think you are missing the core point, its not something people want to do daily it is likely to be a 1 time ever thing per account and it would not be customer driven in terms of action, it would be done by administrators.
Is any solution there?
Thanks in advance
For example let's say that you have a client with an invoice of 100 INR. As soon as you change to EUR, the invoice becomes 100 EUR but in reality 100 INR are equal to 1.41 EUR so it's a disaster.
There are modules in the Marketplace that allow you to freely change the currency of a client without messing up with existing invoices.
* Set the client's profile to Inactive or Closed (or whatever status you don't send e-mails to.)
* Change their e-mail from [email protected] to [email protected]/USD (or whatever currency it is.)
* Create a new profile for the [email protected] using the new currency.
* Move products from the old to the new client.
* Update products pricing to use their new currency.
This way their old invoices remain properly stored in the old currency while new invoices are generated in the new currency. You can switch back and forth whenever you want, without compromising the invoices.
Two shortcomings of this approach: 1) The client cannot access the invoices in the inactive account, unless you teach them to login with /USD to see the old invoices. 2) It only fixes the currency issue. Other changes (like name and address) will still change whenever the customer changes them. (Which is illegal in most places.)
This is completely wrong for accounting. When an invoice is created
WHMCS should store the currency, amount, exchange rate (in case of conversion), etc. All invoices/transactions/etc shouldn't suffer changes. This is something that must be rethought urgently.
I like Linus Torwalds quote here. If enough people are using or rely on a bug then its not a bug anymore, it's a feature. Changing currency is something that people want and request as you can see here for the simple reason that a customer may want to change his currency. A simple example of this is someone moving from Europe to the US and now wants his invoices in USD instead of Euros or the other way around. WHMCS can change currency without issues in the customer account, the bug here is that it also changes them for past transactions and invoices because all it does its update the currency symbol in the SQL database. This is actually amazingly dumb to fix. All they need to check is the time stamp or date and freeze those records so they are not changed when you hit the change currency button. This way the change will apply to new transactions and invoices but not past ones.
The strange thing is that I don't understand why WHMCS is even doing this. Its extremely easy just to apply the new currency to new invoices, and leave the past ones alone because WHMCS does not actually update the amount on the old invoices, it just updates the currency symbol on them. This is not a rocket science and I had to disable the currency feature for this reason as well.
Currently we can't allow a customer to change their currency or their address without either breaking the law (because it modifies past invoices!) or creating an entirely new profile for them.
IMHO the inability to be compliant with the law without creating a new profile is a serious bug, not a missing feature.
If you have taken steps to change the currency to, for example, EUR: you already had to jump through multiple hoops due to WHMCS not allowing people to switch currency (as it pretends they always paid in that currency, which already is a huge flaw). So you had to run some queries to fix the currency values...Next up: you have to retain the USD packages and create new EUR packages for new orders right? That way, your existing clients keep paying in USD, and your new clients finally get the new currency...Well... To make that story even better: that ensures that everyone who once paid in USD and has their account set to USD: they can't place new orders anymore because the system won't allow them to order in EUR! I'm not even joking... Their entire order will be thrown out, or when they're logged in: it will not throw an error during order but just show blank boxes... Great going WHMCS... This function is so very *very* messed up for a billing "solution", it's really extraordinary ridiculous. To make it this flawed requires really quite some skill.
It saves all the necessary data about each created invoice to the database, including the currency and even it's number format. The module even displays the right currency for the invoice while you're viewing it from the admin area.
So, in a nutshell...the process looks like this:
invoice gets generated -> data gets written to a database thus preventing stupid changes for all of the older invoices if the user decides to use a different currency after that -> if invoice is paid, module creates a PDF file locally (optional) thus preventing ANY changes in the future...invoice stays the same forever, even if you change your WHMCS theme and the user gets the same invoice data, no matter when he tries to view/download it. So, you're happy, your accountant is happy...
You can even edit the data for each saved invoice and change the currency afterwards if you want, among other things.
Check out the WHMCS forums thread -> http://forum.whmcs.com/showthread.php?95294-M-BIT-Cached-Invoices-Addon-Module-for-WHMCS-Keep-your-invoices-intact-forever!
We're open to all sugestions, don't be shy.
This is a *HUGE* mess.
Changing the currency for a client resulting in all past invoices (paid or not) going to that currency as well is ridiculous. It shouldn't work like that at all, and it is a bit strange for an accounting tool to have such a major bug inside of it.
If a client moves from USA to Europe for example, or vice versa, and now wants to pay in that currency: it should be possible! Without all the trouble.
It also causes issues for business owners within the EU as they will have to do a currency conversion for every payment not received in EUR by clients living within the eurozone and having to pay taxes...
This must be fixed.