Difference account calculates to the 3rd decimal point

[james-rose]

Soon after starting to use this app, I started noticing that every few days I get an extra 0.01 to budget or I'm 0.01 over budget. For an unrelated issue I had filed a ticket with YNAB support and gave them access to my budget. While investigating the other issue, they noticed that the difference account calculates to the 3rd decimal. What they wrote:
"Also, while I was in there, I saw that your USD Difference account was tracking amounts to the thousandth place ##.123 - was that intentional? It won't cause a major difference in calculations for that isolated account, but if you end up transferring money out of that account into another of your accounts, then that small value in the thousandth place will start to wreak havoc on your calculations, especially since your budget settings are set so that the number format is to the tenth decimal (##.12)."
And after I told them about the extra or missing 0.01, they replied:
"And that .01 extra to budget is most certainly caused by the rounding up/down to the second decimal. I'd reach out to the developer of that API and see if there could be adjustments to how transactions are imported - or you could begin to log transactions to the third decimal place for consistency and to avoid calculation issues in the future."

[borsboom]

I was using fca4ynab without this issue for a couple of months, but I've recently also gotten this $0.01 over/under budget issue and figured it was probably related.

First, a little background on why the calculations are done to three decimal places: since we're dealing with foreign currencies and conversions, the post-conversion amounts may legitimately be fractions of cents, so rounding to two decimal places for every transaction seemed like it would introduce more error. I figured keeping as much precision as possible would be best.

I'm thinking the best compromise may be to continue using three decimal places for individual difference transactions, but then having adjustment transactions always leave the difference account's balance with a 0 in the third decimal place. This way we don't lose precision, but also don't end up with these sorts of weird results. I haven't tried implementing this yet to see if it fixes the issue, but I think that's what I'll try first.

[borsboom]

Well... I don't think my compromise will work. The problem is that, if a difference transactions is a transfer, then the extra decimal place "infects" the destination account as well (which is what the YNAB support person said, I just hadn't quite understood what they meant yet).

I think I'll just have to get it to round all transactions to the budget currency's precision. It's not ideal but should be good enough in most cases.

[james-rose]

Either way, this is only a minor issue, but getting rid of that 0.01 would be nice.

[borsboom]

I believe #9 will prevent this in the future. It will also create an adjustment transaction in the difference accounts force the balance have a 0 in the last decimal digit. I'll use it myself for a while to see if it causes any trouble, and then I'll make a new release that includes this fix.

However, this PR will not retroactively fix old transactions that are transfers to non-difference accounts, so getting rid of the $0.01 over/under budget will need to be done manually if you have any of those. You can do so by:

1. In the Budget Settings, change the Number Format to 123,456.789 (the one that shows all three decimal digits).
2. Look for any accounts that have a balance with non-zero last decimal digit.
3. In those accounts, round any transactions with non-zero last decimal digits to the nearest cent.
4. In the Budget Settings, change the Number Format back to your original setting.

Note: while your budget's number format has three digits, fca4ynab will not round to cents (since it always rounds to the budget's number format's decimal digits).

[borsboom]

If you'd like to test this without building from source, you can grab a binary by clicking on Artifacts on the top-right of https://dev.azure.com/borsboom/foreign-currency-accounts-for-ynab/_build/results?buildId=169.

[james-rose]

I’m on vacation without my Mac until December 5th, but I’ll install it then and try it out.  Thanks.

…

On Nov 26, 2019, 07:12 +0900, Emanuel Borsboom ***@***.***>, wrote: If you'd like to test this without building from source, you can grab a binary by clicking on Artifacts on the top-right of https://dev.azure.com/borsboom/foreign-currency-accounts-for-ynab/_build/results?buildId=169. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[borsboom]

Released in v0.1.6.

[james-rose]

This issue is happening again only with my credit card diff account since July 7th.

[borsboom]

@james-rose Had you made any settings changes on the 6th or 7th?

The fact that the memo field's amounts have three decimal places for the 09/07/2020 transaction for €0.002 implies that, at the time that transaction was created, the budget's number format in the settings had three decimal places (since fca4ynab uses the number format to render the amounts in the memo). Since fca4ynab rounds to the number of places in the budget's number format, that would have been correct behaviour at the time. It looks like the number format then went back to two decimal places on 10/07/2020 and fca4ynab went back to rounding to the nearest cent.

[james-rose]

Had you made any settings changes on the 7th?

I don’t remember doing so, but it’s possible.  I’ll go ahead and fix them and see if it happens again. Best James

…

On Jul 12, 2020, 16:05 +0200, Emanuel Borsboom ***@***.***>, wrote: @james-rose Had you made any settings changes on the 7th? The fact that the memo field's amounts have three decimal places for the 09/07/2020 transaction for €0.002 implies that, at the time that transaction was created, the budget's number format in the settings had three decimal places (since fca4ynab uses the number format to render the amounts in the memo). Since fca4ynab rounds to the number of places in the budget's number format, that would have been correct behaviour at the time. It looks like the number format then went back to two decimal places on 10/07/2020 and fca4ynab went back to rounding to the nearest cent. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.