Please, I have a problem with the way exchange rates are offered.
Screenshot shows the problem
I have two currencies, the U.S. dollar and the Lebanese lira.
For example, the first line (31/12/2021) expresses an exchange rate of $1 = 27,400 LBP
It is therefore difficult to read this figure and to know the exchange rate represented by each line
I have two suggestions.
The first (which is the favorite): is to have two column on the exchange rate page.
The first represents the exchange rate of the main currency against the foreign currency, and the second represents the exchange rate of the foreign currency against the main currency
The second is to add a custom field dedicated to the exchange rate page so that the user manually insert exchange rate.
The first proposal is definitely preferable because it saves time and is considered more accurate because it is automatic
What you see is a representation of your functional currency in foreign/other currencies, and it is the correct thing to do. I support the idea of extending custom fields to Exchange Rates to allow users to disclose information such as the source of exchange rate information etc.
No, I do not agree. It looks like a factual list of exchange rates used by the program.
I do not know what you mean by this.
Your issue seems to be that you do not like highly precise decimal fractions. But the program is not going to show you a rounded or truncated number when it is using one that is more precise. In a case like that, you would not be able to verify or duplicate results.
No this is even more confusing. A dozen means twelve (12) so your sentence now reads “If I If I told you the 12 had 28 pieces” If anything using your example “the piece represents 0.0357 of the 12” would make more sense as this would be a possibility, that is, a piece is a fraction of 12.
I think that the problem is that some currencies have huge numbers when translating to another - often because of very high inflation in that country
As in the example 27,400 LBP = $ 1
You could argue that is a problem of the LBP and could be solved by moving to a new LBP unit for example NLBP where 1 NLBP = 10,000 LBP so that the exchange rate is now $1 = 2.74 NLBP
Presumably at some stage this is what will happen but who knows when as it really requires a functioning government and banking system to carry out the conversion. Historically, all currencies with huge exchange rates versus the dollar have been revalued in one form or another.
I presume that most people use the number of LBP per $ rather than the number of $s per LBP when dicussing this as it is easier to talk about 27,400 or 29,000 or 25,000 than 0.000036 or 0.000034 or 0.00004 or whatever number of decimal places you need
I don’t think manager can really sort this out other than provide an indication of the reverse exchange rate in another column
This is an example of what one of my ZWL (base currency) to USD exchange rates looks like:
Having the exchange rate displayed in ZWL per USD would help me in several ways:
Our ZWL to USD exchange rate is set once per week by the Reserve Bank based on the results of a currency auction. The rates are provided on their website daily (where I retrieve them for input into Manager), but are represented as ZWL per USD (so the above would be 108.66600). When I am comparing our exchange rates to those listed by the Reserve Bank, I cannot tell easily if they match (and therefore if the rate has changed from the previous week and needs to be updated in Manager), so I waste time opening the old listings on the Reserve Bank’s site to compare those.
In all our day-to-day conversations, we discuss the rate as a number of ZWL per USD. “The rate passed 100 today”, or, “the bank rate is 108 today but some traders are using 190.” It would be much easier to get quick insights from the exchange rates in Manager if we could display them in the opposite way.
I often need to use historical exchange rates for calculating inventory costs in an external spreadsheet. Although the rate as represented in Manager has many decimal places, it is still a rounded number, and if I copy it for use in my calculations it will be less accurate than if I used the shorter but more accurate rate as provided by our Reserve bank. Using the above example, the rate as provided by the bank is 108.66600. Manager displays this as 0.009202510444849. If I divide 1 by this number for use in my calculations, I get 108.66600000000419081295600016162. Perhaps this will have no meaningful impact on the final numbers once they are rounded to the nearest cent, but it adds clutter to the workings and means I usually either refer to the Reserve Bank’s site for the rate or do the calculations manually first and then break the number where the string of zeroes is.
I haven’t previously thought these inconveniences justified me submitting a request, but since another user has made the request I would like to add my support and hopefully build a clearer argument for those who are unconvinced of the merits. I also acknowledge that it wouldn’t quite be as simple as adding another column – I have three foreign currencies listed, so what would the column header be? But I am confident @lubos will find a solution if he supports the idea.
Entering the rate the other way isn’t hard. Since in-field calculations are supported, you can just enter “1/27400” and let Manager do the work. This is what I do. However, it’s clear from other forum discussions that not every user knows about this, and as per my post above I do support this idea, although more for the final display in my case.