DEPRECATED: These functional specifications are currently outdated - for the current ones please see:  Configuring Mifos

This section details the configuration settings, which should be specified during installation using database scripts.

In version 1, system will not provide the front-end. The configuration values will be stored in the database. Therefore, there will not be any difference between configuration values that can be edited multiple times and the ones that cannot be specified once and cannot be edited later. The administrator, however, should be careful in changing these as it could considerably impact the way the application behaves. No history will be maintained for these values.

Here is a spreadsheet that clearly maps out all items that can be configured in Mifos. (XLS) The MFI's business team should complete this spreadsheet so that their Mifos Specialist can install Mifos correctly.

[[][Instructions for how to configure Mifos]] (TBD from Aditi).

 

( * ) Indicates values that CANNOT be CHANGED after installation of the application.

 

3.1 Fiscal year

• * Working days- The working days in a week can be specified. Once a day has been marked as a week day, it shouldn’t be removed as it could already be a part of some meetings and repayment schedules
• Default working days- None. Important- At least one working day should be specified during installation for system to work
• Starting day of the fiscal week should also be specified. This can be any working/non-working day of the week. This will be used by reports module to generate weekly reports. By default, starting day will be Monday
• Allow calendar definition for next year - The number of days after which the calendar definition for the next year can be specified.

 

3.2 Localisation

 

• * Country: This indicates the country to which the MFI can belong. MFI can belong to only one country.
• * Currency: Each MFI will have a single currency depending on the country of MFI.
• Date Format: Date format is dependant on the locale chosen.
• Language -System will support languages from a pre-defined list. A primary language for the whole of MFI will be fixed during installation. Users can however, choose another language from the languages supported as a user preferred language. All labels and static text will be displayed in the user-preferred language.

 

 

3.3 Accounting rules

As mentioned in the Accounting requirements section, rounding rules will be specific to a currency. See Accounting in the Functional Specification for more information on these items.

• * Number of digits after decimal and whether to round up or round down will be specified for each currency in the database.
• * Amount to be rounded to. Default- 0.01
• * Rounding rule- The rounding rules supported by the system will be “Round up” and “Round- down”. Default- Round up. For details and examples, refer Rounding
• * Number of interest days in a year- Can be 360 or 365. This is used only for interest calculation and should not be modified once set. Eg: In the case of a moratorium, the loan schedule is recalculated and changing the number of interest days in a year could bring about different calculations
  • Note: This is not applicable for meetings, as meeting calendar always has 365 days in a year.
  • Also, this is not applicable for fees and penalties calculation and repayment schedule generation.

 

3.4 Miscellaneous

• Sequence of name- For the purpose of displaying names of personnel, clients and clients’ father/spouse’s names, system will support the following three sequences:
  • First Name (Middle name if exists) Last Name (Second last name if exists)
  • Last Name (second last name if exists), First Name (Middle Name if exists)
  • First Name (Middle name if exists) (Second last name if exists) Last Name. This option will be set by default
  • For details, refer Name.

 

• Session time out rule- HO can specify the time for session time out for system users. This time will be stored in minutes. System will timeout the session if it is idle for more than this duration. Default: 15 minutes.

 

• Officer titles- Six officer titles can be specified for centers and groups. The tittles can be added/edited from the database but existing titles should not be deleted as there could be references to these titles in the system. Note- Centers and groups will refer the common list of officer titles.
  • An individual can be given one or more titles.
  • Assigning a client to a position is optional, that is, a title can exist without a client assigned to the title.
  • Groups and centers refer a common master list of titles, that is, separate master lists are not defined for groups and centers.

 

• Back-dated transactions: HO can specify whether/not system will accept back-dated transactions. This is an MFI wide setting and will be applicable to all transactions in all offices for all loans, savings and client accounts. By default- backdated transactions should be allowed. If the setting is changed it applies to only future transactions
  • If “yes”, user can enter transactions dated earlier than current date (but later last meeting date).
  • If “no”, then user can only enter transactions dated with the current date. Also, “date of transaction” for bulk entry will be the current date always.

 

• Office hierarchy- The number of levels in office hierarchy can range between 2 and 5. Default labels of these levels will be (in ascending order): Branch Office (BO), Area Office (AO), Sub-Regional Office, Regional Office, and Head Office (HO)
  • Important: HO and BO levels should never be removed from the system
  • Default labels of the five levels are (in ascending order): Branch Office (BO), Area Office (AO), Sub-Regional Office, Regional Office, and Head Office (HO)
  • Lopsided hierarchy for offices can exist in the system. For example, a BO can have HO as the parent office even if there are AOs existing in the structure.
  • The hierarchy defined sets the reporting structure for the MFI.
  • The front end for this configuration will be implemented in version 1.
  • A new hierarchy can be added, however a level cannot be removed if there is a office existing at that level.

 

 

3.5 Process flow/optional states

• * Clients and accounts have some optional states, which can be hidden and excluded from the state flows. If omitted, these optional states will not be visible in the UI. Once an optional state is included, it should not be removed as some records could be in that state.
  • The optional states are:
  • Pending Approval (Clients)
  • Pending Approval (Groups)
  • Pending Approval (Loan accounts)
  • Disbursed to Loan Officer (Loan accounts)
  • Pending Approval (Savings Accounts)

 

3.6 Client Rules

 

• * Whether “Center” hierarchy is present in the system. By default- center hierarchy should exist.
• Whether Groups are allowed to apply for loans- If this value is set to NO, groups will not be allowed to open loan accounts. Once the value is set to Yes, it should not be changed to NO as there could be group loans existing in the system. By default- group loans should be allowed.
• Whether Clients can exist outside group. By default, this should be set to yes. Once the value is set to YES, it cannot be changed to NO, as there could be clients outside a group existing in the system.

 

3.7 Lateness/dormancy definition

NOTE: deemed unimplementable since a user interface still exists for maintaining application-wide lateness/dormancy settings. See Admin->View lateness/dormancy definition in Mifos Web UI, PrdConfAction class, and editLatenessDormancy.jsp.

• Specify the number of days of non-payment after which status of loan account is changed to "Active in bad standing” by the system. Default- 30 days. This field should not be left blank.
• Specify the number of days to define "Dormancy" in Savings Accounts. The account status will be changed to "In active" by the system. Default- 30 days. This field should not be left blank. [NOTE: this feature wasn't implemented in V1. A batch job needs to be built to support this feature.]
• The front end for this configuration will be implemented in version 1.

IMPORTANT: The above values indicates those values specified in a configuration file. Reinstallation of the application will not be needed for a modifed value to be reflected

 

3.8 Labels

System allows renaming of some labels. These labels, if renamed, will be replaced by the new label at all the places in the GUI. These labels are:

• States- All states for all entities can be renamed.
• Interest
• Office Hierarchy- Names of offices at each level. Example, Head office can be renamed to “Home” etc.
• Client
• Group
• Center
• Payment Modes- Cash, Check and Vouchers can be renamed.
• Product Types- Loans and Savings can be renamed
• Bulk Entry
• Grace types- None, Interest only payment, Grace on all repayments
• Personal Information
  • External ID
  • State
  • Postal Code
  • Ethnicity
  • Citizenship
  • Handicapped
  • Government ID
  • Address fields- Address 1; Address 2; Address 3

 

3.9 Look-up options

Look up options for the following attributes can be defined and specified during installation. Post installation, the options should not be deleted however, more options can be added in each list.

• Salutation
• User title
• Marital Status
• Ethnicity
• Educational level
• Citizenship
• Business/work activities
• Purpose of loan
• Handicapped
• Collateral type
• Attendance

 

3.10 Hidden/Mandatory data fields

The attributes table describes which client attributes are mandatory and which are optional. But there are some attributes, which can be specified as mandatory/optional to suit the specific needs of different MFI’s. The rules around the entity creation and modification will depend on these data fields; therefore this classification into mandatory/optional fields and hiding of the irrelevant data fields should be done only during installation and should not be modified later. These attributes are listed below:

• Second last name- This is applicable for clients, client’s spouse/father and personnel
• External ID
• Client phone number
• Client Trained
• Ethnicity
• Citizenship
• Handicapped
• Loan- Purpose of loan
• Educational level
• Photo
• Address of group- This is applicable to address 1, , city, state, country and postal code for group

Hiding Data Fields
Some attributes can be hidden from the UI. These are:

 

• Middle Name- can be hidden separately from client, spouse/father and personnel
• Second last name- can be hidden separately from client, spouse/father and personnel
• Government ID- can be hidden separately from client and personnel
• External ID- can be hidden separately from client, group and center
• Address 3- from all addresses
• State- from all addresses
• Country-from all addresses
• Postal Code—from all addresses
• Client Trained and Trained on date
• Ethnicity
• Citizenship
• Handicapped
• Client business/work activities
• Educational level
• Photo
• Entire address of client- This is applicable to address 1, address 2, address 3, city, state, country and postal code for client
• Entire address of group- This is applicable to address 1, address 2, address 3, city, state, country and postal code for group
• Entire address of center - This is applicable to address 1, address 2, address 3, city, state, country and postal code for center
• Telephone number can be hidden separately for client, group, center
• Group trained and Trained on date
• Receipt ID and date- From all transactions
• Collateral type and Collateral notes

 

3.11 Accepted payment types

These different payment types are required for reporting purpose and do not have any financial implications

Note: Payment types have no direct impact on GL codes. An MFI-- recognizing that all of it's loan disbursements are handled via checks- might assign a particular GL code that has some correlation to a checking account but the logic is handled on their side. This is outside the Mifos system.

The system supported payment types are:

• Cash
• Voucher
• Checks

For the transaction types listed below, one or more of the above payment types can be set as “acceptable”. Only the “accepted payment types” will then be available as the possible mode(s) of payment for the transaction type. Once a payment type has been included as an accepted payment type for a transaction, it should not be removed as it can have references in some transaction entries. The following transaction types will each have its own list of accepted payment types:

• Payment types for clients/group/center fees
• Payment types for disbursements of loan amounts
• Payment types for loan repayments
• Payment types for withdrawals from savings accounts
• Payment type for deposits in savings accounts
• Accepted payment type for bulk entry is always Cash only.

 

 

 

3.12 Custom fields

In addition to the pre-defined fields, there can be upto 10 custom fields to define user data. These can be either personal or MFI related fields.

 

• These can be text, date, or numeric fields.
• The label is provided and content of these fields is defined by the MFI
• If chosen, these fields will be included and positioned at the bottom of the UI.
• The 10 custom fields will be of following types: 2 date formats, 3 integer, 5 text fields.

 

Creation of Custom fields

The categories for which a custom field can be created as well as the type of custom field are pre defined. A user with required permissions can create new custom fields.

Attributes to define custom fields

The rules and attributes for custom field creation are described in the table below. The table also shows those values that can be edited after a custom field is created.

 

S.No.	Attribute Name	Data type	Range	Can be modified after definition	Description /Notes
1	Category	Drop down- Single select	Client; Group; Center; Loan; Savings; Personnel	No
2	Name	Text	N/A	Yes	The change, if any, will be applicable to all the existing and new records or accounts
3	Type	Drop down- Single select	Text; Date; Integer	No
4	Default Value			Yes	The change, if any, will be applicable to all the new records or accounts
5	Mandatory	Checkbox		Yes	The change, if any, will be applicable to all the new records or accounts

 

System Validation

 

 

Checklists

=Overview=

Checklists communicate or remind the internal processes required before changing the status of accounts or customer records. Each time a user attempts changing the state of an account or customer record, the checklist defined for that state change is shown to the user. The user can read through the checklist and make sure all the requirements are met. These checklists are (are or "can be" since its not mandatory) associated with all workflows for accounts and client records.

=Functionality=

* Checklists are defined by the HO and associated with certain states of customer records or accounts. Checklists are not attached to individual customer records or accounts, but are displayed in between state changes.

* It provides a set of "reminders" to the user. For example, if HO defines a checklist for Pending Approval state of a loan account, every time a user attempts to change the state of a loan account to Pending Approval, the checklist is displayed to the user. The user can then make sure each condition on the checklist has been satisfied.

* A checklist is defined for the destination state and is not dependant on the source state. * Only one (can be none) checklist is allowed for each destination state in clients, groups, centers, loan accounts and savings accounts.

* Only the latest version of a checklist is maintained in the system. Older versions of a checklist are not maintained. Checklists can be modified and or made inactive.

=Defining Checklists=

Checklists have to be defined and saved, so that it can be attached to states of customer records and accounts. Attributes of checklists are given below:

 

S. No	Attribute Name	Range	Mandatory for Active/Inactive states	Can be Modified after Definition or not?	Remarks
1	Name	50 char	Yes	Yes
2	State	Active or Inactive	N/A	Yes	If the checklist is Inactive, it is not displayed in the respective state transitions. When a checklist is created, the state is Active by default.
3	Type	Client, Group, Center, Loans, Savings	Yes	Yes
4	Displayed when moving into status	States applicable to the selected type (i.e., Client, Group, center Loans, or Savings)	Yes	Yes	Status applicable to the type selected
5	Created Date	N/A	N/A	N/A	System Generated
6	Created By	N/A	N/A	N/A	System Generated
7	Items	N/A	At least one item is mandatory.	Once specified, an item cannot be modified. But it can be deleted.	These are line items with a size limit of 250 characters per line item. There is no maximum limit on the number of items that can be included in a checklist.

 

 

 

=Attaching Checklists to States=

The saved checklists are attached to states of accounts or customer records as per the type and state specified during creation. The specifications for the same are:

 

• Type: Loan; Savings; Client; Group; or Center
• Status: All statuses specific to the type. For example, a checklist can be defined for Type = Clients, and Status= Pending Approval. In this case, the checklist is displayed whenever any client record status is changed to Pending Approval. In a similar manner, a checklist can be attached to any state transition for all the types listed above.
• Exclusion: Checklists for following states cannot be defined (not required):
• Centers- Active state
• Groups and clients- Partial Application state
• Exclusion: Checklists will not be displayed during creation of a client, group, center, loan or savings account.
• On the checklist (during a state change), a ’checkbox’ appears against each line item defined. The user can check the box if the particular line item has been satisfied.
• All items on the checklist are considered mandatory by default and they will have to be checked before the state transition is accepted by the system.

=Out of Scope for Version 1.0=

 

• Checklists in multiple languages; however, the data model supports storing checklist in multiple languages.
• Reusing the items on checklists. Each item on a checklist has to be manually entered.
• Storing responses for checklists.

 

 

 

 

 

 

 

Not Yet Implemented

• Meeting/repayment rule in case of a holiday or non-working day- The rule to handle the case if meeting/repayment falls on a non-working day or holiday, can be specified by the HO for all offices. The options are:
  • Same day- Meeting/repayment will be assumed to be on the same day even if it’s a holiday.
  • Next working day- Meeting/repayment will be shifted to next working day.
  • Next meeting/repayment day- Meeting and client account payment will be shifted to next meeting. Repayment will be shifted to next repayment day.
  • Default- Same day