mirror of
https://github.com/actualbudget/actual.git
synced 2026-07-15 22:54:03 -05:00
[GH-ISSUE #2436] [Bug]: Reconciling split translations from nYNAB import creates orphan transfers #7912
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/actual#7912
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 @naeramarth7 on GitHub (Mar 7, 2024).
Original GitHub issue: https://github.com/actualbudget/actual/issues/2436
Verified issue does not already exist?
Is this related to GoCardless, Simplefin or another bank-sync provider?
What happened?
Picking up on #1835 , reconciling nYNAB imported split transactions creates orphan transfers.
File for reproduction:
ynab5-demo-budget.json
After import:
Checking (balance: 600)
Saving (balance: 250)
After reconciliation of checking:
Checking (balance: 600)
Saving (balance: 300)
There is now a second "split part b" transfer in saving, which does not have a counter part. The total budget increased from 850 to 900 due to this orphan transfer.
What error did you receive?
No error, but the transactions and balances are off after reconciliation.
Where are you hosting Actual?
Docker
What browsers are you seeing the problem on?
Chrome
Operating System
Mac OSX
@MatissJanis commented on GitHub (Mar 21, 2024):
👋 Thanks for the report. I checked the situation and I have a suspicion that the export file is faulty.
It has two entries for transaction
split part b. Each of them has a different ID. One of them is a root-level transaction and the other is a subtransaction.This leads me to believe that
split part bis not a single transaction, but it is in fact two different transactions (with similar transaction details).The interesting part is: why is the sub-transaction transfer created only after reconciling? That is very odd. However, it's more likely that the provided export is actually faulty and thus the issue is possible. With non-faulty exports this should not be possible and thus the bug would not be visible.
At least these are my investigations & assumptions so far.
@Wizmaster commented on GitHub (Mar 22, 2024):
Hello @MatissJanis!
I can confirm the issue, it comes from the nYNAB export that can be seen as "faulty" :) Unfortunately it's the export nYNAB is currently doing. I was hit by that issue and am working on a fix but it's not yet ready.
The issue comes from nYNAB export file not outputting the "transfer_transaction_id" fields on the affected transactions, the field does not even exists on the sub-transactions. This leads the import module to create malformed transactions in Actual that are (kind of) fixed upon action on those, either reconciling the account or changing anything on the transactions, by creating the missing reverse transfer transaction.
I hope to have a working fix in a few days!