BUG: Open Ended Recurring Donations lose their Next Installment Date when the last open opp is closed.

[mrbelvedere]

From John Fine.

Isssue #4: When I edit my last open Opp to set its STage to a closed Stage, and set its Close Date to whatever date I want (usually the date that the donation check has written on it), the RD code apparently sets Next Donation Date to blank (maybe because there are no more open donations - although there should always be 1 more open Opp as per Issue 3). Then after running the nightly batch which gen's 2 more open Opps, the Next Donation Date of the RD is set to my Close Date (not by me - presumably by RD trigger code), and the Close Date of the newly gen'd Opps is based on that Close Date also (1 year and 2 years after it). This prevents me from continuing to get auto-gen'd Opps indefinitely based on the original Date Established, which is the behavior I am after. In other words, I want my series of Opps that I started (by setting RD.DateEstablished to 9/1/2014),to be due on 9/1 of each year after that, forever, irrespective of what I set each Opp's Close Date to when I edit it to indicate that the money has arrived.

[davidhabib]

@kbromer The fundamental issues here are: 1) we compute the next opportunity's date based off the CloseDate of the last opportunity.
2) if you edit an opportunity and change it to a Won Closed stage, and don't touch the CloseDate, Salesforce will automatically set it to today's date. 3) some users might change the opp's close date to be the date they receive the check.

due to both 2 and 3, future opps on any of our recurring schedules are going to get off, if you are closing the last opp. I verified this bug happens both in NPSP 2.0 and 3.0.

To fix this undesireable behavior, we'd need to change the RD code to never base the next payment on the previous payments CloseDate, but instead base it on the canonical schedule it should follow. I'm not sure if this would be achieved by adding a custom date field on the Opp of what it's official RD date is, and using this instead of CloseDate, or whether we can change the core logic in RD always be able to figure out what the n+1 date should be given n closed opps.

I'm assuming the reason this hasn't been reported before is that it only rears its ugly head if you are closing the last opp in the sequence. In cases like monthly where the batch is always creating many additional opps in the future, you typically haven't come close to closing all of the existing opps. I think the typical use case hitting this is just going to be yearly, and your forecast range is < 24 months.

so we have several choices I need feedback on:

1. do nothing. obscure enough since version 2.0 and we haven't heard enough complaining.
2. redesign the date calculations the proper way, and rework all the code to use the same logic.
3. just try to do a strategic fix when the schedule is yearly.

thoughts?

[kbromer]

In theory, this should be set for the same schedule as the Next Payment Date logic off the Recurring Donation object itself I think. I thought that's how it was originally designed, to always generate the Opp based off of that if it doesn't already exist, but its been a couple of years since I looked at it ;)

Lets go with option #1 for right now, but keep this in the backlog as a possible future fix (or contributor fix!). This doesn't feel pressing, is a corner case, and doesn't prevent the user from adjusting any future Oppty as required

[kbromer]

Is this still in the queue @davidhabib?

[davidhabib]

yep, put back on the backlog.

[judisohn]

**lurch: add

[LurchTheButler]

Tracking W-008241

[mpusto]

We are close to releasing new RD features and will not be addressing bugs in the old RD code.