Discussion: Should the Existing Contribution Matcher actually overwrite the `receive_date` of an existing contribution?

[MarcMichalsky]

Discussion: Should the Existing Contribution Matcher actually overwrite the `receive_date` of an existing contribution?

[MarcMichalsky]

Serializing CiviBanking transactions was necessary because there are not many distinct fields and there might be a lot of custom data per transaction.

I understand that, but perhaps APIv4 support would still be useful?

You should not rely on bank transactions for fundraising statistics anyway.

The transaction date is not of interest for our fundraising but for accounting purposes.

Would you be able to give my suggestion a try implementing?

Of course! I would suggest implementing it as a field in the configuration of the Existing Contribution Matcher. How about preserve_receive_date?

[MarcMichalsky]

Keep in mind this matcher can be configured to be in cancellation mode as well.

Yes, but I think it's fine to use the booking_date as the cancel_date in cancellation mode, as it shouldn't overwrite any existing information.

[jensschuppe]

I'd suggest making it optionally configurable to not overwrite the date for keeping backwards compatibility. In general, the receive_date semantically represents the "physical" booking date, as the money is not in your account until the actual transfer is completed, so the date which is being overwritten in your case seems to be more of an announcement date …?

[MarcMichalsky]

Well, it is the date on which the donation is made. From a fundraising perspective, this information is more valuable. The actual booking date is important for our accounting department to reconcile with the bank accounts. However, this date is already available in the transaction.

Unfortunately, it is a pity that the transactions are stored in serialized form in the database and cannot be retrieved via APIv4, as otherwise it would be easy to create SearchKits that could display the donations combined with the data of the assigned transaction(s).

[jensschuppe]

Serializing CiviBanking transactions was necessary because there are not many distinct fields and there might be a lot of custom data per transaction. You should not rely on bank transactions for fundraising statistics anyway.

Would you be able to give my suggestion a try implementing? I guess that's what @bjendres would have been suggested as well. Your workaround with value_propagation also sounds practicable.

[bjendres]

Sounds good, I think both interpretations make sense, depending on the setup. Therefore an additional configuration parameter for that matcher seems the right way forward. Keep in mind this matcher can be configured to be in cancellation mode as well.

However, the priority should always be not to break existing setups.