PepeBarz
commented
3 days ago 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
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
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