CiviCRM Stack Exchange is a question and answer site for administrators and users of the CiviCRM Constituent Relationship Management software. It only takes a minute to sign up.
Sign up to join this community
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)
Here is a View (well a pair of them actually)
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.
