You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I figure a strange behavior, really hard to catch.
On an installation using many payment processors, the next_sched_contribution_date on contribution_recur is set with SEPA settings, even if it's not SEPA payments. This behavior is very annoying.
Its seems that sepa_civicrm_post considers every recurring contribution as "eligible" without verification of its payment processor.
/** * CiviCRM POST event: make sure the next collection date * is adjusted according to the change */functionsepa_civicrm_post($op, $objectName, $objectId, &$objectRef) {
if ($objectName == 'ContributionRecur' || $objectName == 'SepaMandate') {
if ($op == 'create' || $op == 'edit') {
if ($objectName == 'SepaMandate') {
CRM_Sepa_Logic_NextCollectionDate::processMandatePostEdit($op, $objectName, $objectId, $objectRef);
} else {
CRM_Sepa_Logic_NextCollectionDate::processRecurPostEdit($op, $objectName, $objectId, $objectRef);
}
}
}
}
Moreover, the mechanism updates the next_sched_contribution_date only if it is empty, but based on params sent to the civicrm_pre hook, which is not relevant in case of the update of partial data.
Is my assumption correct?
In that case, I suggest t:
Check the if the payment_processor_id is associated to SEPA
Check the value of next_sched_contribution_date in both self::$currently_edited_recurring_contribution_params and $objectRef
The text was updated successfully, but these errors were encountered:
I figure a strange behavior, really hard to catch.
On an installation using many payment processors, the
next_sched_contribution_date
on contribution_recur is set with SEPA settings, even if it's not SEPA payments. This behavior is very annoying.Its seems that sepa_civicrm_post considers every recurring contribution as "eligible" without verification of its payment processor.
Moreover, the mechanism updates the
next_sched_contribution_date
only if it is empty, but based on params sent to thecivicrm_pre
hook, which is not relevant in case of the update of partial data.Is my assumption correct?
In that case, I suggest t:
payment_processor_id
is associated to SEPAnext_sched_contribution_date
in bothself::$currently_edited_recurring_contribution_params
and$objectRef
The text was updated successfully, but these errors were encountered: