Moratoriums
Introduction
Many MFI's, including KMBI and SECDEP, need the ability to delay their loan schedules without penalty, usually in case of some catastrophe. We need to add a feature to be able to define this moratorium period where the clients do not have to pay, and the loan schedules are essentially pushed out. There is also a need for selecting certain branches that the moratorium period will be applied to - this will be in a separate spec.
User Stories
| Priority | User Story | Section in FR |
|---|---|---|
| 1 | As an Administrator at an MFI, I want to be able to define a payment moratorium and have all schedules in the entire organization pushed out. |
Goals
- Ability to define a period ("holiday") that schedules are pushed out - for the entire organization or specific branches.
- Loan schedules are essentially pushed out during that period (as if that period of time does not exist in the schedule). There is nothing collected during that period.
- Mandatory savings schedules are also pushed out.
- Any fees associated with clients, groups, centers are also pushed out.
Non-Goals
The following items will not be addressed in this release:
- Setting a moratorium for any entity less than a branch office.
- Selecting what exactly will be pushed out in a moratorium - assumption is all principal, interest, fees are pushed out during a loan schedule, etc.
Definitions and Terminology
| Term | Definitions |
|---|---|
- Mandatory fields will be preceded by *
- Links are italicized
- Buttons are Button
Related Documents
- Business Requirements - KMBI - Mifos Business Requirements
Holiday Push Out
This feature will allow schedules to be pushed out
Use Cases
Administrator creates a holiday with repayment rule Payment Moratorium for entire organization.
Actors
- Administrator
Preconditions
- None
Basic Flow
- Administrator navigates to Define new holidays.
- Administrator creates a new holiday "Payment Moratorium" with a period from one date to another. Administrator hits Preview.
- System displays new holiday with the Holiday name, dates, and repayment rule "Payment Moratorium." Administrator chooses to Submit.
Post-conditions
- Mifos has new moratorium defined for the period above.
Alternative Flows
Administrator edits new holiday of Payment Moratorium.
- At step 3 of basic flow, Administrator clicks on Edit Holiday to edit details of the holiday, and hits Preview again. Use case continues at step 3 of Basic Flow.
Post-conditions
- Mifos has new moratorium defined.
- Schedules that includes dates in that moratorium period are pushed out accordingly. These include loans, mandatory savings, and any fees.
Validations
- Holidays periods cannot be created in the past (either To or From dates must be before current date) - following error message is displayed - Holiday can't be added for current date or dates in the past.
Administrator creates new Payment Moratorium on top of existing holiday(s).
Actors
- Administrator
Preconditions
- None
Basic Flow
- Administrator navigates to Define new holidays.
- Administrator creates a new holiday "Payment Moratorium" with a period from one date to another. Administrator hits Preview.
- System displays new holiday with the Holiday name, dates, and repayment rule "Payment Moratorium." Administrator chooses to Submit.
Post-conditions
- Mifos has new moratorium defined for the period above.
Scenarios
| # | Priority | Scenario Description | Expected Behavior |
|---|---|---|---|
| 1 | P1 | Payment Moratorium defined for 4/1/2010 (Thursday) to 4/20/2010 (Tuesday). No other holidays defined during this period. | All schedules that hit this period inclusive will be shifted. Examples: - A client that meets weekly on Thursdays will NOT have payments due for loans, mandatory savings, or fees for 4/1, 4/8, or 4/15. Their schedule will continue on 4/22 and end 3 weeks later than original. - A client that meets weekly on Wednesdays will NOT have payments due on 4/7 and 4/14. Their schedule will be shifted to 4/21. - A client that meets monthly on the 2nd will not have a payment due on 4/2. Their schedule will be shifted to 5/2. - A client that meets bi-weekly every Thursday with a payment on 3/25 will not have payments due on 4/8. Their schedule will be shifted to 4/22 (2 weeks later). - A client that meets bi-weekly every Thursday with a payment on 3/18 will not have payments due on 4/1 or 4/15. Their schedule will be shifted to 4/29. |
| 2 | P1 | Payment Moratorium defined for one day 4/1/2010. No other holidays already defined on this day. | Only schedules that had a payment date on 4/1/2010 will be affected. The schedule will be shifted accordingly the frequency of their repayments. Schedules that meet on other days will not be affected. |
| 3 | P1 | Payment Moratorium defined for 4/1/2010 to 4/10/2010. There is already a holiday defined that overlaps some or all of that period with a different repayment rule. | The Payment Moratorium shift will take precedence. Example: There is an existing holiday defined on 4/2/2010. A moratorium is issued on top for 4/1 to 4/10. Any schedules on 4/2 are pushed out accordingly (moratorium). |
| 4 | P2 | Scenario #3, then another holiday is defined on top. | Any time there is a moratorium, doesn't matter if a holiday is defined before or after the moratorium was set in Mifos, the moratorium takes precedence if there is both a moratorium and a holiday on the same day. |
| 5 | P1 | Overlapping holidays that are not moratoriums are defined. | In this case, for the day(s) that 2 holidays are defined, the holiday defined last should take precedence. However, we will not fix this in this release. |
| 6 | P? | A Payment Moratorium is defined immediately following a non-moratorium holiday | Mifos will apply the repayment rule for days that fall in the non-moratorium holiday, and then apply schedule-shifting to payments that fall in the moratorium. For example, a holiday is defined for the week starting Monday, 4/29/2010 (just before the payment moratorium defined above) with repayment rule Next Meeting/Repayment. A client with payments due on Wednesdays will have their 3/31 payment shifted to 4/7. But for the moratorium, they would have two payments due on that day. The two payments are shifted to Wednesday, 4/21 and the remaining schedule is shifted to 4/28 and beyond. |
User Stories
| Priority | Size | User Stories | Mingle card # |
|---|---|---|---|
| 1 | Small | As a User, I can create a new holiday for a Payment Moratorium for the entire organization. | |
| 1 | Large | As a User, I can see that loan schedules have been pushed out for that moratorium period. | |
| 1 | Medium | As a User, I can see that mandatory savings schedules have been pushed out for that moratorium period. | |
| 1 | Medium | As a User, I can see that client, group, and center fees have been pushed out for that moratorium period. |
Payment Moratorium Functional Requirements
New Repayment Rule
| FR# | Pri | Description | Comments / Mockups |
|---|---|---|---|
| 1.1 | P1 | Add new repayment rule called Payment Moratorium under Repayment Rules drop down in Define New Holidays. This option should appear last. | |
| 1.2 | P1 | When previewing new holiday, under Repayment Rule column, should say Payment Moratorium. | |
| 1.3 | P1 | When viewing all holidays, Repayment Rule column needs to show correct rule of Payment Moratorium | |
| 1.4 | The rule to follow when shifting schedules is this. At every repayment date in a schedule, check to see if there is a holiday or moratorium defined. If there is a moratorium defined take that first and shift accordingly. If not, then apply holiday repayment rule accordingly. Continue for each date in the repayment schedule until it is done. |
Effect on Loan Schedules
| FR# | Pri | Description | Comments / Mockups |
|---|---|---|---|
| 2.1 | P1 | All client and group loans will be shifted with the holiday period. | |
| 2.2 | P1 | This includes all penalties, fees, interest, and principal due for that period. | |
| 2.3 | P1 | Applies to any frequency of loan installments (weekly, every 2 weeks, monthly, etc), interest rate types (flat, declining balance, etc), and any kind of loan products. | |
| 2.4 | P1 | If a recurring fee is added to a loan after a moratorium has been set, that recurring fee should also be pushed out w/ the rest of the loan as expected. | |
| 2.5 | P1 | Work with LSIM on or off. If LSIM is on, then it's the repayment schedule, not the meeting dates that are pushed out. | |
| 2.6 | P1 | Bulk Loan Creation - loans created using Bulk Loan Creation should follow same rule if loan repayment schedule could overlap with holiday period with this new repayment rule |
Effect on Savings Schedules
| FR# | Pri | Description | Comments / Mockups |
|---|---|---|---|
| 3.1 | P1 | All client and center savings deposits will be shifted with the holiday period | |
| 3.2 | P1 | This includes mandatory deposits. Voluntary deposits should display the same, as they do not double up if not deposited currently anyway | |
| 3.3 | P1 | Applies to any frequency of deposits | |
| 3.4 | P1 | ||
| 3.5 | P2 |
Effect on Fees Schedules
| FR# | Pri | Description | Comments / Mockups |
|---|---|---|---|
| 4.1 | P1 | All client, group, and center fees will be shifted with the holiday period | |
| 4.2 | P1 | ||
| 4.3 | P1 | ||
| 4.4 | P1 |
Other Assumptions
LSIM
GLIM
QA Considerations
Standard Considerations
Security (Permissions, Roles, and Data Scope)
| Does the user need to be in a particular user hierarchy to use this feature? | No |
| Does the office hierarchy affect use of this feature? | No |
| Are you using any existing permissions to control this feature? | No - though there is an open bug on Holiday permissions |
| Are you adding any new permissions or changing existing permission to control this feature? | No |
| Are you using any existing activities to control this feature? | No |
| Are you adding any new activities or changing existing activities to control this feature? | No |
| Are there any special considerations for upgrade scenarios? What will be the default value for new permissions? | No |
| What will be the default values for default roles in a new installation? | No |
Impacts to System
| Does this feature affect Bulk Loan Creation? How? | Yes |
| Does this feature affect Collection Sheet Entry? How? | Yes |
| Does this feature affect Redo Loans? | Yes |
| Does this feature affect Undo Loans? | Yes |
Globalization/Localization
| Will this feature support users localizing data that they enter? | N/A |
| Does this feature involve any date/time related data, and if so how should conversions be handled? | No |
| Is there currency or other numeric data ? If so does it require any special handling or validation? | No |
Logging
Change Log
| Do changes to the data that is collected or stored by the new feature have to be fully logged by the system? | N/A |
| Does the administrator configuring the system need the ability to turn on or off logging for this feature? | No |
| Is the feature currently logged but the structure of the logged records changing? | No |
Reporting
Provide any relevant information about reporting requirements for the new features and answer the questions below, providing detail to explain any particular area when necessary.
| Does the feature affect any existing reports? | Collection Sheet report |
| Does the feature require adding any new reports? | No |
Performance
| Will the feature be a high use-case scenario? | No |
| Will the feature have potential for high concurrency? | No |
| Does the feature include complex UI or data gathering logic that will be used by a significant portion of the user base? | No |
| Does the feature contain risks of database connection timeout? | No |
| Will the feature contain any bulk insert/update/delete transactions? | No |
| Will the feature contain any caching mechanisms or cache refreshing mechanisms? | No |
| Could the feature result in a large amount of data being sent to the client or between the database and web server? | No |
| Would users on a low bandwidth connection likely face issues with a part of this feature? | No |
| Does the feature affect existing batch jobs or require adding any new batch jobs? | No |
Setup and Installation
New Installations
| Will the feature include demo data? | No |
| Does the feature require any data to be gathered at setup runtime? | No |
Backward Compatibility and Upgrades
| Is there any data conversion that needs to be done as part of an upgrade? | No? |
| Will customers lose data or will the way existing data is stored change significantly? | No |
| Will another feature, workflow or portion of the data model be deprecated as a result of this new feature? | No |
| Will existing role permissions be changed or impacted by this feature? If so provide details in the security section. | No |
| Will existing customers need to learn a new UI process or change the way they use the system as a result of this new feature? | New option for repayment rules in Holidays |
Hosting Support
| If different user groups are using the same database, are there concerns over the sharing of data related to the feature? | No |
| Are there expected to be performance related issues with having many customers sharing the same hardware in support of this feature? | No |
Configuration
| Does this feature require changes to configuration files? | No |
| If so, is this feature enabled or disabled by default? | N/A |
Customers
| Which MFI's do we expect to use this feature? | SECDEP, KMBI |
| How will this impact them? | Can only create holidays w/ this repayment rule after it's deployed |
Open Questions and Notes
Review and Approvals
| Date | Name | Role | Status |
| PM | |||
| Dev | |||
| QA |