CiviCRM Community Forums (archive)

We have 2 customers who very much want to be able to use recurring contributions against pledges. I have a patch in place in BaseIPN (along with a tpl tweak) that seems to be working adequately for their needs but obviously they'd like it in core so just exploring what the spec would be

Basic implementation
1)   Expose ability to create a recurring against a pledge (via tpl tweak)
2)   In Base IPN look up the contribution id, see if it’s linked to a pledge OR another contribution attached to the recurring_contribution is linked to a pledge – if so
a.   If payment is not complete then update it
b.   If payment is complete then this is a subsequent payment & getOldestPayment (pending or in progress status) & update that

Above implementation works reasonably well in my use case as my users are pretty savvy but I presume for Core the following safeguards would be needed
1)   If a pledge has been linked with a recurring payment (ie. has a contribution with contribution_recur_id IS NOT NULL) then the ability to edit payment schedule should be disabled
2)   When creating a recurring payment against a pledge the number of recurring payments should be locked to the number of outstanding pledge payments & the instalment amount should be locked
3)   Note that recording a recurring payment with only a single instalment is a valid scenario as that is the only way Authorize.net (& others??) support future start dates

Patch I am using currently using

Index: CRM/Core/Payment/BaseIPN.php
===================================================================
--- CRM/Core/Payment/BaseIPN.php   (revision 37196)
+++ CRM/Core/Payment/BaseIPN.php   (working copy)
@@ -563,12 +563,23 @@
             require_once 'CRM/Core/BAO/FinancialTrxn.php';
             $trxn = CRM_Core_BAO_FinancialTrxn::create( $trxnParams );
         }
-       
         //update corresponding pledge payment record
         require_once 'CRM/Core/DAO.php';
         $returnProperties = array( 'id', 'pledge_id' );
-        if ( CRM_Core_DAO::commonRetrieveAll( 'CRM_Pledge_DAO_PledgePayment', 'contribution_id', $contribution->id,
-                                              $paymentDetails, $returnProperties ) ) {
+        require_once 'CRM/Contribute/DAO/Contribution.php';
+        $relatedContributions = new CRM_Contribute_DAO_Contribution( );
+        $relatedContributions->contribution_recur_id = $recurContrib->id ;
+        $relatedContributions->find(  ) ;
+        while($relatedContributions->fetch()){
+           $pledgeDetail = CRM_Core_DAO::commonRetrieveAll( 'CRM_Pledge_DAO_PledgePayment', 'contribution_id', $relatedContributions->id,
+                                              $paymentDetails, $returnProperties ) ;
+         }       
+        //update corresponding pledge payment record
+        require_once 'CRM/Core/DAO.php';
+        $returnProperties = array( 'id', 'pledge_id' );
+        if ( (is_array($pledgeDetail) || !empty($pledgeDetail['pledge_id'])) || CRM_Core_DAO::commonRetrieveAll( 'CRM_Pledge_DAO_PledgePayment', 'contribution_id', $contribution->id,
+                                              $paymentDetails, $returnProperties )
+             ) {
             $paymentIDs = array( );
             foreach ( $paymentDetails as $key => $value ) {
                 $paymentIDs[] = $value['id'];
@@ -597,8 +608,9 @@
         CRM_Core_Error::debug_log_message( "Contribution record updated successfully" );
         $transaction->commit( );
         
-        self::sendMail( $input, $ids, $objects, $values, $recur, false );
-
+        if(CRM_Utils_Array::value('is_email_receipt',$values)){
+          self::sendMail( $input, $ids, $objects, $values, $recur, false );
+          }
         CRM_Core_Error::debug_log_message( "Success: Database updated and mail sent" );
     }
     

NB - it's easy to do the UI stuff for this as a customisation but hard to 'get to' the BaseIPN code as it won't call hooks as Drupal isn't loaded. Would be good to get the BaseIPN support for linked pledges into 4.1 even if the UI relies on people 'enabling' it by tweaking their Contribution.tpl (until further debate has happened)

1) Pledges are pledges as far as our customers are concerned - commitments to pay an amount over a period of time. If they get a credit card then it's better than receiving cash but if the credit card fails on one or more payments that's the equivalent to a cheque not turning up.

Importantly the reporting of pledges needs to include all pledges, whether or not a credit card was received. Pledges work on the assumption that the pledge itself is the important thing. Recurring contributions don't place a lot of emphasis on that side of it (the recurring contribution itself isn't exposed).

Basically it's making the treatment of pledges with credit cards the same as pledges without. At some later point when accounting integration is in place they will also want the same treatment for all pledges in that integration

2) "Did you expose the recurring contribution block in the back-office Contribution form (e.g. contact/view/contribution?reset=1&action=add&cid=102&ppid=9&context=pledge&mode=live) - which is normally suppressed when that form is used to make a pledge payment.".   Yes - in theory there might actually be more than one sequence of recurring contributions against a single pledge &  potentially some cheques mixed in. (e.g. because the pledge goes beyond the expiry date). But I believe that each recurring contribution subscription
should only ever relate to one pledge.

3) As an aside, the only way in which Authorize.net supports future start dates for credit card payments is by creating a recurring contribution subscription with only one payment - one of our customers regularly offers to put the payment through in the future (e.g. after pay day). The same approach facilitates this