Written confirmation

Problem/Motivation

Sending written statements of confirmation are important for both immediately validating oral declarations that lack recordings (guidance 3.10.1), and (potentially long after the declaration created) validating any declaration that lacks sufficient evidence (guidance 3.8.1). Although HMRC discusses these issues separately they are in fact exactly the same in their underlying logic.

Additionally:
A written confirmation is also an acceptable way of providing the required 'explanation' to a donor (guidance 3.6.2 says "explanation can be included on a Gift Aid declaration but can also be made separately").

B . Lastly, sites may wish to send confirmations in some or all cases even where they don't strictly need to, simply to minimise audit-related risk.

C. Sites may in some circumstances wish to resend confirmations, for example if they discover mistakes in the text of past confirmations, in cases of data entry error, or updated donor contact information.

Cancellation

The most obvious call to action in a written confirmation email is basically "click here to cancel this declaration" which HMRC expects to be retrospective cancellation if done within 30 days of the confirmation being sent. An edge case to consider here however is that when dealing with written confirmations done years after the declaration was made, the donor might wish instead to communicate something like "yeah, that declaration is fine when I made it 4 years ago, but actually I stopped being a taxpayer last year". This consideration has 2 consequences:

(A) We need to have 2 templates, one for immediate confirmation, one for long-after confirmation.
(B) We shouldn't assume at the API level that a cancellation within 30 days of confirmation being sent is a retrospective retraction of the declaration (even though our UI might default to that and we might not provide other options to donors).

Proposed resolution

Stage 1
a. Have a confirmation_date field on the declaration that marks the date the last written confirmation was sent.
b. Create a confirmation event that represents a wish to send a confirmation for a particular declaration. Subscribers should be able to stop the event being processed by further subscribers e.g. first one wins.
c. There should be 2 kinds of confirmation event, one for immediate confirmation and one for retrospective confirmation.
d. Have DeclarationForm dispatch the event post-save if the validity is NEEDS_CONFIRMATION and the confirmation_date field is blank.
e. Uncertain: do subscribers tell the even about the date confirmation sent and give the event the appropriate evidence entities they've created and leave it to the event caller to save these on the declaration, or do the subscribers save them on the declaration directly.

Stage 2
a. Create an email confirmation subscriber that sends a confirmation email, using a different template for the 2 kinds of confirmation.
b. The email templates should link to a cancellation form that retracts the declaration altogether
c. There shoud be an email evidence entity representing the confirmation and its text, to/from emails, date, etc.

Stage 3 (postponed)
Add an extra field 'send_confirmation' for declarations 'Send a written confirmation to the donor'.
The value of this (if enabled) is considered by DeclarationForm when deciding whether or not to send a confirmation.

Remaining tasks

User interface changes

API changes

Data model changes