Answers.Body: <p>A similar report came up in the IRC channel - this looks a lot like <a href="https://issues.civicrm.org/jira/browse/CRM-18247" rel="nofollow">CRM-18247: Contribution receive date is incorrect/misformatted in email sent by API Contribution.sendconfirmation</a>.</p>
  
  <p>The <a href="https://github.com/civicrm/civicrm-core/pull/7980/commits/5bab7daf82c8005c92527fd8f3a76f0bb4f315a6" rel="nofollow">patch from that issue's PR</a> may solve the issue for you?</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-16T02:01:46.347Z
Answers.LastActivityDate: 2016-03-16T02:01:46.347Z
Answers.UserDisplayName: Chris Burgess
Answers.Body: <p>I don't think CRM-18247 is the culprit here.
  I believe for that version of CiviCRM, it would have been
  <a href="https://issues.civicrm.org/jira/browse/CRM-19094" rel="nofollow noreferrer">https://issues.civicrm.org/jira/browse/CRM-19094</a></p>
  
  <p>This bug was fixed but has re-emerged due to changes in ARB handling(4.7.7&lt;).
  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.
  <a href="https://gist.github.com/ginkgomzd/20d1c83fbdf8b698009eedb262b63de1" rel="nofollow noreferrer">https://gist.github.com/ginkgomzd/20d1c83fbdf8b698009eedb262b63de1</a></p>
  
  <p>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.</p>
  
  <p>Here is the change needed:
  <a href="https://github.com/ginkgomzd/civicrm-core/commit/d6719eb555d41da1fee034df3ac785ca491e5830" rel="nofollow noreferrer">https://github.com/ginkgomzd/civicrm-core/commit/d6719eb555d41da1fee034df3ac785ca491e5830</a>
  UPDATE: PR submitted: <a href="https://github.com/civicrm/civicrm-core/pull/9349" rel="nofollow noreferrer">https://github.com/civicrm/civicrm-core/pull/9349</a>
  and bug filed: CRM-19594</p>
  
  <p>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).</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-11-02T22:31:30.317Z
Answers.LastActivityDate: 2016-11-02T23:41:02.710Z
Answers.LastEditDate: 2016-11-02T23:41:02.710Z
Answers.UserDisplayName: ginkgoMZD
Body: <p>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 <em>sometimes</em> show the wrong dates and membership type. The correct membership dates and type are being stored in CiviCRM.</p>
  
  <p>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).</p>
  
  <p>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.</p>
  
  <p>The contact's membership page shows no other memberships. What might do this? How can I resolve it? </p>
  
  <p>The issue seems to affect memberships inconsistently about half the time.</p>
  
  <p>The issue only affects renewing members.</p>
  
  <p><a href="https://i.sstatic.net/Nl3WF.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Nl3WF.png" alt="enter image description here"></a></p>
  
  <p><a href="https://i.sstatic.net/VqvkO.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/VqvkO.png" alt="enter image description here"></a></p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-06T19:14:00.310Z
Comments.Text: 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.
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-04-05T13:28:25.533Z
Comments.Text: 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}
Comments.UserDisplayName: Terri C
Tags: <drupal><email><receipts>
Title: Wrong dates and type on membership email receipts
ThreadText: # Wrong dates and type on membership email receipts
  
  (Asked by: username_0 on 2016-03-05)
  
  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](https://i.sstatic.net/Nl3WF.png)](https://i.sstatic.net/Nl3WF.png)
  
  [![enter image description here](https://i.sstatic.net/VqvkO.png)](https://i.sstatic.net/VqvkO.png)
  
  **Tags:** drupal, email, receipts
  
  > **Comments:**
  > **username_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.  
  > **username_2**: 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}  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_3 on 2016-03-16. Score: 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](https://issues.civicrm.org/jira/browse/CRM-18247).
  
  The [patch from that issue's PR](https://github.com/civicrm/civicrm-core/pull/7980/commits/5bab7daf82c8005c92527fd8f3a76f0bb4f315a6) may solve the issue for you?
  
  
  ---
  
  ### Answer by username_4 on 2016-11-02. Score: 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).
  
  
  ---
  
  