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

in-cell expressions mis-interpret decimal separator #422

Closed
hsoft opened this Issue Feb 6, 2015 · 1 comment

Comments

Projects
None yet
1 participant
@hsoft
Copy link
Owner

hsoft commented Feb 6, 2015

From the forum:

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)
1
1.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.

@hsoft hsoft added bug thinking labels Feb 6, 2015

@hsoft

This comment has been minimized.

Copy link
Owner Author

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.

@hsoft hsoft removed the thinking label Jul 2, 2015

@hsoft hsoft closed this in 6350272 Mar 27, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.