1. Export for Acknowledgments

Requirements

Provide a mechanism to export core and custom contact + contribution + membership data on a regular basis. Data set filtered by contribution receipt date range. Field list attached.

Proposed Implementation

CRM-10071: Create a new CiviReport - "Contribution and Membership Details", based on the "Contribution Details" report, but adding Display Column options for membership fields. Membership fields will be populated for rows where the contribution record is linked to a membership record (signup or renewal). Users will be able to select any subset of fields for a specific purpose (and save as a new report instance if applicable). "Export to CSV" will include all selected display columns plus all relevant record ID's (primary keys for contact, contribution, recurring contribution, membership …).

Estimate: 20 hrs (10 EFF, 10 core team)

2. Recurring Contribution Improvements

Requirements

Allow authorized EFF staff to cancel or modify a recurring contribution or an auto-renew membership from CiviCRM. Cancellation should update CiviCRM database recurring contribution status, insert an activity record, and use Authorize.net ARB (automated recurring billing) API to send cancellation request to the processor. Updates should modify the CiviCRM recurring contribution record, insert an activity record, and use Authorize.net ARB (automated recurring billing) API (or relevant API for PayPal and Google) to send the change request to the processor.

Allow donors to cancel or modify a recurring contribution or an auto-renew membership from CiviCRM links which are included in each recurring contribution / auto-renew membership receipt.

Implementation

Detailed specifications can be found on the issue tracker.

Recurring Contributions

• Staff (admin) cancellation is triggered from a contact's Recurring Contributions listing - 'Cancel' action link. If processor supports API-based cancellation (e.g. Auth.net, PayPal …), prompt user as to whether they want to send cancellation request to the process (default) OR just update recurring contribution status to cancelled.
  
  
• Staff (admin) update is triggered from 'Edit' action link. Edit form allows changes to amount and number of installments (Auth.net does not allow change to frequency).
  
  

• Staff (admin) can enter new credit card details and / or update billing address from an action link (Change Billing Details). Form has Credit Card Information block (cc type, cc #, exp date and CSC all required), and Billing Name and Address block. Existing values are pre-filled for Billing Name and Address when form is loaded.

• Recurring contribution / auto-renew membership initial notification AND subsequent receipts should include a link to Cancel a recurring contribution (similar to existing CancelSubscription link and page for auto-renew memberships). Donors confirm the Cancellation request by clicking a button on the web page. Cancellation confirmation email should be sent to donor.
  
  
• Recurring contribution initial notification and subsequent receipts should include a separate link to Update a recurring contribution. Link includes checksum and loads an edit form with fields to update amount, and number of installments. Separate link to Change Billing Details. Link includes checksum and loads an edit form with fields to enter new Credit Card Information, as well as Billing Name and Address fields (these are pre-filled).  Update confirmation email should be sent to donor.

Auto-renew Memberships

* Staff (admin) cancellation is triggered from a contact's Memberships listing - 'Cancel' action link. If processor supports API-based cancellation (e.g. Auth.net, PayPal …), prompt user as to whether they want to send cancellation request to the process (default) OR just update the status of the associated contribution_recur record to cancelled.

* Staff (admin) can enter new credit card details and / or update billing address from an action link (Change Billing Details). Form has Credit Card Information block (cc type, cc #, exp date and CSC all required), and Billing Name and Address block. Existing values are pre-filled for Billing Name and Address when form is loaded.

* Auto-renew memberships initial notification email AND subsequent renewal receipts should include a link to Cancel the automatic renewal (this is existing functionality). Donors confirm the Cancellation request by clicking a button on the web page. Cancellation confirmation email should be sent to member.

* Auto-renew memberships initial notification and subsequent renewal receipts should include a separate link to Change Billing Details for the auto-renewal. Link includes checksum and loads an edit form with fields to enter new credit card details, and Billing Name and Address fields (these are pre-filled).  Update confirmation email should be sent to member. NOTE: Frequency and amount values are driven by the membership type configuration and can not be modified by the end-user.

Additional Issues

• What other processor(s) need to be supported with this functionality? Each processor may have different rules about what can be updated via API (if anything). Will need to create stub function for each processor (updateSubscription).
  • Need PayPal and Auth.net, and Google Checkout for now.
• Donors may receive a cancellation or update notification from Authorize.net. Can / should this be suppressed so that they don't receive duplicate notifications?
  • See if we can suppress processor notifications (I think there's a flag for that in Auth.net API, not sure about others).
• BUG FIX: Currently when we get recurring contrib w/ non-matching amount, we ignore it. Instead we should treat this as an update (update contribution_recur and create activity record).
• CRM-9459 - Review patches from Ryan and Jeremy - and incorporate if appropriate and useful. In particular, this patch appears to be making Failure Count and Failure Retry Date available in the recurring contribution selector (listing) which would definitely be useful for admins. Probably should also expose these values to 'view' page if their not present already.

Estimate: 50 hrs (30 EFF, 20 core team)

3. Scaling / Interface Responsiveness Issues

Requirements

Need to resolve the following "scaling" bottlenecks:

- quick search (autocomplete) is fast, but behavior if clicking enter is a lot slower

- advanced search

- activities tab (more activities takes longer)

- manage groups > view contacts in a group

Proposed Implementation

Integrate Solr search engine (tentative, needs further investigation)

Estimate: TBD

4. Batch data entry for contributions and membership payments

Requirements

Provide a streamlined interface for data entry of batches of contributions and membership payments (checks). Allow selecting existing contact or creating new contact (and populating existing contact values). Field selection should probably be profile-driven to provide flexibility in the fields that are included. List of fields required by EFF is attached.

Design issues:

* Ajax-based form vs. grid/spreadsheet format UI? Blackbaud and Convio Commonground both use spreadsheet format. Blackbaud provides overlay form for adding a new contact or updating contact details such as address, phone etc. We should investigate UI models provided by other donor management applications.

* Is it best to have separate processes (grid / form) for regular contributions vs. membership signup/renewals? This would reduce the number of fields needed for each type of input and potentially simplify things.

• Ok to have separate process.

* Do we need to support back-office credit card payments - or is this just for checks and cash?

• Just for checks and cash

* Blackbaud and Convio both provide dynamic status "bar" showing count and total amount entered in "batch". This functionality integrates logically with the CiviAccounts Specifications - Batches "Manual Batches" specification. Does EFF need 'batching' functionality at this time?

• Yes, include basic batching functionality (enter count + total at the beginning, verify when "done")

Implementation

Profile driven batch grid. Will discuss details with Aaron and other EFF stakeholders.

Estimate: 150 total (50 from EFF, 50 from MIH, 50 core team)

5. Allow end-user to select from multiple payment processors on single online contribution page

Requirements

Administrators should be able to configure online contribution pages to offer a choice of available payment processors to donors.

Implementation

* Modify schema to allow 1 : many relationship between online contribution pages and enabled payment processors

* Modify contribution page configuration screen to allow "multiple select" for payment processors that allow all features selected (i.e. recurring if enabled).

* Modify online contribution page form to conditionally provide radio button field to select from payment processors offered (if > 1 processor is configured for that page). Pay later and direct debit could now be part of these options.

* Modify post processing to invoke selected processor

Estimate: 50 hrs  (25 EFF, 25 MIH)

6. Additional Fixes and Improvements

Optimize Repeat Contribution Report

Currently report takes a long time to render or times out.

Estimate: 10 hrs

Add/Edit Contribution: Soft credit pane auto-complete

Can't select desired contact if more than 10 matches on the same name 'Smith, Elliot". Either provide a 'more' option in the drop down when > 10 exact matches, OR increase the number of records returned for this instance of the widget to 20.

Estimate: 1 - 4 hrs (depends on approach)

Project Totals

Total Estimated for all Items: ~220 hours

Charged to EFF contract: 115 hours

Items in section 6 will be included as time allows.