[
http://mifosforge.jira.com/browse/MIFOS-2799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kay Chau updated MIFOS-2799:
----------------------------
Fix Version/s: (was: Release E - Iteration 5)
Release E - Iteration 6
> repayments not allowed before most recent customer meeting even with LSIM +
> backDatedTransactionsAllowed
> --------------------------------------------------------------------------------------------------------
>
> Key: MIFOS-2799
> URL: http://mifosforge.jira.com/browse/MIFOS-2799
> Project: mifos
> Issue Type: Bug
> Components: Loan Account
> Affects Versions: Release 1.4
> Reporter: Sam Birney
> Assignee: Van Mittal-Henkle
> Priority: Major
> Fix For: Release E - Iteration 6, Release E
>
> Attachments: patch-2799.txt, patch-2799.txt
>
>
> Summary
> we ran into a roadblock today. The short summary is that Mifos does not any
> permit transactions to be entered prior to the most recent client meeting
> date, even when LSIM and back-dated transactions are enabled. After
> discussing with Ryan, we think it may be working as designed, but perhaps it
> is a design that did not anticipate this use case where repayments are made
> at banks and then imported into Mifos in bulk, potentially on a later date.
> We have a short-term workaround that would be good to get some feedback on
> (particularly from developers) and we should discuss longer-term approaches.
> Details - Short-term fire
> Each day we have been importing bank repayment transactions, trying to catch
> up on the thousands since the pilot started. Although this has been working
> fine up until now, most of the payments we tried to import today were
> rejected with an invalid transaction date. We tried entering some manually
> in the apply payment UI and got the same result, an error message that
> transactions can not be back-dated prior to the last customer meeting date.
> We looked at the data and did some experiments with setting the clock ahead
> on the test server here. We found that the reason we ran into this today is
> the majority of pilot customers were migrated from the old system on Feb.
> 16th and we set the meeting day to be the 16th of each month, and now that it
> is March 16th we can no longer enter any transactions prior to today for
> those customers.
> The current problem is we still have hundreds of transactions that happened
> before the 16th to enter. Within the Mifos UI, the only option we could
> think of is redoing loans, and there are way too many for that to be feasible
> - we've been redoing many each day due to other issues and are barely keeping
> up with the new ones.
> So, the workaround we came up with was to update the date of the customer
> meetings in the database from today to a future date (in the
> customer_schedule table) then import/apply the payments, then set the meeting
> dates back to today for the sake of some sort of data consistency. We tried
> this out on the test server and it worked, with no ill effects as far as we
> could tell, so George decided to go ahead with it. This is the workaround
> that we would really like to get a sanity-check about.
> Details - Longer-term approach
> Even if this workaround is OK for now when we are catching up on 10 days or
> so of data after migrating systems, we still need to figure out the
> longer-term plan for this so we are not doing that for some accounts every
> day, forever. In the planned use case here the finance department tries to
> import payments from banks at the end of the day they were made, but
> often/usually it is 1-2 working days later. So, if any of those customers
> have meeting dates that fall in between that time, this situation will occur
> again, and we would have to apply whatever workaround potentially every day.
> As for longer term solutions, I think the desired behavior would be to remove
> the restriction about meeting dates for customers that don't actually have
> meetings. We could change the existing behavior of LSIM + backdated
> transactions, or potentially introduce a new configuration variable to make
> this option apply only for MFIs that specifically choose it.
> (AccountingRules.allowBackDatedTransactionsRegardlessOfMeetings?)
> As a possible enhancement, Mifos could have the concept of a global date when
> the books were last closed in accounting, that could be updated each period,
> and not allow back-dated transactions before that date. But when there are
> no customer meetings, it does not seem to make sense to have meeting dates
> affect when transactions can be made.
> More technical details
> Looking at the code, we can see that this is nothing particular to the bank
> import feature -- both it and the UI for applying single payments end up
> going through the same logic. The relevant transaction date checking seems
> to be in AccountBO in the method isTrxnDateValid and
> isTrxnDateBeforePreviousMeetingDateAllowed which it calls. To summarize the
> logic in pseudocode:
> if back-dated transactions are not allowed then the transaction date must be
> equal to today.
> otherwise:
> if LSIM is enabled:
> if it is a loan account:
> disbursements must be on or after the approval date.
> repayments must be on or after the approval date and most recent
> meeting date.
> else it is another type of account:
> transactions must be on or after the creation date of the account.
> else LSIM is not enabled, all transactions must be on or after the most
> recent meeting date.
> So, the proposed change would be to essentially take out the meeting date
> check from the back-dated, LSIM case. Or if this should be a separate
> configuration option, then make it conditional on configuration variable.
> In case history sheds any light or rings any bells, Ryan found a very
> relevant bug report that is now closed: MIFOS-1692.
> Comments/Feedback?
> any ideas about what we can do with the short-term and ongoing issue?
--
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 Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Mifos-issues mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mifos-issues
