mirror of
https://github.com/actualbudget/actual.git
synced 2026-07-16 07:04:23 -05:00
[GH-ISSUE #2495] [Bug]: Transaction not synced with Gocardless, has no transactionId #90627
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/actual#90627
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @SirJohnDoe on GitHub (Mar 23, 2024).
Original GitHub issue: https://github.com/actualbudget/actual/issues/2495
Verified issue does not already exist?
Is this related to GoCardless, Simplefin or another bank-sync provider?
What happened?
After syncing bank transactions with Gocardless, I noticed that one transaction was missing due to the balance not adding up to my current balance when I check it in my bank app. I had this issue before when initially setting up Actual and syncing the past 3 months, but figured it had to do with historic data and corrected it manually.
What I noticed is that this particular transaction doesn't have a transactionId, it shows:
"transactionId":" "in the log, where all the other transactions have some value shown there. Seeing that the transaction shows up in the log (both browser and server) and the current balance also matches, it seems the data is complete, but not shown/processed in Actual. The transaction in question has entryReference 20240320-90950171.Server log:
Browser log;
The transaction in question is a 'Payment request'. You can send these using the bank app to other people with a link so they can pay you. In this case it was a friend paying me back for a concert ticket.
I run Actual v24.3.0 as a Home Assistant add-on.
What error did you receive?
None
Where are you hosting Actual?
Other
What browsers are you seeing the problem on?
Chrome
Operating System
Windows 11
@MatissJanis commented on GitHub (Mar 24, 2024):
👋 First of all: thank you for providing all this data! It's much easier to help if all the necessary logs are provided.
Are you sure your friend has made the payment? Has it cleared? I find it strange that you can make a payment request to a 3rd party and that it would affect your ledger prior to actually receiving the funds (i.e. what happens if you make a 10m payment request from your friend? Does that temporarily make your balance go up by 10m?).
After receiving the monies from your friend and the transaction clearing (in a few days from today I guess?) - does the
transactionIdappear as a non-empty value?--
Internally the problem is that
" "(transactionId) is actually treated as a valid value. So we look-up your ledger in Actual to find a transaction with the id" ". And I'm guessing you've had previous payment requests, so it is in fact matched. And because it is matched (thus existing in Actual) - we update it and move on instead of creating a new one.We might need to add some logic here to trim the
transactionIdvalues. That way" "would be turned into""and it would thus NOT be a valid transaction-id to use for matching. And thus it would try to match by date & transaction amount instead oftransactionId.But this is dangerous as it is a breaking change that can impact other users of Actual. Would need to be careful.
@SirJohnDoe commented on GitHub (Mar 25, 2024):
Thanks for the explanation. To answer your questions: the payment request is created in my bank app, and only shows up in the transactions once someone actually pays. The payments are always instantly (all Dutch banks support SEPA instant) received. So the transaction I tried to sync is the final transaction, there is no clearing involved as it's always instant and only shows up (becomes a transaction) when someone pays.
@MatissJanis commented on GitHub (Mar 26, 2024):
What's the institution ID for this bank? We could create a custom bank mapper for it to trim the
transactionIdvalues. I think that's the safest solution here.@SirJohnDoe commented on GitHub (Mar 26, 2024):
The institution ID is ASN_BANK_ASNBNL21. Thanks!
@MatissJanis commented on GitHub (Mar 26, 2024):
Fix: https://github.com/actualbudget/actual-server/pull/328
@MatissJanis commented on GitHub (Apr 1, 2024):
👋 I was chatting with @kyrias and he noted that according to GoCardless documentation the
transactionIdfield has to be unique (and optional; source). In your case it does not seem to be unique.Which leads us to believe the patch should actually be on GoCardless side. Could you reach out to their support and see if they can patch it on their side?
Thanks
@SirJohnDoe commented on GitHub (Apr 2, 2024):
👍 I've send in a ticket to support about this. I noticed that basically all the 'internal' transactions (paid payment requests, account fees, interest payments) have transaction ID " ".
When I send in the ticket I saw this support article. Why does Actual not use the internalTransactionID? It seems that one is truly unique and already filtered by GoCardless for duplicates.
@SirJohnDoe commented on GitHub (Apr 2, 2024):
Just got a response from GoCardless. They suggest to use the internalTransactionID;
@kyrias commented on GitHub (Apr 2, 2024):
Because it didn't exist when the GoCardless (or then Nordigen) support was added, and switching at this point would need to be done very carefully to not break existing users.
The options I can think of are:
transactionIdorinternalTransactionId. This seems like it would probably be the simplest option, but it would mean that we need to continue supporting using both IDs essentially forever, and it means adding GoCardless-specific metadata to the account which is only needed for this one little thing.gocardless-{resourceId}-{internalTransactionId}maybe?imported_idan array, and always use both when they're available. This just seems like it'd make the application more complicated for no real advantage.Also, I find it so annoying how GoCardless support responses to their API not working the way it's documented is always for you to implement random work-arounds rather than them cleaning up the data to correspond to their own documented schema.
@MatissJanis commented on GitHub (Apr 2, 2024):
+1 to @kyrias
Ideally we should push more on GoCardless here to either patch it on their end or update the documentation to reflect the reality (
transactionIdNOT being unique).I will also leave this issue open in case anyone wants to pick up the refactors to gracefully switch over to
internalTransactionId.@matt-fidd commented on GitHub (Apr 19, 2024):
Just as an observation from my Nationwide account I sync via GoCardless, it doesn't look like internalTransactionId is populated until the transaction is booked.
Pending
Booked
The GoCardless docs don't seem to mention this at all, and I'm unsure whether it's inconsistent between different banks.
@marian-code commented on GitHub (Jun 28, 2024):
Hey guys is there any update on the issue. I'm experiencing very similar problem where some transactions do not have unique ID. In my case the field is not empty but it is the same as several other transactions. Interestingly the affected transactions seem to be the ones where I sent manually, It has never happened for card payments.
Anyway thanks for all the hard work, Actual is pretty great.
@nichtdu commented on GitHub (Oct 24, 2024):
just adding for reference the KB-Article from gocardless with further information concerning this topic
https://bankaccountdata.zendesk.com/hc/en-gb/articles/11529646897820-internalTransactionId-a-unique-transaction-ID-now-generated-by-GoCardless