Answers.Body: <p>We set our memberships to and end date of 30th June then add a Grace period of 1 month to allow for collection of member fees. You can set grace periods and define the length of that period. Maybe this will assist you. Essentially for us our members are current as at 30th June then on 1 July they fall into a status of Grace, then if renewed they are current again or after 31 July they fall into expired member status.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-06-05T22:07:15.277Z
Answers.Text: Yes a custom status may be what would help here. Eg make a status called Plus One - and set it to work for 1 day from End Date.
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-06-07T17:34:35.093Z
Answers.Text: I think this will suffice as a workaround, thanks!
Answers.UserDisplayName: Peter_
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-06-05T13:37:53.710Z
Answers.LastActivityDate: 2016-06-05T13:37:53.710Z
Answers.UserDisplayName: Gary Martin
Body: <p>I have an issue where all monthly auto-renew members expire on the day that they will be charged.  The payprocessor charges on the same day of the month that the membership was created. eg.  01/08/16, 02/08/16, 03/08/16 etc. but it may happen at 11pm....it's never the same time of day per customer.  This leaves the members in an expired state since Civicrm api job process_membership expires the membership on that same day, the "end_date".  I'd say that's clearly unwanted behavior for an auto-renew member!  Civi calculates the end_date by incrementing the month by 1. But the end_date should be padded by a day if a member is to get a whole month of uninterrupted membership.  </p>
  
  <p>Is there a way to define a month, or otherwise work around this within the UI?  </p>
  
  <p>end_date seems like an unfortunate choice for field name, since it falls within the date range of membership but apparently is definitely not being treated like the other days in that range.  IMHO, valid_through makes a lot more sense since it's more clear as to how it should be treated.  </p>
  
  <p>It seems like there are two options. 1) redefine the monthly membership period as month++ day++ or 2) reconceptualize end_date as valid_through and expire when that day is over.   Even though I think #2 makes more sense, I think #1 may be easier.  I've tested the daily member and it doesn't expire on the "end_date",...I'm thinking there's a check to see if the end_date is equal to the current date or start_date.</p>
  
Tags: <civimember><payment-processor><recurring-contributions>
Title: Memberships ending a day early before auto-renew
ThreadText: # Memberships ending a day early before auto-renew
  
  (Asked by: username_0 on 2016-06-03)
  
  I have an issue where all monthly auto-renew members expire on the day that they will be charged. The payprocessor charges on the same day of the month that the membership was created. eg. 01/08/16, 02/08/16, 03/08/16 etc. but it may happen at 11pm....it's never the same time of day per customer. This leaves the members in an expired state since Civicrm api job process\_membership expires the membership on that same day, the "end\_date". I'd say that's clearly unwanted behavior for an auto-renew member! Civi calculates the end\_date by incrementing the month by 1. But the end\_date should be padded by a day if a member is to get a whole month of uninterrupted membership.
  
  Is there a way to define a month, or otherwise work around this within the UI?
  
  end\_date seems like an unfortunate choice for field name, since it falls within the date range of membership but apparently is definitely not being treated like the other days in that range. IMHO, valid\_through makes a lot more sense since it's more clear as to how it should be treated.
  
  It seems like there are two options. 1) redefine the monthly membership period as month++ day++ or 2) reconceptualize end\_date as valid\_through and expire when that day is over. Even though I think #2 makes more sense, I think #1 may be easier. I've tested the daily member and it doesn't expire on the "end\_date",...I'm thinking there's a check to see if the end\_date is equal to the current date or start\_date.
  
  **Tags:** civimember, payment-processor, recurring-contributions
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2016-06-05. Score: 3
  
  We set our memberships to and end date of 30th June then add a Grace period of 1 month to allow for collection of member fees. You can set grace periods and define the length of that period. Maybe this will assist you. Essentially for us our members are current as at 30th June then on 1 July they fall into a status of Grace, then if renewed they are current again or after 31 July they fall into expired member status.
  
  > **Comments:**
  > **username_2**: Yes a custom status may be what would help here. Eg make a status called Plus One - and set it to work for 1 day from End Date.  
  > **username_0**: I think this will suffice as a workaround, thanks!  
  
  ---
  
  