[ 
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 - Unscheduled)
                   Release E - Iteration 5

> 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: Sam Birney
>            Priority: Major
>             Fix For: Release E - Iteration 5, 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 email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Mifos-issues mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mifos-issues

Reply via email to