E-mail
This is an attempt to separate out the unique aspects of the initiatives discussed into discrete sponsorable entities and to identify the dependencies (i.e. some items depend on the underlying payments work, some on the invoice work, some on both & some on neither.) This will eventually be merged back into the main document but not just yet
1) UI change to Record ALL payments in payment tables
Contribution receipting screens create 1 records in each of two financial tables. Note that contribution_type_id will need to be recorded in the contribution table as the contribution_page will not be adequate for that.
- Introduce part-paid status - what are the implications on a membership if part-paid - separate scoping required
- report to show over-ride status
(existing payment recording screens)
Contact summary contributions tab- needs to have little '+' box so you see linked payments
2a) Invoice recording - Scenario 1
No dependencies
Add invoice tables: civicrm_invoice & civicrm_entity_contribution
Involves UI, BAO, API changes. Most invoices initially will be one-to-one but, for example, one contribution page could create 1 invoice but 2 contributions (membership & donation)
2b) Invoice recording - Scenario 2
Not dependent on payment work but probably most easily implemented @ the same time
Record a line item for all contributions
Data changes to line_item table Plus UI changes so that a record is created in it for ALL contributions. Note that if this approach is used it would be done as part of the payment recording step
3) New payment recording screen for back end users:
Depends on Payment and Invoice Work
One check/credit card transaction that needs to be allocated to many obligations ( such as event fees, member dues, donations, etc ) (eg Staff/bookkeeper gets a single check, that can be applied to multiple pledge payments, event fees or membership obligations. The bookkeeper should be able to change the allocation if needed. ( For example, 50% of the check is originally applied to an event fee. Later on, it isrefunded for the event and instead applied to a membership fee. ).
BAO + UI for entity_financial_transaction table Dependencies = #1 & #2. Imagine ability to match to entire invoice and to allocate to line items.
4) Auditable functionality :
Dependent on Invoice Work
Invoices CANNOT be deleted only disabled. Even if the contact or every records is deleted no deletion of invoices. Contributions can only be soft deleted. Refund contributions will be created when contributions are cancelled (credit note). These will create a new invoice record.
5) Cancellations:
Depends on payment and invoice work (although incremental may be possible)
When a cancellation of a contribution is made a negative record is created in contribution, invoice, entity_financial transaction, available for re-allocation/ refunds. (note that there may be some variations of how it is displayed in the UI (ie. there may be an option to turn-off display of negative contributions)
6)Contact dashboard information
Incremental - reflection of payment / invoice work:
UI improvements: - The contact should be able to see all financial activity, unpaid obligations, and scheduled payments on their contact dashboard. So if a person ( such as a member ) logins into the website,they can see all their financial activity and current unpaid balance.
7) Front end interface to paying invoices:
Dependent on Payment and Invoice work:
The contact should be able to make a payment online that covers multiple obligations ( either in part or in full ). Such as they make a deposit for school tuition, plus a fundraising dinner, and part of their member dues in a single credit card transaction. A common situation with parents paying for schools is they pay an initial deposit before the school year starts, then make several large payments at the end of each semester.
8) Statements:
Dependent on Payment and Invoice work:
The staff can email or print a statement that shows a summary of all obligations, money received, open balance, and amount due right now. ( i.e. the statement that is attached to this wiki article that uses my custom mail merge tokens. )
9) Batch contribution creation:
Independent requirement:
The staff person should be able to batch-register people for a paid event or membership, or donations or pledge, which results in a unpaid financial obligation for all those contacts. ( Since CiviCRM already supports batch actions for event registrations and membership creation, those existing screens can be enhanced. )
10) Payment scheduling:
Independent requirement:
When the staff creates any type of financial obligation for a contact, they can set up the planned schedule ( such as a pledge of $2400, with payment expected every month for 12 months. ( This already exists in the pledging area of CiviCRM)
11) Dependent on PAYMENT work: Bank reconciliation screen. Includes UI tweak - show which account 'stuff' goes into
12) Taxation.
Dependent on INVOICE work:
Line item level - need to be able to record tax rate or more than one - more scoping required
13) Accounting package integration
Incremental - growth potential based on payment or invoice work
