CiviCRM Community Forums (archive)

We have a customer who regularly enters batches of membership and contribution transactions. Apparently she might have 200 in a day so needs a good data entry method (which her existing desktop system does provide).

Some of the complexities are

1) people might pay a membership fee and a donation in the same payment and the membership fee is off a variable amount. Ie. an $80 payment might be a $60 membership and a $20 payment or it might be a $80 membership. The distinction is important

2) When entering family memberships they need to be able to select and edit family relationships without a long-winded method

3) they would ideally be able to enter memberships and non-memberships in the same batch entry. Along with cheque numbers. They would want a banking deposit slip for cash & cheque payments.

Gaps

So, obviously it's great that there is a batch data entry screen. However, I'm trying to figure out how to adjust it so that the customer will accept it as a replacement for what they have

My UI Observations

• The UI is hard to work with. Even before I add custom fields it's off the side of my screen. There seems to be mostly because of wasted space - columns are a bit too wide, the height of the columns is more than needed to fit in the word 'OR' (see pic attached). Wrapping the text  or shortening the header of the 'send receipt' column would narrow that column considerably
• At 40 rows the fill down javascript buttons are slow enough I get that long-running script message
• Entering dates. It doesn't seem to be possible to type a date into date picker fields. Having to switch to using a mouse to enter a date seems painful. It I try to tab from one field to the next it appears not to work. However, on closer analysis it is tabbing - just it's stopping on all the 'clear' links as well as the fields

Missing functionality

• Ability to enter memberships and non memberships contributions in one batch
• Ability to break down the payment while doing data entry
• Ability to adjust membership relationships without too much pain
• Check number isn't on the membership batch entry

Thoughts on how to go forwards

The customer's existing system has 'more' or '...' fields on things like 'Financial Type' which would pop up an in-screen little priceset box to do data entry on. Obviously some summary of this would need to be visible back on the batch form.

They also have a field 'family members' which pre-populates the number of members with the family relationship. (which is the relationship type tied to the membership). The box allows the to edit family members and select which ones inherit the relationships.

So, adding these as pop-up editable boxes off the batch form is one options.

Another is having the ability to pop up an entire form for each individual row so that a more complete form could be presented with the fields as on the batch & extra features for entering price sets. There are a couple of possibly advantages to this

1) it means not having to worry about the UI issues mentioned above - a form per person that feeds back to the batch screen provides the benefits of the batch screen without being constrained by the layout (obviously any data entered or filled down in batch mode would prepopulate into the popup & it would contain the same fields but also offer price sets as an option & some way to edit / select relationships for membership types). I realise Nicolas has done some work on the relationships side

2) The form to enter the membership with a bunch of profile fields would be re-usable as a back office form.  At the moment I'm finding people are directing staff to 'log out and fill in the membership page as if you were them' rather the do data entry 'back-office' and have to fill in contact fields on one tab, membership fields on another & have too many fields on the screen that are unrelated.

Any feedback / thoughts?

The approach we take to this in OMMS, is by making it much quicker to navigate to a page where you engage in the process with a contact.

Given the vagaries of Internet connections/people's computers/volunteers interrupted in the middle of processing something etc, I believe it is better to have a screen focused on processing each contact's transaction quickly, rather than enter a whole lot of transactions on the one screen and then hit submit and then go back and stamp each donation/application form etc as processed (and what if some fail!).

What clients need in their "membership renewal" or "donation entry" screen etc will vary wildly between clients, so this should be in the "client app" which can use the flexibility and power of existing "app frameworks" like Drupal, Zend Framework, ObjectiveC (mobile apps) etc to present the appropriate fields, and then use the CiviCRM API to process the transaction.

So what we've done is make it really easy for a person to type in the name or membership number of a person, and go straight to that processing screen.  They then enter the info, hit submit, wait for the success message, stamp the form as processed and move on to the next one.

If all of these transactions need to be linked together in a "batch" then the processing screen can be "batch aware" - there are various ways this could be done.

You can then write rules as to what should happen on each transaction being processed through the data entry screen (eg credit card transactions) and/or when the batch is processed (eg cash/cheques are banked).

Upon the relevant events, the rules trigger actions in CiviCRM through the API, CiviCRM returns a meaningful success or error message and then the app can direct the user accordingly.  It can make sense for some rules to be within CiviCRM core, but I think that are bigger architectural "fish to fry" in core Civi before trying to put in a rules engine (http://en.wikipedia.org/wiki/Business_rules_engine).

That's the way we like to do it anyway :-)

Hope that helps!

Happy to have a Skype call to discuss.

I just tested entering dates from the keyboard and it works fine for me (Firefox 22). Not sure why it's not working for you ??

what syntax did you use for the date - I tried a few but the only one that seemed to not cause validation errors then was replace by today's date

re date input, used mm/dd/yyyy (same format as widget inserts).