All of our membership levels renew/expire on the first of the year. We also need this feature. Right now if a member is paid up to next year and they change their membership level and pay for the new level, the renewal date is not changed. This is bad. What is desired is for the renewal date to be advanced as it is when a member renews. We have to find these records and do it manually now.
Sorry for the late update.
The first step was finished and emails can now be carbon copied to contact’s alternative emails. To do so the contact fields which store the alternative emails must be explicitly marked on the email setting page.
Unsubscribing will unsubscribe all alternative emails simultaneously because they all belong to the very same account. The person clicking “unsubscribe” is warned about this on the unsubscribe page.
For now we paused the development of this feature. but not for good. :) So I’m changing this wish status back to “collecting comments”.
Thank you everyone for a valuable feedback.
Excellent. Do you have a description of how this feature will work? Will the user be able to login with either email address, or will one still be "primary" for the account?
I fully agree. The documentation actually suggests assigning the bundle member to a different non-bundle membership type, but this is not appropriate if there are no applicable levels. The only solution that I've been able to come up with is to assign them to a non-bundle level and then mark them as lapsed. Also ugly. I suspect the issue is that if they are just made into a regular contact any membership history will be lost, but if they are just a member because they are in a bundle, such history really isn't important to me. If you really wanted to keep history, just add a note to the notes field when you unbundle them and make them a contact in the same way that a note is added when a membership is renewed.
257 votesEvgeny Zaritovskiy responded
Collecting comments now.
It is difficult to address your broader question without major restructuring. That is why I was suggesting a rewording of the column name to use a word that would apply in all cases without confusion. It is simple to change it and I don't see any downside for existing users.
If you get me going on broader issues, this no longer remains simple. I'd like, for example, to be able to distinguish between membership dues that our tax deductible (like ours are) and membership dues that are not tax deductible (like other organizations). Ideally each payment (or amount on an invoice) could have a tax deductible status and we could run and email a nice report for a given date range for each contact summarizing their giving. Perhaps I should list this as a separate item on this board.
We also are very interested in importing donations. We have a history of multiple years of donations in our Access database. Even the WA API does not allow donation importing, only payments. Our requirements are fairly straightforward. Ideally we would import a spreadsheet of donations. One column would contain the existing WA ID. Additional columns would match up with the system fields for donations and the user defined custom donation fields. We would be satisfied with importing only new donations and having you auto-number them as they are imported.
I suspect one thing that must be thought about is the possibility that someone imports a bunch of donations and then realize that they made some type of mistake and need to delete them. It would be nice for this and many other reasons to be able to delete all donations that were imported in a particular import.