Problem/Motivation

Follow on from #3572561: Invalidation as a separate process from Cancellation.

In the other issue we joined together Cancellation plus Invalidation, so that they always occurred together, without a way to do each one separately. In the default, common case this is fine, but there might also be more complex cases.

  1. If we have a "years old" declaration with a recent confirmation, the Donor might make a clear request for a proactive cancellation.
  2. If we have multiple declarations each with a recent confirmation, the Donor might make a clear request to cancel just some.
  3. If we have a "years old" declaration with a recent confirmation, and another overlapping one that's solid, then the Donor might make a clear request to retroactively cancel the former but keep the latter.
  4. If we have a "years old" declaration with a recent confirmation, and another overlapping one that's solid, then the Donor might accept our offer to cancel Gift Aid "as if never made". Then they are surprised or even upset that we are still claiming on the solid one - because throughout the entire process we never mentioned it - and HMRC chase them a penalty. Sure, hopefully we have solid evidence, but it doesn't seem good for our relationship with either the Donor or HMRC.

Proposed resolution

  1. We could have a flag on the confirmation entity for "proactive only"
  2. We can set the validity to invalid or invalidated on specific declarations. Or if you prefer, have cancellations with a reference to a specific declaration (more code, but more consistent UI)
  3. We could set date-based to FALSE on the cancellation entity, or use the previous solution
  4. Perhaps we shouldn't send out the default confirmation mail in these cases, but instead leave the staff to resolve the process manually. Perhaps this part belongs on #3570296: Improve self-cancellation UI. We can at least fix the text in DonorCancelForm::getDescription()

Remaining tasks

User interface changes

API changes

Data model changes

Comments

adamps created an issue. See original summary.

adamps’s picture

adamps commented

From #17 on the original issue by Jonathan:

I think the overriding principle in these edge cases should be that what happens matches what we tell the donor should happen. In particular we need to be very careful about what we promise the donor about retrospective cancellation and never underdeliver on that; if in doubt, underpromise and overdeliver.

I think currently we violate this with DonorCancelForm::getDescription(), where we promise total retroactive cancellation if there's one single declaration that can be retroactively cancelled?

I think we can handle this here by not being specific about whether there's retroactive cancellation when it's not obvious there is. We could say that this is the case if there's more than one declaration, but actually even that is not straightforward. More old declarations could be input later, or moved from another context. So maybe we just don't mention retroactivity on the self-cancel form?

It does seem possible in principle to precalculate the impacts of a cancellation as a range of dates that will be affected (for date based declarations). I think we could regard that as our "our design can in principle support this" solution, but definitely ignore it for now. It's hard to communicate well, beyond the 99% use case, and has risky gotchas.

adamps’s picture

adamps commented

We also have #3570296: Improve self-cancellation UI which is potentially more relevant for item 4), and self-cancellation.

adamps’s picture

adamps commented
Issue summary: View changes