github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-11-12 03:42:19 -06:00
Code Issues 3.0k Packages Projects Releases 58 Wiki Activity

[Bug]: Posting a schedule does not remove it from upcoming #2288

New Issue
Closed
opened 2026-02-28 20:09:03 -06:00 by GiteaMirror · 15 comments
GiteaMirror commented 2026-02-28 20:09:03 -06:00
Owner
Copy Link
Copy Source

Originally created by @shall0pass on GitHub (Jul 16, 2025).

Verified issue does not already exist?

  • I have searched and found no existing issue

What happened?

This is more of a workflow and usability issue. If you have an upcoming schedule and decide to post the schedule early, if the posted date is beyond the 2 or 3 day window of schedule matching the schedule will not be removed from the upcoming transactions. This can easily result in a double entry for a schedule if it's not noticed. I've attached a screen grab with the behavior. I think the reason this is broken is that the current date is entered for the posted transaction instead of the scheduled date.

Image

How can we reproduce the issue?

  1. Create or modify a scheduled transaction that is more than 3 days into the future.
  2. Go to the account the schedule will be posted to and select to post the transaction.

You will see that the scheduled transaction is still shown as upcoming.

I see a couple of options to resolve this, there may be others.

  1. Insert the scheduled date into the posted transaction. This will ensure the schedule matching works with the date.
  2. Keep the current date inserted and add an automatic step to skip the next scheduled transaction. Somewhat related, it would be nice to be able to reinsert the transaction back into the schedule as a once-off to remove it from the ledger OR (and not sure if it's possible) if the linked transaction is deleted to UNSKIP the next scheduled transaction.

Where are you hosting Actual?

Docker

What browsers are you seeing the problem on?

Microsoft Edge

Operating System

Windows 11

Originally created by @shall0pass on GitHub (Jul 16, 2025). ### Verified issue does not already exist? - [x] I have searched and found no existing issue ### What happened? This is more of a workflow and usability issue. If you have an upcoming schedule and decide to post the schedule early, if the posted date is beyond the 2 or 3 day window of schedule matching the schedule will not be removed from the upcoming transactions. This can easily result in a double entry for a schedule if it's not noticed. I've attached a screen grab with the behavior. I think the reason this is broken is that the current date is entered for the posted transaction instead of the scheduled date. ![Image](https://github.com/user-attachments/assets/9aed10da-4da0-456d-9e5f-daedfd1c4368) ### How can we reproduce the issue? 1. Create or modify a scheduled transaction that is more than 3 days into the future. 2. Go to the account the schedule will be posted to and select to post the transaction. You will see that the scheduled transaction is still shown as upcoming. I see a couple of options to resolve this, there may be others. 1. Insert the scheduled date into the posted transaction. This will ensure the schedule matching works with the date. 2. Keep the current date inserted and add an automatic step to skip the next scheduled transaction. Somewhat related, it would be nice to be able to reinsert the transaction back into the schedule as a once-off to remove it from the ledger OR (and not sure if it's possible) if the linked transaction is deleted to UNSKIP the next scheduled transaction. ### Where are you hosting Actual? Docker ### What browsers are you seeing the problem on? Microsoft Edge ### Operating System Windows 11
GiteaMirror added the regressionbugschedules labels 2026-02-28 20:09:04 -06:00
GiteaMirror commented 2026-02-28 20:09:06 -06:00
Author
Owner
Copy Link
Copy Source

@MaudMan commented on GitHub (Jul 18, 2025):

This same scenario is in the documentation and says it's expected behavior - https://actualbudget.org/docs/schedules/#how-actual-finds-schedules

@MaudMan commented on GitHub (Jul 18, 2025): This same scenario is in the documentation and says it's expected behavior - https://actualbudget.org/docs/schedules/#how-actual-finds-schedules
GiteaMirror commented 2026-02-28 20:09:06 -06:00
Author
Owner
Copy Link
Copy Source

@shall0pass commented on GitHub (Jul 18, 2025):

I understand that if a scheduled transaction is outside of the window the matching won't occur. But posting the scheduled transaction intentionally using the tool provided to post that transaction, not from a data import or bank sync, should behave as if you posted that scheduled transaction and that schedule has been fulfilled for that occurrence. This is a usability issue because it doesn't do what what is normally expected.

@shall0pass commented on GitHub (Jul 18, 2025): I understand that if a scheduled transaction is outside of the window the matching won't occur. But posting the scheduled transaction intentionally using the tool provided to post that transaction, not from a data import or bank sync, should behave as if you posted that scheduled transaction and that schedule has been fulfilled for that occurrence. This is a usability issue because it doesn't do what what is normally expected.
GiteaMirror commented 2026-02-28 20:09:06 -06:00
Author
Owner
Copy Link
Copy Source

@MaudMan commented on GitHub (Jul 19, 2025):

But the documentation I linked to actually says you post the transaction early (on the 10th), but you'll still see the scheduled transaction upcoming on the 15th because it's outside the 2-day window for matching a scheduled transaction.. I was merely pointing out that the documentation states this is expected behavior (ie. not a bug).

@MaudMan commented on GitHub (Jul 19, 2025): But the documentation I linked to actually says you post the transaction early (on the 10th), but you'll still see the scheduled transaction upcoming on the 15th because it's outside the 2-day window for matching a scheduled transaction.. I was merely pointing out that the documentation states this is _expected_ behavior (ie. not a bug).
GiteaMirror commented 2026-02-28 20:09:07 -06:00
Author
Owner
Copy Link
Copy Source

@shall0pass commented on GitHub (Jul 19, 2025):

I still thinks it's a usability bug. It may be known, and therefore expected because it's known, but that doesn't mean it can't be remedied.

@shall0pass commented on GitHub (Jul 19, 2025): I still thinks it's a usability bug. It may be known, and therefore expected because it's known, but that doesn't mean it can't be remedied.
GiteaMirror commented 2026-02-28 20:09:07 -06:00
Author
Owner
Copy Link
Copy Source

@shall0pass commented on GitHub (Jul 19, 2025):

"Therefore, post the transaction to Actual early and update the transaction date to match your bank statement."

If you review the screen grab, I never changed the date of the posted transaction. This text in the docs is out of date. I think the original behavior inserted the scheduled date, not the current date. When the change was made to insert the current date, the usability problem emerged.

@shall0pass commented on GitHub (Jul 19, 2025): "Therefore, post the transaction to Actual early and update the transaction date to match your bank statement." If you review the screen grab, I never changed the date of the posted transaction. This text in the docs is out of date. I think the original behavior inserted the scheduled date, not the current date. When the change was made to insert the current date, the usability problem emerged.
GiteaMirror commented 2026-02-28 20:09:08 -06:00
Author
Owner
Copy Link
Copy Source

@MaudMan commented on GitHub (Jul 19, 2025):

Right, but in your demo, if you adjust the date of the posted transaction to within 2-days of the scheduled transaction, then the next scheduled transaction for 7/22 disappears. So the 2-day scheduled transaction matching hasn't changed. Maybe a feature request to allow adjusting the 2-day matching would be a decent solution?

@MaudMan commented on GitHub (Jul 19, 2025): Right, but in your demo, if you adjust the date of the posted transaction to within 2-days of the scheduled transaction, then the next scheduled transaction for 7/22 disappears. So the 2-day scheduled transaction matching hasn't changed. Maybe a feature request to allow adjusting the 2-day matching would be a decent solution?
GiteaMirror commented 2026-02-28 20:09:08 -06:00
Author
Owner
Copy Link
Copy Source

@shall0pass commented on GitHub (Jul 19, 2025):

Or adjusting the "Post a schedule" tool to actually satisfy an occurrence of a schedule. I'm convinced this is a bug. A maintainer can close this off if they disagree, but I feel pretty strongly that the "Post a schedule" tool shouldn't require extra steps to satisfy a schedule.

@shall0pass commented on GitHub (Jul 19, 2025): Or adjusting the "Post a schedule" tool to actually satisfy an occurrence of a schedule. I'm convinced this is a bug. A maintainer can close this off if they disagree, but I feel pretty strongly that the "Post a schedule" tool shouldn't require extra steps to satisfy a schedule.
GiteaMirror commented 2026-02-28 20:09:08 -06:00
Author
Owner
Copy Link
Copy Source

@matt-fidd commented on GitHub (Jul 20, 2025):

I'm happy to call this somewhere halfway between a bug and improvement. I can see it being confusing but it is clarified in the docs. I'll leave this as-is for now, but if any other maintainers disagree we can move it to a feature request.

@matt-fidd commented on GitHub (Jul 20, 2025): I'm happy to call this somewhere halfway between a bug and improvement. I can see it being confusing but it is clarified in the docs. I'll leave this as-is for now, but if any other maintainers disagree we can move it to a feature request.
GiteaMirror commented 2026-02-28 20:09:08 -06:00
Author
Owner
Copy Link
Copy Source

@shall0pass commented on GitHub (Jul 20, 2025):

I'm still unclear how this would be a feature request, but if that is the way we need to go, I accept.

I thought more about the idea of expanding the window for matching, but I think that logic fails. If I change the window of viewing schedules in the ledger out to one month, I could post a schedule early one month out and the same behavior would happen that's described in this report. The schedule would remain in upcoming and not be removed for the next occurrence.

Is that really how the tool is supposed to work?

If I go back to an earlier version: https://deploy-preview-446--actualbudget.netlify.app/accounts/43a4ec6f-19df-46c2-bc86-032240d65655

The tool works as expected. If you post a transaction from the ledger using the tool from v23.1.12, it is no longer shown as upcoming. I think this is a regression.

@shall0pass commented on GitHub (Jul 20, 2025): I'm still unclear how this would be a feature request, but if that is the way we need to go, I accept. I thought more about the idea of expanding the window for matching, but I think that logic fails. If I change the window of viewing schedules in the ledger out to one month, I could post a schedule early one month out and the same behavior would happen that's described in this report. The schedule would remain in upcoming and not be removed for the next occurrence. Is that really how the tool is supposed to work? If I go back to an earlier version: https://deploy-preview-446--actualbudget.netlify.app/accounts/43a4ec6f-19df-46c2-bc86-032240d65655 The tool works as expected. If you post a transaction from the ledger using the tool from v23.1.12, it is no longer shown as upcoming. I think this is a regression.
GiteaMirror commented 2026-02-28 20:09:09 -06:00
Author
Owner
Copy Link
Copy Source

@shall0pass commented on GitHub (Jul 20, 2025):

I took a few minutes to go through the most recent releases. This bug was not present in 25.4.0. It was introduced in 25.5.0. This is a very recent change to behavior. Only two months.

@shall0pass commented on GitHub (Jul 20, 2025): I took a few minutes to go through the most recent releases. This bug was not present in 25.4.0. It was introduced in 25.5.0. This is a very recent change to behavior. Only two months.
GiteaMirror commented 2026-02-28 20:09:10 -06:00
Author
Owner
Copy Link
Copy Source

@matt-fidd commented on GitHub (Jul 20, 2025):

Thanks, I wonder what changed. I'll take a look when I get home tonight unless someone beats me to it. We're getting close to mergefreeze so I'm wary about forcing it in to the next release, but I'll add it to the milestone in case I can get a nice easy fix in before.

@matt-fidd commented on GitHub (Jul 20, 2025): Thanks, I wonder what changed. I'll take a look when I get home tonight unless someone beats me to it. We're getting close to mergefreeze so I'm wary about forcing it in to the next release, but I'll add it to the milestone in case I can get a nice easy fix in before.
GiteaMirror commented 2026-02-28 20:09:10 -06:00
Author
Owner
Copy Link
Copy Source

@shall0pass commented on GitHub (Jul 20, 2025):

Going out on a limb here: https://github.com/actualbudget/actual/pull/4719

@shall0pass commented on GitHub (Jul 20, 2025): Going out on a limb here: https://github.com/actualbudget/actual/pull/4719
GiteaMirror commented 2026-02-28 20:09:11 -06:00
Author
Owner
Copy Link
Copy Source

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

Going out on a limb here: #4719

That's my guess. That PR made the function match the text better but it can no longer exclusively rely on the schedule rule to handle everything since the rule may not match.

Probably what needs to happen is to add a second option to "post on date" that would match the old functionality, then update the existing action to run the schedule rule and/or skip the upcoming schedule date.

@youngcw commented on GitHub (Jul 20, 2025): > Going out on a limb here: [#4719](https://github.com/actualbudget/actual/pull/4719) That's my guess. That PR made the function match the text better but it can no longer exclusively rely on the schedule rule to handle everything since the rule may not match. Probably what needs to happen is to add a second option to "post on date" that would match the old functionality, then update the existing action to run the schedule rule and/or skip the upcoming schedule date.
GiteaMirror commented 2026-02-28 20:09:11 -06:00
Author
Owner
Copy Link
Copy Source

@CrimsonFlash commented on GitHub (Dec 4, 2025):

Looks like this bug has returned. I've seen it happening for the past few versions, so not sure when it was re-introduced.

Sorry for the black out text, but it's the same steps/results as in the OP.

Transaction for the future, when posted today, does not clear out the future transaction.

Image Image Image

Where are you hosting Actual?
Windows Server bare metal

What browsers are you seeing the problem on?
Firefox, Chrome, native macOS app

Operating System

Windows 10, 11, macOS

@CrimsonFlash commented on GitHub (Dec 4, 2025): Looks like this bug has returned. I've seen it happening for the past few versions, so not sure when it was re-introduced. Sorry for the black out text, but it's the same steps/results as in the OP. Transaction for the future, when posted today, does not clear out the future transaction. <img width="929" height="390" alt="Image" src="https://github.com/user-attachments/assets/b46c92c3-acf5-4a7b-bdf9-c69ce4df09b1" /> <img width="928" height="189" alt="Image" src="https://github.com/user-attachments/assets/af43d7e2-8d3c-41af-8f6f-e87d59b3d6d7" /> <img width="929" height="379" alt="Image" src="https://github.com/user-attachments/assets/2223a020-07f8-4597-8e48-936523a665b0" /> **Where are you hosting Actual?** Windows Server bare metal **What browsers are you seeing the problem on?** Firefox, Chrome, native macOS app **Operating System** Windows 10, 11, macOS
GiteaMirror commented 2026-02-28 20:09:11 -06:00
Author
Owner
Copy Link
Copy Source

@youngcw commented on GitHub (Dec 4, 2025):

@CrimsonFlash This is expected. If you post a schedule outside of its +-3 day match window you have to skip the date manually.

@youngcw commented on GitHub (Dec 4, 2025): @CrimsonFlash This is expected. If you post a schedule outside of its +-3 day match window you have to skip the date manually.
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
tech-support
theme
transaction import
transaction reconciliation
transactions
translations
upstream
user interface
✅ approved
wontfix
No labels bug regression schedules
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
GiteaMirror ninjasurge (Kaehlen Rog)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#2288