Adding Currency Option on Voucher Level

Dear @lubos and Moderator Team

this request has been discussed many times but I prefer to refresh again with more supportive information to enable decision maker and moderator team to discuss and evaluate it again.

The request is to add the option to choose currency on voucher across all tabs where it is applicable.
this option is active under Expense Claim and Journal Entries as per below snip
image

image

I would love to see this option under all other vouchers tabs such as Sales and all its related tabs, Purchases and all its related tabs. and where it is applicable.

Currently there are enforcement by system to create more that 1 customer, vendor for every currency if we have business in more than one currency for same customer or vendor which will result in long vendor and customer list in the long term.

Advantages of having this feature

  1. Consistency over all tabs which a key goal
  2. all customer transaction will be in one ledger. the system is currently listing currency under ledger. system report can be improved by allowing the option to show document and local currency either in one report or as current option we need to choose if we need local or document currency.
  3. we will have the option and more control over customer name and transactions
  4. we will send to customer or vendor only 1 Statement of Account
  5. Credit Limit issue where usually we have 1 credit limit for every customer
  6. it will lead to comply more with government requirement

I know above points might not be sufficient to support this request but at least it will start up as brain storming points for others to list Advantages or Disadvantages to help decision makers evaluate the validity of this request

I have reviewed ideas list not able to find it therefore I created this subject

Thanks for your comments and feedback

The current method is a much better workflow imo. Currency is set on accounts and this closes the door for many potential What-Could-Go-Wrongs (WCGWs). Enabling free selection of currency will open the door to all of those.

This isn’t enough justification to change the current method–in fact, this is not a good practice. The best practice is to have an agreement with your customer which defines the currency denominating the contract. If the customer pays in another currency, then they will be subject to your conversion rate. Manager can already handle that.

The best practices for when you have multiple agreements with substantially different term with a single customer is to have multiple customer accounts.

Owing EUR1000 and SAR 1000 is not the same as owing SAR 5200 for example since the terms could be that EUR invoices be settled as EUR and SAR invoices be settled in SAR.

Journal Entries on the other hand are a special case since:

  1. They should enable the user to tackle unusual situations where none of the other tabs is meant to deal with. Hence, they need to be more powerful and flexible.
  2. Journal Entries are written by professional accountants who should know how to properly deal with the intricacies of accounting. Which makes easing off controls less risky than say a billing staff who has the ability to ruin an account simply by selecting the wrong currency.

However, I too think that the ability to combine multiple customer accounts for reporting purposes is a good thing to have.

There’s been multiple suggestions made in this regard but none–that I recall–was ever placed in ideas.

But that doesn’t seem to be a problem since Custom Reports are mature enough now to handle such combination.

Yes you are correct that these are not enough justification. but we can’t debate that this is the best practice or not. I can tell a big and small software companies using suggested idea. and the currency in their system is based on transaction lever.

We do have business with Aramco and other big companies where we have to follow bidding currency or we invoice them as per supplier currency to hedge FOREX risk

Iam pretty sure that manager is capable to handle these cases in professional manner if it is implemented. if it does show this issue it will be common forex gain or lose which is commonly used.

if Custom Reports will handle reporting in easy set up there will be no issue and it will sort the purpose of this subject. but unfortunately not everyone capable to set up custom reports to get what he needs where myself is the 1st in the list.