Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reverse the rate of the exchange rate in multi-currency. #30816

Open
avadnc opened this issue Aug 31, 2024 · 1 comment
Open

Reverse the rate of the exchange rate in multi-currency. #30816

avadnc opened this issue Aug 31, 2024 · 1 comment
Labels
Feature request This is a feature request

Comments

@avadnc
Copy link

avadnc commented Aug 31, 2024

Feature Request

When entering the exchange rate in Dolibarr, it is done as follows: 1 unit of my local currency (the one configured in Dolibarr) indicates how many units of foreign currency it can purchase.

I would like the user to be able to enter the rate in reverse: How many units of the local currency (the one configured in Dolibarr) are required to purchase 1 unit of foreign currency.

Use case

In Mexico, the central bank, also known as Banxico, provides exchange rates in the following way: 1 Dollar costs 20.6523 Mexican Pesos. For users with little knowledge of Dolibarr, this can cause confusion, as they would need to divide 1 / , resulting in a very long decimal number.

https://www.banxico.org.mx/tipcamb/main.do?page=tip&idioma=sp

Suggested implementation

I suggest adding a selector in the module configuration that reverses the exchange rate calculations. I’m not entirely sure about the full impact of this change, but it’s something that could be discussed and collaborated on.

Suggested steps

No response

@avadnc avadnc added the Feature request This is a feature request label Aug 31, 2024
@PepeBarz
Copy link

PepeBarz commented Nov 9, 2024

I strongly agree that this is a major issue with marketing Dolibarr in most smaller countries, most potential customers of a Dolibarr instance would likely consider this a deal breaker.

While the current way is probably natural for digital services and for large countries or regions with in a common strong currency like the US$ or the Euro, it is certainly a very poor way for the rest of smaller countries in the world that usually have a weak currency rate and that have to make transactions in multicurrency with international or local suppliers or customers that require to handle proposals, invoices and payments in a mixture of currencies likely US$ or Euros and the local currency.

Take for example Costa Rica with a exchange rate of 523.09CRC/US$, this way of seeing it is easy for a human to remember, enter, audit and interpret, now consider having to enter a exchange rate per Dolibarr method of: USD/local currency = 1USD/523.09CRC= US$0.0019117169129595/CRC which in turn will be rounded up by Dolibarr to 0.0019117169, this is not natural to a human and is very error prone and hard to visually inspect.

So the natural way, that you will see this implemented in most countries with a week local currency where the US$ or the Euro are probably considered the reference strong currencies can have exchange rates of 10:1 to several thousand ¨local currency/USD¨ is to use the local currency as the reference, how many CRC do I have to pay per USD. This way of handling the multicurrency actually adds further to the rounding error as a large exchange rate usually means also that a few dollars turn into hundred of thousands or millions in local currency thus amplifying the conversion rounding error in all transactions

My suggestion would be to change the current way to something like shown below where the user can select the method or to have a similar procedure as it is used in the multicurrency proposals where you can enter the price of an item in local currency in one field or tab to the next field and enter the price in the particular currency of the proposal and the number automatically adjusts, so the idea would be that the user can see both the decimal fraction and the inverse at the same time and manually correcting one would automatically update in real time the other

191403e3469fdbbc5b07ee486730d544912a3c52

25c058595e04d5ddf98d203be9267667ff32eecc

You can see the way it is normally handled in government official invoices in Costa Rica in this image, displaying the exchange rate in this format and the corresponding local currency amount that it converts to is not an option, it is a formal legal requirement which I would bet is similar in most Latinamerican countries, not being able to accomplish this likely becomes a real deal breaker for anyone trying to market a Dolibarr instance

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature request This is a feature request
Projects
None yet
Development

No branches or pull requests

2 participants