Membership pay later: extra year added on contribution completion

[Sophie.SK]

Hi there,

One of our clients is having a problem that is very similar to issue #CRM-122210.

1. Create a membership type of: annual, fixed or rolling
2. Build a contribution page for that membership where payment is "pay later" by default
3. Submit the form to purchase a membership
4. Open the membership record to and edit the contribution, which is currently in "pending" status
5. Edit that record, add the contribution amount, select the payment method and update the status to "Complete"
6. The membership extends itself by an extra year

This also occurs when editing the contribution from the contribution tab, instead of starting from the membership record.

Our client follows the same steps and has the same problem, but is using Drupal 6.28 and Civi 3.4.7 rather than D7/4.2.7. Unfortunately that issue was closed as it couldn't be reproduced on the demo site.

Initially I couldn't replicate this problem and assumed that he was following the steps for a standard renewal (which adds an extra year as expected), but eventually I managed to replicate it and also came across the issue.

Any help is appreciated. I'll do my best to provide any extra information.

Many thanks!

[petednz]

I think i just hit a couple of these last week. Can you clarify your ref to 122210

I can't find in forum or jira.

[Sophie.SK]

Can you clarify your ref to 122210

D'oh - my mistake, I meant #12221 without the trailing zero. It's on Jira.

I emailed Simon West (the one who submitted that issue), and he has given some extra information:

It may have been solved when the membership prices were moved from being entered on the contribution form, to the membership type itself. I think that was the case; in the end, their membership structure was probably one of the most complex you can think of!

So I'll take a look into this and see if anything comes from it.

[Sophie.SK]

I've looked into this and it looks like their membership and contributions are separate - the membership is just attached to the contribution. I'm still "learning Civi", so I'm not sure if this is what Simon was referring to or if he means that there is no contribution form at all, just a membership.

[Sophie.SK]

Hi there,

Wondering if anyone got any further with this? I've looked a little further into this to no avail.

Thanks!

[Dave Greenberg]

Sophie - Can you see if you can replicate this on the public 4.3 demo please. If so, please file a new issue in the issue tracker with the exact sequence of steps that causes the misbehavior (include URLs for each step so we can be sure and follow along). Thx!

[Sophie.SK]

Hi Dave,
I'll replicate the steps as outlined in the first post.

1. Create a membership type of: annual, fixed or rolling.
http://drupal.demo.civicrm.org/civicrm/admin/member/membershipType?reset=1

2. Build a contribution page for that membership where payment is "pay later" by default
http://drupal.demo.civicrm.org/civicrm/contribute/transact?reset=1&id=4
Done this exactly as it's set up on the client's site; they have an option to add a magazine subscription when signup, which is why you can add extra amounts.
Our client also has some profiles set up - instead of "I will pay by cheque" they have "I will pay by direct debit". They collect the member's details, then process the direct debit manually by sending the details off to the bank themselves.

3. Submit the form to purchase a membership
see: http://drupal.demo.civicrm.org/civicrm/contact/view/contribution?reset=1&id=95&cid=202&action=view&context=contribution&selectedChild=contribute
See attachment 1.

4. Open the membership record to and edit the contribution, which is currently in "pending" status
See attachment 2. At this stage, our client uses the Status Override and manually sets the membership to "Current" so that they can use the site while payment is being processed, then save the record before going to the next step (after a couple of days).

5. Edit that record, add the contribution amount, select the payment method and update the status to "Complete"
See attachment 3.

6. The membership extends itself by an extra year
See attachment 4: top is the "Edit membership" screen; bottom is the Membership tab.


Whew, glad I managed to replicate that. :-) I was worried I wouldn't be able to.

I'll file an issue on Jira. Will there be any chance of back porting it to 3.4.7?

[Dave Greenberg]

Sophie - The 'extra year problem' is caused by the special steps your client is doing. By design Pending memberships do NOT have an end date - the end date is set when the payment is recorded. Manually overriding the Pending status and setting the end date to the 'expected' end date is what's causing the 'problem'. At that point, the system thinks this is a current membership which ends a year from now. Then when the payment is recorded the system sees that as a renewal and bumps the end date another year.

One solution is to not give the constituent permission to 'use the site' until the payment is recorded (this is how the workflow is designed to work). You might also be able to come up w/ some other work-arounds (manually set end date to today plus a few days only, for example, might work - at least they'd only get a few more days if things work as I expect them to). Could also look at some other temporary authentication into the site via role or ??

[Sophie.SK]

Hi Dave,

Argh! - that's so not what the client wanted to hear - but I understand thank you for the feedback.

Is it possible to have this documented somewhere (or, indeed, is it documented somewhere and I've just missed it), just for future reference?

As far as temporary authentication goes - I'll have to discuss with the client. I suspect that being a current member means they get discounts on conferences, etc., that they can't get a discount on if their membership is pending. I could be wrong, but this client does deal with a lot of conferences with discounts for members, so I'm extrapolating.

Again - thank you for the help! Much appreciated.

[Dave Greenberg]

Sophie - This behavior could potentially be documented in the User Guide in this chapter:
http://book.civicrm.org/user/current/membership/everyday-tasks/

If you're up for doing some edits (and even for working on general improvements to the book), details about how to edit the book are here:

http://civicrm.org/participate/documentation

Feel free to ping me back here, or chat w/ Michael McAndrew (michael @ civicrm dot org) if you need help getting started.