One-time contributions on a page with recurring enabled, if public selection of future recurring start dates is enabled

[adixon]

If you have a public contribution page that has recurring enabled, and you have enabled the iATS setting of "enable public selection of future recurring start dates", then if the date is after the 28th, the first allowed recurring date will be pushed to the first of the following month.

That much is reasonable for recurring contributions, though not optimal, but if the page is used for a one-time contribution on a date after the 28th, then the default future received date (which is hidden) will get used as the recorded date of the one-time contribution.

This is particularly an issue for end-of-year contributions that get recorded as received in the following year.

Note that the one-time transaction is actually getting transacted immediately, it's only the receive date as recorded in CiviCRM which is wrong, so you can safely just update the date received and carry on ...

The better solution (to be implemented) is also a fix for generally improving the future recurring start date option - to always allow the current date as the first contribution date, and then pull the next recurring contribution date back to the 28th of the next month.

[adixon]

Pull request, needs testing on Mar 29/30/31.

[larssandergreen]

It seems like this issue is still unresolved and is about to become much more of a problem again as end of the year contributions will be recorded in the wrong year, leading to incorrect tax receipts being sent. Is there a path to fixing this before the year end?

[kelizoliva]

This has already started to manifest as a problem for the clients we have that use this processor. We are seeing one-time contributions marked as received on Jan 1 2020, with a receipt sent on 12/29/19. This is going to drastically affect end-of year donations drives, again. Any chance this math will get corrected?

[KarinG]

@kelizoliva - simply just "disable the enable selection of future start" to solve this immediately. The reason why this is happening is b/c some months don't have 29, 30 or 31 days, so we're pushing the date forwards to be within [1-28] on public forms that offer Recurring Contributions; Alternatively - you can try the patch that's referenced in this issue: https://github.com/iATSPayments/com.iatspayments.civicrm/pull/276/files

[adixon]

This PR now found and pulled!

To recap: there was an issue when future recurring dates are enabled and a donation is made after the 28th of the month.

We'll test this in a couple of days to make sure it really works.

[lcdservices]

We just hit this in the last few days. It looks like the PR was merged and included in 1.7.3, which we were running. But the behavior with the one-time payments was still present. Looking at the PR, it seems that only addresses the behavior with recurring payments.

Are there plans to address the one-time problem -- where transactions made after the 28th are dated for the 1st of the next month?

[kelizoliva]

We also had this issue come up for a client who was very displeased during end of year giving while we were all on holiday vacation, after we told the the issue had been fixed.

[cmmadmin]

We had this issue with one-time donations occur in Dec 2020: Donations made Dec 29, 30 and 31 show up in Civi and in email receipts as received on January 1. But, we were using 1.7.2 version of this extension. We upgraded to 1.7.3 today. How confident can we be that this will be fixed for this coming Dec 2021? I'm asking because the last couple comments in this issue seem to indicate the fix didn't work. Is that true? Is there a way we can test it to be sure?

[wzachtaylor]

@KarinG Picking this thread back up. From reading back through this, it seems there was a fix in place for recurring contributions by "disable the enable selection of future start." Is there an update on how this affects one-time contributions? If there is a fix for that, how can I test that to confirm? note we are on CIviCRM 5.41.2 and iATS extension v 1.7.4.

[wzachtaylor]

Is anyone able to give any clarity on whether or not this was resolved in 1.7.4? In years past, our donors were receiving confirmation emails and receipts with the wrong date if the donation was made after the 28th of the month. Any help with a fix would be appreciated.

[cmmadmin]

Hello, I'm working with wzachtaylor. We are concerned that we will have the same problem with one-time donations made on Dec 29, 30 or 31 being sent with receipts dated after the new year. Seems like it was suggested that we disable the "future start date" feature to avoid this. But, that seems like it will only affect recurring contributions and not one-time. Since we've had this problem 3 years in a row we're under some pressure to ensure it doesn't happen again since it requires a lot of work of our finance team to fix the records and creates concern from our year-end donors. Can anyone help us with a solution for this?

[adixon]

Yeah, since today is the 28th, I'll try to reproduce your error in the next few days and see if I can understand where the issue arises.

It's a bit confusing because a one-time future non-recurring contribution is treated as recurring contribution with one contribution, because it has to go through the same flow of saving the payment credentials and then charging it, instead of the one-time flow.

Real recurring contributions get their receive dates adjusted so that the date of the month is consistent.

With a particular mix of settings, it appears that the code flow is going through a process to push the receive date to the following month, even though it doesn't need to, or want to.

In any case, thanks for your persistence in this bug!

[adixon]

Okay, I think I can reproduce the issue, e.g. here: https://iatsdemocivicrmca.e.civicrm.ca/civicrm/contribute/transact?reset=1&id=6

The issue is that when a page offers recurring and 'enable of future start', then the form exposes the allowed future start dates as a drop down and limits them to exclude dates after the 28th, which forces the first of the next month even if they pick a one-time option.

I think the correct behaviour should instead be to allow and provide the default of the current date and then let the code pull back the following month to the 28th if a date after the 28 is chosen.

[adixon]

Okay, this is now in master. There is still one case that is a bit non-obvious that should be pointed out.

If:

1. you are restricting the days for recurring contributions
2. offering the public to make their choice for when their recurring contribution starts

then, on a page offering both one-time and recurring, one-time contributions will be restricted by the available days filter.

[adixon]

There's still one more improvement to make, which is to solve the above non-obvious bug.

Currently, for that case, the transaction will happen immediately, but will be recorded as the next allowable date.

[wzachtaylor]

@adixon With these improvements you are working on, are you planning a new, tried and tested release? Or do you have a path forward or suggestion for patching our system? Should we also disable the “Enable public selection of future recurring start dates” setting just to be on the safe side?

[adixon]

Yeah, that's a good question. I understand at least one way that the issue was arising and there's a minimum patch you could try for it here: https://github.com/iATSPayments/com.iatspayments.civicrm/commit/9b0b284811a6830638d16a6e4a24c7a40854aee5

On the other hand, that patch and a bunch of other ones are now together in what I would consider a reasonably low risk maintenance release that's in beta right now. Unfortunately, we won't be able to run that through the usual 'test matrix' that we do to catch unexpected impacts, but at this point, I think we'll just make it a release without the extra testing.

It's tricky because there are also risks to not updating, as more of the core changes, so I'd particularly recommend the new version if you're doing any civicrm core updates, or if you've got the issue this comment is for (#267).