1

We have ended up with about 30 recurring payment subscriptions in Civicrm that are either not connected any longer to their corresponding ARB in Auth.net, or they are no longer connected to to the membership they originally belonged to. (Because someone has cancelled auto-renew on the membership without attending to the recurring payment.)

So, my question: How can we edit Recurring payment subscription statuses when they have become dysfunctional in relation to Auth.net or to their original membership?

The best way I can think of would be to go into the database and change the relevant recurring payment subscriptions' contribution_status_id to whatever is appropriate. Most of the time this will be the status id for cancelled.

Will I get away with this? Remember, the subscription is already dysfunctional. I'm aware that if I changed this on a functioning subscription havoc might occur.

One thing that may be relevant... as I mentioned above, there are situations in which we have a functioning ARB in Auth.net, a corresponding and functioning Recurring Payment subscription in Civi, but which is no longer linked to the membership that created it, cos that membership is no longer in auto-renew state. So Auth.net will be pinging this Recurring payment subscription in Civi... the money just won't be getting allocated anywhere.

Would that be a problem?

I'd like to be able to set these subscriptions' statuses to 'cancelled' even though they're active, since they no longer relate to a membership (we then report on them manually).

Or is there a better way to accomplish all this? Thanks for your help!

2

More frequently than not I find myself tweaking records in civicrm_contribution_recur precisely for the reasons you mention.

You will need to be sure, however, to account for any amounts not collected and perhaps create new recurring contributions or pledges so that those amounts are not entirely lost. Depending on how payments were recorded after the subscriptions became dysfunctional, this might be a lengthy task.

In the case of dysfunctional subscriptions, updating the the contribution_status_id to whatever is appropriate should not impact anything else.

Regarding recurring contributions associated with memberships - contributions per force must have a financial type, this would be the financial type used to create the subscription, so there should never be a case where money doesn't get allocated somewhere, there would indeed be a problem on reporting financials if this were not the case - could you clarify further?

Hope this helps, Tamar

  • Thanks Tamar, this is really helpful. Regarding your last paragraph on financial type: For complex reasons to do with how we've implemented a free trial period with Authorize.net and memberships - amongst other things - we need to report on recurring payment subscriptions to get a real indication of who's paying for memberships and who's not. So getting the status of these subscriptions right is our prime mission here. That shouldn't affect the financial type of any actual contributions. So unless I'm missing something that shouldn't be a concern. But perhaps I am missing something! – Andyg8 Sep 27 '16 at 19:38
  • Nope, doesn't sound like you are missing something - our clients don't maintain membership financials, they maintain memberships separately from contributions - 9 out of 10 times it will be the financial information that will be correct (If you have proper reconciliation processes in place) - in your case, it sounds as if you are reporting memberships on the financial side (i.e. by financial type) - I think, unless I'm missing something :-). – Tamar Meir - Cividesk Sep 27 '16 at 19:47
  • Tamar, thanks for that! I agree with your thoughts, and I don't think you're missing anything either... Thanks so much for your help, and good luck. – Andyg8 Sep 28 '16 at 13:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.