Updating Client Currency on Account - Invoicing Retained with Old Currency.
-
PretecsChris shared this idea 11 years ago
- Admin Area
- 50 Comments
174
Votes
Login to Vote
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.
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
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.
https://bakernotes.com/
https://blickpunktleben.com/
I'm really surprised to see this major invoicing issue being discussed as a "Feature request" since 5 years and some other low priority stuff with less voting get implemented... This problem should have been taken into consideration as soon as WHMCS provided multi currency support.
Let's start by the invoices alone, without thinking about currencies. Once invoices are sent to the client these are legal documents that should not change, especially after being paid. It means that even in 10 years, exporting the invoice should be exactly the same as today no matter what happened on the client configuration (here we only talk about currency but names and addresses should also be frozen). Changing them not only cause problem to us but to our clients as well. You need to edit a paid invoice? Cancel it and create a new one as it should normally be done.
First idea to have a quick workaround without even touching the currency implementation would be to have an option to freeze invoices. It solves the actual reported problem on the invoices side. Here is a quick and basic idea on how I would implement it.
Settings
- Add an option like "Freeze Paid Invoice", disabled by default.
UI
- Use the invoice currency instead of client currency for all invoices
- If option enabled and status = Paid, block editing the invoice (many possibilities: readonly fields, remove the "Save changes" button, etc.).
DB and coding
- Add a field "currency" to tblinvoices. This will contain the currency code and not the id! Reason: if you remove the currency, your invoice changes as currency is not found. [1] [2]
- CreateInvoice: currency_id = current client currency
- UpdateInvoice: if option enabled and status = 'Paid' = frozen invoice = do nothing (throw error?).
Just with this idea, you solve the biggest part of the problem raised by this feature request: invoice won't change in the future (and more as it might help from a legal/audit perspective too).
Same idea for the transactions: keep the currency the transaction was made with.
Now for the currency change, as I said it's something that should have been in mind as soon as the idea of allowing multiple currency at the same time was introduce. Some clients need to change their account currency. It's rare but it happens. Creating new accounts is another workaround but add complexity for the client (multiple accounts to check) and internal staff (more work).
Let's say the client want to switch from USD to EUR.
1. He has to contact us first (I would not advise automation because of potential abuse risks)
2. As someone already gave the idea, we have 2 choices when starting the currency change process:
- convert related orders/services/etc. pricing of this client with the current conversion rate
- keep the same value
3. If convert option is selected, convert everything to the new currency, including credits.
Everything before the switching date will keep the old currency reference. It means that refund for old invoices will be done with the old currency for example. New invoices/orders will be done
That's all for the main/basic idea. I know that it's easier said than done.
[1] This will trigger another problem with currencies: WHMCS allows everything as currency code when adding a currency. Currency code must be ISO 4217 compatible. It's simple to solve this as it "only" requires :
- remplace the text input by a select input with all available ISO 4217 currency codes
- OR let the text input but throw an error if the code is not a ISO 4217 valid one...
[2] I would even go further and adding client name/address and our company address too in the frozen data so invoice are 100% the same any time.
never designed or intended to be used for the purposes of changing an existing clients currency once they have billing and transaction activity
What WHMCS should do is make it so that IF account is empty, this is accessible from Profile view, if account has been used, invoice generated or service added, disable this.. Just make it no longer possible at least since you don't really convert everything in the account. That way people can't make the mistake thinking they can swap out currency since you obviously don't have that feature.
Thanks for explaining, while I do understand your perspective I think you perhaps need to have a dev meeting and consider a different approach and business needs over development complexity.
Your assumption that an exchange rate needs to be stored against every invoice and transaction is not right, you are allowed to attribute gains or losses against exchange rates within your returns as such all you actually need to do is have a table that stores the daily rates for each accepted currency which relativity speaking is tiny, it is 1 table that is updated daily and is available for reference.
Additionally, you are working on the basis that this is an all or nothing change, it is not, hostbill for example will store invoices and transactions in multiple currencies and has included the very basic feature exactly as I described above for years, example: https://imgur.com/a/RjGmCoG as does Blesta and client exec, only WHMCS lacks this feature, all bias for your own product asside, you need to ask yourself why this is, consider the possibility you may be locked in an echo chamber.
Having a bang up to date currency is not a big issue accounting wise.
I hope this provides some further insight and I think you as the dev team need to sit in a meeting with someone from your accountancy department and understand that you are way over thinking it from a code perspective.
This is a bug, not a feature, it needs to be fixed.
As for Blesta they designed it to be that way from day one. If you design the whole core in a software to take into account how it process currencies, invoices, etc, its very different. WHMCS would require a whole software rewrite in order to do that. Its very complex indeed, but there are work arounds that don't require messing with WHMCS accounting features.
It would not require a whole rewrite, because the FACT is that when required I CAN do this manually, on a case by case basis, there fore it is capable, the only thing I bring in to the mix is a reference exchange rate base from the day which is publicly available in about 200 places and already pulled daily in to WHMCS anyway, it needs a table, that is it.
While updating the currency on the account would be the ideal solution, I know from real world experiences (inside and outside of hosting) that a currency generally is hard coded and cannot be changed, and if an error was made when signing up that another account needs to be created. What this then runs in to an issue of course is that because an email address needs to be unique for each account and then this feature request bumps in to this one:
https://requests.whmcs.com/topic/multiple-billing-accounts-using-one-login
So IF WHMCS has no plans to implement this beyond marking it for future consideration when it sounds likely they have no desire to move this forward, the following needs to be addressed:
When there is zero indication or warning that changing this currency will result in further issues, it is VERY easy to see someone may think that this is not going to cause further issues.
To start with, the request title fails to encompass all of what it would take to provide the level of functionality that is being requested by many here in this thread.
A clients currency in WHMCS affects far more than just invoices. To implement this feature, the currency would not only need to be stored against every invoice, but also every order, service, addon, domain, invoice and transaction. That introduces a level of complexity many times greater than exists today, both for product design and UI/UX and considerations would have to be made both at a product design and UI level for how to deal with a single client with items in 1, 2 or any number of additional currencies. It would affect how we deal with credit, no longer can you have a single credit balance, it would affect anywhere we display income totals for a client, it would affect how we display outstanding invoice due balances within the client area, it would even affect how we generate invoices, no longer being able to combine items due by the same customer on the same date because currency also needs to be taken into account, billing reports would need to be rewritten, and this is just the start of areas it affects.
To those suggesting that amounts be converted dynamically using the latest exchange rates, the challenge is that we are not always guaranteed to have an up-to-date exchange rate for every currency defined in a WHMCS system - we are restricted both by the currencies that are supported by the exchange rate feeds we support, and admins choosing to disable automatic currency rate updating, along with admins who simply aren't happy with the rates provided by the feeds we support. All of these these make dynamic currency conversion both for display purposes and "on change" of currency far from reliable.
The ability for an admin user to change currency via the clients profile was never designed or intended to be used for the purposes of changing an existing clients currency once they have billing and transaction activity and to change it to work in the way being discussed here would be a significant body of work to undertake. That work would include fundamental backwards breaking changes to design, workflows and APIs which in itself restricts when such a change can be made, as well as affecting almost all areas of the product that deal with billing. That work would take a significant amount of resources and time, and delivering that would mean taking those resources and time away from other features which have more votes and have been demonstrated to have higher demand.
We hope this provides a level of insight into the factors and considerations that affect the decision making for a feature request such as this, and helps to convey the challenges of such a request, both from a technical but also a product design and planning level.
Why not do it in the following way?
Since all transactions are related to the currency globally in the account and WHMCS but WHMCS has no problems offering different currencies to different customers (problem seems to be when trying to convert one to another), a currency change could imply a completely different account. Well, do so then.
Changing currency is not something would usually do unless they move out to another country, that includes companies so that most customer would be ok with a hard change into their balances.
Example:
JOE wants to switch from USD to Euro. Instead of asking JOE to create a new account and then manually transferring all his product there, WHMCS could do this from the admin side in a more nicer and transparent way.
User requests currency exchange from this account. The customer is warned about what this involved (warning, disclaimers, etc.).
This is then approved by the admin manually or can be left to be automatically. Most likely manually to avoid messing up things or users abusing the system changing back and forth a currency.
Most likely this involves a 1 change only and the customer is warned he can't go back, just like merging an account can't be reverted either.
Internally, WHMCS could duplicate the existing account to a new one.
Example, the account USD is ID 446. This has all the tickets, products, invoices, credits, transactions, etc. Basically it's the customers account with all the data that involves and related SQL tables.
When a currency exchange is done. WHMCS creates a new account and duplicates all the data to a new account ID 447.
All data, except everything related to the tables that can cause a problem. So it does not transfer any invoice, transactions, etc.
Billing related data is left in the account ID 446. You internally close the account and mark a balance cut, recording the date of the change.
Credits from account 446 are asked on the admin side to input the currency exchange rate to transfer them to account 447. Once done, you mark negative transactions for the credits on account 446 so they are at 0. The new account 447 now has the credits converted with Euros. This are new credits anyway.
This new account 447 also has 0 transactions and invoices. All invoices and purchases from this point are now done in account 447 in Euros. They will not mess anything because they are all new.
The product pricing is not rocket science since they will bill with the new currency from now on on the new account.
Now, here comes the trick that developers have to implement. When the customer goes to his transaction or invoices page on WHMCS, he can still see all the old data from account 446 (in USD) except there is a cut date when the change was done. That data is basically just pulling the records only for historical purposes. This does not influence in anyway the new account. They are just read records. The reason to do this is to avoid the customers having 2 accounts. He can still see all transactions and invoices prior the cut date. You could implement something, even more, more straightforward for the admin, since admin can switch to any account anyway.
Now, you can make all this fancier in the future and even convert some things, like total income, etc. You don't need to convert and exchange everything. Just keep all the financials in the old account. Most customers just want 2 things when they request this:
a) They want to be billed in the new currency
b) They don't want a new account, they don't want to lose the prior data, invoices, etc.
Something like this would solve that because its transparent for the customer. What account ID he has, or where the data is pulled internally from the tables is irrelevant for the customer. For WHMCS core function this would just consider it a new account and the prior one a closed one. No messing with the core accounting functions.
With less than a dozen votes per year, this is not currently on
our radar for implementation. However should this change and this idea
gain popularity we are keeping that possibility open for the future.
This shouldn't be a "feature request" at all, this is proper accounting and bookkeeping practices. If you can edit a client currency, then everything should be archived prior to the currency change.
If there is zero interest in ensuring proper records are maintained in the product by WHMCS, the currency should not be editable at all and force a new account to be created, and manually move all products over to that.
Please fix this "BUG" no one asked for a change of new orders design on the admin dashboard, you implemented significant changes to that twice while this was left unanswered for 5 years.
Please reconsider or give us a number of just how many people do need to ask for it in order for it to be on your radar?
https://requests.whmcs.com/topic/update-exchange-rates-for-latin-america-countries
https://requests.whmcs.com/topic/updating-recurring-invoices-in-other-currencies
https://requests.whmcs.com/topic/multiple-currencies-foreign-and-local-currency-exchange
https://requests.whmcs.com/topic/the-ability-to-set-prices-in-different-base-currencies-for-different-products
https://requests.whmcs.com/topic/new-currencies-for-automatic-conversion
https://requests.whmcs.com/topic/be-able-to-change-currency-after-product-added-to-cart
https://requests.whmcs.com/topic/ability-to-easily-change-the-default-currency
https://requests.whmcs.com/topic/automatic-currency-conversion-for-already-existing-productsservices
Common WHMCS you can do it.
I am saying this because think a customer signed up from USA and later he moves to Germany. When he was in USA he was making payments in USD and now as he is in Germany he wants to use EUR as his currency. So what option do we have in such cases? It sounds weird and unprofessional to ask him to just create new account with EUR currency and loose all past data on same domain he used with old account. Suppose he creates a new account and later he moves to UK then do we have to ask him to create one more account for Pounds and loose all data of previous 2 accounts which he created for USD and EUR?
And I also suggest that customers should not be able to change their default currency by themselves because doing so will increase chance of fraud orders and may create mess. So client area currency changing feature should be available only for administrators not for customers. If customers want to change their currency they can request through support ticket and backend staff can change if customer has a good reason for changing it.