Thanks for posting. From our perspective invoice is just a mechanism to distinguish between registrations that were paid online from those that weren't. Do far I can't think of a way around this. If you do not record payments, how do you track and reconcile your cash receipts and your event income?
Can you elaborate - what do you find onerous about applying payments to invoices?
The typical process is like this:
1) Find the invoice, go to its details (this can be done from the list of invoices, from a particular contact, from event registrations)
2) Click on Record payment
3) If desired you can add information about payment tender etc. Or you can skip this.
4) Click on Save.
So recording payment for an invoice is two button clicks.
This is tricky...how to display no-date events on the calendar?
have you considered using a subscription form instead? The subscription confirmation email could include the link(s) to recordings. Or do you need people to pay for them?
Thanks for the details. We will now wait to collect feedback and votes to prioritize.
There are two aspects of this:
1) Allow to save events in the admin backend without requiring a date. This is relatively easy.
2) Allow to publish events without a date. The big question is then: where to display them in the calendar and where to place them in the list view (events are ordered by date). Registration for these events should also be automatically disabled.
Thanks for bringing this up Steve.
I would appreciate comments from others, especially specific examples of fields where validation would be beneficial. So far phone numbers and zip codes have been mentioned.
Also, some questions:
1) How to handle validation:
a) post-input (allow any entry, validate and display error)
b) display formatting and enforce valid input only. E.g. .'('&[field_for_three_digits]&')-'&[field_for_3_digits]&'-'&[field_for_4_digits]
2) How to deal when records are imported
3) How to deal with records already in the database
Sorry, we wouldn't be able to look at this for a while, at least for the next 6 months.
Thanks for clarifying. I thought you meant sent emails - you are talking about customizable email templates.
Your point makes total sense, this is in fact in our roadmap to move all customized email templates into one centralized location.
Can you elaborate - what do you see this centralized page showing vs. the existing page 'Email log' under Contacts. Current page does show all the emails sent (except for some admin copies). And each email has 'Origin' field to help find the source of it.
Good point, we will consider this.
For now I would like to collect feedback on how people use the new functionality - would appreciate comments from others!
Am I correct that credit in your case corresponds to partially/fully unused payment?
If so, have you considered using 'Comment to payer' field in payments? This field is shown to the contact.
The internal notes are designed to be admin-only so we would not show them to the contact.
Thanks for posting. This makes good sense, especially making this a special separate option on the membership level (so that it can be separate from other possible one-off fees)
I would appreciate comments from other non-profits who have come across this processor.
Thanks for posting - though for now I doubt this is feasible. Email is not a very reliable medium in terms of timely delivery, due to server loads on our side and/or recipients side actual time from initiating the sending to delivery can be in pretty broad range.
Nevertheless, maybe there is another way to improve in this are - e.g. send a few hours (2-4) before, etc.
I would appreciate comments from other users.
Steve, thanks for posting. Before we go into a (potentially very broad) topic of dynamic pages/APIs, I wonder if this can be narrowed down to something with a simpler solution,
Can you give us more examples of stuff you would want to display on the page?
You should be able to display member's name already, see examples here:
Your other example was Chapter name - which I assume would be a field in the member record?
Can you elaborate - why would you need a gadget to list past events?
In our next version 4.3 payments will be fully decoupled from invoices/transactions - e.g. it will be possible for one payment to cover event registration AND a membership application. (Though donations are treated separately/differently as they do not have 'invoices')
So I would like to wait until version 4.3 (early December) and then resume this conversation to review possible ways to address this request.
The challenge is that receipts correspond to payments and payment can be for one or multiple invoices. This will become even bigger consideration in v 4.3 (early Dec 2011) when we will allow paying any combination of open invoices online. So event-specific payment receipt does not look like the best path to explore - though I would love to hear feedback/ideas on this.
One idea we have - and we will try to include it in 4.3 - is to enable event field macros in templates, then it would be possible to collect address fields on events and then include those.
Good point, thanks for bringing this up!
Thanks, that's a very important point for us to keep in mind.
Gordon, good point.
I wonder if we should take it a step further: scan emails and and provide a warning if it contains unrecognized macro. What do you think?
OK, thanks for elaborating. Let's see what other users have to say on this.
Can you elaborate further on why not use an advanced search? You can create a saved search for quick access.
This has been raised - personally I have a number of concerns (e.g. if you have several levels of access, this can easily lead to visitor confusion and frustration - I am logged in, why can't see this page? Also, I believe many user might find it unsecure to share even the existence of some pages with public visitors)
Also I feel that much better approach is to create some public-visible content with some excerpts/teasers - it would likely be much more attractive than just page names.
I would love to hear from others on this.
#1 is part of what we do in CMS redesign - will be available in version 5.0 (Q1 2012)
So let's focus this thread on #2. This has come up before and I would like to get more input/comments:
Should restricted pages always be hidden from menu/shown in menu/user choice? And why.
very cool collaboration to come up with a useful and functional way to handle officers!
Thanks for posting - appreciate the detailed wrap up. This definitely sounds like something we should be considering - I know many clubs can use this - though I could not find prior posts on our wishlist. So we will now collect comments/votes and put this into our enhancements queue for future versions.
My point is not that I doubt that staff should have higher level-access but rather that since each member might have a slightly different view, we need to come up with a sensible way for staff to have somewhat matching view - otherwise preview makes less sense it would not match the view of any particular member. Am I making sense?
Thanks Robbi, it's a fair point, the challenge is that if admin is not a member, we need to figure out what to do with certain pages, e.g.
* What membership level should be assumed/emulated for access to member-only content, membership directory, event registration types etc.
* What to show instead of member own profile etc.
* Forms have to be disabled for actual processing (e.g. events, email subscriptions etc.)
Bottom line I think in this case it would be something different like 'member preview' rather than member view for admins who are actually members - and I would appreciate thoughts from everyone on this.
John - what kind of membership information are you including into the invoice template? Have you considered sending that information in one of the membership emails instead?
Can you tell us what kind of information would you ideally like to put on the membership invoice?
Max, have you considered using the Payment instructions in events to specify that payment is only taken only - and a different one for other invoices?
I would appreciate more details - what kind of differences would you like to have between those invoices and why?