Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
in-cell expressions mis-interpret decimal separator #422
moneyGuru has an excellent feature that calculations can simply be entered directly into the field to which they relate. A great use of this is to add tax to an item and record the total amount for the transaction.
I use this when I have an invoice for several items, but tax is shown as a total amount. However, I've noticed a slightly glitch.
My locale (UK) has a currency (GBP) with two decimal places. I can multiply a number with up to two decimal places by another number with many decimal places to get a result. However, if the first term has more than two decimal places (which some invoices do), then the calculation has an erroneous result.
1.231.23 results in 1.51 (correctly rounded)
I wondered at first if it might be a decimal marker issue, but 1.2345*1 results in 12,345.00, as does simply entering 1.2345.
As our tax is currently a whole number (20%), I can work around at the moment by entering as 1.2*n - yet not that long ago, the rate was 17.5%. Again, this is not an issue if the net figure has only two decimal places, but an issue if more.
It's a tricky problem (see #336 for a background). The problem is that we have to distinguish thousand separators from decimal separators, but that's not always easy. The trick I've been using in moneyguru is to check whether the number of digits after the separator is equal to the number of digits in the currency (usually 2).
If we simply say "whenever we see an expression, treat all separators as decimal separators", we break the use case where someone would simply add. for example,
Anyway, there's probably a way to fix this, but we have to keep in mind all other uses cases.