[CRM-20720] CIVICRM-128 Unable to sort Price Options for Price Fieldset. Weight values are not being set at all in database. Created: 12/Jun/17  Updated: 22/Jun/17  Resolved: 22/Jun/17

Status: Closed
Project: CiviCRM
Component/s: CiviMember
Affects Version/s: 4.7.19, 4.7.20
Fix Version/s: 4.7.22

Type: Bug Priority: Important
Reporter: Agileware Assignee: Seamus Lee
Resolution: Fixed/Completed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File TEST_-_Price_Fields___CiviCRM_Sandbox_on_Drupal.png    
Versioning Impact: Patch (backwards-compatible bug fixes)
Documentation Required?: None
Funding Source: Needs Funding
Verified?: No

 Description   

Unable to sort Price Options for Price Fieldset. Weight values are not being set at all in database.

Verified on dmaster for CiviCRM 4.7.21

This bug would effectively block new CiviCRM installs from being configured correctly since Price Options cannot be arranged in a logical order and requires database queries to fix. Not great.

Agileware reference CIVICRM-128






[CRM-14538] Partial payments for Memberships Created: 28/Apr/14  Updated: 21/Jun/17

Status: Open - Unverified
Project: CiviCRM
Component/s: CiviContribute, CiviMember
Affects Version/s: 4.5
Fix Version/s: 4.7.20

Type: Epic Priority: Major
Reporter: sri Assignee: Ramesh
Resolution: Unresolved Votes: 6
Labels: PatchSubmitted
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: JPEG File mulitple_contribute_membership.jpg     PNG File ViewPaymentsPopup.png    
Epic Name: Back-office Membership Membership Enhancements
Versioning Impact: Patch (backwards-compatible bug fixes)
Documentation Required?: User and Admin Doc
Funding Source: Contributed Code

 Description   

Description
Provides back-office staff with the following additional capabilities:

1. Record partial payment for a Membership Creation. Then record one or more additional payments until the Membership fee is completely paid.

Part 1:

Description
-------------
Summary
-------------
Back-office staff may:

  • Record partial payment for a Membership Creation.
  • Both the contribution and the Membership record will be assigned a status of Partially Paid until the balance owing is zero. This will allow staff to easily locate partially paid registrations.

---------------------
Implementation
----------------------
1. Define new Membership status Rule: 'Partially paid'

  • Status is 'Counted', Class='Positive', Reserved=TRUE, Visibility=Admin, Active=TRUE
  • Add to civicrm_data
  • Insert in upgrades

2. New Membership Creation (modifications)
currently (4.4) the Total Amount (Payment Info field set) defaults to total owing AND the user can change that to a smaller amount. However we don't do anything special in that case. We need to make the following changes to postProcessing to handle this condition.

Client Side form behaviors (jQuery)
------------------------------------------------

  • If user enters a Total Amount less than the calculated total fee, set Contribution Status to 'Partially paid' (user MAY override this and change it to something else later)
  • When user clicks "Save", if the Total Amount entered is less than calculated fees AND the contribution status!= 'Partially paid', put up a jScript confirm dialog:
    "Payment amount is less than the amount owed. Expected Contribution status is 'Partially paid'. Are you sure you want to set the contribution status to $statusLabel? Click OK to continue, Cancel to change your entries."

Post Process changes
-------------------------------

  • New contribution record is always inserted with the total OWING (calculated fees) as the total_amount. If total_amount = total owing, NO changes in the rest of the postProcess flow.

If the total_amount on the form is less than the amount owing:

  • Contribution status is set to 'Partially paid'.
  • Financial trxn record is created with total_amount = the amount actually being paid (total_amount from the form). Financial_trxn status is Completed. TO account = the applicable ASSET account (based in payment_instrument)
  • A second financial_trxn record is created for the BALANCE owing. Rules for setting values for this transaction are the same as for a new Pending pay-later transaction:
  • to_financial_account_id = account with "Accounts Receivable Account is" relationship to the financial type of the contribution
  • from_financial_account_id = NULL
  • status = Completed

Tests
-------

  • Extend unit tests to cover membership create with partial payment
  • Extend web-tests to cover the above workflow (membership registration with partial payment)

2 Part:
Description
-------------
Summary
-------------
Back-office staff may:

  • Record one or more additional payments against "Partially paid" or "Pending pay later" membership - until the registration fee is completely paid.
  • Members may be sent receipts for each payment
  • Payments will be recorded as financial transactions against the original contribution record.
  • View existing payments (financial transactions)
  • When balance owing is 0, contribution status will be updated to Completed. Membership status can be set in payment form but comply to default rules when balance owing is 0.
  • Record a refund (used when registration selections are changed and fee was overpaid - see CRM-13973).

---------------------
Implementation
----------------------
1. Implement BAO function which calculates 'amount owing' or 'refund due' for a given Membership record.

  • SUM(line_item.line_total) for all line_item rows linked to the membership row MINUS SUM(financial_trxn.total_amount) for all financial_trxn rows linked to the contribution associated with the membership row AND where financial_trxn.status_id = 1 (Completed).
  • Positive number = Amount Owed,
  • Negative number = Refund Due


2. Using the same form for submitting a Financial Transaction against an existing contribution linked to a membership.

      • IMPORTANT ***: Going forward we are using the same form for applying payments against a Partially Paid membership contribution, so the form class should be structured to support conditional 'integration' with other component transactions.

3.1 Form elements

  • Form elements are a subset of fields exposed in Contribution form (CRM_Contribute_Form_Contribution), but this is a basic create-only form so we'll make use of new form class which only handles this case. (For Memberships we are using the same form what we have used for Events).
  • For this project, the form will always create a financial_trxn (payment or refund) against a partially paid contribution linked to the passed-in membership record. Contact Name (contact display_name) and Membership title are read-only elements on the top of the form.
  • URL params for contact id and membership id are required / passed to the form.
  • All form fields are columns in financial_trxn table EXCEPT for "Send Receipt" and "Receipt From".
  • add a text area to the form for purpose to provide optional email_text - shown conditionally if [x] Send Receipt checked
  • For 'Refund Due' case:
  • Payment Amount label => Refund Amount
  • Form block title = New Membership Refund
  • Page title = Refund for $displayName
  • Additional client-side form behavior (same as contribution form Additional Details): Net Amount = Payment Amount - Fee Amount

3.2 Pre process

  • Amount Owed OR Refund Due for this membership should be calculated during preProcess. This value should be the default for the Payment Amount/Refund Due field AND displayed next to the amount input box.
  • If related member (contact) does not have a valid email address, display status re: can not send a receipt and hide the Send Receipt and From fields (same as for contribution form).

3.3 Form rules

  • If amount owed, payment amount must be < = Amount Owed
  • If refund due, refund amount must = Refund Due (we do not want to support 'partially refunded' membership records at this point).
  • Net Amount = Payment Amount (OR Refund Amount) - Fee Amount

3.4 Post Process
NOTE: Use existing Financial Trxn / Financial Item BAO's as much as possible. Do not put transaction process logic in the form class (create new BAO(s) if necessary).

  • Insert new financial_trxn and entity_financial_trxn (keyed to contribution row). Financial Trxn status is completed. Payment instrument, check number, financial type etc are stored per form values.

------------------
For Payments
------------------

  • update related contribution status to Completed (from 'Pending refund')
  • update related Membership status to Default Rule (from 'Pending refund')
  • If [x] Send Receipt is checked, we need a new function / message template for sending Payment/Refund Receipts. In the interest of keeping the template simple, The 'Additional Payment Receipt or Refund Notification' message template is ideally intended to be used for both event and membership payments and refunds. Best if you can tweak it / add some variables so that it handles both cases.
  • For Payments – use new activity (type = Payment) for the new payment action. Data pattern similar to Contribution activity:
    Source Contact = logged in user's contact
    Target Contact = payee contact
    Subject = "$paymentAmount - Offline payment for $eventTitle (Title Need to be changed with $membershipType)
  • For Refunds – use new activity (type = Refund) for the new payment action. Data pattern similar to Contribution activity:
    Source Contact = logged in user's contact
    Target Contact = payee contact
    Subject = "$refundAmount - Offline refund for $eventTitle (Title Need to be changed with $membershipType)
  • Cancel on form should return to last form or page that the user was on. Successful submit should return to contact's Memberships tab in most cases. If the form is accessed via Find Memberships, then return to the search form with session key (search results s/b preserved if possible).


***Yet to get more information on this Credit Card Block ***
4. Live Mode (submit credit card payment) - Payments only

  • This mode is available if one or more of the required processor(s) enabled (allowBackofficeCreditCard - same rules as contribution form class). This is NOT available for 'Pending refund' contributions / membership records.
  • Submit button title for this mode is 'Submit Credit Card Payment' (not shown on screenshot)
  • Post process invokes selected processor plugin to submit the payment. Rules for entity updates same as above.
  • Activity subject in LIVE mode = "$paymentAmount - Submit credit card payment for $eventTitle

5. Modifications to Edit Membership and View Membership forms
5.1 Selections block: I don't think the intent is to support changing the selected membership type, NOR changing membership-related price set selections. Also even if a membership price set is used we don't need to show the line items in the View or Edit Membership pages, so we may not need to add a Selections section. We do need a new Fees section to show the owed / paid / balance info.

5.2 If 'Amount Paid' is > 0, add "view payments" link to the Fees table (text link and link on Amount Paid amount value). Clicking link loads a new jQuery dialog pop-up which displays payments already made against the associated contribution (e.g. financial_trxn records). We need to filter the financial_trxn rows to only show actual payments (not transfers to AR account etc.). I think we can do this by only showing transactions where the "TO ACCOUNT" financial_account_type_id is 'Asset' (check with Dave/Pradeep to confirm this).
**I’m assuming, we can mimic this similar to Events **

See ViewPaymentsPopup.png screenshot for table elements and layout.


6. Expose "Record Payment" button / action link for Membership records with "Partially paid" status.

Users should be able to navigate to 'New Membership Payment' form from the following buttons and action links:

  • Add a 'Record Payment' action link to the Membership selector actions IF Membership status for that row is 'Partially paid' or 'Pending pay later' (this should be available from contact's Membership tab as well as Find Membership / Membership Dashboard). Same behaviour as 'Record Payment' button.

7. Tests

Need to check the unit and web tests added for the analogous event/participant issues. Any new or modified BAO's or API's should result in new or extended unit tests. There should be web tests for each of the new UI interactions (i.e. create partially paid membership, make another partial payment, make a completing payment).

8. Scheduled Reminders

The use case I would see here is the ability to send reminders to contacts with partially paid memberships (similarly to how we've implemented for event participants). However we don't currently include membership status in the Scheduled Reminders criteria - and we would probably need one or more additional 'events' beyond 'Membership Join Date' and 'Membership End Date' to make this useful (e.g. 'Last Payment Date', 'Membership Start Date'). A simple thing we could do is just add a new token for display of a membership's balance -

{membership.balance}

. Then users could create a smart group of partially paid members and thus handle some key use cases.



 Comments   
Comment by David Greenberg [ 16/May/14 ]

Pushing this issue to 4.6 because there was no reply to request for status.

Comment by Joe Murray [ 18/Jul/14 ]

Dave, could you tell me more about the process and people involved (at least potentially) in this work?

Jamie Novick and I are thinking of trying to get some client money together to push partial payments forward and would like to coordinate with you. We're identifying scope, which may exclude allocating payment funds to line-items, and include user-facing functionality on top of back-end staff facing functionality.

What does it mean that this issue is labelled Team_Dave_Yash_Sprint - are you and Yoshoda and the rest of the team thinking of doing a sprint to push this forward?

I see that this is MIH - what is the amount to be raised and what is the current total raised?

Thanks for doing the work on https://issues.civicrm.org/jira/browse/CRM-13964. Was that funded by someone who might be interested in funding user-facing functionality for subsequent payments?

Comment by David Greenberg [ 18/Jul/14 ]

Joe - This issue was posted by a developer from MillerTech (UK). They had client funding and were supposed to get this done for 4.5 - but the project has been delayed and not sure when / if they are going to continue with it. It is not an MIH. I would suggest contacting Richard Slade or Paul Hunter.

The event partial payments was funding by the Great Lakes Planetarium Association. I don't think they have funding to extend to front-end additional payments at this time.

Comment by Shai Gluskin [ 24/Jul/14 ]

I have a client very interested in partial payments.

I have some questions about current status.
1. The title of this issue is "Partial payment for Memberships." Are partial payments for events covered in a different issue? Has any partial-payment functionality been added to 4.5?
2. Is Alan Shaws and Joe Murray's work as reflected in Allan's blog post (https://civicrm.org/blogs/allenshaw/recording-multiple-payments-one-contribution-and-dividing-one-payment-among-multiple) and Joe's requirement's page (http://wiki.civicrm.org/confluence/display/CRM/CiviAccounts+Specifications-Flexible+User+Payments) guiding this work?

I see that Joe posted just about a week ago on this issue. Joe, can you report back here on whether you contacted Richard Slade and Paul Hunter and what they said.

Thanks much.

Comment by David Greenberg [ 24/Jul/14 ]

Shai - Backoffice partial payments for events is part of 4.5 thanks to generous sponsorship from Great Lakes Planetarium Association. This has been highlighted in the 4.5 release announcements (e.g. https://civicrm.org/blogs/yashodha/announcing-civicrm-45-beta3-release) - might be good for you to subscribe to the civicrm.org blog rss feed - https://civicrm.org/blog/feed .

Comment by Shai Gluskin [ 24/Jul/14 ]

Thanks Dave.

I do subscribe to the release announcements and I had read that, but maybe a couple of weeks ago. When I went to test it yesterday, I tested it on a contribution, not an event. I guess my mind had mixed the release announcement with the old Allen Shaw blog post. When testing partial payments on a contribution I saw it wasn't there... I started Googling and came to this thread. I somehow missed the work on partial payments for events. Thanks for setting me straight.

For feedback on the new functionality shall I do that in JIRA at https://issues.civicrm.org/jira/browse/CRM-13964 or in forum.civicrm.org?

Thanks,

Shai

Comment by David Greenberg [ 25/Jul/14 ]

Feedback to the 4.5 testing forum please. However we are substantially over the sponsored hours already on this project so only actual bugs are likely to be addressed for 4.5 (rather than 'improvements').

Comment by Ramesh [ 16/Jun/17 ]

Hi all, Ramesh here from MillerTech

I've recently been working on the partial payments for membership functionality for version 4.7.x and have assigned this issue to myself.

This development has been designed based on the similar format as the core event partial payment functionality so this route is very different from what was originally anticipated.

Description -

Provides back-office staff with the following functionality on the membership screen.

Record partial payment on membership creation by overwriting the original amount in the “Amount” field. For example, select “General” membership, the pre-populated figure in the “Amount” field will be 100.00, overwrite this amount to a lower partially paid value, say 50.00, change payment method if required and leave the contribution status as “Completed” and save.

This action creates a membership with the “New” status and creates a related contribution with the “Partially Paid” status.

From the “More” option on the related contribution we have the option to “Record Payment”, this screen is similar to when recording additional payments on the event payment careen. It also displays the outstanding balance and does not allow you to enter a greater amount than the outstanding amount.

The view membership screen displays Total amount paid, balance and an option to record payment.

When paid in full the contribution status is set to “Completed”.

Also works with membership price sets.

To do –

  1. Send receipt upon partial payment.
  2. Code the membership offline receipt to show balance and amount paid.
  3. Reporting aspect of partial membership payment.

 

Comment by Monish Deb [ 17/Jun/17 ]

Hi Ramesh

I have gone through the spec and it meets our requirement for CRM-20569 where we treated this is a bug as there were incorrect financial entries on partial payment for membership.

I fixed it by handling the submission of partial payment and added few form validations to ensure that the contribution status to be set to 'Partially paid' if amount is less/equal to expected total amount, also added unit tests with few assertions on related contribution record, if it is updated correctly on partial payment and after paying the additional owed amount.

The only task I didn't manage to fix it yet, is about handling partial payment for multiple membership and raised an issue CRM-20626, as it is not clear/decided how to distribute the partial amount to multiple memberships. This is the PR https://github.com/civicrm/civicrm-core/pull/10352 . I was wondering if I can help you in completing this task.

Feel free to ping me here or you can reach me at Mattermost ( alias- @monish )

Comment by Ramesh [ 19/Jun/17 ]

Hi @monish

Thank you very much for taking time to look into the code - Appreciate your help

regarding multiple membership -  I will try to do that too

and will submit to code

thanks

Comment by Ramesh [ 19/Jun/17 ]

Hi Monish Deb

Please have a look at my PR https://github.com/civicrm/civicrm-core/pull/10516/commits I have fixed the issue CRM-20626

so please have a look and let me know the status

thanks

Ramesh

Comment by Monish Deb [ 21/Jun/17 ]

Hi Ramesh

Does your patch cover all the points mentioned in the description? If not, please complete your fix and assign me for QA. You can add unit-test of mine - https://github.com/civicrm/civicrm-core/pull/10352/files#diff-3cd3f80dd69269a09e1d88996ce92f6fR533 to assert this use-case of membership partial payment via backoffice form

Also, for making changes in PHP we follow the Drupal coding standards as mentioned here https://wiki.civicrm.org/confluence/display/CRMDOC/PHP+Code+and+Inline+Documentation
Can you please correct the indentations on your patch?

You can change your IDE settings as per Drupal coding standards and here's the link to do that https://wiki.civicrm.org/confluence/display/CRMDOC/IDE+Settings+to+Meet+Coding+Standards

Feel free to ping me (alias - @monish) in Mattermost dev channel - https://chat.civicrm.org/civicrm/channels/dev

Thanks!





[CRM-20670] Cannot edit membership type if lots of members already exist Created: 01/Jun/17  Updated: 21/Jun/17  Resolved: 21/Jun/17

Status: Closed
Project: CiviCRM
Component/s: CiviMember
Affects Version/s: 4.7.19
Fix Version/s: 4.7.22

Type: Bug Priority: Trivial
Reporter: Johan Vervloet Assignee: Unassigned
Resolution: Fixed/Completed Votes: 0
Labels: PatchSubmitted
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Versioning Impact: Patch (backwards-compatible bug fixes)
Documentation Required?: None
Funding Source: Needs Funding
Verified?: No

 Description   

We have a particular membership type, and +/- 1 million memberships of that type. If we try to edit this membership type, the screen turns white, because of a memory problem.

My collegue jo0st (can someone arrange that he can submit issues himself) has created a patch; he will create a PR.






[CRM-20650] Translate strings (ts) in CiviMember dashboard and Contribute manage Created: 29/May/17  Updated: 20/Jun/17  Resolved: 20/Jun/17

Status: Closed
Project: CiviCRM
Component/s: CiviMember
Affects Version/s: 4.7.19
Fix Version/s: 4.7.22

Type: Patch Priority: Trivial
Reporter: Francesc Bassas i Bullich Assignee: Unassigned
Resolution: Fixed/Completed Votes: 0
Labels: PatchSubmitted, i18n, localization
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Versioning Impact: Minor (add functionality in backwards-compatible manner)
Documentation Required?: None
Funding Source: Contributed Code
Verified?: Yes

 Description   
  • In CiviMember Dashboard month names not being translated.
  • Contribute page delete message not being translated.





[CRM-15461] Scheduled annual membership reminders not sent after first year Created: 15/Oct/14  Updated: 19/Jun/17  Resolved: 15/Dec/14

Status: To Backport
Project: CiviCRM
Component/s: CiviMember
Affects Version/s: 4.2.19
Fix Version/s: 4.6

Type: Bug Priority: Major
Reporter: Chris Cant Assignee: David Greenberg
Resolution: Incomplete Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Screen Shot 2014-10-15 at 3.13.49 PM.PNG    
Documentation Required?: None

 Description   

I'm reporting this for scheduled reminders on annual membership but there may well be other cases where this is an issue.
We have rolling annual memberships and I have set up reminders eg a month before the membership end. The reminders are not set to repeat, but I do want them to go out again each year (assuming they have renewed).
The first year's reminder is sent out, but not in subsequent years.
It looks like ActionSchedule buildRecipientContacts only adds a membership into civicrm_action_log if there is not an existing record for that entity in there eg "reminder.id IS NULL".
My workaround is to copy the existing scheduled reminders and disable the old ones; that way there is a new action_schedule_id that won't find a duplicate in civicrm_action_log.
An alternative for us would probably be simply to delete the contents of civicrm_action_log.
My workaround does not allow us to catch up as these reminders are only sent out on the specific day eg one month in advance.
There are quite a lot of options for reminders so not sure what to suggest as a solution. I decided a while back that the repeat reminder didn't work as advertised (but I cannot remember the details sorry).
I don't think the 4.4.7 code has changes that might fix this.
http://forum.civicrm.org/index.php/topic,34428.0.html



 Comments   
Comment by David Greenberg [ 15/Oct/14 ]

Chris - I'm thinking a repeating Scheduled Reminder setup like this should do what you want. It should repeat once a year, but will stop repeating at 0 days after Membership End Date (which will move if renewal occurs).

I think the patch attached to this issue MIGHT be needed (it's scheduled for 4.5.3 at this point) to ensure that the updated end date is considered:
https://issues.civicrm.org/jira/browse/CRM-15376

Would be great if you could try this out on a test copy of your site (ideally running 4.5 w/ that patch).

Comment by Chris Cant [ 16/Oct/14 ]

Thanks for looking at this.
The reminder is not set to repeat, but the event "one month before membership end date" occurs every year, assuming the member renews and the end date is therefore updated.
I'll check out that patch which might well be relevant.
Chris

Comment by Chris Cant [ 16/Oct/14 ]

Sorry, only just read this properly and seen the screenshot.
Just to confirm: to get this to work, you say we do need to tick Repeat for 1 year after membership end date?
And the patch is needed?

PS May be a day or three before I can check this out.

Comment by David Greenberg [ 16/Oct/14 ]

We "think" that approach will do what you want w/ the patch. Testing this functionality is a bit challenging though One approach is to experiment with setting the 'repeat after' as a much shorter interval (e.g. 1 hour) and have several test membership where some of the end-dates are 'in range' (i.e 1 month from now), and others aren't.

If you have coding resources and have (or want to have) experience w/ unit testing, a better approach would be to add a new test method to CRM_Core_BAO_ActionScheduleTest (tests/phpunit/CRM/Core/BAO/ActionScheduleTest.php) to exercise this use case. In the test framework you can override current date/time (i.e. "time travel"). Information on tests here: http://wiki.civicrm.org/confluence/display/CRMDOC/Testing

Comment by Chris Cant [ 20/Oct/14 ]

I've upgraded to 4.4.8 and patched ActionSchedule as per CRM-15376.
I've set up a 3 day membership and set repeating reminders as recommended for -1 and -0 days.
I'll check the emails that I get and renew and then look for the emails again.

I'd suggest looking for a solution that works as a mortal might expect, ie without having to tick repeat etc.

Apologies I don't have time to add or test a unit test.

Thanks Chris

Comment by Chris Cant [ 29/Oct/14 ]

Sorry for the delay on getting back to you. It is a bit tricky to test; perhaps I should work up a unit test.
Anyway it does work for my test 3 day memberships, with some minor provisos:
(A)
For a reminder that is sent on the last day of membership, the reminder needs to repeat until 1 day after membership end (not zero days after membership end) - which is fine.
(B)
If the cron runs at a fractionally different time of day then the reminder might not be sent that day - but is sent the next - which is fine.
(C)
(I was concerned that a reminder would go out even if a member had renewed already; however this seemed not to be the case.)

Thanks for your help.

I guess the crucial thing now is to make users aware that this is how you set up reminders.
Personally I would expect the reminders to go out each year without having to set up repeats.
To my mind, a repeat reminder is one that happens for the current year, eg a first reminder goes out with a month to go, and repeats would be at two weeks and zero weeks for example (if they haven't renewed).

Chris

Comment by David Greenberg [ 30/Oct/14 ]

Chris - The overall design of Scheduled Reminders is that reminders are NOT sent more than once unless 'repeat' is specified. The presence of a row for that recipient / for that reminder prevents additional reminders from going out. Given the various use cases covered by scheduled reminders, this design ensures that multiple reminders are not sent unintentionally.

I agree that the renewal reminder use case should be better documented. Maybe take a look at what's currently in the User/Admin book and suggest additions. Might also be good to add some inline help on Enable Repetition checkbox. If you can suggest some text, I'll look at added it for 4.6.

Comment by Eileen McNaughton [ 26/Nov/14 ]

I'm re-opening this (albeit setting to future version) as I think it's still fairly flawed & we should at least track that.

For example if an end_date is 15 Dec 2011 & I set to send the reminder yearly 1 day before the end date until 1 day after the end date then reminders should go out each year on 14 Dec 2011 EVEN IF I manually change the end date such to be in a different month OR purchase a 2 year membership (resulting in a reminder half way through my membership)

Comment by Eileen McNaughton [ 27/Nov/14 ]

WARNING
we enabled yearly repeats and the reminders started going out hourly (every cron)

Comment by Eileen McNaughton [ 27/Nov/14 ]

WARNING
we enabled yearly repeats and the reminders started going out hourly (every cron)

Comment by Owen Kelly [ 28/Nov/14 ]

We use scheduled reminders for renewal reminders, and from what I've read above I think the design is wrong for this use case.

If the reminder entity is a Membership, I would expect the reminder to be sent out when the rule says it will, even if the membership is renewed and the end date changes, a second reminder should be sent out.

We do also have first time welcome emails, that are sent via scheduled reminders (to the effect of "Weclome to your account here's how to use everything"), for those only sending once during the life of the membership is desirable.

Can I propose that by default, Membership entities are not blocked by the activity_log and will always send out based on the rule. And that if you select the Membership entity you will get an addtional checkbox that says something like "Never repeat. Selecting this checkbox will cause this email to only be sent out once, otherwise it will be sent each time the rule fires".

Comment by David Greenberg [ 01/Dec/14 ]

Owen - Curious as to why would you want a member who had already renewed to get a second / additional renewal reminder? I would expect that a typical use case would be to set up 2 or 3 reminders with increasing 'urgency', e.g. something like this ....

  • friendly reminder (1) - 2 weeks prior to membership end date
  • stronger reminder (2) - 1 day prior to membership end date ("Your membership is about to expire, don't wait ....")
  • oh oh reminder (3) - 3 days after membership end date ("Your membership is in Grace Period but you'll lose your valuable privileges soon")

The fact that #2 and #3 do not get sent for members who've already renewed seems like a good thing. But I guess your organization has a different perspective on this ??

Comment by Eileen McNaughton [ 01/Dec/14 ]

As an aside (not in answer to your question to Owen) - we are currently telling our customers to recreate their membership reminders each year (assuming annual memberships) to ensure that each time the membership nears an end date appropriate reminders go out.

Comment by Owen Kelly [ 01/Dec/14 ]

David - not quite, I think we're on the same page. But it's the reminders for the following year/period that need to be sent out again.

Lets say we have 3 memberships per publication:

  • 6 months
  • 1 year
  • 2 years

Each of those have 3 renewal reminders:

  • 1 month before end date
  • 1 week after end date
  • 2 weeks after end date

If a member gets the first reminder then renews they should not get the next two reminders, as their membership end date has been extended and the rule will not fire/match.

If they do not renew after the first reminder, they should get the second reminder. If they now decide to renew they shouldn't get the third reminder - again because the end date has been updated thus the rule wont match.

So now they have renewed, their end date is set either 6, 12, 24 months in the future.

That date rolls around.

They should get the first reminder again, and if they renew they shouldn't get the second or third. If they don't renew they should get the second, and so on.

My understanding of this bug, from chatting with Eileen, is that after the reminder is sent an activity is logged on the contact against the reminder. Thus that specific reminder cannot be sent out again. To me this is a bug. For reminders set on the membership entity this doesn't make sense. For other entities I understand it's value.

I believe all that needs to happen here is that for scheduled reminders set on membership entities to ignore the code that checks if it has already been sent in the activity log.

I haven't dug into the code, so I'm not sure on the specifics of why the block exists, though it makes sense to prevent duplicates being sent. This may be a problem that needs solving if we go with the solution I'm thinking of.

Comment by David Greenberg [ 01/Dec/14 ]

Owen - my understanding is that if you set the Repeat flag to true, and set a repeat schedule that matches your membership duration (e.g. 'repeat every year for 1 year membership), then you should get the desired behavior. The 'repeat' logic basically says it's ok to send again even though there's an activity_log entry once the repeat interval has passed (in this case, 1 year later).

However, Eileen is reporting some bad behavior on repeating reminders (above). I haven't seen other reports of this. Unfortunately it's non-trivial to try this out - you'll have to set up some test reminders - possibly against a test membership type.

Comment by Eileen McNaughton [ 01/Dec/14 ]

The reason we are advocating 'new scheduled reminders each year' and not focussing on debugging what happened when we tried the recipe described in this ticket is that (annual) reminders are sent out one year after the first reminder IF the end date criteria also matches (for end date based reminders). This is fine as long as the end date is always extended by a year.

If, however, you manually update the end date, e.g to give a 3 month extension, then next anniversary of the first renewal going out will be (for example) 4 months before the end date & the reminder won't go out.

Comment by Owen Kelly [ 01/Dec/14 ]

We do in some cases use the same reminder on a 3, 6, 12 month membership. And we do often manually update end dates.

Comment by Eileen McNaughton [ 01/Dec/14 ]

As an amusing footnote - the customer who wound up with the hourly reminders going out got a bumper crop of renewals - many of the people who phones up to complain wound up renewing after due apologies had taken place.

Comment by Graham Mitchell [ 02/Dec/14 ]

It strikes me that the weakness here is that the repeat schedule cannot currently be set in such a way that it can cope with membership end date changes that are non-standard. Setting the repeat schedule to repeat every year for an annual membership will generally be fine, but won't work for those members whose end date has perhaps been manually amended to something other than a year ahead, as a result perhaps of making a partial payment, or for some other reason. Is it possible to give an option for repeating such that the reminder can be set to repeat based purely on the end date, so regardless of what that end date is, the reminder will go out when the criteria match?

Comment by David Greenberg [ 02/Dec/14 ]

Moving to 4.6 to see if we can recreate the bug reported by Eileen.

I think Grahams's idea is similar to Owen's - provide an option to repeat based on matching criteria w/o checking for prior reminder events in the action log. However, I think there are issues with that approach that need to be flushed out.

EXAMPLE:

  • Membership reminder set for 3 days before membership end_date
  • Send scheduled reminders cron job runs every 4 hours
  • Janet Goodmember's membership end_date is 3 days from now

With current design, Janet will get one and only one reminder (second job run will check for existing reminder in action_log). If we remove that check, then Janet might get 5 or 6 reminders on the same day.

Owen / Graham - would you be up for starting a wiki page on this topic and listing out key user stories? That might be a better way to work towards design improvement.

Comment by Graham Mitchell [ 02/Dec/14 ]

Here you go: http://wiki.civicrm.org/confluence/display/CRMDOC/Towards+improvements+in+Scheduled+Reminders

Comment by Andrew Hunt [ 02/Dec/14 ]

Whoa this is serious. First, a proposed solution, and then some other notes.

We talked it over at the office, and I think the best approach would be to add a new "reference date" field in action_log. Basically, people expect the reminders to be re-evaluated when the date is changed. If each action_log row has the date by which it was calculated (the end date, in this case), the reminder join clause at https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/BAO/ActionSchedule.php#L1163 could simply add a bit to see if the row has the same reference date as is currently being used, along with the same actionSchedule ID and entity ID.

Here are some examples:

  • Membership renewal: the end date should be different than it was the last time the reminder went out.
  • Membership comped extension: the end date will still be different, even though it's not a full term later.
  • Rescheduled meeting: assignees get the reminder a day before the meeting was originally scheduled, the date gets changed last-minute, and then they get a new reminder before the new meeting date.
  • CPR certification renewal: contacts with that custom date field get a reminder three months before it will expire, they get recertifiied, and the field gets set to a new date in a few years. They should get a new reminder three months before that date.
  • Event snowed out: everyone got a reminder for the event, it gets rescheduled a month later, and they should get a new reminder as the new date approaches.

I think this would be pretty simple to implement and would work predictably without having to make any assumptions about frequency. As the examples show, this problem actually affects far more than memberships--they just happen to be the most common.

The one challenge would be the upgrade path: dealing with all the old entries that have no reference date recorded, and for which the reference date might have changed. The two options I can think of are:
1. doing a lookup as part of the upgrade and populating that field, even if it means that some past reminders will have a new reference date, leading to suppressed reminders
2. leaving the field null, meaning that everything will be evaluated fresh, leading to extra reminders
I think the best approach would be to do option 1 just for rows where action_date_time is in the past 9 months or so. That way, people who just got reminded won't be pestered, but people up for renewal will get their reminders because null doesn't match the new end date.

One final note: the "anniversary mode" for contact fields like birthdays dodges this problem by only checking action_log entries in the past 11 months. Since it's annual by definition, that works fine, and meanwhile, it wouldn't be addressed by this because the date probably won't change, being something in the past that's worth remembering the anniversary of. The relevant line is https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/BAO/ActionSchedule.php#L1170

Comment by Graham Mitchell [ 02/Dec/14 ]

To my mind this sounds like it could be an elegant and minimally intrusive solution. Thanks Andrew (and colleagues).

Comment by Andrew Hunt [ 02/Dec/14 ]

Thanks--I also went crazy on the wiki page, Graham, outlining a bunch of scenarios and laying out how the reference date idea would affect them (including one potential problem, albeit a real edge case).

Comment by Andrew Hunt [ 02/Dec/14 ]

One final thing (that I mentioned on the Partners list when Eileen emailed about it): if this ends up being the solution, I really think this should go into 4.4 LTS and 4.5. The only reason we are just seeing it here and there is that it's only been a little while since membership reminders were moved to scheduled jobs. Give it a few months, and we'll have real problems as more sites have a full year under their belts at 4.3 or later

Comment by Eileen McNaughton [ 02/Dec/14 ]

One idea I did have was deleting action_log entries tied to membership_end_date if it changed (in the membership BAO) - which would effectively reset a non-renewing reminder

Comment by Eileen McNaughton [ 03/Dec/14 ]

If testing scheduled reminders on 4.4 PLEASE ensure that you pay attention to the 'limit to' - addition to flag - see
https://issues.civicrm.org/jira/browse/CRM-15500

patching this in 4.4.11

Comment by David Greenberg [ 15/Dec/14 ]

I've filed a new issue to implement the suggested improvement for membership renewal reminders:

https://issues.civicrm.org/jira/browse/CRM-15728

If anyone can replicate the 'repeat' bug mentioned by Eileen in the comment thread, let's open a separate issue for that.





[CRM-9352] Printing/Emailing Contribution Receipt uses the Membership receipt template and not the Contribution Receipt Created: 14/Dec/11  Updated: 19/Jun/17  Resolved: 20/Dec/11

Status: To Backport
Project: CiviCRM
Component/s: CiviContribute, CiviMember, CiviReport, Usability
Affects Version/s: 4.0.7
Fix Version/s: 4.1.0

Type: Bug Priority: Major
Reporter: Zack Esgar Assignee: Deepak Srivastava
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When searching for a contribution and selecting contributions, then clicking the drop down option to Print / Email Contribution receipt. The system generates a membership receipt when the contribution or donor has no tie to memberships. If no membership types are defined it throws an error saying no membership ID found. Here is the forum that led to finding this bug http://forum.civicrm.org/index.php/topic,21905.msg94812.html#msg94812 .



 Comments   
Comment by Deepak Srivastava [ 20/Dec/11 ]

Already fixed with CRM-9218.





[CRM-20413] Wrong payment_instrument used for civicrm_contribution for membership office contributions Created: 11/Apr/17  Updated: 18/Jun/17

Status: Open - Verified
Project: CiviCRM
Component/s: CiviMember
Affects Version/s: 4.7.18
Fix Version/s: Unscheduled

Type: Bug Priority: Trivial
Reporter: Seamus Lee Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Versioning Impact: Patch (backwards-compatible bug fixes)
Documentation Required?: None
Funding Source: Needs Funding
Verified?: No

 Description   

When a back office Credit Card Contribution is submitted for Membership the resulting payment instrument id in the civicrm_contribution table is equal to check. This is incorrect and causing data integrity errors

The payment instrument is correct for the "payments" part of the contribution



 Comments   
Comment by Tamar Meir [ 13/Jun/17 ]

We are seeing a similar issue with back office credit card event registration - payment instrument is set to "Check".





[CRM-20456] Scheduled membership reminders sends multiple times Created: 20/Apr/17  Updated: 16/Jun/17

Status: Open - Unverified
Project: CiviCRM
Component/s: CiviMember
Affects Version/s: 4.7.18
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Franky Van Liedekerke Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Versioning Impact: None (no code merged)
Documentation Required?: None
Funding Source: Needs Funding
Verified?: No

 Description   

I've added 2 scheduled reminders for memberships:

  • 1 month before Membership End Date
  • 1 week before Membership End Date

Now the first one fires (and stores an "activity" record for that person), so when I get the payment, I extend the membership (by a year in my case).
However, the second reminder is still being send and without logging an "activity" for that person (but I know they received the second reminder because I frequently get complains about that).



 Comments   
Comment by Joanne Chester [ 19/May/17 ]

Regarding the missing activity, I presume you have double-checked that  "Record activity for automated email" is ticked on the 1 week before Membership End date reminder.

Also, I have checked this against 4.7.19 and cannot reproduce it.  I used 13 hours before membership end date and 12 hours before membership end date.  My scheduled reminder job runs hourly at 8 mins past the hour and I renewed as soon as I received the 13 hours before membership end date reminder.  I didn't get a 12 hours before membership end date reminder.

(I needed to compress the time  scale as testing was on a staging site recently upgraded to from 4.4 to 4.7.19 with the upgrade for the live site scheduled for after this weekend.) 

Comment by Franky Van Liedekerke [ 16/Jun/17 ]

(Sorry for the late reaction, but I never got a notice that a comment was added here).
I was on 4.7.18 at that time, and didn't got around testing it on 4.7.20 yet. But yes, the "Record activity for automated email" was checked.
I'll reactivate it now, so we'll see about complaints in the future





[CRM-17219] When renewing one's membership from backend, cannot choose to use priceset Created: 14/Sep/15  Updated: 16/Jun/17

Status: Open - Unverified
Project: CiviCRM
Component/s: CiviMember
Affects Version/s: 4.6.7, 4.6.8
Fix Version/s: Unscheduled

Type: Bug Priority: Major
Reporter: Guanhuan Chen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Versioning Impact: Patch (backwards-compatible bug fixes)
Documentation Required?: None
Funding Source: Needs Funding

 Description   

When renewing one's membership from backend, if you come through the steps:
Membership -> New Membership -> select a contact -> select a membership type of one of the memberships that the contact holds

Then a renew notification will popup on the side. If you click on the link that pops up, it takes you to a renew page with the contribution amount pre-populated from the last contribution payment amount. On that page, you will not be able to select price set as you do when you create a new membership.



 Comments   
Comment by David Greenberg [ 14/Sep/15 ]

Guanhuan Chen This is actually a feature request. As far as I know price sets have never been supported for backoffice membership renewals. Ping us if CompuCorp is interested in working on this feature or funding development.

Comment by Guanhuan Chen [ 19/Jan/16 ]

Hi Dave,

Could you get us some estimations on this and we will discuss and let you know if we would like to go ahead with this?

Many thanks.

Guanhuan

Comment by Coleman Watts [ 19/Jan/16 ]

Guanhuan Chen it would help our workflow if you could submit this to https://civicrm.org/paid-issue-queue for an estimate.

Comment by Guanhuan Chen [ 20/Jan/16 ]

Sure, this is now submitted to Paid Issue Queue. Sorry about that.

Comment by Coleman Watts [ 08/Feb/16 ]

Estimate: 6-8 hrs.

Comment by Coleman Watts [ 08/Mar/16 ]

Guanhuan Chen let us know if you want to sponsor this one.

Comment by Owen Pearson [ 25/Jan/17 ]

Just linking this issue to this earlier one CRM-15861 Offline membership renewal doesn't display priceset choices which has had some work done on it.

Comment by Joe Murray [ 16/Jun/17 ]

Changing from Paid Issue Queue to Needs Funding as it appears no funding was received.





Generated at Fri Jun 23 02:41:46 UTC 2017 using JIRA 7.3.3#73014-sha1:d5be8da522213be2ca9ad7b043c51da6e4cc9754.