Current use of charge_date means sheduled reminders don't work.

[artfulrobot]

Currently we use charge_date as the receive_date in CiviCRM.

This date is given by GC when we set up a mandate. It's basically the date the money leaves the customer's account.

But it's not confirmed until a day later. It's the confirmed-ness that creates/updates a pending payment to status Completed. This means that when a payment becomes completed the date is always historical - a day ago.

In turn, a scheduled reminder on a Completed payment will not be (likely) triggered as the scheduled reminder code only looks for things that have happened in the last 24 hours.

Question / Proposal

Should we have it so that the Contribution receive_date is updated to the date the payment is confirmed (assuming it is successful)?

This would mean you'd see a contribution's date start off as Pending, say on the 1st, but then when it completed it would be updated to the 2nd.

It would mean you could do scheduled reminders on a Completed payment more reliably.

If we do this, should we keep the recurring contribution's start_date the same? What about memberships, should they use the original date or the confirmed date?

Alternatives

1. We could implement an update when the payment is paid out by GC to your organisation. The problem with the latter is that the date gets further away from the date that a customer (supporter) can see on their bank statement. Especially if GC have cause to pause payouts.

   2. You could say: just add a day to your scheduled reminder. But perhaps there could be a delay (weekend/bank hols?) before a payment is considered confirmed? So payment that took, say 4 days to confirm thanks to a bank holiday weekend instead of the usual 1 could be missed out of the scheduled payment.

Be really interested in your views on this!

[mattwire]

@artfulrobot I don't have much to add other than I don't think decisions should necessarily be driven by the behaviour of scheduled reminders which in my opinion are too rigid and do not meet a lot of use-cases. I now exclusively use civirules for reminders and for membership/recur at least there are now enough conditions/triggers to cover most scenarios. I work with a client that has 3 different rules for triggering the "reminders" depending on if the payment is gocardless, stripe or an offline recurring payment. This is necessary because of the different ways each one is "settled".

[artfulrobot]

Thanks @mattwire

I see your point, but schedule reminders is a core feature, and to be honest, charge_date was picked for its easy availability more than any other reasoning, so I just wondered whether confirmed date would be better/clearer, as well as being more useful to core features - scheduled reminders.

This is a bit off-topic, but I've always felt a little worried about CiviRules with delayed executions - I guess that's what you're using - e.g. scheduled reminder that's going to fire 7 days after a completed payment means you can edit that reminder up until it triggers on the 7th day; a civi rule that's triggered and told to wait 7 days I think is less obvious/cancelable. I'm lacking experience in this though, so I could be wrong.

[wmortada]

I don't have a strong opinion about this but think I am inclined not to change the current arrangement.

At a-n, we don't currently run any scheduled reminders on completed payments so this isn't an issue for us.

I agree with @mattwire that we shouldn't tie ourselves in knots just to make scheduled reminders work.

Instinctively, the current arrangement seems the right one as it is recording the actual date of the payment so should correspond with financial records. I think changing it could cause problems - e.g. the contribution in CiviCRM falls into the following month so there is a discrepancy with the financial records.

This change could cause other problems that we haven't thought of here so I think I'd be inclined to stick with what we've got unless there was a strong argument for change.

[aydun]

This points to there being multiple dates of interest relating to a payment and maybe more should be recorded. receive_date should be as consistent as possible across different payment methods. Back in ye olde days of cheques, it was the date the org received the cheque although it wouldn't show in a bank account for some days.

[Upperholme]

If I were to guess I'd say that there are a lot more people using Scheduled Reminders than there are using CiviRules. I would also guess that there is an assumption that Scheduled Reminders should be able to work with GC payments. So if the plan is not to change things such that the reminders don't work as one might expect, this needs to be flagged up somewhere, probably in the Scheduled Reminders UI so that people are in no doubt. If it's doable to make scheduled reminders work without making a mess, I'd say that would be the ideal outcome, but I also agree with @wmortada that we don't really want to be messing with payment dates. As @aydun suggests, maybe we should be recording more dates in order to give the flexibility. As regards memberships, I think people are primarily interested in membership dates rather than payment dates. A client I work with has organisations for members, and they can take a long time to pay in some cases, but the membership dates are based on when they first applied rather then when they paid. Different models will apply here.

[mattwire]

@artfulrobot civirules has supported "CRON style triggers" for about a year now which are not the same as delayed execution. They can currently be triggered for quite a few date-related things such as relationship dates, membership (end) dates, activity dates etc. so provide a nice extendable scheduled trigger system for any action you choose to use. Not trying to force anyone to use civirules, just feel it's a lot more flexible (I started looking at scheduled reminder criteria some time ago and they use hard-coded criteria that you cannot change so I just went with implementing any missing functionality in civirules to allow me to do the same but with more control.

[artfulrobot]

Thanks everyone for your input!

@aydun more dates: certainly useful, but a bit out of scope for what we can do in this extension.

@wmortada

Instinctively, the current arrangement seems the right one as it is recording the actual date of the payment so should correspond with financial records.

It's recording the date of the actual payment as seen by the customer; not the receiver.

So it won't match the organisation's bank account records: that would have to use the pay out date, and (then it wouldn't match directly on amount either because the payout = ∑(income that day - fees).)

If you meant Civi's Financial records: well those will match whatever date we give it; currently we use GC's charge_date, but if we moved to using completed date it would make no odds. We do (sometimes) change the Contribution record's date. We don't change a financial transaction (i.e. "Payment" in the API) record's date.

I'm not suggesting any change that would alter existing financial transactions; it's just a case of what date to log future ones on: the charge date, or the confirmed date.

@aydun re:

"it was the date the org received the cheque although it wouldn't show in a bank account for some days."

We're not doing that either really as the receiving cheque equivalent would probably be the mandate creation date; an instruction to take the money. We currently future-date the initial contribution and start date to the charge_date, which would be the equivalent of the date we give the cheque to an intermediary who is going to cash it before later paying some of that cash into our account. So not sure there's a clear parallel there?

@mattwire yes, I'm definitely up for looking more into CiviRules; could include a "cook-book" style set of suggestions in the GC documentation.

[artfulrobot]

I'm going to close this on the basis that

• changing receive_dates to the confirmed date only seems to benefit Scheduled Reminders; financially it's no more relevant than using the charge date as we do now, in fact charge date is at least the date something happened where as "confirmed" is the date they decided nothing else is likely to happen so it's considered confirmed.
• CiviRules can be used (so says @mattwire) to do something like Scheduled Jobs.
• I'll add a note to the docs to explain when you can and can't use scheduled reminders successfully.
• Ideas for core: having more dates available on the Contribution object might be helpful; having something that made Scheduled Reminders look further back than the last 24 hours might be useful.