-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: Wrong amount budgeted for category with multiple schedule goal templates #1983
Comments
I can confirm this bug from my own budget:
|
I'll call that a WHOOPS on my behalf. Please check the linked PR #1984 to verify it's fixed. Sorry about that. |
@shall0pass This fix was working for me at the end of November but the new month has thrown up a problem (for me at least). This has come to light because my categories are now full (less any transactions on the 1st). So total budget for Dec 1150 less paid 1000 = 150 still available in December.
|
Yeah. It's currently written in a way that if there are leftover funds in a category and the total balance is less than the total is needed for the month, it just tops it off. Anything over the minimum it'll be treated as a discrete month. This was done so that it's possible to add extra funds to the category in one month as savings for the next month. Schedules with multiple month frequencies for example are treated as sinking funds and if those are included in the same category as other monthly schedules everything becomes fuzzy if you want to add a little extra to meet your goal faster. The ability to have multi month or multi year schedules was the primary reason to include previous balances in the calculation. It would be much cleaner to just schedule the base payment regardless, but then there could be months where the goal isn't met unless manual intervention is taken (i.e. starting a 6 month schedule 2 months before the first payment is due). Of course, in that example, once you're past the first payment the monthly amount would be correct. I have a POC using a method shared with me on Discord, maybe it's time to put it up as a WIP and you can try it and comment on it. It uses a method to calculate shortfalls based on annual needs rather than monthly needs. I still see some oddities, but the method is a little harder for me to sort out bugs. No one has reported it yet, but there are quirks if you have two schedules that are on different cadences with vastly different amounts with the current method too. |
@Kidglove57 Here is the WIP method I mentioned above. |
Thanks for explaining @shall0pass. I think what’s bothering me is that this is then out of line with how a single line template behaves. Say; “#template 100” which will fund 100 regardless of any brought forward amount. I am using the multiple schedule template in a monthly subs category and in a household bills category. Where the scheduled payments are the same each month. The solution is of course for me to hold off funding the next month until the turn of the month. Not a big deal but I just found it confusing compared to my single line template. The multi line schedule template now seemed to behave more like an “up to” template. I’ll certainly take a look at the other link you mentioned. Thanks for your hard work on this! |
@Kidglove57 the Schedule template is best compared to the "by repeat" template. @shall0pass Here is a crazy idea. What if the schedule template processing converted the schedule into a "by" template and then ran that instead of having custom processing? Do "by" templates handle what Paul is seeing better? |
Yes, I can see that now. It was just that I was only using the multiple line schedule template for fixed monthly bills where the “by repeat” is not relevant. Previously I had just kept a manual calculation and funded to that. Or am I mistaken? I had not got around yet to trying it for multiple line annual schedules. That sounds like an experiment worth trying - for annual software subs for example. I can quite see that the two are very different use cases. |
@youngcw Converting the schedules to 'by repeat' could also be difficult. Some schedules can have multiple days per month per schedule. @Kidglove57 Maybe an option is to use the 'full' keyword for monthly schedules. 'full' forces the whole schedule to be budgeting in the month of the schedule, so for monthly schedules it might be a more desired output. If that works better, it could be applied on all monthly schedules that don't need a '$/number of months' calculation. |
@shall0pass thanks for the tip, I’m out this evening but I will certainly try that tomorrow. So that would be multiple lines for my monthly bills in the format: |
@shall0pass I found a few moments before I went out. Thank you so much |
What are your thoughts on making that the default behavior for schedules with an 'every 1 month' cadence? |
For exactly 1 month cadence that probably would make sense. Its not that different, but probably would match what people expect more often than not. |
I’m also fine with this so long as we can document it fully for the casual user. Thank you! |
I'll put something together so it can be tested. Unless someone beats me to it :) |
I gave this a try with my live budget. It worked on one category but gave some odd results on two others (over provisions). Whereas using the "full" prefix worked in all the situations that I have tried. |
Verified issue does not already exist?
What happened?
I create 3 monthly schedules which total 327.11.
Then I add them as goal templates to the category "Bills":
Finally I apply the budget template for December and expect that 327.11 is budgeted. However triple that (981.33) is budgeted.
It appears that if X schedule goal templates are added to a category the budgeted amount for each schedule is added X times to the category.
Sample database to reproduce the bug: schedules-goals.zip
cc @shall0pass you've done a lot of work in this area
What error did you receive?
No response
Where are you hosting Actual?
Docker
What browsers are you seeing the problem on?
Firefox
Operating System
None
The text was updated successfully, but these errors were encountered: