2

We recently set up a new CiviCRM install (Drupal 7, CiviCRM 4.7.3, hosted on Bluehost). Most everything is fine, but the email receipts sometimes show the wrong dates and membership type. The correct membership dates and type are being stored in CiviCRM.

Some contact and membership data has been imported previously. User H C renewed via the membership page, paid via PayPal Standard. Their membership shows correct since/start/stop dates (since July 30th 2008, start February 29th 2016, stop February 28th 2017).

The receipt emailed to the member shows incorrect dates though: membership start date October 1st 2011, membership end date October 1st 2012. It also says the membership type is Registered when it should actually say Senior.

The contact's membership page shows no other memberships. What might do this? How can I resolve it?

The issue seems to affect memberships inconsistently about half the time.

The issue only affects renewing members.

enter image description here

enter image description here

Improve this question
2
  • 1
    One quick thought in case something went screwy with the import, can you check in the db table civicrm_membership and filter to find any membership belonging to the above contact id - just to double check there is no other Membership lurking there.
    – petednz - fuzion ♦
    Mar 6, 2016 at 19:14
  • I have the same issue - the receipt has the wrong membership type. If it helps tracking the issue, it displays the first type listed in the database. Database shows member with correct type. Template code for html: <tr> <td {$labelStyle}> {ts}Membership Type{/ts} </td> <td {$valueStyle}> {$membership_name} </td> </tr> Code for plain text:<br /> {ts}Membership Type{/ts}: {$membership_name}
    – Terri C
    Apr 5, 2016 at 13:28

2 Answers 2

Reset to default
3

A similar report came up in the IRC channel - this looks a lot like CRM-18247: Contribution receive date is incorrect/misformatted in email sent by API Contribution.sendconfirmation.

The patch from that issue's PR may solve the issue for you?

Improve this answer
1

I don't think CRM-18247 is the culprit here. I believe for that version of CiviCRM, it would have been https://issues.civicrm.org/jira/browse/CRM-19094

This bug was fixed but has re-emerged due to changes in ARB handling(4.7.7<). The bug only presents when contribution ID's overlap with Membership ID's. The problem is quite serious, as Memberships will be renewed without payment, and the problem can very easily escape detection. In a newer incarnation I encountered, there were multiple memberships associated with one Contribution. This SQL can be used to find memberships in that situation. https://gist.github.com/ginkgomzd/20d1c83fbdf8b698009eedb262b63de1

However, without the recent changes to ARB, I don't know if the contribution would get associated with both the wrong and right membership. Instead, it may have only been associated with the wrong membership... in which case, Gnu help you.

Here is the change needed: https://github.com/ginkgomzd/civicrm-core/commit/d6719eb555d41da1fee034df3ac785ca491e5830 UPDATE: PR submitted: https://github.com/civicrm/civicrm-core/pull/9349 and bug filed: CRM-19594

I'm not 100% certain that this will not cause another bug to show up, but I found that this code has been around since before the migration away from Subversion, so there is some hope that this is outdated logic and this change will be inconsequential (only beneficial).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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