Administrative Configuration

Introduction

The following configurations can be defined at the time of installation and changed at any time using links in the Manage organization section on the Admin tab.  The following describes in details what options and labels are available for administrative configuration.  For the latest details on how to configure these, see this section in Configuring Mifos.

Customized Text (Mifos 2.2.x and above)

In Mifos 2.2.x, UI text labels were replaced with Customized Text.  Any text in Mifos can be customized using the Define Customized Text link on the Admin tab.  Any original text will be replaced with the new text entered.  For example, to replace references to clients with members, customized text should be defined with original text being clients, and new text being members.

UI text labels (Mifos 2.1.x and below)

Mifos allows the following labels to be renamed from the Define labels link on the Admin tab. The new labels will then appear throughout the Mifos UI.  New labels should retain the same meaning as the original label (For example:  you should not rename the label "Active in Bad Standing" to "Active in Good Standing".)

These labels are:

• Interest
• Office Hierarchy:  Names of offices at each level. For 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, Grace on all repayments, Principal only grace
• Personal Information
  • State
  • Postal Code
  • Ethnicity
  • Citizenship
  • Handicapped
  • Government ID
  • Address fields- Address 1; Address 2; Address 3
• States: All states for all entities can be renamed. [labeled status in the UI]
• Miscellaneous: Interest, External ID, Bulk entry

Look-up options

Look up options for the following attributes can be defined and specified during installation. Post-deployment, the options should not be deleted. However, more options can be added in each list, from the Define lookup options link on the Admin tab.

• Salutation
• User title
• Marital Status
• Ethnicity
• Educational level
• Citizenship
• Business activity
• Purpose of loan
• Handicapped
• Collateral type
• Officer title
• Mode of Payment

Mandatory/Hidden Fields

Mandatory/Optional Fields

The client account attributes table describes which client attributes are mandatory and which are optional. But some attributes 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 should be done only before deployment and should not be modified later. These attributes are listed below:

System Wide (all applicable, such client, group, and center, personnel)

• External ID
• Ethnicity
• Citizenship
• Handicapped
• Loan- Purpose of loan
• Education level
• Handicapped
• Photo
• Address1- This is applicable to address 1, city, state, country and postal code for that address

Client / System User fields

• Second last name- This is applicable for clients, client’s spouse/father and personnel
• Middle name - Same as above
• Government ID
• Poverty Status
• Phone Number
• Trained On
• Trained
• Business/work activities
• Number of Children

Loan

• Purpose of Loan
• Source of Funds

Hiding Fields

In addition, some data fields can be completely hidden from the Mifos UI.  This should also be done pre-deployment, and should not be modified later.  These are:

System Wide (all applicable, such client, group, and center, personnel)

• External ID
• Ethnicity
• Citizenship
• Handicapped
• Education Level
• Photo
• Assigning client to positions
• Address 2
• Address 3
• City/District
• State
• Country
• Postal Code
• Receipt ID and date
• Collateral type and Collateral notes

Client / System User Fields

• Middle Name- can be hidden separately for client, spouse/father and personnel
• Second last name- can be hidden separately for client, spouse/father and personnel
• Government ID
• Poverty Status
• Phone Number
• Trained (Client + Group)
• Business / Work activities

Accepted payment types

Mifos supports the following payment types, which are required for reporting purposes and have no financial implications:

• Cash
• Voucher
• Checks

For each of the transaction types listed below, one or more of the above payment types can be set as Acceptable, from the Define accepted payment types link on the Admin tab. 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 affect existing transaction entries. Transaction types are as follows:

• 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

The payment type for collectoin sheet entry is always Cash only.

Note: Payment types have no direct impact on GL codes. An MFI, recognizing that all of its loan disbursements are handled via checks, might assign a particular GL code that has a correlation to a checking account. The logic for that is outside Mifos.

Custom fields

In addition to the pre-defined fields, an unlimited number of custom fields can be used to define user data, through theDefine additional fields link on the Admin tab.  These can be either personal or MFI-related fields.

• Custom fields can be text or numeric.
• The MFI provides the label and the content of these fields.
• Custom fields are positioned at the bottom of the UI.

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.

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

Checklists

Checklists remind users of the internal processes required before the status of accounts or customer records can be changed. Checklists are optional, and can be created 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. For example, if the system administrator defines a checklist for the 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.  Note that a user's responses to the checklist are not saved.

A checklist is defined for the destination state and is not dependent on the source state. At most one 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. Checklists can be modified and or made inactive.

Checklists are defined and saved using the Define new checklist link on the Admin tab, so that they can be attached to states of customer records and accounts. Attributes of checklists are provided in the following table:

Attaching checklists to states

The saved checklists are attached to states of accounts or customer records according to the type and state specified during creation, as follows:

• 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):
  • 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 checks the box when 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.
• Responses to the checklists

Holidays, Moratoriums, and Non-Working Days

Working and non-working days can be specified during configuration.   The property FiscalCalendarRules.WorkingDays is used to specify which days of the week are working days.  For details on these properties and how to configure them, see this section in Configuring Mifos.

Holidays and Moratoriums can be defined from the Admin tab by a user with appropriate permissions using the Define new holidays link.  By default, no holidays are defined.  Each holiday is specified by a name and from/to dates, which are inclusive and apply only to future dates. A holiday is also defined by a repayment rule, which is used for the rescheduling of meetings and repayments that fall on that holiday(s).

Holidays/Moratoriums and Offices

Holidays and Moratoriums can be applied at the branch office level up to organization wide.  When creating a holiday, the office hierarchy is displayed (depending on how your Mifos is configured) and offices below Head Office can be selected.  If a parent office is selected (any office above a branch), all offices below that office inherit the holiday as well.  It is also possible to individually select one or more branch offices that a holiday applies to. 

Repayment Rules

The same options can be set for holidays and non-working days, and these apply to both.

The rule options are:

• Same day: Meeting/repayment will be assumed to be on the same day even if it’s a holiday or non-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.
• Next working day: Meeting/repayment will be shifted to next working day.
• Moratorium: Meeting and repayment schedules are pushed out.  Schedules resume after moratorium is over. 

The rule can be defined for or after specific meetings, loan disbursal dates and loan repayment dates are scheduled, with the following implications:

Meetings: Meetings cannot be scheduled to regularly fall on a non-working day. If a meeting occasionally falls on a non-working day (for example, if meetings are scheduled for the third day of every month, which may occasionally fall on a non-working day), then the system moves the meeting according to the rule defined. The collection sheet will be updated according. [Note: if repayments are moved to the next meeting, then attendance is counted twice?]

Loan disbursement date: For loans not yet disbursed, the user cannot specify a disbursement date that falls on an existing non-working day. If the non-working day is defined after the disbursement date is set, the system changes the date according to the rule defined. The system validates the first repayment date at the same time.

Loan repayment schedule: The repayment schedule is calculated factoring in known non-working days. If a non-working day is defined after a loan repayment schedule is calculated, the system updates the payment dates and updates the repayment schedule for the loan. Note that no changes to interest are made, even if the balance declines. If multiple repayment dates are affected, then all of the repayments that were delayed by the holiday must be repaid together on the next scheduled repayment date, according to the rule defined.

Mandatory savings deposit schedules, voluntary deposit schedules, and client fee schedules also take non-working days into account.

Meetings and payments that are rescheduled are flagged in the schedule display with a *.