Planning on sponsoring some misc improvements (mostly POS stuff)

[kmarkley]

We've been using CiviCRM for almost 2 years to sell tickets to theatre performances.  Right out of the gate, we sponsored participant counts for price sets (i.e. "table of 8" price sets, CRM-5724) and soon thereafter submitted a patch for admin-only price sets (CRM-5766).  We needed both of these in order to use civi at all, but even then there were a number of pain points I outlined in a rather long-winded rant (forum.civicrm.org/index.php/topic,13226). 

(Several of the issues identified have since been addressed by the core team - thanks again!)

It took longer than I hoped, but we are finally ready to sponsor a few more of our highest-priority items.  It is my sincere hope that other folks will find these helpful and they can be folded back into the core project.  So, submitted for your feedback, in roughly descending priority, a few things we'd really like to get done:





1. Handling live credit card transactions in the same backend form as cash/check transactions.

Basically, when entering a new participant or contribution, there should be a choice of either recording a (cash/check/etc) transaction or submitting a live CC transaction.  This should be true everywhere, notably:

- participant/add
- contact/view/participant?reset=1&action=add
- contribute/add
- contact/view/contribution?reset=1&action=add
- contact/view/participant?reset=1&action=update

(This last would allow CC payment on 'pay-later' registrations -- a major pain point now.)



2. Auto-loading of contact data into the credit card form.

This currently works if the transaction is initiated from the contact record, but it should be true everywhere.  Upon selecting a contact in participant/add or contribute/add the contact's name and billing address should be loaded into the CC form, saving much frustrating re-entry of data. 

(If no billing address data exists for the contact, the primary address should be loaded instead since they're the same 90% of the time.)

When the form is submitted, the name and address should be written to the contact's billing address exactly as it is now.



3. Allow transferring a registration to another event.

For those of us with many similar events (e.g. performances of the same production), ticket exchanges are a common need.  I have been doing this for the past year by directly manipulating the database (simply changing the event_id in the participant record is all that is needed), but a UI would be very helpful.  I imagine a link or button on the 'view participant' page that brings up a form where a new event can be selected.

The source field for the participant record should also be changed to something like "Registration transferred from {old_event} (by {user})".

Obviously, it is not always appropriate to transfer a registration to another event.  For this reason, the feature should be a) separately permissioned AND/OR b) globally enabled somewhere in admin/setting.



4. A custom report that combines individual and household contributions.

If The Smiths make a $100 donation, Jane Smith makes a (separate) $50 donation, and Joe Loner contributes $75, I need a report that produces The Smiths: $150; Joe Loner: $75.  The report should be based on the "Top Donors" report (i.e. descending aggregate).

<digression> As a side note, I think this is a big weakness of the civi data model.  Individuals 'without' a household are really just a household of 1.  I wish reports/searches/labels/etc all worked at either a 'household level' (i.e. grouped) or an 'individual level' (i.e. ungrouped). </digression>



5. Add the ability to update basic contact data in the middle of an event registration or contribution. 

Say you're registering an contact for an event and you learn that they've changed their email address or that you've misspelled their name.  It would be nice to make the correction without having to leave the form, search for the contact, make the change, and then start all over with the registration.  I'm not sure how this is best accomplished - maybe just opening the contact in a new window or a floating form.  Right now, there is not even a link to the contact.



6. Some small miscellaneous changes.

a) Make a link to event location map available as a smarty variable in confirmation emails (CRM-6589).

b) Display available participants when an event is selected on the backend registration form.  Currently a message is displayed if the maximum has been reached (or exceeded), but this doesn't help in the case of someone wanting to register 2 participants when only 1 slot is left.

c) Make the "paid via" field required (and perhaps defaulted).  This field is often left blank when entering data quickly which causes a hassle when (for instance) the cash drawer doesn't balance or the list of checks to deposit is incomplete.



7. More robust credit card swiper support.

USB swipers come in 2 types.  The basic (and cheaper ones) will read the CC number and insert it into a text field, which works fine with civi.  The other sort reads all the data on the magnetic stripe in its raw ascii form.  (see http://en.wikipedia.org/wiki/Magnetic_stripe_card#Financial_cards)

I imagine CC forms in civi including a "swipe now" button that brings up a floating form with a single text field.  Swiping a card would fill the text field with the raw data (allowing visual confirmation of successful swipe) and hitting enter would dismiss the form, parse the data, and populate the appropriate fields of the main CC form.

The feature should be globally enabled/disabled from the admin section.



I am really not interested in creating or maintaining a fork of civiCRM, so community feedback will meaningfully impact how or even if we get these done.  Any change that doesn't look promising in terms of eventually being incorporated into civi will likely be dropped.  So please weigh in!


Basically our plan is to just work down the list until we run out of budget.  Can't say how far that will get us, but if anyone has similar needs and would like to chip in, that would be awesome.

[Eileen]

First up ... thank you for stepping up.

I agree that the ability to step back into & complete pay later registrations by credit card is a major pain point at the moment. I have been hijacking the waitlist code somewhat to help out with this - if you add ppid=123 (where the participant_id is 123) to a front end event registration URL it will allow you to pick up the registration & complete it. The limitation is that the initial contribution is not completed or set to inactive & hangs around. I have held off worrying about this until CiviAccounts is in place.

Regarding the address pre-filling issue. I did look at this code once & suspect someone like Kurund who knows that profile code pretty well would sort it fairly quickly. The issue I was looking at was that at the moment it WILL pre-fill for back-office entry but using the location_type = 5 (Billing) rather than the is_billing flag. Not sure if you planned to do the work yourself & contribute or sponsor the core team to but this item I would definitely recommend you sponsor core team to do. (We wound up just changing our address types to 5 rather than fixing )

Allow switching from one event to another = YES, YES, YES! This may be better done after CiviAccounts is in place.

I think there may be reports out there on the household payments - perhaps post that item separately in the forum & see what responses you get

[kmarkley]

Regarding the address pre-filling issue. [...] The issue I was looking at was that at the moment it WILL pre-fill for back-office entry but using the location_type = 5 (Billing) rather than the is_billing flag.

This is my experience when beginning the registration/contribution process from a view contact page.  E.g: contact/view/participant?reset=1&action=add

The improvement I would like to see is:

1) loading name/address from participant/add and contribute/add once a contact is selected (first priority)
2) loading the primary address if the billing address is not available (second priority)

(We wound up just changing our address types to 5 rather than fixing)

I would be interested in hearing a little more about how you made this work.  In truth, we don't much need more than 1 address/contact.

Not sure if you planned to do the work yourself & contribute or sponsor the core team to but this item I would definitely recommend you sponsor core team to do.

Planning on hiring someone to to do the work.  Probably webaccess just because we have an existing relationship with them.

[Eileen]

We literally updated all location_type_id values to 5 in the civicrm_address table where we knew them to be billing addresses. In your case you could do it to all addresses.

ie.

"UPDATE civicrm_address SET location_type_id = 5" + optional WHERE statement

[kmarkley]

Ah.  So its a recurring-maintenance thing more than a set-and-forget thing.  Still helpful, though.  Thanks.

At the risk of hijacking my own thread, does is_billing actually do anything?

[robinhood]

Just want to offer my encouragement and support for this line of thinking.  The workflow for a POS app has to be quick and streamlined, and flexible enough to allow people to change their minds while standing in the queue.  I will do what I can to help.

[kmarkley]

I'm not sure if it is a good sign or bad sign that s few have weighed in on these proposals.  Either no one has any objections, or else no has the same frustrations/priorities as we do. 

We are (finally) ready and willing to chip in and contribute to the project again as we did a couple years ago.  It would make a big difference going forward if we had some sense as to whether these things (especially items 1-3) might be folded back into core.

Would it be preferable to turn it into a MIH? (Probably removing items 4 and 6a so that it is more focussed on POS improvements.) 

[Donald Lobo]

In general we do think the blog gets a lot more feedback that an individual forum post, might be worth for you to convert your forum post into a blog

For an MIH, focussing on one specific aspect helps. Items 1-3 (and some of the misc items) focus on improving the backend registration and might be a good combined MIH. I would try to consolidate all this in the blog post and see how much interest is there for these fixes in the community

lobo

[kmarkley]

Thanks lobo.  I will work on a more focused spec for a blog post.

Here's the thing, though:  Even if nobody else is interested enough to chip in to a MIH, we would still like to sponsor as much as we can afford.  In which case it would be nice to know what items might be eligible to be folded back into core before we throw our hard-earned money into something that quickly becomes obsolete. 

[Donald Lobo]

I think most/all of the items you raised seem quite useful. In specific 1,2,3 and 6 are shortcomings that would be good to improve in core

There is some stuff for 4 and other forum discussions on it

not sure how to handle 5

7 would be super useful to orgs like yours, and i suspect a drupal module might be a good way of taking the first cut at it and seeing how that goes

lobo

[kmarkley]

Thanks lobo.

I think it is obvious at this point that number 4 is different in kind and doesn't belong on this list.  6a is also a bit off the main topic.

I think the simplest way to handle 5 is to generate a link to the contact record (that opens in a new tab/window) once a contact is entered into the registration/contribution form.  Maybe there is a cooler/smoother solution possible, but this would meet the immediate need and seems very straightforward.  I don't understand the code well enough to know how/if data in the main form would need to be refreshed once the contact form was saved...

Items 2, 5, and 6b all amount to just loading more data into the form upon selection of a contact or event.  6b seems almost trivial given that civi already checks current- vs max-participants.  Outputting the difference instead of just a full/not message can't be a very big deal.  (I might attack this one myself). 

[Eileen]

Just a quick note re Make-It-Happen (MIHs) - the theory is that you have enough $$ to knock off a number of items. You can either pay out your $$ until they are gone & you get what you sponsored OR you can seed fund an MIH - which would mean that others will hopefully step up & supplement what you contribute so that a more complete solution / feature set comes out of it.

Going down the MIH path wouldn't stop you from getting work started on some items in time for 4.2

[Dave Greenberg]

Kirk - These all seem like good additions and improvements (excluding item 4 for now which we've said would be best to discuss separately).

I think #1, #2 and the miscellaneous improvements (#6) could be grouped together as a single project - "Streamline back-office credit card transaction input". Ballpark estimate for this set would be ~40 hrs.

RE #3 - Sounds like you do NOT need to account for fee_level / fee_amount differences when you change events. Is this because all your events have the same fee structure? If we take the simplistic approach and just change the event_id w/o updating the $$-related fields (and w/o updating associated contribution record) - seems like things would be "out of balance". I guess we could allow this via UI and "warn" the user that the fee data would not be changed / would reflect the original event fee?? As Eileen noted, supporting adjustments to fees received should probably wait for CiviAccounts functionality.

RE #5 - Adding a link to open contact edit form in a new window is trivial BUT might not be the best approach. Opening a pop-up form based on a profile seems preferable - since you could control which fields to include and user could save the changes inline and get returned to the participant form. This feature could use the existing reserved "New Individual" profile. Alternatively, Adam Wight at Giant Rabbit just submitted a potential patch to set a "default event registration profile" - which could be used here. We can check w/ Kurund on a ballpark for this once we figure out an approach.

RE #7 - Don't know much about this, but I agree with Lobo that a Drupal module might be the way to go.

[kmarkley]

Thanks.

I am pursuing #4 separately here: http://forum.civicrm.org/index.php?topic=22802  It makes sense that it doesn't belong with the others, but it remains an organizational priority and therefore will affect the funding available for the other stuff.

RE #3:  As it stands now, one can cancel a registration and create a new one.  If the new event is set up for it, one could manually adjust the fee for the new registration and force things to balance.  Adding a feature to simply transfer the registration without regard to fees should in no way prevent this current workflow or a more sophisticated one that might arise from the civiAccount project. 

But for those us us with dozens of events that are identical but for the date, it would be a great efficiency improvement to have simple ticket exchange.

It is obviously true that transferring a registration to a new event might be wholly inappropriate, for instance if the fees are radically different.  For this reason the feature should be separately permissioned (and globally disable-able) so that it is only available to folks who can be trusted to not use it inappropriately and/or those with the authority to make an exception to any fee differences.

If people still feel it is a dangerous idea, what if the system limited transfers to events that used the same price set as the original registration?  This would cover my use case and certainly limit the possibility of getting the money all "out of balance". 

RE #5:  That sounds much nicer than my idea.  Especially if it can be rolled into other work.

RE #7: I don't know much about this either except it slows the queue down to a crawl to process credit cards like at the entrance to an event.  I'm grasping at any/all improvements in this area.

[Dave Greenberg]

I'll ask Kurund for a ballpark on #5 using a profile.

RE: #3 - Limiting transfer of registration to events using the same price set seems like a good 1st step. That's probably a simple change and we could include that in the "Streamline ..." project

Would be good to get these in the 4.2 queue relatively soon. Keep us posted about funding availability.