github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-05-10 16:26:43 -05:00
Code Issues 1.6k Packages Projects Releases 57 Wiki Activity

[Feature] Better upcoming payments for ranged schedules #1001

New Issue
Closed
opened 2026-02-28 19:27:58 -06:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-02-28 19:27:58 -06:00
Owner
Copy Link

Originally created by @psybers on GitHub (Mar 23, 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?

Sometimes, recurring payments are within a range. In my example, the cost is based on the number of days that activity is offered that month, so holidays and the number of weeks make it vary.

For example, you might have a monthly payment that varies between $-80 and $-320 and then set the schedule up as a range. When you set the schedule to a range, it shows upcoming transactions using the average of that range, e.g. $-160:

image

Depending on the range, that might not be very accurate.

Describe your ideal solution to this problem

What would be more useful is to find all linked payments for that schedule, e.g.:

image

and then use the average of that set of transactions as the scheduled transaction's amount. In this example, that would be $-165.68 instead of the range's average of $-160. This would be very easy to calculate, and would better handle scenarios where most payments are similar and you have a few one-off payments that are very different. In the example above, the low payment of ~$90 is an outlier—most payments are closer to $190.

A better solution would be one that can learn from the set of transactions already linked and forecast forward based on that. This could be useful in two scenarios. The first is where the payment somewhat alternates between a couple of values. The second is when the payment is slowly increasing (or, though this rarely happens in life, decreasing) over time. Here it would be nice if it then tries to guess a better estimate than the average.

Teaching and learning

This should be fully automated, so nothing needs to happen on the user's end. The documentation might be updated to describe that behavior, though the current documentation on creating schedules does not mention the ranges at all.

Originally created by @psybers on GitHub (Mar 23, 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? Sometimes, recurring payments are within a range. In my example, the cost is based on the number of days that activity is offered that month, so holidays and the number of weeks make it vary. For example, you might have a monthly payment that varies between `$-80` and `$-320` and then set the schedule up as a range. When you set the schedule to a range, it shows upcoming transactions using the average of that range, e.g. `$-160`: <img width="458" alt="image" src="https://github.com/actualbudget/actual/assets/1115390/dcc99c6b-ef41-4463-86a6-b24835493095"> Depending on the range, that might not be very accurate. ### Describe your ideal solution to this problem What would be more useful is to find all linked payments for that schedule, e.g.: <img width="64" alt="image" src="https://github.com/actualbudget/actual/assets/1115390/76fdf965-b7d8-495c-89f2-4e43fb10d3f1"> and then use the average of that set of transactions as the scheduled transaction's amount. In this example, that would be `$-165.68` instead of the range's average of `$-160`. This would be very easy to calculate, and would better handle scenarios where most payments are similar and you have a few one-off payments that are very different. In the example above, the low payment of ~`$90` is an outlier—most payments are closer to `$190`. A better solution would be one that can learn from the set of transactions already linked and forecast forward based on that. This could be useful in two scenarios. The first is where the payment somewhat alternates between a couple of values. The second is when the payment is slowly increasing (or, though this rarely happens in life, decreasing) over time. Here it would be nice if it then tries to guess a better estimate than the average. ### Teaching and learning This should be fully automated, so nothing needs to happen on the user's end. The documentation might be updated to describe that behavior, though the current documentation on creating schedules does not mention the ranges at all.
GiteaMirror added the needs votesfeature labels 2026-02-28 19:27:58 -06:00
GiteaMirror commented 2026-02-28 19:27:58 -06:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Mar 23, 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 (Mar 23, 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.
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 needs votes
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#1001
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?