RNAO

• Simplest approach is to add contribution_type_id to price set field and line items. We already use that model for membership (membership_type pushes contribution_type_id into contribution records, event pushes it into contribution records for event registration).
  • I agree with this implementation pattern.
  • Potential additional scope (need to consult client): we will need to use similar pattern for premiums, but in that case I believe we need one account for the cost of the item and a second account for the markup on the item, ie the non-deductible amount represented by (market value - cost). So we would need to add cost_account_id (or cost_contribution_type_id if that table is not renamed) and markup_account_id to civicrm_product table, from where it will be pushed to civicrm_premiums. In place of civicrm_contribution.non_deductible_amount we would now need non_deductible_cost_amount, non_deductible_markup_amount, non_deductible_cost_account_id, and non_deductible_markup_account_id. (Unsupported use case: cost and markup of same product getting different accounting codes depending on which campaign page it appears on.)
  • Potential additional scope (need to consult client): we may need to associate an account_id with each fee level, meaning we would likely need to move fee levels out of civicrm_option_value and civicrm_option_group into their own table.

• Add contribution_type to existing Price Set custom search (list and export).
  • Add optional column for Accounting code to
    • Bookkeeping Transactions Report,
    • Donor Report (Summary),
    • Donor Report (Detail),
    • Membership Report (Summary),
    • Membership Report (Detail),
    • Donation Summary Report (Organization),
    • Pledge Summary Report,
    • Pledged But Not Paid Report.

3hrs per report (JMA)

• • Out of scope: Add optional column for Accounting code to:
    • Donation Summary Report (Household),
    • Top Donors Report,
    • SYBUNT Report,
    • LYBUNT Report,
    • Grant Report,
    • Soft Credit Report.

Issues:

• For price-set registrations where each line item has its own contribution type, what do we put in the contribution (payment) record?
  • A separate contribution type for the whole page would be appropriate. This might be a summary account in the accounting package. The migration of data into the accounting package will need to ensure that there is no double counting of detail and summary lines for the transaction.
• What are the additional search / reporting / export / api requirements?
  • Out of scope: civicrm_event_create($params) - shouldn't this already support contribution_type_id? I guess it is supported but just not shown on API page in example. But as we will not be using the API, this is not a requirement for us.
  • Out of scope: add $params['accounting_code'] as an optional substitute or equivalent for $params['contribution_type_id'] or $params['contribution_type']
  • Out of scope: while we don't need this, I'm unable to see how to create additional named participant registrations through API, or to retrieve participants according to whether they are primary or additional participants.
  • Out of scope: While we don't need this, I'm unable to see how to access price sets, fields, and line items through API either for configuration or for a transactio

25 hrs (assumes custom search is only output)

This scope assumes using the new contribution = obligation model. Payments and refunds are recorded in the financial_trxn table. Foundation work for this is covered in the sizing for Partial Payments below.

Phase 1: Issue a refund of $xx amount against an existing contribution (payment).

The user selects a "Refund" action for paid membership, event registration or contribution record. Goes to a form where they can enter amount to be refunded, confirm date and add refund reason. Option to send refund notification email. This phase does not include modifying event fee or line item selections. If this is needed, user enters a full refund + new registration.

There are two parts to the accounting for this. First is the creation of credit adjustment transaction(s) that records a negative amount against the account for each line item or line sub-item being reversed. When the invoice is reissued, there will be a link between the refund and the item being refunded. This will be represented in the db by new records in the civicrm_invoice_line_item and civicrm_invoice_line_sub_item tables with the same account code as the original with a negative amount. The original records will have a link created to the reversing record, as well as to a credit adjustment record that collects all changes made at one time and records a reason for them. The second part of the accounting is the creation of a financial transaction representing the money transfer back to the contact. This action records a negative financial trxn linked to the existing invoice record (or its line items or line sub items if the refund/reversal is for particular item(s) on the invoice.

Processor interaction for refund is optional for payments made via processors that support refunds. Some processors may NOT support partial refunds (needs investigation). For checks or other "manually recorded" payments, we still create the "refund contribution" record.

Completed contributions (donations or contribution payments for memberships, events) can no longer be cancelled in place. Users will need to use the "Refund" action.

50 hrs

Phase 2: Linking refunds to specific line-items.

A refund needs to generate reversal G/L entries at the line item level. Also, support is needed for charging a cancellation fee, which is like a line item.This phase pretty much collapses into the next item below as a result.

Change existing registration fees / selections

The principal requirement in this area is to support changes to event registrations and membership purchases. Registration changes in particular are frequent and need to have an easy to use UX. From a user perspective, they are able to 'edit' an existing invoice transaction. Internally, if there are changes at the time of save, create a new registration/purchase, mark the original as superceded, and record the refund/additional amount in a new difference_amount field.

Issue: how do backoffice staff do an additional payment in case of non-present credit card? Answer: RNAO accept any of a variety of methods of payment for any obligation, including cash, cheques, credit cards, special RNAO credits in accounting system (treated like any other G/L account), etc. They would likely do a PoS terminal credit card transaction if they are getting the credit card over the phone, though it might be nice to do it online via CiviCRM if that is legit.

JM Jan 6, 2011: Additional note: to be more explicit, the changes to existing fees need to be tracked at the line item level, so that if there is a cancellation of one and an addition of another, that needs to be tracked as two separate line item G/L entries.

100 hrs rough est

Included in above Reversals and Refunds estimate.

Phase 1

• API and batch input workflow
  • create and manage batches (list items, set batch status)
  • input checks for new / existing contacts via input grid
  • Batch Report

75 hrs (JMA for reporting)

Phase 2

• Assignment of a payment to an outstanding obligation (i.e. membership or event registration or pledge payment or pay-later contribution)

25 hrs

Using the model which separates obligations (contributions) from payments (financial transactions) - see spec w/ my comments here: http://wiki.civicrm.org/confluence/display/CRM/Partial+Payments+for+Event+Registrations+and+Memberships: $9375