[16.0][FIX] account_statement_import_online_gocardless: Unique ID prefer transactionId over entryReference.

[kasado]

At least one bank provides not unique entryReference. Suppose transactionID is unique.

[kasado]

Hi @pedrobaeza could you take a look please? Assuming you are champion for online bank import addons.

Kasparas

[pedrobaeza]

What is the rationale behind this? I haven't found any duplication using entryReference. It depends a lot on each destination bank though. For most of them in my tests, transactionReference was empty.

Anyway, there is a blocking point: if you change this now, for all the existing imported transactions, you are changing their identification (if transactionReference exists), so they will be reimported again on the next synchronization. The only way to accept this is to have a parameter (for example, at journal level), defaulting to the current behavior, but switchable to your one for deciding this order.

But again, I would like to know the reasons of the change before.

[kasado]

@pedrobaeza ,
Thank you for quick review. The issue is with Paysera LT bank. For state TAX transfers, they put the payment code in place of a reference number. So, for any payment with the same payment code, I'm getting the same transactionReference, consequently, the same unique_import_id. That transaction is silently filtered off during import. We can put this PR on hold, I'll try to discuss with Paysera, but do not expect them to change anything, (even if they agree, that it is not proper response of transactions querry).
On the other hand it looks like transactionID is better candidate for unique_import_id than entryReference.
I don't think it is a good idea to have new parameter for this only case.

[pedrobaeza]

As said, you can't change now the uniqueID, as this will reimport existing transactions. At least, a parameter should be put.

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.