actual
actual copied to clipboard
Scheduled transactions don't handle 29th/30th/31st dates appropriately
Running v23.5.0, when I set up a monthly scheduled transaction starting 31/5 the current behaviour is to not schedule anything for June, because there is no 31st day in June.
I'm sure opinions will differ on whether the best option would be to schedule the transaction for 30/6 or for 1/7, I don't have an opinion on that as long as it gets scheduled somewhere. 🙂
Sorry, just realised I had the wrong tab open and have posted this on docs instead of actual-server. Closed this and will post it in the proper place when I have a minute.
As a workaround, you can set it to repeat on last day of the month:
I have always used the last day of the month option. In my experience, some payees will take it then and others on the 1st.
Only my view but I think the current option is adequate and probably the only reasonable solution.
I believe there is another issue live for the more thorny problem of payments due on a weekend?
Many thanks for moving this @j-f1
The last day of month option is useful and does solve the problem for the 31st - however there's still an issue with payments which should always be on the 29th or 30th, even if the month is longer, and only move forward if the month is shorter.
I haven't tried a weekend yet so won't comment on that topic 😅
Many thanks for moving this @j-f1
The last day of month option is useful and does solve the problem for the 31st - however there's still an issue with payments which should always be on the 29th or 30th, even if the month is longer, and only move forward if the month is shorter.
I haven't tried a weekend yet so won't comment on that topic 😅
An example would be Feb. If you have something going out on the 30th in January Feb would get ignored and March would pick up again.
The end of the month wouldn't work in the above situation as the 30th isn't the end of the month all the time as @EKCJ pointed out.
This seems like a bug.
The package that Actual uses to create the schedules, appears to implement the ICAL spec RFC5545 for date recurrences,
From some cursory googling, I dont think the spec can actually cope with this and thus neither does the package, i think its expected to simply return invalid dates.
We would have to define i think, our own behaviour of what we want actual to do with these invalid dates, (e.g. always just forward to the next real date) and apply some logic around the returned occurences.
No, an internal system does not need to be created. The ICalendar spec can absolutely handle the case of "last day of month" and "last workday of month" scenarios.
Also From the ICalendar spec definition of Recurrence Relation
The BYSETPOS rule part specifies a COMMA-separated list of values that corresponds to the nth occurrence within the set of recurrence instances specified by the rule. BYSETPOS operates on a set of recurrence instances in one interval of the recurrence rule. For example, in a WEEKLY rule, the interval would be one week A set of recurrence instances starts at the beginning of the interval defined by the FREQ rule part. Valid values are 1 to 366 or -366 to -1. It MUST only be used in conjunction with another BYxxx rule part. For example "the last work day of the month" could be represented as:
FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
I would suspect the last day of the month could then be specified as:
FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR,SA,SU;BYSETPOS=-1
So long as the rest of the RRULE does not specifically select a date such as the 29, 30, or 31st it will work. It should be implemented as a radio button or some form of either/or scenario.
EDIT: Validated online using rrule.js online demo
As I understood it, selecting a specific date is exactly what is wanted? While having it cope with out of bounds dates for certain months
Ok, I put my foot in my mouth back there, you're correct. I did manage to find this, which looks to be the exact same question.
https://stackoverflow.com/questions/35757778/rrule-for-repeating-monthly-on-the-31st-or-closest-day
It's supported by a newer addition called RSCALE, but not all RRULE libraries support it yet.