Record donor name & address

Interesting.

AFAICS your main reason for proposing using a profile is to share the information across multiple declarations. I don't think it is necessary to update the address on cancelled declarations, so this argument supposes an expectation of multiple ongoing declarations - and this is a case I would prefer to avoid😃.

Absolutely I agree it could work like this however I have some reservations. On the other hand, I see some costs/downsides. Splitting the information between 2 entities (the declaration and the profile) seems to make code more complex. We might need to create both, or just one; they have different life cycles, updated at different times by different means; the references between the entities could become complex especially if clerical errors were made at some point. The profile isn't entirely under the jurisdiction of this module and other modules might alter it. It won't necessarily have log messages, nor a trail of attached evidence.

it must keep a record of the updated information — this can be kept as an electronic copy such as a scanned document.

So we need evidence and presumably it will be on the declaration entities. But each declaration might end up have evidence that entirely fails to match it's current state, because it points to a profile that was initially matching but has since been edited. Possibly there was evidence for that edit, however it might be difficult to find that declaration that holds it or it might even have been deleted (for example because a certain number of years have elapsed from when it expired).

I feel that the concept of a declaration has a legal status in a very clearly defined way. You have some ideas, often clever, potentially a bit mind-boggling, that amount to doing things slightly differently. Whereas I feel we should do exactly what they say😃. The declaration is like a contract that was made with specific statements at a specific time in the past. I believe they want to see the contracts exactly as they were made. A particular declaration might now be outdated, but still can be needed to cover some past donations. So I would like to just mark it as outdated, and otherwise leave it exactly as it was made.

In June 2020, Miss Helen Jones of Bedford granted Gift aid indefinitely. In March 2024 Mrs Helen Smith of Edgeware (the same lady now married with a young child) grants Gift aid for the current year. Let's say she never sent us a change of address, but it's the same user account, so we have some common context. We can show HMRC either declaration and they can match it to their records. However there was no Mrs Smith living in Bedford in 2020.

Let's put this on the list of matters to discuss😃.

When you make a Gift Aid claim you don't show the declarations to the Inland Revenue or break it down by declaration. Instead the claim is specific to a financial year and shows the donors name, address and the total amount of donations in the year for that donor that you're claiming Gift Aid on. The address used should be the best address for the donor that you have, even if you're making a claim for 3 years ago when they gave you an older address.

So the concept of address is really more at the level of the donor rather than the declaration, even if it needs to be present on the declaration.

OK that makes sense, thanks. Probably you are right and perhaps I am worrying about nothing. However the audit process states that the auditor will ask to see the relevant Gift Aid declaration, plus various other things.

I think your concerns about audit are worth taking seriously for sure. Maybe revisions and Entity Reference Revisions for the profile reference field would address it. Or just store the address *at the time of declaration* on the declaration in an address field that doesn't get updated.

Yes that could work.

Or another option, instead of using a profile we could make a Donor entity type. It could share code with Declaration using a trait or shared base type. This would allow both entity types to share the same set of whatever protection mechanisms we devise: revisions, author, date, log messages (the text field that describes the change, I forget the proper name), evidence fields, etc.

we could make a Donor entity type

That's probably got advantages. My hesitation about using a solution other than profiles, is that if one is using commerce, then the customer naturally has a set of already provided addresses in the customer profiles, which it makes sense to allow as options.

My suspicion is that this will be hard to answer until we have a more precise articulation of the exact UI scenarios we need to cover.

Requirements for Donor entity

• Prevent it being deleted (except admin override)
• Have revisions with author and date
• Name and address field both mandatory
• Distinct from other non-Donor things (if using profiles, need to know which ones represent donors)
• Be clearly identified as a Donor, so anyone editing it is aware that it specifically represents name and address for Gift aid purposes
• Staff editing: requirement to provide evidence with a file/media attachment
• Staff viewing show: a list of declarations; button to add a declaration; cancellation button (with date)

Completely agree, reusing is good and we should gather all the information before deciding. My intuition at this point is towards the separate Donor entity because "Donor" and "profile" are not the same concept, and have different requirements. The Donor entity is governed by legal requirements and basically we don't want anyone else messing with it.

If we do create a new entity, then we need to look at the implications. Presumably we would copy the address from the profile, which means that the address now exists in 2 places; someone might change one and forget to change the other. However we might not always want to change both together: e.g. perhaps a customer orders a gift to send to someone else, and chooses to edit their own commerce profile rather than create a new one (slightly strange, but seems nevertheless valid). Obviously this shouldn't change the Gift Aid information.

I feel that if we use the existing commerce profile, then we don't actually solve the Problem/Motivation in the IS: profile might get deleted too soon; order might not have an address; revisions are off by default; staff not required to provide evidence; lack of clarity which profiles relate to gift aid.

If we create a new profile type "gift aid" then we could solve many of these, but then we have the address existing in 2 places anyway. So the choice between "Donor entity" and "gift aid profile type" is likely just a matter of ease of implementation. The profile type automatically comes with lots of free stuff, including a user tab, however there's a risk it will end up being not quite the stuff that we want and difficult/impossible to alter.

Profiles are tied into users: I can't find any UI to create a profile independently of a user. The global profile listing page includes all profile types and there are no filters.

The profile type automatically comes with lots of free stuff, including a user tab, however there's a risk it will end up being not quite the stuff that we want and difficult/impossible to alter.

Yes.

So the choice between "Donor entity" and "gift aid profile type" is likely just a matter of ease of implementation.

Yes.

I feel that if we use the existing commerce profile, then we don't actually solve the Problem/Motivation in the IS: profile might get deleted too soon; order might not have an address; revisions are off by default; staff not required to provide evidence; lack of clarity which profiles relate to gift aid.

Good considerations.

I'm definitely open to the idea that it'd be no harder, and likely cleaner or more robust, to have a donor type.

One aspect of handling the commerce customer profile integration could be that if a user edits their default customer profile, then we add a checkbox saying "I have changed my name & tax address for UK Gift Aid too." and update the matching donor correspondingly. Or possibly, we should just assume this is what happens as long as the name is unchanged - HMRC would probably prefer our best guess as to the up-to-date contactable customer address, rather than what we can rigorously prove.

I feel that the context field should potentially move from the declaration into this address.

Profiles don't seem to have an owner or created field. We likely won't be able to distinguish a self-edit from a staff one.

I have my doubts about item 6 from IS

6. If a donor or staff edit a profile referenced from a declaration, then we should create a new revision of the declaration recording who made the change.

We would need to do this for every declaration right? If so, then I have a doubt over the need for this issue😃. We could just store the address on the declaration and perform the same process of creating a new revision of each declaration.

Here is my alternative suggestion to the one in the IS (the original one absolutely can work, but I feel that the balance is in favour of this one)

1. Create a new Donor class
2. Move the charity and context fields into it (from declaration)
3. Add an address field
4. Give it owner, created, revisions, log messages etc as per Declaration
5. Create a create/edit form which is simple, taking bits from Declaration
6. Create a listing page (I know it's not in the requirements, but I'll be really quick, and it helps e.g. if the user was deleted).

One aspect of handling the commerce customer profile integration could be that if a user edits their default customer profile, then we add a checkbox saying "I have changed my name & tax address for UK Gift Aid too." and update the matching donor correspondingly

Yes I like it.

Or possibly, we should just assume this is what happens as long as the name is unchanged

I prefer the first version. The name can change and still be the same person.