dvankley / firefly-plaid-connector-2

Connector to pull Plaid financial data into the Firefly finance tool
GNU General Public License v3.0
94 stars 14 forks source link

Customizations made to "pending" transactions get deleted #110

Open nprzy opened 1 month ago

nprzy commented 1 month ago

I noticed that when Plaid syncs transactions that are still "pending", firefly-plaid-connector-2 will sync them into FF. Then when that pending transaction is fully posted it will delete the transaction and create a new one. This is problematic for me when I manually set tags/categories/budgets on transactions, only to have them reset when the transaction posts and is re-created.

It appears that Plaid provides a pendingId field when a transaction is posted that tells you what the pending transaction ID was. It would be nice if we could use this to update the existing pending transaction rather than delete/recreate. As a secondary nice-to-have, it would be nice if we could add a "pending" tag to pending transactions in FF.

I can probably submit a PR for this.

dvankley commented 1 month ago

Interesting. I didn't realize that field was available (maybe it wasn't when I first built this).

It would be nice if we could use this to update the existing pending transaction rather than delete/recreate.

Sounds good. We'll also need to disallow transfer matching logic on pending transactions so we don't end up trying to update a transfer.

Also note that Firefly doesn't allow updating a transaction type (or at least it didn't when I wrote that; I can check if that's changed). I think that will require us to continue to delete/recreate for transfers.

dkichler-improving commented 1 week ago

I've also noticed and began observing this behaviour and was thinking about similar solutions.

However, in investigating deeper, I found that in some cases the final posted transaction does not actually include a reference to the pending transaction that was deleted, instead the pending_transaction_id remains null, losing any ability to link it back to the original pending.

Lacking a consistent pending_transaction_id reference, some of my initial thoughts were around how to have the import take the authorizedDate rather than date - authorized_date stays consistent across the pending and final transactions, whereas date changes from authorized to posted date. This would have the impact of causing Firefly to consider the two duplicates upon subsequent posts (I think), but also leave transactions in Firefly against the authorized date, which might mess up reconciliations 🤷 .

AmineI commented 1 week ago

In my case, I ended up just coding an option flag to add only finished transactions to firefly - pending don't get imported until they are confirmed.

It was quite a basic change at the time, see commit here : https://github.com/dvankley/firefly-plaid-connector-2/commit/d19aea91e5620ac55d0d3aaa7fe4c6232b0f9051

dkichler commented 5 days ago

In my case, I ended up just coding an option flag to add only finished transactions to firefly - pending don't get imported until they are confirmed.

It was quite a basic change at the time, see commit here : d19aea9

I considered this as well, but I really like the visibility on pending transactions, especially for near real-time tracking budgets like groceries or eating out. Some of my institutions take forever to settle transactions, like up to 5 days for txns on a weekend.

I found that in fact most of the institutions I subscribe to will not even post pending transactions via Plaid, probably to avoid trouble like this. The only institution where this is problematic for me is CIBC, and they do a terrible job of reporting accurate balances or transactions even through their own portal (ie txns pending for a long time, pending txns disappearing entirely for a couple days at the threshold of settling, balance reporting pending transactions or payments that are not even listed in the transaction details, etc)