Improved handling of data entry for split transactions #1253

Closed
opened 2026-02-28 19:37:34 -06:00 by GiteaMirror · 1 comment
Owner

Originally created by @deftly1970 on GitHub (Jul 17, 2024).

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?

When entering a split transaction, the flow of the data entry could be improved to speed entry. Currently when "Split" is chosen, the first step after choosing "split" is to enter the total of the transaction. Hitting Enter after this takes the cursor down to the first line of the split, retaining any previously utilized category if applicable for the payee. After entering the first amount of the split, hitting enter adds a new line for the split, again retaining any previously utilized category and leaving the cursor active in the Amount field.

Describe your ideal solution to this problem

I propose that when Split is chosen, after entering the transaction total and hitting Enter, a new line should be added and on that new line, the cursor should move back to the category field to allow the user to choose the appropriate category for the first line of the split. The user can then tab forward to the amount field to enter the first split amount. Subsequent lines added in this way should all position the cursor in the category field since by default, if split is chosen as the initial "category" the transaction will always require choosing two or more categories in order to complete it.

Teaching and learning

No response

Originally created by @deftly1970 on GitHub (Jul 17, 2024). ### 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? When entering a split transaction, the flow of the data entry could be improved to speed entry. Currently when "Split" is chosen, the first step after choosing "split" is to enter the total of the transaction. Hitting Enter after this takes the cursor down to the first line of the split, retaining any previously utilized category if applicable for the payee. After entering the first amount of the split, hitting enter adds a new line for the split, again retaining any previously utilized category and leaving the cursor active in the Amount field. ### Describe your ideal solution to this problem I propose that when Split is chosen, after entering the transaction total and hitting Enter, a new line should be added and on that new line, the cursor should move back to the category field to allow the user to choose the appropriate category for the first line of the split. The user can then tab forward to the amount field to enter the first split amount. Subsequent lines added in this way should all position the cursor in the category field since by default, if split is chosen as the initial "category" the transaction will always require choosing two or more categories in order to complete it. ### Teaching and learning _No response_
GiteaMirror added the needs votesfeature labels 2026-02-28 19:37:34 -06:00
Author
Owner

@github-actions[bot] commented on GitHub (Jul 17, 2024):

Thanks for sharing your idea!

This repository uses lodash style issue management for enhancements. That means enhancement issues are automatically closed. 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 (Jul 17, 2024): :sparkles: Thanks for sharing your idea! :sparkles: This repository uses lodash style issue management for enhancements. That means enhancement issues are automatically closed. 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 -->
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#1253