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 calculacions regression #336

Closed
hsoft opened this Issue Jun 22, 2013 · 7 comments

Comments

Projects
None yet
1 participant
@hsoft
Owner

hsoft commented Jun 22, 2013

until now I was using moneyGuru 2.4.3 and I'm used to enter values in cells like calculations (for example 500+80), now I have upgraded to 2.5.4 and something has changed:
if you enter 500+80 = 580.00 this works as before
if you enter 500.00+80 = 580.00 this works as before
if you enter 1,500.00+80 = 1,500.00 => this is not working anymore (but was working in version 2.4.3)

@hsoft hsoft closed this Jun 22, 2013

@hsoft

This comment has been minimized.

Owner

hsoft commented Jun 22, 2013

I think I've been seeing the same thing. I'd not actually worked out the exact conditions that caused it, but for a while I thought it'd completely broken... I guess I must have been working on transactions all above $1000.

I usually use it to remove GST on imported data, so just type "/1.1" on the end. I can confirm that if there's a comma it gets a bit confused and thinks its the decimal point, and if there's both it just reverts to the previous value when you hit enter.

1000s separators, no decimal separator

  • "3,000/1.1" => $2.73 (assumes , is decimal separator)
  • "3.000/1.1" => $2.73 (assumes . is decimal separator)
    Both types of separators
  • "3,000.00/1.1" => Reverts to previous value
  • "3.000,00/1.1" => Reverts to previous value
    Multiple 1000s separators
  • "3,000,000/1.1" => Reverts to previous value
  • "3.000.000/1.1" => Reverts to previous value
    And cents...
  • "3,000,000.00/1.1" => Reverts to previous value

Correctly works for

  • "3000.00/1.1" => $2727.27
  • "3000,00/1.1" => Reverts to previous value (This is probably correct behaviour given my decimal separator is a .)
@hsoft

This comment has been minimized.

Owner

hsoft commented Jun 22, 2013

argh, not sure what happened to the newlines in my comment, should read

1000s separators, no decimal separator

  • "3,000/1.1" => $2.73 (assumes , is decimal separator)
  • "3.000/1.1" => $2.73 (assumes . is decimal separator)

Both types of separators

  • "3,000.00/1.1" => Reverts to previous value
  • "3.000,00/1.1" => Reverts to previous value

Multiple 1000s separators

  • "3,000,000/1.1" => Reverts to previous value
  • "3.000.000/1.1" => Reverts to previous value

And cents...

  • "3,000,000.00/1.1" => Reverts to previous value

Correctly works for

  • "3000.00/1.1" => $2727.27
  • "3000,00/1.1" => Reverts to previous value (This is probably correct behaviour given my decimal separator is a .)
@hsoft

This comment has been minimized.

Owner

hsoft commented Jun 22, 2013

There's 2 distinct problems here:

  1. Thousands separators being considered decimal separators (simply typing "3,000" yields "3.00").
  2. Operations not working with numbers having thousands separators and decimal separators.

IIRC, I was aware of 2. and I had given up trying to make it work due to the complexity involved and what I assumed was a rare use case, but 1. is a bit more serious.

Also, the use case of modifying an already-formatted number is probably a lot more common than I first thought, so I should handle the complexity of the operation, dive in, and support all of that.

By the way, do you guys think it would be useful to have mathematical operations as a mass edit operation. For example, you could select a bunch of transaction and apply a "/1.1" on them?

@hsoft

This comment has been minimized.

Owner

hsoft commented Jun 22, 2013

(from [c0b51c1eb98e]) [#336] Fixed confusion in amount parsing between thousand separators and decimal separators.
https://bitbucket.org/hsoft/moneyguru/changeset/c0b51c1eb98e/

@hsoft

This comment has been minimized.

Owner

hsoft commented Jun 22, 2013

(from [b88d2091c570]) [#336 state:fixed] Improved amount expression parsing.

Instead of having two separate code path for expression parsing and "simple" amount parsing, expression parsing now uses simple amount parsing code to reformat the expression before evaluation, thus normalizing expression parsing and simple amount parsing.
https://bitbucket.org/hsoft/moneyguru/changeset/b88d2091c570/

@hsoft

This comment has been minimized.

Owner

hsoft commented Jun 22, 2013

By the way, do you guys think it would be useful to have mathematical operations as a mass edit operation. For example, you could select a bunch of transaction and apply a "/1.1" on them?

Sort of, but not quite like that.

Whenever I do the "x/1.1" operation, I'm actually taking a single transaction:

  • x from account -> expense

and converting it to a pair of transactions:

  • x/1.1 from account -> expense
  • x/11 from account -> GST (sales tax) liability/asset (depending on whether its on sales or receivable)

That's by far the most common modification I do to existing transactions. I would think a tax feature (with multiple, configurable tax rates & matching categories, and the ability to assign to part/whole of a transaction).

The other common cases I split transactions are:

  • splitting a receipt into a few categories for different items on it (would almost never be a bulk thing)
  • splitting out common fees from certain transactions (e.g. ATM fees of between $1 and $3 on cash withdrawals)
  • adding a PAYG liability to employee wage payments to be sent to the tax office at the end of the quarter (typically the same amount each time, but its not a "simple formula" from the wage amount, so wouldn't quite fit the tax feature suggested above; plus it's an additional liability on top of the amount actually paid, rather than a portion of it).

I don't see a really generic solution to these cases, except the last one where I use a scheduled payment (and avoid importing the employee wage payments in lieu of these scheduled ones).

@hsoft

This comment has been minimized.

Owner

hsoft commented Jun 22, 2013

and converting it to a pair of transactions:

Sorry, by this I mean a 'compound' transaction of multiple transfers in the one transaction (I select the transaction, press cmd+i, adjust the amount going to the expense by /1.1, and add a second row going to the appropriate GST category to make up the total)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment