When submitting a direct debit webform and the creation of upfront contributions starts, it results in calling membershipextras_calculateContributionReceiveDate hook which results in calling CRM_MembershipExtras_Utils_InstalmentSchedule::getPaymentPlanSchedule method that is used to determine the payment plan schedule and then decides if the direct debit dates calculation logic should be performed or not (since it is only done on monthly payment plans), but because it depends on reading the payment schedule value from the $_REQUEST variable which is only set if the request is coming from the admin form submission, the method end up returning NULL which prevents from running the direct debit date calculation logic on the payment plan, here I changed the method so it determine the schedule based on the payment plan frequency information stored in the database (frequency unit, frequency interval and number of installments), which is guaranteed to be set at both admin form and webforms.
Before
The receive dates starting from the 2nd (direct debit) contribution onward are wrong.
this is how it is after webform submission, the 2nd contribution in this example starts at 23 of November
Though according to the current configuration, the 2nd installment should start at the same date as the first contribution
here is how it will look like (correctly) if it was submitted from admin webform
After
The receive dates starting from the 2nd (direct debit) contribution onward are correct.
Side notes
I also renamed isPaymentPlanWithSchedule method to isPaymentPlanPayment given that all payment plans should have schedule information if they are submitted from the admin form so it does not make sense to check if the schedule parameter is there or not.
Overview
When submitting a direct debit webform and the creation of upfront contributions starts, it results in calling membershipextras_calculateContributionReceiveDate hook which results in calling CRM_MembershipExtras_Utils_InstalmentSchedule::getPaymentPlanSchedule method that is used to determine the payment plan schedule and then decides if the direct debit dates calculation logic should be performed or not (since it is only done on monthly payment plans), but because it depends on reading the payment schedule value from the $_REQUEST variable which is only set if the request is coming from the admin form submission, the method end up returning NULL which prevents from running the direct debit date calculation logic on the payment plan, here I changed the method so it determine the schedule based on the payment plan frequency information stored in the database (frequency unit, frequency interval and number of installments), which is guaranteed to be set at both admin form and webforms.
Before
The receive dates starting from the 2nd (direct debit) contribution onward are wrong.
this is how it is after webform submission, the 2nd contribution in this example starts at 23 of November
Though according to the current configuration, the 2nd installment should start at the same date as the first contribution
here is how it will look like (correctly) if it was submitted from admin webform
After
The receive dates starting from the 2nd (direct debit) contribution onward are correct.
Side notes
I also renamed isPaymentPlanWithSchedule method to isPaymentPlanPayment given that all payment plans should have schedule information if they are submitted from the admin form so it does not make sense to check if the schedule parameter is there or not.