Details
-
Type:
Bug
-
Status: Done/Fixed
-
Priority:
Minor
-
Resolution: Fixed/Completed
-
Affects Version/s: 4.4.7, 4.6.7, 4.6.9, 4.7.9
-
Fix Version/s: 4.7.25
-
Component/s: CiviPledge
-
Labels:
-
Versioning Impact:Patch (backwards-compatible bug fixes)
-
Documentation Required?:None
-
Sprint:4.7.10 Pledges, 4.7.14 Pledges
-
Funding Source:Contributed Code
Description
Hi again guys,
Reproduced on the demo site - attached screen shots show progression.
To reproduce:
1. Create a pledge with a fractional dollar amount (e.g. 1618.80) for 12 installments
2. Enter a payment that covers 3 installments
3. Third installment shows $0 due in pending status against which a payment can be recorded (see pending_installment1)
I played around with a few different sequences, payments that cover 1, 2, 4 and 5 installments all work as expected (completing all installments covered), it's just when you enter a payment that covers three installments that the pledge misbehaves if the total pledge is for a fractional dollar amount (see pending_installment2).
I was about to test with a whole dollar pledge amount but the demo site went into maintenance mode, so I tested in our 4.6.7 dev environment - when the total amount of the pledge is an integer, the issue didn't occur (e.g. $1,200 in 12 monthly installments, first payment of $300 covered first 3 installments, all 3 were marked as completed as expected).
That said, for our clients, fractional dollar amount pledges and receiving quarterly amounts for pledges set up for 10 or 12 installments are both very common occurrences.
The client that reported this issue left the $0 pending installment untouched, and continued to report payments as they came in on subsequent expected installments - the $0 installment was eventually marked as overdue by the system, as was the entire pledge even though it was paid in full - you can record a $0 contribution against the $0 expected installment which will put things back in order, but this isn't intuitive.
As I was recreating this scenario to provide you with a screen shot from our 4.6.7 dev environment, I stumbled upon something that I think is the cause of miscalculating pledges that has been plaguing us for quite some time, but I couldn't for the life of me figure out a pattern, until now!
To reproduce:
1. Create a pledge with a non-whole dollar amount (e.g. 1900.80) for 12 installments
2. Enter a payment that covers 3 installments (e.g. 475.20)
3. Third installment shows $0 due in pending status against which a payment can be recorded as previously explained
4. Leaving the $0 pending installment untouched, continue to record individual payments (e.g. $158.40) against subsequent installments - they are marked completed as expected, while the $0 pending installment together with the pledge will eventually become overdue (see pending_installment3)
5. Curious to see if any other multiples would cause the same issue, I recorded a payment that would cover 6 installments (e.g. $950.40), and the problem got bigger (see pending_installment4)
6. The system applied the contribution to the pending/overdue $0 installment as one of the 6 installments being paid and marked it as completed, but left two pending installments (e.g. for a total of $316.80), while the total balance of $158.40 is calculated correctly on the pledge line.
OK, I think I'm done for tonight! Look forward to hearing from you on this one....
Thanks as always,
Tamar
Attachments
Issue Links
- is duplicated by
-
-
- Done/Fixed
-
- links to
Activity
Mathieu Lutfy worked on and resolve the rounding issue that caused the third installment not to be marked as completed - PR to be published shortly.
MERCI BIEN MATHIEU!!!!!!
Hi Mathieu,
Not sure if your fix also covers a situation in which the total amount of a pledge is a non-integer split out in 12 installments - when the amount is paid in full against the full installment, the last installment gets left in pending status even though $0 is due and the last installment gets left out to dry and the pledge remains in a status of "in progress".
Let me know when you have submitted a PR and created a build for me to test.
Thanks!
Hi Tamar,
Can you test here: http://core-8540-23t2s.test-ubu1204-5.civicrm.org ? (login = prdemo / prdemo1234)
I'm writing a test to make sure we do not have mysterious regressions for this issue in the future.
Is the issue you mention the same as CRM-17279 ?
Mathieu
Hi Tamar Meir, a new demo site is available here: http://core-8540-26tex.test-ubu1204-5.civicrm.org/ (prdemo/ prdemo1234)
I added some tests, since this is the kind of thing that can easily have regressions. If you can confirm the fix, we can probably merge this in the next 4.7 release.
Mathieu
Hi Mathieu,
I had emailed back on June 8 but am realizing that emails don't get posted on comments like they do with redmine and zendesk - sorry about that. What I wrote was:
"I think the additional issue I reported is slightly more related to CRM-17279 than to CRM-17281, but I tested my last comment in http://core-8540-23t2s.test-ubu1204-5.civicrm.org/civicrm/contact/view?reset=1&cid=202 and that one seems to be fixed with the changes you made to rounding as well. The issue in CRM-17279 still persists - reproduced on the same contact record in the test site for this PR."
I tested in the new dev site you sent as well:
3 payment rounding issue is fixed:
http://core-8540-26tex.test-ubu1204-5.civicrm.org/civicrm/contact/view/pledge?reset=1&id=4&cid=203&action=view&context=pledge&selectedChild=pledge&key=2ca3fc43b4efac35807275153919d88f_8238
Payment in full is almost fixed - just noticed that while all installments are marked as completed, the pledge status isn't updated to completed:
http://core-8540-26tex.test-ubu1204-5.civicrm.org/civicrm/contact/view/pledge?reset=1&id=6&cid=203&action=view&context=pledge&selectedChild=pledge&key=2ca3fc43b4efac35807275153919d88f_8238
and now that I think about it I guess this last issue must be the same issue as in CRM-17279 - I think both could be resolved if there is a verification along the lines of:
if actual amount = total pledge amount,
subsequent expected pledge payment amounts = 0
subsequent expected pledge payment status = "Completed"
pledge status = "Completed"
else... whatever function you currently have in place for ensuring correct rounding logic.
Will post this last part into CRM-17279 - the PR that resolves CRM-17281 can be merged.
Thanks for all your work on this!
Hi Tamar,
Thanks for the testing. This may be an interface issue, because the pledge page only refreshes the pledge payments, not the pledge info itself.
If the user refreshes the full page, the pledge should show as being closed/complete.
Can you test to see if that is what you were running into? I will have a look to see if it's simple to fix, but I have a feeling it might not be the case.
Mathieu
It was indeed a refresh issue on http://core-8540-26tex.test-ubu1204-5.civicrm.org/civicrm/contact/view/pledge?reset=1&id=6&cid=203&action=view&context=pledge&selectedChild=pledge&key=2ca3fc43b4efac35807275153919d88f_8238
I tested again with a new pledge and then refreshed and it was marked as completed.
There is still the issue of http://core-8540-26tex.test-ubu1204-5.civicrm.org/civicrm/contact/view/pledge?reset=1&id=5&cid=203&action=view&context=pledge&selectedChild=pledge&key=2ca3fc43b4efac35807275153919d88f_1280 as explained in detail in the now closed https://issues.civicrm.org/jira/browse/CRM-17279, so perhaps it's still an almost fixed issue or a slightly different one that may be resolved with the logic I posted here: https://issues.civicrm.org/jira/browse/CRM-17279?focusedCommentId=90424&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-90424 which could be treated as a separate PR?
Thanks and let me know,
Tamar
Mathieu Lutfy Tamar Meir is their anything left to fix ? (please let me know if you need any help)
Thanks!
There seems to be a fix here - please file a follow up for outstanding issues (otherwise it's confusing to assign a fix version)
Nope - not merged - still requiring QA
I think this was sorted
The PR was not merged (re-opening this issue).
Tamar Meir could you review the above PR?
I'm going to pile on an issue which may very well be related, and I'm happy to test or work with this.
1. add a pledge with only a single scheduled payment
2. there is no link to enter that payment
If pledges are not allowed with a single payment, that's ok I guess, but if so they should be blocked. However, if single-payment pledges are allowed once created there should be a way to enter that payment. I'd vote for the latter.
Stoob - I feel your issue should have a separate issue.Can you confirm you can recreate it on demo before you do because I can't replicate it on the site I use pledges on- I can expand the pledge from the arrow & then I get the record payment link
Thanks Eileen, I just tested it. Separate issue, you are correct. Also, newly created pledges under 4.7.16 work fine, but my testing pledges created _ prior to 4.7.16 don't work in 4.7.16. (_scratches head) However, since these older pledges don't work anyway, and don't have any payments, we will delete and re-create these pledges.
Whatever happened to the creating-a-pledge mechanism in 4.7.16 must have fixed it! (thanks)
Based on the last comments, it seems OK to close this issue?
Oops my bad. While going through my patches, I noticed that my PR is still open:
https://github.com/civicrm/civicrm-core/pull/9585
Hi! Thanks for filing this.
Current status of this issue is non-critical and unfunded, which means the core team is not working on it. In order for this issue to progress, one of the following will need to happen:
* Someone submits this to the paid issue queue to provide funding.
* Someone provides a patch or pull-request for the core team to review.