Removing Meeting Requirements

Owned by Former user (Deleted)
Last updated: Sept 07, 2010Version comment
6 min read

Removing Meeting Requirements

Feature Summary
Currently, Mifos system requires every client, group and center to have a meeting assigned to them to be Active. But the MFI's following the teller model do not have meetings and thus we want this dependency on meeting schedule to be removed. The current dependencies on Meeting schedule has been detailed out in the Meeting Requirements section. The description below, however, also gives a brief of the current implementation followed by the propsed solution for each scenario.

Configuration

  • Current: Meetings are built into the Mifos sytem. There is no way to turn meetings on/off in the system.
  • Proposed solution: A configuration item is added (needs to be wordsmithed): "Include meeting support in Mifos? yes/no". Like client hierarchy, this parameter should be configured during set-up and shoulndn't be changed once it's set.

Clients/groups/centers

  • Current: The system mandates that every client, group and center should have a meeting schedule.
  • Proposed solution: If meetings are turned off: _ The "Schedule Meeting" function on the create center pipeline (group pipeline, if centers dont exist) should be removed and the mandatory check for meetings should be removed. _ The "Schedule Meeting" function on the create client outside group should be removed and the mandatory check for meetings should be removed. _ "Meeting details" should be removed from client, group, center detail pages. _ Edit Meeting Schedule should be removed from center detail page (or group page, if centers don't exist) and for clients outside groups. * Meeting attended/missed should be removed from the perf history box on client page

Client accounts

  • Current:
    • All the fee payments for a client, group and center are aligned to the meeting dates depending on the fee periodicity
    • One time fee is attached to the upcoming meeting.
    • A restriction is present that a weekly fee cannot be applied to a monthly meeting. Similar restriction is present for weekly meeting and monthly fee.
  • Proposed solution: If meetings are turned off:
    • All the periodic fee that are associated to the client during the create client process should be charged upon client activation, with future charges occuring as per periodicity.
    • For example, if client is created on 15th Oct and an upfront fee and a periodic fee (periodicity = 1 month) are applied to the account. Client is approved i.e. client activation date is 1st Nov. The upfront fee will be due on 1st Nov and periodic fee will be due on 1st Nov, 1st Dec, and so on.
    • After activation, when an upfront fee, misc fee/penalty, or a new periodic fee is applied to the account, system should assume that the fee is due immediately. (OOS: User can enter due date for fee)
    • For example, if client activation date is 1st Nov (Wednesday) and a fee with periodicity = 1 week is applied on 4th Nov (Saturday), fee due date should be 4th Nov, 8th Nov, 15th Nov and so on.
    • The date and charges in Upcoming charges section should be updated as per the fee/misc fee or penalty charged to the client
    • In above examples, on 5th Nov, if the client has not made any payment - overdue amount will include the fee due on 1st Nov = fee due on 4th Nov. Upcoming charges date will 8th Nov (since that is when the fee is due next).
    • Center activation date can be different from group activation date which can be different from the client activation date. The rules above, however, will apply to a center account depending on the center activation date. Similarly for group accounts and client accounts. Center activation date should not affect its group's or client's accounts.
    • Weekly or monthly fee can be applied to all customers. There will be no restriction on the fee type based on its periodicity.

Loans

  • Current: _ Loan repayment time has to be divisible by the meeting time. If the loan repayment frequency is different from the frequency of meetings, then client or group cannot apply for that loan. _ Loan disbursal date can be only a meeting date and by default is the next meeting date. _ Loan repayment dates are aligned with meeting dates based on the frequency of repayment. _ Clients and groups cannot be transferred to another branch/center with active loan accounts.
  • Proposed solution: If meetings are turned off: _ Clients can apply to any loan product irrespective of the loan repayment frequency. _ Clients and groups can be transferred to another branch/center with active loan accounts. _ Loan disbursal date should be blank and entered by user. _ Loan disbursal date can be any future date (one year from the current date) but must be a working day (ie, not a holiday or non-working days if those have been specified). * A new field should be added: date of first repayment. Default should be date of disbursement + loan frequency + grace period (um, can this be calculated on the fly, once user specifies disbursement date?) but can be edited by user to support scenarios where loan disbursal happens on different day the payment. The loan repayment schedule will be generated from this date based on loan frequency.
    • Date must be within 1 year of today's date.
    • Date cannot be earlier than loan disbursal date + grace period.
    • If interest is deducted at disbursement, first repayment date should not be accepted as first repayment date is same as disbursal date.
    • "First repayment date" field should be added to create, edit and disburse loan pipelines.
    • If the disbursal date is updated at any time, the loan repayment dates should not be effected. Loan disbursal date must be earlier or the same as first repayment date.
    • Date of first repayment can be changed up until the loan is disbursed.
    • If any repayment date happens to be a holiday, it should be moved to next repayment date, next working day, pervious working day, etc as per the configuration specified by HO.
    • If disbursal is done through bulk entry, first repayment date should remain unchanged. If date of transaction (from bulk entry) implies that the first repayment date becomes invalid, the disbursal through bulk entry should not be permitted. User should be prompted to change the first repayment date (from disburse loan pipeline of the account) and then disburse it from bulk entry if required.
  • Proposed solution: If meeting are turned on: * Even if meetings are turned on-- system should allow user to edit disbursal date to a non-meeting date-- ie, allow disbursals in between meetings.

Savings

NOTE: Many MFIs operating in teller mode don't collect savings. So handling this scenario is a low priority.

  • Current: * Savings deposit dates are the same as the account owner's meeting dates.
  • Proposed solution: _ Given that this isn't currently a use case-- can we simply punt on this? _ If the logic for "mandatory/voluntary amount for deposits" is removed, savings account will work fine. * QUESTION: The most common scenario I think that will happen is that savings deposits are tied to loan repayments. ie, per each loan repayment there will be a corresponding required savings deposit. If a user has 2 loans with repayments on different dates-- there will be 2 required savings deposits-- also due on that day. Again, I dont think we need to handle immediately-- but is this scenario something that Mifos can handle? In the teller model, I dont think there is a scenario of an MFI defining required or voluntary savings plans outside the loan schedule. More research will determine this.

Bulk Entry

  • Current: * Bulk entry screen displays expected payments based on a center (or group if center doesn't exist) meeting date.
  • Proposed solution: If meetings are turned off: _ Bulk entry should still display expected payments per group based on the "date of transaction" entered into the system. Default date should be today's date. NOTE: Need to follow up with Enda to determine if they will use bulk-entry in their operations. _ Remove "Attendance" column from bulk entry.

Misc

  • All batch jobs that consider meeting dates, should not be run. So the system should check the configuration and should run these batch jobs only if meetings are present in the system.

Open issues

  • If any time, before or after a center/group/client is created without a meeting, a meeting can be assigned. If it is done, what will happen to the loan accounts already present? ANSWER: If we make meetings an MFI wide configuration which is specified during set-up, then this is a non-issue.
  • Also, what should the behavior be for the customer accounts repayments and savings deposit dates? ANSWER: functionality for cust accounts has been detailed above. Still open issues on savings deposits.
  • If the meeting dates are not present, what should be the way to handle savings deposits? Should there be a parameter at savings product definition called "Frequency of deposits? If yes, then in case meeting dates are present, should the frequency of deposits be ignored?
  • Will this affect reports in any way?
  • Date of transaction in bulk entry- How much in the past can this date be?

Main.aditi_swatirathi - 19 Apr 2005