Thanks @AMJohnson for surfacing this:
example: cid=41193575
Looking at annual recurrings created that day, most of them had the right month for the next_sched_date but ~50 created between 8-9pm have the next month
https://civicrm.wikimedia.org/civicrm/admin/search#/edit/7180
The issue here is that the contributions were added to CiviCRM on Sept 25, even though they actually took place on Aug 14. Our code (getLastTriggerDate) is written for monthly donations and doesn't consider that we might have an annual donation that happened more than a month in the past.
Longer term, we will need to think about if we want to use cycle_date for the date within the year for annual donations, e.g. 365 for Dec 31 (and then handle leap years to keep things on schedule) or add a check for when the actual last contribution took place and continue to use it as a date within the month. Would need to consider what happens when we switch from an annual to a monthly donation and we potentially have a cycle date that is out of range. Will also need to look into how this is handled by other CiviCRM payment processors for consistency.
In the meantime, I've fixed the next scheduled dates for all of the recurrings in the linked SK.
@Lars is this fixed? Are we safe to change donors from monthly to annual if they request it as a result of the annual receipt send, or are there any other blockers? Apologies if this has been shared on other threads, it's been busy and I've lost track.
@krobinson This is not a blocker for switching donors from monthly to annual. It's something we should deal with in the longer term, but it works as is for now (except in the specific case that we observed here, where the contributions were created in CiviCRM more than a month after they actually took place, which would not be the case for changing frequency). I don't know of any other blockers to switching recurring frequency.