[
http://mifosforge.jira.com/browse/MIFOS-2773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=57093#action_57093
]
Sam Birney commented on MIFOS-2773:
-----------------------------------
I looked into the code and Adam's ideas -- the running total algorithm made
sense and seemed correct to me. The LoanBO.paymentAmountIsValid code also
seemed to follow the proper logic that Kay describes... So, we went back to
testing many cases and could not reproduce it. I'm not sure why we saw it
before. It's possible it was user error, but three different people saw it
happen for more than one loan, so maybe it is some subtle edge case. My hunch
is maybe the error was somehow related to the confusion between group loan
external IDs and individual loan external IDs and only showing up when there
was a collision there, and perhaps we are no longer seeing this case now that
that error has been fixed.
Anyway, since we have now found that this is much more rare than we initially
thought, I think we can safely lower the priority and defer any potential fix,
and if it happens occasionally we can make manual corrections.
> bank import rejects overpayments when they should be applied to the next
> installment
> ------------------------------------------------------------------------------------
>
> Key: MIFOS-2773
> URL: http://mifosforge.jira.com/browse/MIFOS-2773
> Project: mifos
> Issue Type: Bug
> Components: Misc
> Affects Versions: Release 1.4
> Reporter: Sam Birney
> Assignee: mifosdeveloperqueue
> Priority: Critical
> Fix For: Gazelle C
>
>
> we noticed that sometimes a customer pays (e.g.) $102 when their next
> expected payment in mifos is $98. If this is the final payment, the bank
> import is correctly not allowing the overpayment. However, if there is
> another payment due next month of $98, should not the correct bank import
> behavior be to apply $98 to the current installment and $4 to the next
> installment? When manually applying payments this is what happens, so
> shouldn't it be the same in bank import?
> it does happen often, mainly because their old MIS puts rounding leftovers in
> the first repayment, and Mifos puts it in the last. So a normal old loan may
> have a schedule of (102,98,98,...,98) and in Mifos it is (98,98,...,98,102).
> So, the customer goes to pay 102 and Mifos is expecting 98. So, this will
> happen almost all of the time during the next year of transition, but then
> will become more rare once all the active loans have schedules that were
> generated by Mifos.
> -Adam Monsen wrote:
> Until we get the chance to look at this, you might check out the
> following:
> * in the import plugin, we actually do a running total since the API
> doesn't support this type of validation. This might be causing or
> related to the problem you're seeing
> * LoanBO#paymentAmountIsValid and friends appear to allow overpayment of
> one installment as long as it doesn't exceed the total repayable amount
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://mifosforge.jira.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mifos-issues mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mifos-issues
