Deduplicate matches two report records to one journal entry

[alensiljak]

Just a preliminary report for now but it seems that the deduplicate method in import will match two separate entries in the downloaded report to the same transaction record in the journal.

After the import completes, I get two transactions, both marked as duplicates of the same line:

; duplicate of x:\beans\journal\journal.2025.bean:3384
...
; duplicate of x:\beans\journal\journal.2025.bean:3384

Considering that the first transaction has been copied earlier and is an exact match, the second one is overlooked. The result is an account balance mismatch even though all the records are marked as processed.

Did not debug yet but my guess is that the transactions from an existing book should also be marked as "matched" (or something similar, or simply removed from the list) to avoid double-matching.

[blais]

The dedup code was never really intended to be that robust. I'm thinking it might be best we just remove it by default and provide functions for users to install and test out as they please. That will lead users down the path to building their own.

[alensiljak]

Yes, providing a few options (or comparers) would be useful, while having the user needing to assemble their own override of the deduplicate() function.
I've just implemented an exact matcher (the records are anyway copied from the file generated earlier). Thanks for the tip!