Answers.Body: <p><a href="https://www.fuzion.co.nz/blogs/need-know-latest-payment-recurring-contribution-help-identify-problems" rel="nofollow noreferrer">Here</a> is a View (well a pair of them actually)</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-07-22T23:27:53.487Z
Answers.LastActivityDate: 2018-07-22T23:27:53.487Z
Answers.UserDisplayName: petednz - fuzion
Answers.Body: <p>I would think the answer might be somewhat payment-processor dependent, i.e. how it handles failures. With iATS, we record failures as failed contributions, but an IPN-oriented/processor-managed-schedule would not work the same. Similarly, the next-scheduled-contribution-date field and the number of consecutive failures fields are also potentially useful, if used by the processor.</p>
  
  <p>When those fields are used, then it's relatively simple to generate all kinds of reports, e.g. a monthly report of all the currently failing recurring cc payments.</p>
  
  <p>Even if you're not using those fields, you could generate a report of all contacts with an active recurring contribution for which there is no contribution in the past month, but that's not entirely reliable.</p>
  
  <p>In general, handling failing recurring contributions is tricky because I often see abandoned recurring contribution series beside new ones and you don't want to harangue an existing monthly donor if they have an old expired one sitting there ...</p>
  
  <p>The email-to-an-administrator is a simple feature that we implemented in the iATS recurring-payment job, it could get bundled into the corresponding api job if you think it's a generally useful feature. On the other hand, my experience of trying to control emails sent by CiviCRM core relating to recurring emails has been spotty, so I'm not quite convinced that's a good route ...</p>
  
  <p>My last point would be to encourage us to express these issues as stories/use-cases, because there are different times you'd want to keep track of failures and how you want to do it might depend, e.g. if it's an automated feature vs. an admin followup.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-07-24T15:20:29.520Z
Answers.LastActivityDate: 2018-07-24T15:20:29.520Z
Answers.UserDisplayName: Alan Dixon
Body: <p>Anyone have a good recipe or a report for finding folk who had a recurring payment due in say the last 2 weeks but for whom no contribution was received? </p>
  
  <p>I can see ways to do this with Smart Groups and Include/Exclude or via Drupal Views - but thought there might already be a better solution - looks like iATS have an email notification (nice)</p>
  
Tags: <recurring-contributions><reports>
Title: How can I easily identify recurring contributions that failed to be recorded or failed to occur
ThreadText: # How can I easily identify recurring contributions that failed to be recorded or failed to occur
  
  (Asked by: username_0 on 2018-07-22)
  
  Anyone have a good recipe or a report for finding folk who had a recurring payment due in say the last 2 weeks but for whom no contribution was received?
  
  I can see ways to do this with Smart Groups and Include/Exclude or via Drupal Views - but thought there might already be a better solution - looks like iATS have an email notification (nice)
  
  **Tags:** recurring-contributions, reports
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2018-07-22. Score: 2
  
  [Here](https://www.fuzion.co.nz/blogs/need-know-latest-payment-recurring-contribution-help-identify-problems) is a View (well a pair of them actually)
  
  
  ---
  
  ### Answer by username_1 on 2018-07-24. Score: 0
  
  I would think the answer might be somewhat payment-processor dependent, i.e. how it handles failures. With iATS, we record failures as failed contributions, but an IPN-oriented/processor-managed-schedule would not work the same. Similarly, the next-scheduled-contribution-date field and the number of consecutive failures fields are also potentially useful, if used by the processor.
  
  When those fields are used, then it's relatively simple to generate all kinds of reports, e.g. a monthly report of all the currently failing recurring cc payments.
  
  Even if you're not using those fields, you could generate a report of all contacts with an active recurring contribution for which there is no contribution in the past month, but that's not entirely reliable.
  
  In general, handling failing recurring contributions is tricky because I often see abandoned recurring contribution series beside new ones and you don't want to harangue an existing monthly donor if they have an old expired one sitting there ...
  
  The email-to-an-administrator is a simple feature that we implemented in the iATS recurring-payment job, it could get bundled into the corresponding api job if you think it's a generally useful feature. On the other hand, my experience of trying to control emails sent by CiviCRM core relating to recurring emails has been spotty, so I'm not quite convinced that's a good route ...
  
  My last point would be to encourage us to express these issues as stories/use-cases, because there are different times you'd want to keep track of failures and how you want to do it might depend, e.g. if it's an automated feature vs. an admin followup.
  
  
  ---
  
  