Planning on sponsoring some misc improvements (mostly POS stuff)

[e_mason]

re #3 - we've got three potential clients who have asked about this, or some version of it.  There are two situations where this would be useful:

1) Long Term (semester) classes with multiple days.  In this instance, the problem is really one of trying to use the CiviEvent registration as a dynamic class roster.  An event system that allowed for multiple sections of the event might address this, as would using something else (e.g., spreadsheet) to manage section enrollment.  But there are major issues then for limiting enrollment in a particular section.

2) Short Term, repeating events such as tours.  Here  I'd say the price set is less of an issue that the type of event b/c some of the tours are free (well, any price set rule would have to allow for an absence of price set)

[Dave Greenberg]

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

Kurund's estimate for #5 using a reserved profile is 20-30 hrs.

[jcm55]

Also using CiviCRM here for theatre tickets.  We are pretty happy with the feature set for self-service ticket purchases, but we would love to see some improvements around live POS purchases at the theatre.

#1 above (cash / credit live POS in same backend form ) would be amazing
#3 above (registration transfer i.e "ticket exchange) would also be amazing.  Even more amazing if this could be self-service.

We do have some money available to contribute towards these items.

Regarding #7 (USB card swiper support), see my post here:

http://forum.civicrm.org/index.php/topic,23761.0.html

I've been using this URL as a starting point for live POS workflow:

https://www.bactheatre.org/db-test/civicrm/participant/add?reset=1&action=add&context=standalone&mode=live&eid=EVENTID

Appending eid=123 causes the form to load with a specific event preselected.

Using those URL params, along with the USB swiper support I mentioned above, I'm getting pretty close to a decent live POS workflow screen -- for credit card transactions, anyway.

Some outstanding issues:

-- I'd like the contact to be matched (if existing) or created (if not existing) automatically, based on the name data from the CC track.  Email address should be optional, in a separate field, and patrons can supply it if they want a receipt.  Having to click a button and enter new contact data in a separate pop-up is too clunky for live POS workflow.

-- eid and mode URL params are not persistent.  If I complete a transaction and click "Save and New", I'm no longer in mode=live and the event is no longer pre-selected.

-- Billing address and CVV2 fields should be optional.  Many in-person purchasers object to supplying address data, and neither our payment gateway (Authorize.net) nor merchant account provider require it.  We do get a slightly better rate if at least postal code is provided, but we'd still want to accept the transaction if the patron didn't want to provide their postal code.  I've solved this by adding some code to CRM/Event/Form/Participant.php, but perhaps there's a better way: 

Code: [Select]

CRM/Event/Form/Participant.php.orig CRM/Event/Form/Participant.php
--- CRM/Event/Form/Participant.php.orig 2012-03-07 22:38:33.000000000 -0800
+++ CRM/Event/Form/Participant.php 2012-03-07 21:10:47.000000000 -0800
@@ -280,7 +280,20 @@ class CRM_Event_Form_Participant extends
             
             require_once 'CRM/Core/Payment/Form.php';
             CRM_Core_Payment_Form::setCreditCardFields( $this );
-           
+
+            if ($this->_mode == "live") {
+                $notrequired = array(
+                                'billing_street_address-' . $this->_bltID,
+                                'billing_city-' . $this->_bltID,
+                                'billing_state_province_id-' . $this->_bltID,
+                                'billing_postal_code-' . $this->_bltID,
+                                'billing_country_id-' . $this->_bltID,
+                                'cvv2' );
+                foreach ($notrequired as $unsetfield) {
+                    $this->_fields[$unsetfield]['is_required'] = false;
+                }
+            }
+                                       

I'd love to hear suggestions/comments on any of the above.

[Donald Lobo]

couple of thoughts and comments:

1. Might want to chat with kmarkley and see if we can try and improve things for the "tickets workflow". Seems like we are quite close. If both of you are at CiviCon and the code sprints after that, we could potentially sit, hack and get it done

2. Not persisting eid / mode is a bug. Please file an issue and we can address this. Better yet, if you get on IRC we can work with you to create a patch for the issue (its quite trivial)

3. You can make billing address / cvv2 optional via the buildForm hook and hence avoid hacking core

lobo

[Eileen]

3. You can make billing address / cvv2 optional via the buildForm hook and hence avoid hacking core

At some point it would be good to configure cvv to be able to be optional (admin setting)- we just advise our customers to enter 000 rather than customise when it's not required but it's a fairly common request

[kmarkley]

Hi.  So sorry for having dropped the ball on this over the last couple months.  The sad truth is that we are a very small shop and running my organization takes all my attention.  We would really love to see these improvements and have funds budgeted, but it is hard for me to find the time to write up a detailed spec, drum up support for a MIH, etc. etc.

jcm55: If you don't mind me asking, are you actually with BACT, or a developer with BACT as a client?  Perhaps we could work with you to help finish what you've started and expand the scope of work to include more of the items I listed at the top of the thread?

The swiper stuff sounds cool and I'll respond separately to your post.

If its possible to make address/cvv2 optional via a drupal module, I would be down with that as well.  Seems like it might eliminate the need for my #2 above.




So, to recap:

1. CC on same form as cash/check

Seems like there is support for the idea.  Just need to find someone to code it.


2. Loading contact data on CC form.

May not be necessary if billing address and cvv2 can be made optional


3. Transferring a registration.

Seems like there is support for the idea if transfers are limited to events with the same price set.  It probably should still be globally enabled/disabled for those orgs for whom it is not appropriate.  Changes needed in the DB are trivial (just change the event ID in the participant record).  So it is mostly about making a UI, checking against price sets, and creating a configuration option to enable it.


4. Custom report.  Doesn't belong in this project


5. Update contact during registration/contribution.

Possible via profiles.  Need someone to code it.


6a.  Map link smarty variable.

Low priority, maybe shouldn't be included.

6b. Display available participants during registration.

Trivial.  Just needs doing.

6c. Make "paid via" required.

Trivial, but also low priority.  Whatever.


7. USB swiper support.

Well underway already.




I would love to help, but I think that's mostly limited to helping spec, helping fund, and helping test.

[jcm55]

2. Not persisting eid / mode is a bug. Please file an issue and we can address this. Better yet, if you get on IRC we can work with you to create a patch for the issue (its quite trivial)

This is fixed now in CRM-9848 with patch attached.

3. You can make billing address / cvv2 optional via the buildForm hook and hence avoid hacking core

Here's a simple hook to make billing address and cvv2 optional.  As written, it makes those fields optional only on civicrm/participant/add&mode=live but pretty easy to modify this to make them optional elsewhere.

Code: [Select]


function civicrm_billing_fields_optional_civicrm_buildForm( $formName, &$form ) {
    if ( $formName == 'CRM_Event_Form_Participant' && $form->_mode == "live") {
        $blt = $form->_bltID;
        $notrequired = array ( 'billing_street_address-' . $blt,
                               'billing_city-' . $blt,
                               'billing_state_province_id-' . $blt,
                               'billing_postal_code-' . $blt,
                               'billing_country_id-' . $blt,
                               'cvv2');
        $formRequired =& $form->_required;
        $formRequired = array_diff( $formRequired, $notrequired );
    }
}


[jcm55]

jcm55: If you don't mind me asking, are you actually with BACT, or a developer with BACT as a client?  Perhaps we could work with you to help finish what you've started and expand the scope of work to include more of the items I listed at the top of the thread?

My wife is the Executive Director of BACT, and I am the de facto volunteer IT Manager

I'm going to try to make it to the code sprint in SF on 3/30, at least for part of the time, and I'm willing to take a stab at some of the remaining items that have been outlined in this thread.   Although I have a CS degree, I've never written code for a living -- hacking on CiviCRM is actually my first foray into PHP.  So we'll see how it goes

[kmarkley]

Thank you again for your help on this.

I don't want to either overstate nor understate my ability to contribute to this.  I do seem to often get dragged away from the discussion.  And I'm not a coder.  On the other hand, I really do have budgeted dollars to sponsor some improvements.

Maybe we could just divvy up the list?  If there are particular items you'd like to attack yourself, I would be willing/able to just go hire someone to go after the others.  Seems like there is support for items 1 and 3, but (so far) less discussion on how to go about it.  Maybe that's a good place for me to start?

Thoughts?

[kmarkley]

Alright. Its been a week and I'd like to keep this progressing before I get busy/distracted again.

So, I'd like to move forward on hiring someone to deal with transferring registrations between events and unifying the forms for live cc transactions and regular cash/check transactions.  Here's my rough draft spec, if anyone would like to comment or point out errors in my thinking.



Transfer event registrations.

1. Provide enable/disable preference on 'CiviEvent Component Settings' page (civicrm/setting/preferences/event).  Defaults to disabled.

2. When enabled, provide a "Transfer Registration" link next to event name on 'View Participant' page (civicrm/contact/view/participant).

3. Create a form/page with a single select form element displaying events that are active and use the same price set as the event in the original participant record.

4. When form is submitted:

   a. Change the event_id for the participant record to the event id of the selected event
   b. Change the source field for the participant record to "Registration transferred from [old event] by [user] on [date]".
   c. Return to the view participant page.




Use same form for live credit card transactions and regular check/cash/other transactions.

1. Should apply to all back-end forms that currently use the "mode=live" url argument for credit/debit card processing, including:

   civicrm/participant/add
   civicrm/contribute/add
   civicrm/contact/view/contribution?reset=1&action=add
   civicrm/contact/view/participant?reset=1&action=add
   civicrm/contact/view/participant?reset=1&action=update
   etc. etc.

2. Provide a UI (tabs? select? radio?) element to switch between modes.

3. This probably requires re-organizing the form to include a "Payment Details" section to contain the form elements peculiar to each mode.

4. Pre-load form elements for both modes to avoid UI delays when switching modes.

5. Change the UI on the Contributions, Events, and Membership tabs of the View Contact page to display a single button for adding a contribution/registration/membership.

[kmarkley]

I've also been thinking about how we match or create new contacts in contribution/registration forms. 

In addition to the issue I identified earlier about making small changes to a contact's information, there is the desire to match contacts based on the name on a CC data track as mentioned by jcm55.  And even more than that, there's the fact that one must type in a name (last name first) to check for a match and then type it in again (in the opposite order) to create a new contact via the create new contact pop-up form.

What about a flow that works something like this:

• The form presents separate fields for last name, first name, middle name, and billing email. There might also be a hidden field for contact id.
• When you start typing in either the last name or email fields, you are presented with possible matches as you are now.
• If you select a match, the other fields are automatically populated.
• A 'clear' link is provided to clear all the contact fields.
• When the form is submitted:
  
  • If a matching contact was selected, the contact is updated with the data in the form, much as importing contacts in "Fill" mode (i.e. blank fields are ignored, non-blank fields overwrite the db).
  • If a contact was not manually selected, the default dedupe rule is applied just as it is for people who register/contribute from public-facing pages.
  • If there's no match, a new contact is created.

Think something like that could work?

[Dave Greenberg]

Kirk - Wondering if the following "smaller" changes would get you most of what you need for this particular problem (assuming the CC swipe can populate contact fields if a match is detected):

* Selecting an existing contact from the auto-complete populates all known contact field values (including your idea to populate billing address w/ known primary address if we don't yet have a billing address).

* Modify (in your install) the order of fields in the "New Individual" profile so Last Name comes first (you can do this in the Profiles > Fields listing).

What's missing from that solution other than the fact that the "add contact" is not quite inline? How big an issue is that?

[kmarkley]

Well, I get it that my idea might be a bit big for this project.  But the basic issues that are affecting POS workflow are:

1. Typing the contact name in twice - once for matching and again for creating a new contact.

2. Making minor changes to contact info during registration/contribution (as originally identified).

3. Typing the contact name a third time for (unswiped) credit card transactions.

4. Manually entering a billing address in the form when it might already exist in the db  (as originally identified).

5. Matching contacts when a name is entered by a credit card swipe.


It just started to feel to me like we were approaching these as separate issues rather than looking generally at the how contact info is entered and matched. 

On frontend forms, contact matching is done when the form is submitted, and a new contact is created automatically if there is no match.  It seems a little weird to me that on the backend one must first manually check for a match and then manually enter data for a new contact.

My proposal was just about removing ALL duplicate data-entry, based on the basic idea behind a lot of other POS systems. These other systems feel to the end user a lot like working on a local db (think access or filemaker) in which the same form and form elements are used to display, create, and edit a customer's record.

So while I would welcome incremental improvements on any of these issues, I still thought it was worth thinking through how the underlying logic of data entry was perhaps not ideal. 

Not sure what, if anything, this means for the current project.  It's not hard to image that a change like this would be big, slow, and expensive.  Still worth thinking about, though.