[Bug]: Reconciling split translations from nYNAB import creates orphan transfers

[naeramarth7]

Verified issue does not already exist?

• I have searched and found no existing issue

Is this related to GoCardless, Simplefin or another bank-sync provider?

• I have checked my server logs and could not see any errors there
• I will be attaching my server logs to this issue
• I will be attaching my client-side (browser) logs to this issue
• I understand that this issue will be automatically closed if insufficient information is provided

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]

👋 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 b is 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]

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!