From: Pooja C. <po...@an...> - 2010-04-14 17:52:27
|
Hello We are deploying Mifos for an MFI in India and here is a requirement for which I am assuming development effort is required and there is no 'quick-fix' by playing with the configuration options for achieving the same result. Kindly go through this and let me know if my conclusion is incorrect. Thanks - it is a long mail. *Scenario*: Our client is using Mifos plus certain customized plug ins written by us hosted by us. We have written a software-client on EFTPOS machine (hand held keyboard+printer+display+GPRS+ thumb-print reader) for loan disbursal plus accepting repayments from the field. The Loan Office carries this device and logs on to this device instead of logging on to UI. It is a simple interface which takes the client's cell number or a/c number (if the client does not have a cell) and either sends a confirmation of loan cash disbursal to the client post biometric validation or sends a confirmation of installment receipt to our server which inserts appropriate data in Mifos db. A month back, a new requirement came in, where our customer needed to 'register' clients using the same interface - loan application form data arriving at a later date and being uploaded via excel files. So, we added this 'Register' feature to the hand held which created the account in pending approval state for which a receipt and hence an a/c number was given to the client. This account automatically becomes active once the file upload is successfully done for that client. So far so good. Now, our customer having seen the success of on-field-registration now wants to do on-field-disbursement. I am being concise at the cost of not being entirely accurate but this is a good enough description - *on the field registration plus disbursement*. Now, some of the people to which this on-field-disbursement of loans is being provided are existing clients with some other loan active in good standing with the MFI, and some are fresh enrollments. We are OK with creating a client, open a loan a/c and do a disbursal via our plugin. The problem is the meeting date. *Two problems*, first being more of a premise: 1. These on-field-loans could be repaid by the client in weekly meetings or in monthly installments on every 5th/10th/15th. If the client has an existing weekly meeting scheduled, say every Monday, how do we account for monthly installments? This is similar to the oft-asked question of accepting payments on non meeting days and we have resolved it in a fashion for our purpose. Accepted Resolution: This is what we have done to resolve the problem of multiple loans being repaid in entirely unrelated schedules for the same client: We interpret the meetings per account instead of per customer. The same small grid for selecting meeting which opens everywhere gets opened on the create account page instead of create client page. (There are no set client meetings for our MFI). And we send these newly selected meeting details to the function as input instead of customer_meeting dates which we ignore. Once the payment schedule is generated, our task is done. Then Mifos standard code takes over. The important factor is that we IGNORE the additional interest. For example: if a client chooses weekly repayment of Saturdays , and the disbursal is happening on Monday, say the 12th April, then the first repayment could be either 17th Apr or 24th Apr - in both cases the interest component for the days between 12th Apr to 17th Apr is not charged. It is as if the loan was actually disbursed on 17th Apr. Those who know Mifos code will understand that we are actually just adding a column for reporting and not touching the otherwise well running code. Minimal development effort. So far not so good but one can make do. I plan to extend the above solution to the hand held client as well. The only difference would be that instead of selecting the dates in UI, the selection will be done via the hand held assuming today as disbursal date. 2. Our customer wants to charge a specific Pre-EMI from their clients but does not want to deduct it from the loan amount always. For example: Say a client takes a loan on 23rd Jan choosing 5th as monthly repayment date, the loan also being disbursed on 23rd Jan. Our customer wants to optionally keep the first repayment date as 5th Feb or 5th Mar with a further option of deducting first interest, or schedule it, or bundle it. Let me explain. If first repayment is to be done on 5th of Feb, then the first installment will be only of the interest component for the days between 23rd Jan and 5th Feb. They want an option to EITHER deduct this amount directly from the disbursal amount on 23rd Jan, OR schedule a repayment on 5th Feb for only the interest component between 23rd Jan - 5th Feb, actual installments with Principal starting 5th Mar, optionally the first repayment of interest-alone happening earlier than 5th Feb (because at times clients do not prefer to or are not able to make a second visit so soon after the first one), OR bundle it, in which case the first repayment is scheduled for 5th Mar and it has an interest component calculated for days between 23rd Jan to 5th Feb as well as for 5th Feb to 5th Mar. Proposed Resolution: The development work which we avoided in my resolution to problem 1, is what makes the resolution to problem 2 a lot of work. 1. Am I correct in assuming I cannot play around with any settings and achieve this result? Or half of this result? 2. As a proposed solution, will it work if we simply add the objects on user interface to select these options - A:Disbursal Date, - B:Repayment Starting Date, - C:Mode of Pre-EMI - Deduct / Schedule / Bundle / ignore 3. And change the schedule generation algorithm accordingly? 4. Am I correct in assuming that the only piece of development is the change to algorithm according to these configurations (Once the schedule is generated and installments created with correct principal, interest etc, everything else will pick up correctly from there) ? Or will I be eaten by raptors <http://xkcd.com/292/> while I build this? Although it is more of a confirmation that I am asking for, I'll be grateful for any pointers, specially anything added in the recent release, which you think I am missing from my description. Thank you. Regards --- Pooja. |