Adding a payment to a recurring contribution sequence should update the contribution_recur table

A customer is experiencing a recurring payments flow in which the contact is winding up without the next_sched_contribution_date being set. As the processor is IATS (& the flow is from back-office membership renewal ) it is essential that this date be set in order for consequent payments to be processed.

In looking at this it seems to me that calculating the effect of the recurring contribution record is something that should happen in core rather than have every different processor implement it.

The tricky thing about this is that there is a risk adding it to core will clash with whatever work around the processors are currently doing. However, on looking at IATS & eWay I can see it shouldn't matter as they load the details about the processor, call the transaction update and then update the recurring record (bypassing hooks) by an sql update to the contribution recur records using values calculated from the previously loaded data. Stripe bypasses all core functions from what I can tell.

I will log issues against those 3 processors & any other recurring ones I can think of.

My recommendation will be to add an IF to the code before handling recurring - ie

if (!method_exists('CRM_Contribute_BAO_ContributionRecur', 'updateOnNewPayment'))

We would need to keep that fn name for a few releases until they have been able to migrate over. However, since it makes sense for organisations that want recurring contributions to work in all flows to backport function presence is a better place to check than version