A matched contribution's receive_date should be set to value_date instead of booking_date

[GFF-DS]

According to #409 a matched contribution's receive_date is set to booking_date. However, the booking_date is not necessarily the date when the contribution is received. That's the value_date.

At least in Germany on the donation receipt we have to print the value_date and not the booking_date as the contribution's date.

So my suggestion would be to set the contribution's receive_date to the transaction's value_date instead of the booking_date.

[jensschuppe]

As far as I can tell, this should be configurable within the matcher (in the Existing Contribution and the Default matcher plugins), as in there's an option for whether to preserve the receive date of an existing contribution. For new contributions, the receive date should still be set to the value date, see here:

org.project60.banking/CRM/Banking/PluginImpl/Matcher/CreateContribution.php

Line 215 in 05eeeac

$contribution['receive_date'] = $btx->value_date;

So I guess this issue is about updating the receive_date of existing contributions when the preserve_receive_date option is not set?

[GFF-DS]

Yes, it's about matched contributions for which the receive_date should be updated according to the setting in preserve_receive_date.

They are currently updated to booking_date, see ExistingContribution.php.

[jensschuppe]

They used to not be updated at all before that PR, so your use case would be different from the one in #409.

I can imagine a new configuration option update_receive_date (working title) which can be set to a parameter name in the transaction namespace and default to booking_date (as that has been the default since #413 got merged) and which you could set to value_date to override that.

[GFF-DS]

I don't see what's the difference between my use case and that one in #409 (but maybe I'm missing something?). In both cases, the issue is that the contribution's receive_date sometimes is wrong. This may happen for example, when a contribution is automatically added by Twingle for payment_instrument bank transfer or SEPA OOFF (with contribution state Pending). Twingle creates the contribution with receive_date as the date when the Twingle form was submitted. However, the actual contribution receive_date may be later, for example, when the bank transfer is made a few days later.

What #409 fixes is that for this cases, the contribution's receive_date is corrected during import of the bank statement. However, it should be corrected to value_date and not booking_date.

Also, it's not consistent, that for new contribution's the receive_date is set to value_date, while for existing contributions its's set to booking_date.

[jensschuppe]

@MarcMichalsky can you chime in assessing the differences (if any)? I think we have differing use cases from a fundraising and accounting point of view here.

[GFF-DS]

I read again #409 and it's actually something else, you are right. Sorry for my misleading.

Yes, there's different perspectives from fundraising and accounting. Still I think it's not good to have the inconsistency

• receive_date is value_date if contribution is new
• receive_date is booking_date if contribution already exists (if updated)

As (at least in germany) for donation receipts created with CiviCRM you have to set receive_date to value_date, my suggestion would be to always use value_date.

[MarcMichalsky]

As (at least in germany) for donation receipts created with CiviCRM you have to set receive_date to value_date, my suggestion would be to always use value_date.

I agree.

[jensschuppe]

I can imagine a new configuration option update_receive_date (working title) which can be set to a parameter name in the transaction namespace and default to booking_date (as that has been the default since #413 got merged) and which you could set to value_date to override that.

Let's do this then, @MarcMichalsky and @GFF-DS …?

[GFF-DS]

Yes, cool! I would have capacity for testing and documentation.

[jensschuppe]

👍 for the conceptual agreement - we'll have to find developer resources though. Tagging needs funding accordingly