Answers.Body: <p>CiviCRM has a notion of recurring contributions that is slightly more than just repeated transactions with the same information. Users can set up a series of contributions on a monthly or annual basis (or actually daily or weekly) that will charge an online payment processor appropriately. There is a separate table for storing the information about the recurrence, civicrm_contribution_recur, which is accessible via the API. Note that you can connect contributions to the appropriate record in this table by setting civicrm_contribution.contribution_recur_id.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-10-29T00:38:02.317Z
Answers.Text: I'll add to this and say that (almost) all payment processors implement repeating contributions in a way that makes them virtually impossible to move to a new system.  E.g. PayPal and Authorize.net send a specially formatted notification to a system when a repeating charge is processed.  Since the format of the notification changes by system, it's extremely difficult to move repeating contributions between two systems.
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-10-28T20:57:30.317Z
Answers.LastActivityDate: 2016-10-28T20:57:30.317Z
Answers.UserDisplayName: Joe Murray
Answers.Body: <p>Assuming you're just importing old data for reference, then a simple solution would be to introduce a custom financial type 'legacy recurring' or some such thing and assign that financial type to all the recurring contributions that you import. CiviCRM won't consider them 'recurring' by default in it's reports, but you can create your own to generate the information you want. Most of the functionality from setting them up as CiviCRM recurring contributions might be misleading anyway.</p>
  
  <p>As Jon notes, you'll need a separate strategy for actually migrating over those recurring contribution schedules in a way that will continue working, which will depend on your payment processor.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-11-01T18:12:53.447Z
Answers.LastActivityDate: 2016-11-01T18:12:53.447Z
Answers.UserDisplayName: Alan Dixon
Body: <p>We are new to CiviCRM and have just started importing data and running checks. We have imported the last five years of our donor contribution information and all of the data is correct in the BOOKKEEPING TRANSACTIONS REPORT but when running a REPEAT CONTRIBUTIONS REPORT the totals don't match even though the listed transactions and totals match the BOOKKEEPING TRANSACTIONS and our imported csv file. All of the filters and dates are identical. We thought this might have to do with merged or deleted records? We did permanently delete records that included contributions was this incorrect?</p>
  
  <p>Any hints are appreciated - Thank You, Kim</p>
  
Tags: <civireport>
Title: Repeat Contributions Report - Where Is Data Pulling From?
ThreadText: # Repeat Contributions Report - Where Is Data Pulling From?
  
  (Asked by: username_0 on 2016-10-28)
  
  We are new to CiviCRM and have just started importing data and running checks. We have imported the last five years of our donor contribution information and all of the data is correct in the BOOKKEEPING TRANSACTIONS REPORT but when running a REPEAT CONTRIBUTIONS REPORT the totals don't match even though the listed transactions and totals match the BOOKKEEPING TRANSACTIONS and our imported csv file. All of the filters and dates are identical. We thought this might have to do with merged or deleted records? We did permanently delete records that included contributions was this incorrect?
  
  Any hints are appreciated - Thank You, Kim
  
  **Tags:** civireport
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2016-10-28. Score: 4
  
  CiviCRM has a notion of recurring contributions that is slightly more than just repeated transactions with the same information. Users can set up a series of contributions on a monthly or annual basis (or actually daily or weekly) that will charge an online payment processor appropriately. There is a separate table for storing the information about the recurrence, civicrm\_contribution\_recur, which is accessible via the API. Note that you can connect contributions to the appropriate record in this table by setting civicrm\_contribution.contribution\_recur\_id.
  
  > **Comments:**
  > **username_2**: I'll add to this and say that (almost) all payment processors implement repeating contributions in a way that makes them virtually impossible to move to a new system.  E.g. PayPal and Authorize.net send a specially formatted notification to a system when a repeating charge is processed.  Since the format of the notification changes by system, it's extremely difficult to move repeating contributions between two systems.  
  
  ---
  
  ### Answer by username_3 on 2016-11-01. Score: 2
  
  Assuming you're just importing old data for reference, then a simple solution would be to introduce a custom financial type 'legacy recurring' or some such thing and assign that financial type to all the recurring contributions that you import. CiviCRM won't consider them 'recurring' by default in it's reports, but you can create your own to generate the information you want. Most of the functionality from setting them up as CiviCRM recurring contributions might be misleading anyway.
  
  As Jon notes, you'll need a separate strategy for actually migrating over those recurring contribution schedules in a way that will continue working, which will depend on your payment processor.
  
  
  ---
  
  