Answers.Body: <p>My research indicates that newly created memberships and recurring contributions are linking and updating perfectly. Only ones made with previous versions of CiviCRM and Webform_Civicrm are not functioning correctly, and this might have coincided with some problems with data we imported from a Paypal -> iATS transition. Without being able to nail down specifically why it's not working, I found a workaround -</p>
  
  <p>I'm using this excellent extension - <a href="https://github.com/adixon/ca.civicrm.contributionrecur" rel="nofollow noreferrer">https://github.com/adixon/ca.civicrm.contributionrecur</a>  which lets us do implicit membership renewals. For all memberships that are recurring under a certain ID # (the past ones), it's been enabled to run daily to link the recurring contribution to the membership and then extend the end date.</p>
  
  <p>It has also exposed a new way to potentially gain membership/donations and make our membership model even cooler!</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-09-11T00:12:19.210Z
Answers.LastActivityDate: 2019-09-11T00:12:19.210Z
Answers.UserDisplayName: Zachary
Answers.Body: <p>Payment Processors do not care what the monies are used for. Once the transaction is completed the payment processor’s job is done.</p>
  
  <p>You’ve either run into an issue with CiviCRM Core or with Webform CiviCRM. </p>
  
  <p>Issues with Memberships not renewing are (unfortunately) not uncommon. Membership renewals are complicated from a logic/code perspective as there are so many different Membership models already in core (rolling/fixed, statuses config). If Membership is important for your org consider an extension that handles the logic for you. Eg -> if Contribution is Completed -> add +1y to current Membership start (or end date) - whatever your rules are you have control.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-08-31T20:34:12.750Z
Answers.Text: Makes sense, I updated the description to make it more general. my experience is the core contribution pages work as expected for rolling memberships, but ones made via webform_civicrm do not, yet I can't find any difference in the db between the recurring/membership tables.
Answers.UserDisplayName: Zachary
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-09-01T04:05:30.133Z
Answers.Text: I found this, https://civicrm.stackexchange.com/questions/20014/membership-end-date-not-updated-for-autorenew-monthly?rq=1  could it be relevant? The native civicontribute auto-renewals in our system put the membership in "amount_level"  such as "Full membership - U.S." but with a little r before and after, whereas the webform_civicrm generated ones will state webform payment: etc. without the membership referenced.
Answers.UserDisplayName: Zachary
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-09-01T12:23:42.233Z
Answers.Text: Any differences in values in civicrm_membership_payment?
Answers.UserDisplayName: KarinG - Semper IT
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-09-01T19:25:20.310Z
Answers.Text: I don't see a row present for the contribution that just was made in civicrm_webform_payment, despite the membership having contribution_recur_id linked to the recurring profile. other than that, i don't see any differences in the two data sets (the ones made by civi, and webform)
Answers.UserDisplayName: Zachary
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-08-31T16:36:26.380Z
Answers.LastActivityDate: 2019-08-31T16:36:26.380Z
Answers.UserDisplayName: KarinG - Semper IT
Body: <p>When the iATS scheduler runs a recurring profile which is linked to a membership, the contribution is not being linked to the membership, and thus the membership end date does not increment. Ideas?</p>
  
  <p>Drupal / CiviCRM 5.x / iATS ext 1.6.2</p>
  
  <p>Update; 8/30 looking for ideas here: <a href="https://github.com/iATSPayments/com.iatspayments.civicrm/issues/217" rel="nofollow noreferrer">https://github.com/iATSPayments/com.iatspayments.civicrm/issues/217</a></p>
  
  <p>In this issue KarinG states: " iATS extension itself just takes care of the monies; we use repeattransaction API in 4.7 -> and the fact that the recurring series is attached to a Membership - that should update it."</p>
  
  <p>I think it might be due to an extension or configuration - will report back. Will check the logs.</p>
  
  <p>Second update: could be that I did not select auto-renew on the webform or the field during data-import: <a href="https://github.com/colemanw/webform_civicrm/pull/181" rel="nofollow noreferrer">https://github.com/colemanw/webform_civicrm/pull/181</a></p>
  
  <p>Third Update: After marking auto_renew = TRUE for the recurring profiles, which are linked to memberships, the scheduled job still does not attach the contribution to the membership or update the end date. </p>
  
  <p>Fourth Update: Updated Webform CiviCRM and created a new test webform, test membership, and set up an ongoing contribution for 1 day membership. Will see if it updates tomorrow and compare. Also, in civicrm_line_items the test submission/membership has entity_table = civicrm_membership whereas the former case which did not link to membership shows entity_table = civicrm_contribution</p>
  
  <p>Fifth Update: I made a new webform, test membership, and test record - and the membership does update now! I also have noticed the newly created one creates an activity record for membership renewal whereas the former one, which is not working, does not.  </p>
  
Tags: <webform-civicrm><iats>
Title: membership not updated with recurring contribution
ThreadText: # membership not updated with recurring contribution
  
  (Asked by: username_0 on 2019-08-29)
  
  When the iATS scheduler runs a recurring profile which is linked to a membership, the contribution is not being linked to the membership, and thus the membership end date does not increment. Ideas?
  
  Drupal / CiviCRM 5.x / iATS ext 1.6.2
  
  Update; 8/30 looking for ideas here: <https://github.com/iATSPayments/com.iatspayments.civicrm/issues/217>
  
  In this issue username_1 states: " iATS extension itself just takes care of the monies; we use repeattransaction API in 4.7 -> and the fact that the recurring series is attached to a Membership - that should update it."
  
  I think it might be due to an extension or configuration - will report back. Will check the logs.
  
  Second update: could be that I did not select auto-renew on the webform or the field during data-import: <https://github.com/colemanw/webform_civicrm/pull/181>
  
  Third Update: After marking auto\_renew = TRUE for the recurring profiles, which are linked to memberships, the scheduled job still does not attach the contribution to the membership or update the end date.
  
  Fourth Update: Updated Webform CiviCRM and created a new test webform, test membership, and set up an ongoing contribution for 1 day membership. Will see if it updates tomorrow and compare. Also, in civicrm\_line\_items the test submission/membership has entity\_table = civicrm\_membership whereas the former case which did not link to membership shows entity\_table = civicrm\_contribution
  
  Fifth Update: I made a new webform, test membership, and test record - and the membership does update now! I also have noticed the newly created one creates an activity record for membership renewal whereas the former one, which is not working, does not.
  
  **Tags:** webform-civicrm, iats
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2019-09-11. Score: 1 | Accepted answer
  
  My research indicates that newly created memberships and recurring contributions are linking and updating perfectly. Only ones made with previous versions of CiviCRM and Webform\_Civicrm are not functioning correctly, and this might have coincided with some problems with data we imported from a Paypal -> iATS transition. Without being able to nail down specifically why it's not working, I found a workaround -
  
  I'm using this excellent extension - <https://github.com/adixon/ca.civicrm.contributionrecur> which lets us do implicit membership renewals. For all memberships that are recurring under a certain ID # (the past ones), it's been enabled to run daily to link the recurring contribution to the membership and then extend the end date.
  
  It has also exposed a new way to potentially gain membership/donations and make our membership model even cooler!
  
  
  ---
  
  ### Answer by username_1 on 2019-08-31. Score: 2
  
  Payment Processors do not care what the monies are used for. Once the transaction is completed the payment processor’s job is done.
  
  You’ve either run into an issue with CiviCRM Core or with Webform CiviCRM.
  
  Issues with Memberships not renewing are (unfortunately) not uncommon. Membership renewals are complicated from a logic/code perspective as there are so many different Membership models already in core (rolling/fixed, statuses config). If Membership is important for your org consider an extension that handles the logic for you. Eg -> if Contribution is Completed -> add +1y to current Membership start (or end date) - whatever your rules are you have control.
  
  > **Comments:**
  > **username_0**: Makes sense, I updated the description to make it more general. my experience is the core contribution pages work as expected for rolling memberships, but ones made via webform_civicrm do not, yet I can't find any difference in the db between the recurring/membership tables.  
  > **username_0**: I found this, https://civicrm.stackexchange.com/questions/20014/membership-end-date-not-updated-for-autorenew-monthly?rq=1  could it be relevant? The native civicontribute auto-renewals in our system put the membership in "amount_level"  such as "Full membership - U.S." but with a little r before and after, whereas the webform_civicrm generated ones will state webform payment: etc. without the membership referenced.  
  > **username_1**: Any differences in values in civicrm_membership_payment?  
  > **username_0**: I don't see a row present for the contribution that just was made in civicrm_webform_payment, despite the membership having contribution_recur_id linked to the recurring profile. other than that, i don't see any differences in the two data sets (the ones made by civi, and webform)  
  
  ---
  
  