[
http://mifosforge.jira.com/browse/MIFOS-2799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=58865#action_58865
]
Sam Birney commented on MIFOS-2799:
-----------------------------------
update -- Al M decided to deploy this patch in production and it has been
working well. Just want to make sure it gets into future releases so they are
running an unmodified codebase again. thanks!
> 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: mifosdeveloperqueue
> Priority: Major
> Fix For: Release E, Release E - Unscheduled
>
> Attachments: 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 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
