Hardcoded moneyGuru

Comments and changes to this ticket

• You flagged this item as spam.
  

  frog August 2nd, 2012 @ 09:22 AM

  • Tag set to “data entry, calculations, ui”

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

• You flagged this item as spam.
  

  frog August 2nd, 2012 @ 09:26 AM

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

  Virgil Dupras August 4th, 2012 @ 05:02 PM

  • Tag changed from “data entry, calculations, ui” to “data entry, bug, calculations, ui”
• 

  Virgil Dupras August 13th, 2012 @ 06:24 PM

  • State changed from “new” to “accepted”
  • Assigned user set to “Virgil Dupras”

  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?

• 

  Virgil Dupras August 14th, 2012 @ 05:06 PM

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

• 

  Virgil Dupras August 14th, 2012 @ 05:55 PM

  • State changed from “accepted” to “fixed”

  (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/

• You flagged this item as spam.
  

  frog August 15th, 2012 @ 07:33 AM

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

• You flagged this item as spam.
  

  frog August 15th, 2012 @ 07:37 AM

  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)