E-mail
Custom data on contribution
- eligible for gift aid (required boolean)
- Contributor name (view only)
- Contributor address (view only)
- Contributor post code (view only)
- Contribution amount (view only)
- Gift aid amount (view only)
These fields are set at the time of the contribution. A hook then updates the Individual contact record (see below). Once submitted these fields are view only and cannot be edited.
Custom data on individual
- current gift aid status
- Start Date : Date Type
- End Date : Date Type
- Reason Ended : Alphanumeric ñ Radio Type
- HMRC declined
- Contact declined
- Source : Alphanumeric Text Type
- Notes : Note Textarea Type
Can be overrided by admin. Administrators need the ability to update records manually: for example
- where a user makes a contribution over the phone and declares a change of status
- where a user reports e.g. that they are currently eligible and will remain so until November when they will be ineligible for 9 months. It will be important record this chain of dates for the user's recurring donations.
Set each time a contribution is made with hook.
Gift aid profile
- From person
- name
- address fields
- From contribution
- eligible for gift aid
- Declaration
Constant in module
Rate of gift aid - but this should have a date range in case the basic rate of tax changes.
What happens on user contributions
eligible for gift aid field gets set to yes or no and start and end dates are set as follows:
[eligible | start | end]
if (no or no record and this == no) do nothing
if (no or no record and this == yes) create new row eligible=>yes, set start date=>now, set end date=> now+3yrs
if (yes and this == yes) set end date=> now+3yrs
if (yes and this = no) create new row eligible=>no, set start date=>now, amend previous end date=>now
So user's gift aid record starts life as
[ | | ]
For users making contributions the following might happen
01-jan-10 user makes contrib, says yes =>
[yes|01-01-10|01-01-13]
01-jun-10 user makes contrib, says yes =>
[yes|01-01-10|01-06-13]
01-jan-11 user makes contrib, says no =>
[yes|01-01-10|01-01-11]
[no|01-01-11|-]
01-jun-11 user makes contrib, says no =>
[yes|01-01-10|01-01-11]
[no|01-01-11|-]
01-jan-12 user sets up monthly regular contrib, says yes =>
[yes|01-01-10|01-01-11]
[no|01-01-11|01-01-12]
[yes|01-01-12|01-01-15]
01-jun-12 user calls to say will be no between 1 jul and 1 oct
admin updates=>
[yes|01-01-10|01-01-11]
[no|01-01-11|01-01-12]
[yes|01-01-12|01-07-12]
[no|01-07-12|01|10|12]
[yes|01-10-12|01-10-15]
We don't care that there is no end date on some of the 'no' lines since the calculations of which contributions are eligible will be performed on the 'yes' date ranges but we add end dates to no when known.
Pseudo-code for setting Individual declaration custom fields when a contribution is submitted:
(by DaveJ 4 Oct 2010, please review)
Get current declarations: start_date in past, end_date in future or null
- if > 1, pick latest end_date? (There shouldn't be > 1, we could implement validate
hook to enforce this when admin edits through UI)
Get future declarations: start_date in future, end_date in future or null
- if > 1, pick earliest start_date?
If there's a current declaration:
- if new declaration is positive, new_end_date = if end_date specified then (earlier of (a) now + 3y, (b) specified end_date) else (earlier of (a) now + 3y, (b) start_date of first future declaration):
- - if current declaration is positive, extend its end_date to new_end_date.
- - if current declaration is negative, set its end_date to now and create new ending new_end_date.
- if new declaration is negative, new_end_date = if end_date specified then (earlier of (a) now + 3y, (b) specified end_date) else (start_date of first future declaration if any, else null):
- - if current declaration is positive, set its end_date to now and create new ending new_end_date.
- - if current declaration is negative, leave as is.
If no current declaration, create new:
- if new positive, end_date = if end_date specified then (earlier of (a) now + 3y, (b) specified end_date) else (earlier of (a) now + 3y, (b) start_date of first future declaration.
- if new negative, end_date = if end_date specified then (earlier of (a) now + 3y, (b) specified end_date) else (start_date of first future declaration if any, else null).
Version 2 implementation
See notes on http://wiki.civicrm.org/confluence/display/CRM/Gift+aid+requirements for an introduction to v2 discussions...
Pending contribution based on the giftaid value
At the moment there is a custom field <name>Amount</name> <data_type>Money</data_type> in civicrm_value_gift_aid_submission.
In the current model, if you did a search for how much the contributor has given, you won't catch the extra 20p because it is stored as a custom field, not a contribution.
These pending contributions need to be added to the same batch as the contribution they relate to (how?!) because after the batch is sent to HMRC (UK tax agency), they will process it, and either report that all contributions are eligible for gift aid, or give a list of exceptions that aren't eligible (and say that the rest are eligible).
The key word here is pending. When HMRC says, this person (and contribution) are not eligible for gift aid, the pending gift aid contribution for that person should be set to failed and a negative declaration should be recorded on their record.
Then, the gift aid processor runs a task that converts all pending contributions from gift aid batch X to completed (automatically excluding failed contributions).
Support for multiple charities
Some cases there are multiple charities that each need a gift aid declaration. Any contributions made to a given charity (csutom field to signify which charity) need to be checked against the giftaid declaration that one exist for that charity (matching custome field name).
We'll add a new hook when we have a set of contributions that are going to be batched for giftaid. The hook can then filter out all the contributions that are not eligible. Hence we can use Alpha specific custom fields in the hook
Preview of what is added or excluded
When running a gift aid batch there is no preview of what is added or excluded in the gift aid batch page just a number summary. Actual details are required
This can be done as enhancement to the core gift aid module.
contribution types automatically set as not eligable for gift aid
An exception table that means certain contribution types are automatically set as not eligable for gift aid.
This can be done in the same hook as item2.
