[
http://mifosforge.jira.com/browse/MIFOS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=58947#action_58947
]
johnwoodlock commented on MIFOS-3312:
-------------------------------------
John,
Couple of comments/questions.. First, great information, thanks!
1. You mentioned the 7 lingering accounts that have been generating errors for
weeks. So the other 1382 accounts have a zero interest posting in Q1 2010 which
caused them all to error? Just want to confirm.
The reason for the big jump (1382)in the last quarter is that there was a
recent bug fix that now writes a SAVINGS_INTEREST_POSTING transaction if the
amount is zero and that another part of the method doesn't cater for 'initial'
transaction being SAVINGS_INTEREST_POSTING.
2. What if someone entered a zero amount adjustment, would that be handled ok?
AFAICS, adjustments are handled okay (except where they are the 'initial'
transaction in the calculation... there is a code bug that affected 7 of the
accounts which has been fixed in v1.6)
3. If we had a patch for 1.5 that ran these interest calcs without error, and
ran them today, do you know if the interest would be calculated for the proper
period (3/30 thru 6/30?)
AFAICS, it calculates interest based on the transaction dates (in the range)
and not the savings balance (current). So, the calculation seems good.
However, the posting for the period has already happened... so the question is
what to do with the interest.
Only two of the 1389 accounts (Van's Database) in error accrued interest.
'000100000022933' balance: '1364.0000' Interest (2010-03-31 thru 2010-06-30)
calculated as '16.6000'
'000100000051088' balance: '1378.0000' Interest (2010-03-31 thru 2010-06-30)
also calculated as '16.6000'
all the other either have a zero balance (nearly all) or are below the minimum
balance for getting interest (12 of these).
One possibility might be to run the fix which will get rid of the errors and
then zeroise the 2 figures above and just make 2 adjustments for them
(Kay,Jeff,Ryan decision)
4. Another testing question, I assume the batch job would take the current
balance to calculate interest? So if withdrawals or deposits were made since
6/30 the calculation would be different.
I think the calculation is good (see 3.) but I think we'd have to check on
production data (before running fixed batch job) that the accounts in error
haven't had their balances or 'interest to be posted' figures changed since
Vans dump cos we wouldn't want to zeroise the 2 accounts above if their current
value (for interest) is not zero. (the process is meant to add interest
calculated to the interest to be posted figure.
5. You asked "determine if its okay to ignore offending code for
SAVINGS_INTEREST_POSTING". Do you mean only when interest posting is zero, or
all interest posting? Doing special case when interest is zero seems ok to me.
It doesn't cater for any SAVINGS_INTEREST_POSTING transaction that becomes an
'initial' transaction. Just much more likely that this will be the case for
inactive accounts which result in zero interest postings.
6. any insight as to why activity order is showing up strange as noted in
07/Jul/10 9:32 AM comment? Related, or a different bug?
Different... the activity listing is in descending order of a generated id (not
descending date). So, transactions that are created for earlier activities
(like catch-up interest postings for previous quarters or god forbid someone
mucks around with the system date) will show up 'strange'.
> Interest not posting for savings accounts in 1.5
> ------------------------------------------------
>
> Key: MIFOS-3312
> URL: http://mifosforge.jira.com/browse/MIFOS-3312
> Project: mifos
> Issue Type: Bug
> Components: Savings Account
> Affects Versions: Release 1.5
> Reporter: jbrewster
> Assignee: johnwoodlock
> Priority: Critical
> Fix For: Shamim D, Release E - Iteration 2, Release E
>
> Attachments: debugMifoslog.txt, issue3312SavingsIntCalcErrors.txt,
> screenshot-1.jpg
>
>
> SECDEP reported several accounts were not posting interest on their 3 month
> interest posting date - 30 June 2010.
> I've confirmed that many accounts were flagged in the SavingsIntCalcTask as
> of 30 June. Previously, a few tasks were flagged every day (see MIFOS-2714).
> A large list appears every day starting 30 June. Note the attached list may
> be truncated and not completely list all failed postings.
>
>
>
>
> Here is the error listed in Mifos.log:
> org.mifos.framework.components.batchjobs.exceptions.BatchJobException: Failure
> at
> org.mifos.framework.components.batchjobs.helpers.SavingsIntCalcHelper.execute(SavingsIntCalcHelper.java:67)
> at
> org.mifos.framework.components.batchjobs.TaskHelper.perform(TaskHelper.java:201)
> at
> org.mifos.framework.components.batchjobs.TaskHelper.executeTask(TaskHelper.java:114)
> at
> org.mifos.framework.components.batchjobs.MifosTask.run(MifosTask.java:55)
> at java.util.TimerThread.mainLoop(Timer.java:512)
> at java.util.TimerThread.run(Timer.java:462)
> 2010-07-07/00:13:16.698/PHT INFO, org.mifos.framework.components.batchjobs,
> TaskHelper, executeTask, 113, SavingsIntCalcTask will run catch-up execution
> for Sat Jan 02 08:00:20 PHT 2010
> I've taken a snapshot of the SECDEP test database for further debugging.
--
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
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Mifos-issues mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mifos-issues
