{{ message }}

# in-cell expressions mis-interpret decimal separator #422

Closed
opened this issue Feb 6, 2015 · 1 comment
Closed

# in-cell expressions mis-interpret decimal separator#422

opened this issue Feb 6, 2015 · 1 comment
Labels

### hsoft commented Feb 6, 2015

 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. e.g. 1.231.23 results in 1.51 (correctly rounded) 11.234 results in 1.23 (again, correctly rounded) BUT 1.234*1 results in 1,234.00 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. The text was updated successfully, but these errors were encountered:

### hsoft commented Feb 6, 2015

 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, `*2` next to the amount that moneyGuru supplied (and thus is thousands-separated). Anyway, there's probably a way to fix this, but we have to keep in mind all other uses cases.
removed the thinking label Jul 2, 2015
closed this in ``` 6350272 ``` Mar 27, 2019
Labels
Projects
None yet

Successfully merging a pull request may close this issue.

None yet
1 participant