Payment.create should not set contribution date to today

[artfulrobot]

Overview

I noticed that calling the payment.create API resets the contribution date.

Before

1. create a pending contribution with a historical date.
2. create a payment on it also with a historical date
3. contribution receive_date gets reset to today's date.

After

1. create a pending contribution with a historical date.
2. create a payment on it also with a historical date
3. contribution receive_date gets update to the payment's date.

Technical Details

Has test.

@eileenmcnaughton @JoeMurray @mattwire @adixon may be interested

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[adixon]

Nice catch, thanks.

[eileenmcnaughton]

I agree this is better - my first thought is we shouldn't change it at all

[artfulrobot]

@eileenmcnaughton yes, I can see the appeal of that.

But I think this pr "fixed"what the previous design behaviour was: the code looks for trxn_date but it just wasn't being passed in, so I passed it in.

[eileenmcnaughton]

@artfulrobot so I agree trxn_date should be passed in & I agree it's better. My worry is simply that that if we lock in this change then it will seem like there is agreement that receive_date should be updated - which I'm not sure about. Code comments indicating that it's still an open question would mitigate that - in the test would be enough as that is the part locking in the behaviour -the other part is just passing an obviously sensible param

[artfulrobot]

@eileenmcnaughton I've added a descriptive docblock, altered the test so that it's a one-word change to test either behaviour, and set up an issue at https://lab.civicrm.org/dev/financial/-/issues/139 to discuss this.

[eileenmcnaughton]

@artfulrobot perfect - thanks!