github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-03-10 04:02:38 -05:00
Code Issues 250 Packages Projects Releases 53 Wiki Activity

[Feature] manual transfer manipulation #414

New Issue
Closed
opened 2026-02-28 19:03:10 -06:00 by GiteaMirror · 6 comments
GiteaMirror commented 2026-02-28 19:03:10 -06:00
Owner
Copy Link

Originally created by @carkom on GitHub (May 28, 2023).

Verified feature request does not already exist?

  • I have searched and found no existing issue

💻

  • Would you like to implement this feature?

Pitch: what problem are you trying to solve?

This might be better flagged as a bug but I'm not sure if it's working as intended.

1. Widthrawl transaction from account A to account B for -100 (imported)

Then manually mark it as a transfer, you get:

1. Widthrawl transaction from account A to account B for -100 (imported)
2. Deposit transaction to B from A +100 (generated from marking first as a transfer)

Now your accounts are in balance
Import transactions from Account B. Transfer algorithm fails to recognize the imported Deposit as a transfer. I now have:

1. Widthrawl transaction from account A to account B for -100 (imported)
2. Deposit transaction to B from A +100 (generated from marking first as a transfer)
3. Deposit transaction to B from A +100 (imported)

What is the intended fix for this situation? Are we meant to delete transaction 3? Change # 3 into a transfer as well, and end up with 4 total transactions (2 imported and 2 generated)?

Describe your ideal solution to this problem

I'd like a way to tell actual that # 3 is the real transaction and # 2 should be deleted. Mostly to preserve the metadata and allowing the software to link the 2 real (non-generated) import transactions.

Teaching and learning

There's been some good discussion on this topic (see #669) and some good ideas for improving transfer matching criteria.

Thoughts?

Originally created by @carkom on GitHub (May 28, 2023). ### Verified feature request does not already exist? - [X] I have searched and found no existing issue ### 💻 - [ ] Would you like to implement this feature? ### Pitch: what problem are you trying to solve? This might be better flagged as a bug but I'm not sure if it's working as intended. ``` 1. Widthrawl transaction from account A to account B for -100 (imported) ``` Then manually mark it as a transfer, you get: ``` 1. Widthrawl transaction from account A to account B for -100 (imported) 2. Deposit transaction to B from A +100 (generated from marking first as a transfer) ``` Now your accounts are in balance Import transactions from Account B. Transfer algorithm fails to recognize the imported Deposit as a transfer. I now have: ``` 1. Widthrawl transaction from account A to account B for -100 (imported) 2. Deposit transaction to B from A +100 (generated from marking first as a transfer) 3. Deposit transaction to B from A +100 (imported) ``` What is the intended fix for this situation? Are we meant to delete transaction 3? Change # 3 into a transfer as well, and end up with 4 total transactions (2 imported and 2 generated)? ### Describe your ideal solution to this problem I'd like a way to tell actual that # 3 is the real transaction and # 2 should be deleted. Mostly to preserve the metadata and allowing the software to link the 2 real (non-generated) import transactions. ### Teaching and learning There's been some good discussion on this topic (see #669) and some good ideas for improving transfer matching criteria. Thoughts?
GiteaMirror added the feature label 2026-02-28 19:03:10 -06:00
GiteaMirror commented 2026-02-28 19:03:11 -06:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (May 28, 2023):

✨ Thanks for sharing your idea! ✨

This repository is now using lodash style issue management for enhancements. This means enhancement issues will now be closed instead of leaving them open. This doesn’t mean we don’t accept feature requests, though! We will consider implementing ones that receive many upvotes, and we welcome contributions for any feature requests marked as needing votes (just post a comment first so we can help you make a successful contribution).

The enhancement backlog can be found here: https://github.com/actualbudget/actual/issues?q=label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc+

Don’t forget to upvote the top comment with 👍!

@github-actions[bot] commented on GitHub (May 28, 2023): :sparkles: Thanks for sharing your idea! :sparkles: This repository is now using lodash style issue management for enhancements. This means enhancement issues will now be closed instead of leaving them open. This doesn’t mean we don’t accept feature requests, though! We will consider implementing ones that receive many upvotes, and we welcome contributions for any feature requests marked as needing votes (just post a comment first so we can help you make a successful contribution). The enhancement backlog can be found here: https://github.com/actualbudget/actual/issues?q=label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc+ Don’t forget to upvote the top comment with 👍! <!-- feature-auto-close-comment -->
GiteaMirror commented 2026-02-28 19:03:11 -06:00
Author
Owner
Copy Link

@shall0pass commented on GitHub (May 28, 2023):

I agree that this sounds more like a bug.

@shall0pass commented on GitHub (May 28, 2023): I agree that this sounds more like a bug.
GiteaMirror commented 2026-02-28 19:03:12 -06:00
Author
Owner
Copy Link

@j-f1 commented on GitHub (May 29, 2023):

If you set up a rule to automatically mark the imported transaction as a transfer it should match correctly. I also think #669 would be the more general solution if you don’t want to do that for some reason.

@j-f1 commented on GitHub (May 29, 2023): If you set up a rule to automatically mark the imported transaction as a transfer it should match correctly. I also think #669 would be the more general solution if you don’t want to do that for some reason.
GiteaMirror commented 2026-02-28 19:03:12 -06:00
Author
Owner
Copy Link

@carkom commented on GitHub (May 29, 2023):

I've got an example in #820 that explains it. 95% of the transactions link properly. Not sure why this one doesn't. It's the same account, everything is labeled the same all the same rules are applied...

So I could create a rule that marks it as a transfer and it would fix any future imports. If I choose "apply to existing" transactions I'll get duplicates. So what's the fix for existing transactions? Re-import? If I do that, all the ones that are already linked will get deleted? Then I have to Re-import both accounts? It's a lot of work to go through all this just for one transaction the wasn't captured.

Hence the request for a manual transfer connection option.

@carkom commented on GitHub (May 29, 2023): I've got an example in #820 that explains it. 95% of the transactions link properly. Not sure why this one doesn't. It's the same account, everything is labeled the same all the same rules are applied... So I could create a rule that marks it as a transfer and it would fix any future imports. If I choose "apply to existing" transactions I'll get duplicates. So what's the fix for existing transactions? Re-import? If I do that, all the ones that are already linked will get deleted? Then I have to Re-import both accounts? It's a lot of work to go through all this just for one transaction the wasn't captured. Hence the request for a manual transfer connection option.
GiteaMirror commented 2026-02-28 19:03:13 -06:00
Author
Owner
Copy Link

@j-f1 commented on GitHub (May 29, 2023):

So what's the fix for existing transactions?

Delete it, if you import the transaction again later it will be matched with the transfer once the rule is in place.

@j-f1 commented on GitHub (May 29, 2023): > So what's the fix for existing transactions? Delete it, if you import the transaction again later it will be matched with the transfer once the rule is in place.
GiteaMirror commented 2026-02-28 19:03:13 -06:00
Author
Owner
Copy Link

@youngcw commented on GitHub (Jul 7, 2025):

The two things that should be done here are

  1. make a rule for marking imported transfers as transfers in Actual
  2. If both sides are imported and neither are marked as a transfer, then you can select both and use the make transfer option to connect them.
@youngcw commented on GitHub (Jul 7, 2025): The two things that should be done here are 1. make a rule for marking imported transfers as transfers in Actual 2. If both sides are imported and neither are marked as a transfer, then you can select both and use the make transfer option to connect them.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
AI generated
API
bank sync
budgeting
bug
can’t replicate
dependencies
docker
documentation
electron
experimental feature
feature
feedback
goal templates
good first issue
help wanted
importers
maintenance
needs info
needs testing
needs triage
needs votes
openid
payees
pull-request
Mirrored from GitHub Pull Request
 regression
reports
responsive
rules
schedules
server
✨ merged
split transactions
tech debt
theme
transaction import
transaction reconciliation
transactions
translations
upstream
user interface
✅ approved
wontfix
No Label feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#414
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?