Ynab import id generation may cause missed transactions

[hpernu]

Transactions are sometimes lost and never imported to YNAB. I was able to track this to the way YNAB import id is generated.

Specifically, when the exact same sum on same date is done with the same memo (or empty memo) this will generate the same id. This is fairly common, for example, with transactions between account of my own and sometimes there are those within a same date. I also pay invoices in batches. Sometimes they have the same amount causing the same id even though they are actually to different counterparties. Or sometimes I transfer the same amount to multiple accounts of my own and ynabber only detects this once (on both ends).

Suggest using something more unique. There is, for example the id coming from Nordigen. Although this might have duplicates between banks, I doubt they have any duplicates within a single bank. A hash of, for example, the following data should surely be enough:

• IBAN of the account in question(this already narrows it down to a single account)
• the transaction id from Nordigen(will probably already make it unique but I don't know whether it is seen on all banks - likely so)
• for extra measure, we can also put in payee and memo

For backwards compatibility, though, we have to only start generating new style ids from an agreed upon future date. Otherwise the old transactions would reappear. A suggested date here could be any transaction date greater than 2022-12-01.
This needs to be configurable though for testing purposes.

Any opinions?

[martinohansen]

I've been dreading this for a while. All through it's not common in my case it have happened once or twice.

I agree that a hash of the uuid from Nordigen is the best way forward, I don't even think we need to incorporate the IBAN to make the chance of duplications unrealistic.

Can you confirm that the Nordigen transaction IDs you get are indeed uuids?

With regard to the implementation of this I will suggest two new config settings: 1) an import ID version with either v1 (default) or v2 specified and 2) a import from date to allow the user to only import transactions from this date and onward.

That will allow existing users to change this behavior without too many issues and new users to simply use v2 from the get go.

[hpernu]

I doubt the transactionid from Nordigen is actually an uuid. They seem to be all numbers and possibly it is a bank specific serial id unique to the single bank only.

The simplest thing would be to actually just take a hash of the source IBAN(i.e. payer IBAN)+Nordigen structure for the single transaction. The more data we actually use for hash, the better, as long as it remains constant for same inputs.

I really see the configuration necessary only for testing. I do not see a real normal user usecase for configuring the import id, if the algorithm is wide enough to take all possible (but unchanging) parameters in the hash.
Thats why I was thinking something like YNAB_IMPORITID_V2 = YYYY-MM-DD with the default value being 2022-12-01 .
The only usecase would be to for the tester to switch to new import ids earlier. ( Or perhaps regression testing by making the date extremely high. )