Set future/pending transactions to uncleared #71
Conversation
This adds support for sending 'uncleared' in the cleared field that goes to YNAB if the dumper passes a falsy value in that field. For the default dumper, this checks if the transaction date is in the future. For the N26 dumper, this reuses the pending transaction checks, so if skip_pending_transactions is disabled those pending transactions are sent to YNAB, to be hopefully picked up by the transaction matching.
dequis
force-pushed
the
uncleared-transactions
branch
from
04ed64a to
8b07e45
Compare
|
This is amazing @dequis! Thank you very much for your PRs. I just merged the other ones. Let me know how it works for you. I use two other banks, so once you say it works for you, I could clone your fork and try it on my end. If it all goes well we can merge it. The code looks excellent to me! |
| @@ -43,4 +44,8 @@ def category_id(_transaction) | |||
| def normalize_iban(iban) | |||
| iban.delete(' ') | |||
| end | |||
|
|
|||
| def cleared?(transaction) | |||
| date(transaction) < Time.now | |||
There was a problem hiding this comment.
Maybe here we could use Date.current because the date method will return a date object (limitation of some dumpers, most banks don't return a timestamp..) and I think it reads a bit better to see a date comparing with a date. WDYT?
| end | ||
| end | ||
|
|
||
| context 'when skip_pending_transactions feature is disabled' do | ||
| context 'when skip_pending_transactions feature is enabled' do |
|
Welp, the ynab-side matching isn't doing its thing.
Some of them are wildly different yeah, but the flixbus one is the same except (i guess) the exact timestamp. This does have the advantage of leaving duplicate transactions as uncleared, so it's easy to tell which to keep. Aaaaand after writing this I just noticed this one in the docs:
Which.. sounds easy enough, but will probably just get me uncleared ones several times. |
This adds support for sending 'uncleared' in the cleared field that goes
to YNAB if the dumper passes a falsy value in that field.
For the default dumper, this checks if the transaction date is in the
future.
For the N26 dumper, this reuses the pending transaction checks, so if
skip_pending_transactions is disabled those pending transactions are
sent to YNAB, to be hopefully picked up by the transaction matching.
This works, but I don't know if the transaction matching will be good enough in practice. So I'll be running this for a couple of weeks to see how it goes.
I have no way to test the non-N26 dumpers, and test coverage of those seems weak.