CiviCRM Community Forums (archive)

Hi Tim,
Super exciting to hear about your interest in helping take Price Sets functionality to "the next level". The functionality that you're looking to add will be quite useful for lots of folks. Good news is the existing data model already supports most (all?) of the features below :-)

The general flow contributing a new set of functionality is ...:
1. Create detailed requirements documentation. Based on your bullet points below, this should include:
   * description of the UI for editing price set data for an existing event registration record - including screenshot of a mockup ideally
   * description of the processing rules when price set data is updated and there is an existing payment (e.g. contribution record)
   * description of UI and processing rules for refund handling (if you want to implement this in a more integrated manner)
   * description of search/reporting requirements - on first look, it seems like most of what you need could be handled well by one or two new reports. describing (and potentially mocking up) the filter criteria needed and the output rows could help determine if a custom search OR a new report OR both are needed. 

NOTE: The main reason that editing of event reg records is not allowed when there's an associated payment that the issue of how to handle associated payment records  (contribution + financial trxn) needs to be resolved. Your 'proposal' should include a recommended approach which can then be shared / discussed with others in the community who use CiviEvent and have an interest in moving this forward.

NOTE: If you haven't dug into the data model for storing paid registrations with price set data - that would be good to do upfront. You can do this by creating a simple price set and 'registering a contact' on a test site (s/b running the latest CiviCRM release). Then examining the affected DB tables: civicrm_participant, civicrm_participant_payment, civicrm_contribution, civicrm_line_item (this table stores 'price set purchases' for each participant in a structured way and will be important to impementing improved search / reporting functions).

2. Post the requirements doc on the wiki under this page:
http://wiki.civicrm.org/confluence/display/CRM/Currently+active+projects

3. Write a blog post describing the project (problems you're solving) at a high level and link to wiki page - asking for feedback. Adjust requirements doc as needed based on relevant community and core team feedback.

4. Work with core team to determine how this project fits into release schedule, and post implementation specifications as issues in the issue tracker. Actual code can be attached as patches to the issues, or potentially committed to an svn branch.

Throughout the process, your developers can consult with core team folks as well as other experienced civi developers via IRC. We can also arrange some Skype chats if needed to consult on design or help folks get oriented. There is also the option of having the core team doing some of this as a sponsored project if RNAO has budget for that and it makes sense based on available resources. Our consulting contract info is here: http://wiki.civicrm.org/confluence/display/CRM/CiviCRM+Consulting+Rate+Sheet

Ping me at dave @ civicrm dot org if you want to set up a phone call to discuss further.

(FYI - the fee_level column in civicrm_event table is now a 'text' field - so the 255 char limit problem is already resolved )

Does the Custom Search Eileen put together provide any thing that is useful in your use case?

» Price Set Details for Event Participants

/civicrm/contact/search/custom?csid=9&reset=1

Interesting that you ask. When we stumbled across that page (and I literally mean stumbled, it's well burried) we initially thought we'd found a solution to our problem.

Unfortunately we later discovered that this data was unusable for our purposes.  The reason being that the bulk of our attendees only signed up for free events.  Because of this, they didn't have a CiviContribute record (in the civicrm_contribution table), and as such, no associated civicrm_line_item rows for these "free" selections.  These registrations were only recorded with a CiviEvent record (in the civicrm_participant table).  The sub-events selected were stored as text in the fee_level column (which made things interesting for registrations that required more than 255 characters to store this data).

Given the tight timeline I didn't have the chance to explore creating CiviContribute records for $0 registrations.  This could have made the search you are referring to a lot more useful for us as it would have captured all registrations.  It would still be nice though to be able to write much more specific searches so that we could have easily created lists for each sub-event at our AGM.

Respected community,

I am working on the development of “Refunds and Partial Payment Module” for CiviCRM, I am requesting that please go through this forum discussion and contribute your valuable feedback:

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

Thanks in anticipation
Regards