CiviCRM Community Forums (archive)

We have had a situation where we have had to import some recurring contribution profiles from one Civi DB to another and have had to change the contact ids some recurring contributions were assigned to due to data entry error.

In order to cope with this we have hacked our version of Paypal Pro.ipn so that both the contribution_recur id and the contribution_id are looked up from the invoice_id (which is a unique hash generated by Civi). The contact_id is looked up off the civicrm_contribution_recur.contact_id.

Although our situation is pretty unique I can think of 2 situations where having one unique field & flexibility on the others would make sense:

1) 2 contacts merged through deduping - the contact_id in the Paypal IPN would no longer be correct
2) organisation migrating to CiviCRM has already set up recurring payments. If Civi respected the invoice ID these could be migrated into CiviCRM (not straight forward but without contacting the donor / having the credit card to re-initiate it)


Index: CRM/Core/Payment/PayPalProIPN.php
===================================================================
--- CRM/Core/Payment/PayPalProIPN.php (revision 32660)
+++ CRM/Core/Payment/PayPalProIPN.php (working copy)
@@ -300,6 +300,56 @@
             $ids['related_contact']     = self::retrieve('relatedContactID' , 'Integer', 'GET', false );
             $ids['onbehalf_dupe_alert'] = self::retrieve('onBehalfDupeAlert', 'Integer', 'GET', false );
         }
+        /*
+         * Fuzion Hack to deal with changed recurring ids. This overrides the
+         * contributionRecur number set in the IPN by the one in the database against that invoice
+         * number. This needs to be preserved until ALL recurring contributions started in January 2011 have
+         * expired.
+         */
+    if ($ids['contributionRecur']){
+      $sql = " SELECT cr.id
+               FROM civicrm_contribution_recur cr
+           WHERE cr.invoice_id = %1";
+      $sqlParams = array( 1 => array( self::getValue('i', false ),      'String' ),
+                              );
+                              echo  self::getValue('i', false );
+            if ( $contributionRecurID = CRM_Core_DAO::singleValueQuery( $sql, $sqlParams ) ) {
+                $ids['contributionRecur'] = $contributionRecurID;
+            }
+           
+    }
+    if ($ids['contribution']){
+ $sql = " SELECT c.id
+          FROM civicrm_contribution c
+           WHERE c.invoice_id = %1";
+     echo  self::getValue('i', false );
+
+ $sqlParams = array( 1 => array( self::getValue('i', false ),      'String' ),
+                              );
+              
+            if ( $contributionID = CRM_Core_DAO::singleValueQuery( $sql, $sqlParams ) ) {
+                $ids['contribution'] = $contributionID;
+            }
+
+ }
+ //end hack for changed contribution IDs & recurring IDs
+ /*
+ *Fuzion hack to look up 'correct' contact ID for recurring contributions incorrectly recorded against wrong contact
+ *(extended to all as she is not alone)
+ *but re-assigned. Recommend this is maintained until all recurring contributions initiated in Feb 2011 are finished
+ */
+         if (!empty($ids['contributionRecur'] )){
+       $sql = " SELECT cr.contact_id
+               FROM civicrm_contribution_recur cr
+           WHERE cr.id = %1";
+      $sqlParams = array( 1 => array( $ids['contributionRecur'],      'String' ),
+                              );
+            if ( $contactID = CRM_Core_DAO::singleValueQuery( $sql, $sqlParams ) ) {
+                $ids['contact'] = $contactID ;
+            }
+           
+ }
+ //end fuzion hack
 
         if ( !$ids['membership'] && $ids['contributionRecur'] ) {
             $sql = "


Sounds good.

Yes we could stay w/ invoice id as this invoice id is going to same for recurring and related first contribution record.

So once we do load recurring id, first contribution id and valid contact id in $ids variable, our BaseIPN will take care of rest of the things.

For update contribution contact id w/ recurring contact id I do feel we might wanna validate across contact table and query might be like

    UPDATE   civicrm_contribution contribution
INNER JOIN   civicrm_contribution_recur recur ON ( recur.id = contribution.contribution_recur_id AND recur.contact_id != contribution.contact_id )
INNER JOIN   civicrm_contact contact ON ( contact.id = recur.contact_id AND contact.is_deleted = 0 )
       SET   contribution.contact_id = recur.contact_id;


thanks,

kiran