github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-03-09 11:42:54 -05:00
Code Issues 250 Packages Projects Releases 53 Wiki Activity

[Bug]: Entering a scheduled transaction today does not launch the automatic rule associated to it #2121

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

Originally created by @radtriste on GitHub (May 12, 2025).

Verified issue does not already exist?

  • I have searched and found no existing issue

What happened?

Since https://github.com/actualbudget/actual/issues/4705, the automatic rule when posting a transaction today is not done anymore.
When I post a transaction today, for example, my automatic category rule is not applied and I ended up with an uncategorized transaction.

How can we reproduce the issue?

Post transaction today on a different date from what it is planned

Where are you hosting Actual?

Docker

What browsers are you seeing the problem on?

Chrome

Operating System

Linux

Originally created by @radtriste on GitHub (May 12, 2025). ### Verified issue does not already exist? - [x] I have searched and found no existing issue ### What happened? Since https://github.com/actualbudget/actual/issues/4705, the automatic rule when posting a transaction today is not done anymore. When I post a transaction today, for example, my automatic category rule is not applied and I ended up with an `uncategorized` transaction. ### How can we reproduce the issue? `Post transaction today` on a different date from what it is planned ### Where are you hosting Actual? Docker ### What browsers are you seeing the problem on? Chrome ### Operating System Linux
GiteaMirror added the bugschedules labels 2026-02-28 20:03:54 -06:00
GiteaMirror commented 2026-02-28 20:03:55 -06:00
Author
Owner
Copy Link

@Bhautik2902 commented on GitHub (May 14, 2025):

I am not able to recreate the issue.

How am I trying?
Created a scheduled transaction for a future date. (With and without repeat)
Rule: when the Payee is "XYZ", put it into category "ABC".
Status: working as expected.

Can you please elaborate on where you are facing the issue?

@Bhautik2902 commented on GitHub (May 14, 2025): I am not able to recreate the issue. How am I trying? Created a scheduled transaction for a future date. (With and without repeat) Rule: when the Payee is "XYZ", put it into category "ABC". Status: working as expected. Can you please elaborate on where you are facing the issue?
GiteaMirror commented 2026-02-28 20:03:55 -06:00
Author
Owner
Copy Link

@DavidHeiniluoma commented on GitHub (May 22, 2025):

@Bhautik2902 The issue is when you have edited the auto-generated schedule rule (that has conditions on payee/date/amount) to add additional actions. Since posting the transaction early no longer matches the date in the rule, it does not trigger that rule that would link it to the schedule (and perform any other actions if they've been added to the rule)

Image

For example, this rule. Before the last release, if I chose "post transaction today" it would apply all the actions in the rule - it would remove the upcoming scheduled transaction from the "upcoming" section of the account register and it would apply the categorization rule. Since the latest release, it does neither - the June 15 upcoming transaction remains in the upcoming transactions section (in addition to the one added with today's date) and the newly added transaction does not have a category applied

Image

@DavidHeiniluoma commented on GitHub (May 22, 2025): @Bhautik2902 The issue is when you have edited the auto-generated schedule rule (that has conditions on payee/date/amount) to add additional actions. Since posting the transaction early no longer matches the date in the rule, it does not trigger that rule that would link it to the schedule (and perform any other actions if they've been added to the rule) ![Image](https://github.com/user-attachments/assets/6a8bf25c-bb07-455d-af55-e8ff08837b80) For example, this rule. Before the last release, if I chose "post transaction today" it would apply all the actions in the rule - it would remove the upcoming scheduled transaction from the "upcoming" section of the account register and it would apply the categorization rule. Since the latest release, it does neither - the June 15 upcoming transaction remains in the upcoming transactions section (in addition to the one added with today's date) and the newly added transaction does not have a category applied ![Image](https://github.com/user-attachments/assets/9e7a1852-c5e4-49cb-853b-b7110e568c43)
GiteaMirror commented 2026-02-28 20:03:56 -06:00
Author
Owner
Copy Link

@radtriste commented on GitHub (Jun 2, 2025):

As commented on https://github.com/actualbudget/actual/issues/4705#issuecomment-2929572416, I will try to fix this by having both options.

@MatissJanis @Bhautik2902 @DavidHeiniluoma Are you ok with that ?

@radtriste commented on GitHub (Jun 2, 2025): As commented on https://github.com/actualbudget/actual/issues/4705#issuecomment-2929572416, I will try to fix this by having both options. @MatissJanis @Bhautik2902 @DavidHeiniluoma Are you ok with that ?
GiteaMirror commented 2026-02-28 20:03:56 -06:00
Author
Owner
Copy Link

@Mansarde commented on GitHub (Jun 2, 2025):

I ran into this same issue and have some additional info on when exactly this happens and when not:

  • Due date of scheduled TX > 2 days in the future, then TX in linked rule is ignored.
  • Due date of scheduled TX <= 2 days in the future, then TX in linked rule is posted.

Here's a video that demonstrates this:
(NOTE: In the video I incorrectly wrote MAY in all the notes, but it's actually JUNE)

https://github.com/user-attachments/assets/9a4e9de1-adf0-4e76-b296-5c3dc377902a

EDIT:
In the last message in the video I say Even though that rule's TX doesn't have a date set..
With that I mean that the linked TX in the rule doesn't have a date set, but only the rule itself has.
And that date is always automatically adjusted whenever the schedule's date changes.
So what I wanted to say with that message in the video is that there is no fixed date in the prepared TX that would clash with the schedules' / rule's date.

@Mansarde commented on GitHub (Jun 2, 2025): I ran into this same issue and have some additional info on when exactly this happens and when not: - Due date of scheduled TX > 2 days in the future, then TX in linked rule is ignored. - Due date of scheduled TX <= 2 days in the future, then TX in linked rule is posted. Here's a video that demonstrates this: (NOTE: In the video I incorrectly wrote `MAY` in all the notes, but it's actually `JUNE`) https://github.com/user-attachments/assets/9a4e9de1-adf0-4e76-b296-5c3dc377902a EDIT: In the last message in the video I say `Even though that rule's TX doesn't have a date set.`. With that I mean that the linked TX in the rule doesn't have a date set, but only the rule itself has. And that date is always automatically adjusted whenever the schedule's date changes. So what I wanted to say with that message in the video is that there is no fixed date in the prepared TX that would clash with the schedules' / rule's date.
GiteaMirror commented 2026-02-28 20:03:56 -06:00
Author
Owner
Copy Link

@Bhautik2902 commented on GitHub (Jun 2, 2025):

@radtriste, while working on this, please take a moment to review this comment, if you haven’t already. I believe it’s important that this fix not only resolves the current issues but also lays a foundation for easily addressing any related issues that may arise in the future.

@Bhautik2902 commented on GitHub (Jun 2, 2025): @radtriste, while working on this, please take a moment to review [this comment](https://github.com/actualbudget/actual/pull/4719#issuecomment-2913552968), if you haven’t already. I believe it’s important that this fix not only resolves the current issues but also lays a foundation for easily addressing any related issues that may arise in the future.
GiteaMirror commented 2026-02-28 20:03:58 -06:00
Author
Owner
Copy Link

@SonicJoe commented on GitHub (Jun 12, 2025):

I did come up with a workaround for anyone else hitting this issue. I figured I'd share in case anyone needs it:

  1. Post transaction from the schedule
  2. Unlink the transaction from the schedule
  3. Change the date of the transaction to be the normally scheduled date
  4. Select the transaction (the check box to the left) and select "Run Rules" from the transaction menu in the upper right
  5. This should re-associate it to the schedule and apply all the splits
  6. Change the date back to the actual posted date
@SonicJoe commented on GitHub (Jun 12, 2025): I did come up with a workaround for anyone else hitting this issue. I figured I'd share in case anyone needs it: 1. Post transaction from the schedule 2. Unlink the transaction from the schedule 3. Change the date of the transaction to be the normally scheduled date 4. Select the transaction (the check box to the left) and select "Run Rules" from the transaction menu in the upper right 5. This should re-associate it to the schedule and apply all the splits 6. Change the date back to the actual posted date
GiteaMirror commented 2026-02-28 20:03:58 -06:00
Author
Owner
Copy Link

@Mansarde commented on GitHub (Jun 12, 2025):

I did come up with a workaround for anyone else hitting this issue. I figured I'd share in case anyone needs it:

  1. Post transaction from the schedule
  2. Unlink the transaction from the schedule
  3. Change the date of the transaction to be the normally scheduled date
  4. Select the transaction (the check box to the left) and select "Run Rules" from the transaction menu in the upper right
  5. This should re-associate it to the schedule and apply all the splits
  6. Change the date back to the actual posted date

You could also temporarily set the schedule's date to today before posting it.
That should save you a few steps and only requires you to remember its original date.
I.e.:

  1. Change the schedule's date to today (but memorize what it was before)
  2. Post it
  3. Change the schedule's date to the appropriate next date, based on what it was in step 1 (before you changed it to today)
@Mansarde commented on GitHub (Jun 12, 2025): > I did come up with a workaround for anyone else hitting this issue. I figured I'd share in case anyone needs it: > > 1. Post transaction from the schedule > 2. Unlink the transaction from the schedule > 3. Change the date of the transaction to be the normally scheduled date > 4. Select the transaction (the check box to the left) and select "Run Rules" from the transaction menu in the upper right > 5. This should re-associate it to the schedule and apply all the splits > 6. Change the date back to the actual posted date You could also temporarily set the schedule's date to today before posting it. That should save you a few steps and only requires you to remember its original date. I.e.: 1. Change the schedule's date to today (but memorize what it was before) 2. Post it 3. Change the schedule's date to the appropriate next date, based on what it was in step 1 (before you changed it to today)
GiteaMirror commented 2026-02-28 20:03:58 -06:00
Author
Owner
Copy Link

@Defy3738 commented on GitHub (Jun 26, 2025):

As commented on #4705 (comment), I will try to fix this by having both options.

@radtriste Can I suggest that instead of just those options, there be another to just pretend that the transaction is posted as scheduled (even if the schedule was supposed to be on January 1 but instead the user logs in on January 10 for example)? The reason is to not make managing the budget a daily chore. For example, one can take a few minutes over the weekend to process any "missed" schedules by referring back to receipts/statements/etc instead of having to do it on the schedule date itself.

I realize there is option to add the transaction automatically, but that might not be applicable in all situations or cause clutter with many schedules running. Anyways, thanks for your contributions.

@Defy3738 commented on GitHub (Jun 26, 2025): > As commented on [#4705 (comment)](https://github.com/actualbudget/actual/issues/4705#issuecomment-2929572416), I will try to fix this by having both options. @radtriste Can I suggest that instead of just those options, there be another to just pretend that the transaction is posted as scheduled (even if the schedule was supposed to be on January 1 but instead the user logs in on January 10 for example)? The reason is to not make managing the budget a daily chore. For example, one can take a few minutes over the weekend to process any "missed" schedules by referring back to receipts/statements/etc instead of having to do it on the schedule date itself. I realize there is option to add the transaction automatically, but that might not be applicable in all situations or cause clutter with many schedules running. Anyways, thanks for your contributions.
GiteaMirror commented 2026-02-28 20:03:58 -06:00
Author
Owner
Copy Link

@radtriste commented on GitHub (Aug 8, 2025):

Thank to @matt-fidd, this should would happen only on Post transaction today. But that is more then a way how the rule are detecting the transactions and this could be quite complex...
Do we want to keep this issue ?

@radtriste commented on GitHub (Aug 8, 2025): Thank to @matt-fidd, this should would happen only on `Post transaction today`. But that is more then a way how the rule are detecting the transactions and this could be quite complex... Do we want to keep this issue ?
GiteaMirror commented 2026-02-28 20:03:58 -06:00
Author
Owner
Copy Link

@matt-fidd commented on GitHub (Nov 4, 2025):

Pretty sure this has been fixed in https://github.com/actualbudget/actual/pull/5870

@matt-fidd commented on GitHub (Nov 4, 2025): Pretty sure this has been fixed in https://github.com/actualbudget/actual/pull/5870
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 bug schedules
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#2121
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?