Internationalization

Mifos is currently available in English, French, Spanish, Chinese, and Portuguese and supports localization into additional languages. Mifos is designed using internationalization (il8n) standards.  Mifos can be localized through an online translation tool called Translatewiki.net;  more information can be found here.

All components that ship with Mifos are internationalized (including those stored in the database or XML files) and localizable, depending on the language chosen by the MFI.

Note the following for Mifos:

Country. An MFI can belong to only one country, which is specified during installation.

Currency. Currently, Mifos supports only a single currency per installation.

• Currently, Mifos does not support the use of a comma as a decimal separator (i.e., one can’t use 10,000 instead of 1000.00)
• A rounding rule can be specified for the currency. [link to general rounding rules]

Time zone. MFIs can belong to only one time zone. Mifos stores and displays all operations/transactions in the server time zone.

Date formatting. Mifos supports DD/MM/YYYY as the date format (not MM/DD/YYYY).

System Configuration

Mifos needs to be configured before it can be deployed.  Please read this page carefully before deploying Mifos.  It includes details on how to customize your properties file, set database settings, and also how to configure certain options such as Lookup Options and Hidden/Mandatory Fields through the Admin tab in Mifos.  Explanations of Administrative configuration can be found here as well. 

Manage Mifos Shutdown and User Administration

In Shutdown Mifos, an Administrator can manage a pending shutdown of Mifos and view users that are logged into Mifos.   The Administrator must have the permission "Can Manage Shutdown" in order to do this.

An Administrator can enter the amount of time before planning to shutdown Mifos, then Start Shutdown to start the process.  After Start Shutdown, no more users are allowed to log onto Mifos and will get an error message if they try to do so.  All other users that are already logged in get a message at the top of their screen notifying them that a shutdown will occur and that they will be logged off at that time.

If the Administrator changes their mind, they can Cancel Shutdown, and this will return Mifos back to normal.  Users that are logged on will not see the message at the top anymore, and new users are able to log on.

This page also includes a list of all users that are logged onto Mifos, their branch office, their first and last names, and also what page they are on in Mifos.

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.

UI text labels

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 the Define 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 *.

Chart of Accounts

Introduction

The Chart of Accounts (CoA) is a list of accounts in the general ledger, systematically classified by title and number. The account number is referred to as the GL code. The appropriate financial transactions are posted against these GL codes. Mifos provides a default CoA.  From Mifos 1.1 onwards, the CoA configuration is in XML.  This section in Configuring Mifos describes how to customize your own CoA.

See also: Microfinance Accounting Issues

All offices under the HO use the same CoA. The list of accounts is organized into the following general ledger categories:

• Assets
• Liabilities
• Income
• Expenditure

The Mifos CoA supports up to four levels of categories.

• The first level is called a category, and consists of ASSETS, LIABILITIES, INCOME and EXPENDITURE. These categories cannot be removed or modified and new categories cannot be added.
• Categories are followed by up to three levels of sub-categories. MFIs can rename the description of default subcategories.
• Sub-categories can be added to the CoA within the approved structure, as defined in this specification. The updates, if any, will be reflected in the respective acceptable GL Codes list for the different entities.  For example, if a GL code for interest has been added in CoA, then when creating a loan product, the drop down box for the Interest GL code is populated with options from the CoA.

Default Chart of Accounts

Mifos supports and ships with the following CoA in the configuration file.

Please review the following information very carefully:

• Required general ledger accounts are in BOLD. Required means Mifos depends on their existence: GL code, name, and location must be exactly as shown below.
• Names and GL codes cannot be changed for required GL accounts.
• Subcategories may be added underneath any GL account. Follow this procedure to do so. Once a GL account is added and Mifos is started, only the name may be changed.
• GL codes and names may be alphanumeric. Only numeric GL codes have been tested, however, so experiment at your own risk.
• You may remove any subcategory, but financial action mappings must exist as specified here.
• You may change the name of any general ledger subcategory, but we recommend following standard accounting practices.

10000 -- ASSETS
    11000 -- Cash and bank balances
        11100 -- Petty Cash Accounts
            11101 -- Cash 1
            11102 -- Cash 2
        11200 -- Bank Balances
            11201 -- Bank Account 1
            11202 -- Bank Account 2
    13000 -- Loan Portfolio
        13100 -- Loans and Advances

            13101 -- Loans to clients
            13102 -- Emergency Loans
            13103 -- Special Loans
        13200 -- Loan Loss Provisions
            13201 -- Write-offs
20000 -- LIABILITIES
    22000 -- Interest Payable
        22100 -- Interest payable on clients savings
            22101 -- Interest on mandatory savings
    23000 -- Clients Deposits
        23100 -- Clients Deposits
            23101 -- Savings product 1
            23102 -- Savings product 2
    24000 -- Mandatory Savings
        24100 -- Mandatory Savings
            24101 -- Mandatory Savings Accounts
30000 -- INCOME
    31000 -- Direct Income
        31100 -- Interest income from loans
            31101 -- Interest on loans
            31102 -- Penalty
        31300 -- Income from micro credit & lending activities
            31301 -- Fees
            31302 -- Processing Fees
            31303  -- Annual Subscription Fee
    31401 -- Income from 999 Account
40000 -- EXPENDITURE
    41000 -- Direct Expenditure
        41100 -- Cost of Funds
            41101 -- Interest on clients voluntary savings
            41102 -- Interest on clients mandatory savings

GL Code Changes

Users should not edit a GL code post-installation. The CoA is set once in Mifos, at implementation time. Thereafter, the existing GL Codes should not be edited/deleted. However, new GL Codes can be added under defined sub-categories.

Debit/Credit Financial Transactions

Mifos is required to make debit/credit entries, in a transactions table, when a transaction is made. The entries should be made against the lowest level GL Code under a category. For example, a fee transaction is:

• Dr 31303 (loan fees)
• Cr 11201 (bank account)

An example of complete financial transaction: If a loan payment of Rs. 1000 is received (by cash) for installment 3 on Jan 1^st, 2006 and a user with username mariea records it in the system on Jan 3^rd, 2006, Mifos will make the following entries in the transaction table:

Posting Rules

The CoA is divided into four categories: ASSETS, LIABILITIES, INCOME and EXPENDITURE. The sign of the entry depends on whether it’s a Dr or a Cr AND under which category it is being recorded. The category is included in parenthesis for each accounting entry. While making the accounting/financial entries, the following rules should be used for the signs based on which category the entry falls under.

Assets and Expenditure

• Dr- Increase
• Cr- Decrease

Liabilities and Income

• Dr- Decrease
• Cr- Increase

Transaction Entries

Events that require a debit/credit entry are listed below.

Clients/Groups/Centers Transaction Entries

Fee is received from client/group/center:

• DR Cash (Assets) 11201
• CR Fees (Income) 31301 (exact GL Code to be picked from fee definition)

Misc fee is received from client/group/center:

• DR Cash (Assets) 11201
• CR Fees (Income) 31301

Misc penalty is received from client/group/center:

• DR Cash (Assets) 11201
• CR Penalty (Income) 31102

Adjustment in client/group/center accounts when the last received amount is nullified.The last payment has to be broken down in the components and separate DR/CR entries must be made for each one of them.

Fee /Misc fee nullified:

• DR Fees (Income) 31301 (exact GL Code to be picked from fee definition)
• CR Cash (Assets) 11201

Misc Penalty nullified:

• DR Penalty (Income) 31102
• CR Cash (Assets) 11201

Loan Account Transaction Entries

Loan is disbursed:

• DR client’s loan (Assets) 13101 (exact GL Code to be picked from product definition)
• CR Cash (Assets) 11201

Principal installment received:

• DR Cash (Assets) 11201
• CR client’s loan (Assets) 13101 (exact GL Code to be picked from product definition)

Interest installment received:

• DR Cash (Assets) 11201
• CR Interest on Loan (Income) 31101 (exact GL Code to be picked from product definition)

Fee charged is received:

• DR Cash (Assets) 11201
• CR Fees (Income) 31301 (exact GL Code to be picked from fee definition)

Penalty charged is received:

• DR Cash (Assets) 11201
• CR Penalty (Income) 31102

Misc fee charged is received:

• DR Cash (Assets) 11201
• CR Penalty (Income) 31102

Misc penalty charged is received:

• DR Cash (Assets) 11201
• CR Penalty (Income) 31102

Adjustment, where last payment is nullified. The last payment has to be broken down in the components and separate DR/CR entries must be made for each one of them.

Principal nullified:

• DR client’s loan (Assets) 13101 (exact GL Code to be picked from product definition)
• CR Cash (Assets) 11201

Interest nullified:

• DR Interest on Loan (Income) 31101 (exact GL Code to be picked from product definition)
• CR Cash (Assets) 11201

Fee nullified:

• DR Fees (Income) 31301 (exact GL Code to be picked from fee definition)
• CR Cash (Assets) 11201

Penalty nullified:

• DR Penalty (Income) 31102
• CR Cash (Assets) 11201

Loan account is moved to Closed- Written off state

• DR Loan loss provision (13201) X Amount
• CR Client’s Loan (13101 or 13102, etc) X Amount

Savings Account Transaction Entries

Deposit is made in voluntary/mandatory savings account:

• DR Cash (Assets) 11201
• CR Savings Accounts (Liabilities) 23101 (exact GL Code to be picked from product definition)

Withdrawal is made in voluntary/mandatory savings account:

• DR Savings Accounts (Liabilities) 23101
• CR Cash (Assets) 11201

Interest is posted to the account:

• DR Interest Payable – Mandatory/Voluntary Savings (Expenditure) 41101/41102 (exact GL Code to be picked from product definition)
• CR Mandatory Savings Accounts (Liabilities) 24101 (exact GL Code to be picked from product definition)

Adjustment- Voluntary/Mandatory: last deposit is nullified/decreased/increased. A reverse entry of the original transaction should be made. Also, a fresh entry with the new deposit amount should be made.

Adjustment- Voluntary/Mandatory: last withdrawal is nullified/decreased/increased. A reverse entry of the original transaction should be made. Also, a fresh entry with the new withdrawal amount should be made.

Adjustment: Account balance is reduced:

• DR Mandatory Savings Accounts (Liabilities) 24101 (exact GL Code to be picked from product definition)
• CR Cash (Assets) 11201

Adjustment: Account balance is increased:

• DR Cash (Assets) 11201
• CR Mandatory Savings Accounts (Liabilities) 24101 (exact GL Code to be picked from product definition)

Adjustment: Interest earned is reduced:

• DR Mandatory Savings Accounts (Liabilities) 24101 (exact GL Code to be picked from product definition)
• CR Interest Payable – Mandatory/Voluntary Savings (Expenditure) 41101/41102 (exact GL Code to be picked from product definition)

Adjustment: Interest earned is increased:

• DR Interest Payable – Mandatory/Voluntary Savings (Expenditure) 41101/41102 (exact GL Code to be picked from product definition)
• CR Mandatory Savings Accounts (Liabilities) 24101 (exact GL Code to be picked from product definition)

Rounding: 999 account

Amounts entered in the system should be stored as per the decimal precision specified by MFI. Amounts should be rounded only in the specific circumstances described below. Loan disbursal amounts should not be rounded.

Loan repayments:

• The repayment amount for each installment is calculated based on the product definition.
• If the total of principal, interest, fee and penalty is not rounded, the system rounds the total as per the rounding rules. Then the principal amount is adjusted so that total = sum of principal, interest, fee and penalty.
• The extra/less principal paid in all the installments is then adjusted in the principal amount of the last installment.
• The total of the last installment is rounded during actual payment and the excess/deficit is logged as the 999 account entry given below:
• For example, if each installment total is 50.5, which after rounding becomes 50, the 0.5 from each installment is increased in the last installment. The last installment is adjusted for each installment’s rounding.

When the rounding of loan repayment increases 999 account balance:

• DR client’s loan (Assets) 13101 (exact GL Code to be picked from product definition)
• CR 999 Account (Income) 31401

When the rounding of payment decreases 999 account balance:

• DR 999 Account (Income) 31401
• CR client’s loan (Assets) 13101 (exact GL Code to be picked from product definition)

The following rounding rules apply to savings accounts:

• Rounding is not required for deposits and withdrawals, because these are user entered values and the assumption is that the user will enter only a physically exchangeable amount.
• Rounding is not required when interest is posted to savings accounts.
• Rounding is required when a savings account is being closed and the total balance is not a rounded amount. In this case, a withdrawal entry for the rounded amount is made. In addition, the following 999 account entry is made to adjust the excess/deficit balance:

When the withdrawal in savings increases the 999 account balance:

·         DR Mandatory Savings account (Liabilities) 24101

·         CR 999 Account (Income) 31401

When the withdrawal in savings decreases the 999 account balance:

·         DR 999 Account (Income) 31401

·         CR  Mandatory Savings account (Liabilities) 24101

Example:

Payment of $100 for loan repayment is received by the MFI. This payment includes payment for the principal ($60), interest ($25), fee ($10) and penalty ($5). The following transaction entries are made:

• DR Cash (Assets) 11201; amount 60
• CR client’s loan (Assets) 13101; amount 60

• DR Cash (Assets) 11201; amount 25
• CR Interest on Loan (Income) 31101; amount 25

• DR Cash (Assets) 11201; amount 10
• CR Fees (Income) 31301; amount 10

• DR Cash (Assets) 11201; amount 5
• CR Penalty (Income) 31102; amount 5

Out of Scope

Merging of Sub-Categories

System handling of merging of subcategories as long as the functionality ID of the category is not modified. Guidelines on merging will be included in the installation document. For example, for the above CoA, following merging will be supported:

Miscellaneous

• Front end for CoA
• Status field for GL Codes
• Importing/Exporting of CoA
• Deleting of a GL Code
• Adjustments- GL Codes
• Insurance
• Programs
• Following entries in Chart of Accounts
  • Deposits for short term investments
  • Interest receivable- other interest receivable
  • Inter entity/project donor/HO/branch balances
  • Other assets
  • Investments- long term
  • Fixed assets
  • Liabilities- accrued expenses and payables; loans payable- short term; loans payable- long term; grants from donors; reserves; unearned interest on loans
  • Direct income- interest income from investments; other income
  • Other income
  • Expenditure- personnel; Board expenditure; Occupancy expenditure; Cleaning expenditure; Licenses and insurances expenditure; Postages and telephones; Advertising expenses; Printing and stationary expenses; Travel and entertainment expenses; Repairs and maintenance expenses; Rental expenses- equipments
  • Charges- Finance charges; Professional charges; Training charges
  • Depreciation
  • Other expenses
  • Sub codes- entity; department;

Currency and Rounding Rules

Currency and Rounding Rules

last modified 2010-04-14 14:40

Sources of Funds

Introduction

Funds are donations or grants provided to the MFI specified purpose. Such funds remain even when the specified purpose is achieved and accomplished since they would be accounted for as sources of funding which remain in equity.

Fund Creation

Sources of funds can be managed (created and modified) at the HO and other offices will inherit the details of these funds.

Attributes for Funds

The defined funds will be associated with loan products through loan product definition. When a new fund is created or an existing fund is modified, the additions/modifications should be reflected in the list of funds in each loan product.

Default Source of Funds

Mifos is shipped with the following source of funds:

Office Setup

Introduction

During the initial system configuration, an MFI can configure offices at the following levels. The hierarchy as well as the names of offices can be defined from the Define a new office link on the Admin tab. The middle three levels are optional.

• Head Office (HO)
• Regional Office (RO)
• Sub-Regional Office
• Area Office (AO)
• Branch Office (BO)

The head office (HO) is the main or parent office for an MFI and is automatically created by Mifos.  Users can optionally create regional offices (RO), sub-regional offices, and area offices (AO), which exist primarily for managerial and administrative purposes.  System users with appropriate permissions can create BOs, which are the only offices to which clients can belong. This is the level at which all client interactions take place. The office hierarchy is defined from the View office hierarchy link on the Admin tab.

Once an office is defined as an HO or BO, it cannot be changed into a different office type, such as regional office, sub-regional office or area office. However, offices of these three types can be changed to any other level except for HO.

Note:  If an AO or HO wants to create clients and offer services to the clients, they need to create a “virtual branch” to which clients are then assigned.

Attributes for office creation

The rules and attributes for office creation, provided in the table below, are divided into two groups:

• Attributes defined during office creation, which can also be viewed/edited later on from the office details page.
• Attributes that can be viewed/edited only after office creation, from the office details page.

Office states

By default, offices are created in Active state. New users can be assigned to offices only in Active state. Offices at all levels, except HO, can be made Inactive according to the following rules:

• A BO can be made Inactive only if all the clients, groups, and centers in the BO are in Closed or Cancelled states, and all users belonging to the BO are in Inactive state.
• Offices at other levels can be made Inactive only if all users belonging to the office are in Inactive state and all the child offices are in Inactive state.
• Offices can only be made active if the parent office is active.
• The status of an office can be changed from Active to Inactive, and vice versa, any number of times.

User Setup

Introduction

Mifos system users must be unique in the system. Uniqueness is confirmed by their government ID, if available, or their name and date of birth. All users are assigned to a specific office.  Users that belong to branches can be identified as either non-loan officers or as loan officers, which impacts their data scope (enter link). Users are allowed to perform activities in Mifos based on their user role, which is a collection of permissions. Only users in an Active state can access the system.

At each office, any user with the required permissions can create, view and manage other users in his/her data scope, through the Define new system user link on the Admin tab. A user is created with the following attributes, some of which can be modified after creation.

Attributes for User Creation

 
When the administrator adds a user to Mifos, a user account is created in an active state. User accounts are in either an Active or Inactive state, and there is no limit to the number of times a user state can be changed. A user must be Active to access the system. Loan officers can be made Inactive only if there are no clients assigned to them.

User accounts are assigned a username and password, which the user enters to log in to Mifos. After initial login, the user is required to create and confirm a new password consisting of 6-20 alphanumeric characters.  A user can change the password after login. The user is prompted for the following before confirming the password change:

• Old Password
• New Password
• Confirm New Password

Security features

Security is ensured through the following functions:

• Password encryption
  All passwords are stored in the database in an encrypted format. If a user forgets his password, he can ask the administrator to reset it. The administrator resets the password and communicates it to the user through a method external to Mifos (for example, verbally). The user can change the password at the next login.
• Locking accounts after 5 unsuccessful login attempts
  If the user enters an incorrect password five times consecutively, then the account is locked. The user then needs to contact the administrator to unlock the account and get a new password. If the account is locked, the status remains Active, but the user cannot access the system.
• Last login time display
  Each time a user logs in, his last login time is displayed, which the user should check for accuracy, for security purposes. If a user is already logged in to another machine, the last login time still displays the latest login time of the user. Last login time is not dependent on whether the user has logged off or not.
• Session time-out
  If the user has logged in to the system, but is inactive for a period of time specified by the admin, the session times out and the user needs to login again. Any unsaved data gets lost when a session times out. The session timeout duration is configurable by the administrator at the web server level; the default is set to 30 minutes. Multiple sessions can run simultaneously on the same or different machines.

User data scope

A user’s data scope defines the set of data that a user can view and access and to which a user’s permissions (like edit and create) apply [link to permissions]. The data scope is determined by both the office hierarchy and the user hierarchy.

• Limiting the scope by office hierarchy: The data scope of any user is limited to his/her office and the respective child offices. For example, a user at the HO can view all clients across the organization.  If he has Modify permission, he can modify any client in the system.  A user at an Area Office has access to all the client records in all the BOs under that Area Office. 
• Limiting the scope by user hierarchy: In addition to office hierarchy, data scope is controlled by a two-level user hierarchy: loan officer and non-loan officer.  Because loan officers exist only at the branch level, only branches contain both hierarchy levels.  By default, users in all other office levels belong to the non-loan officer hierarchy.
  • If a user belongs to the loan officer hierarchy, then his data scope is limited to his own clients and he can only view and access these clients. For example, if he has Modify client data permissions, he’ll be able to edit only his own clients.  He will not be able to view or access those assigned to other loan officers.
  • If the user at belongs to non-loan officer hierarchy, the data scope is limited to the user’s office and other child offices. That is, a non-loan officer at a branch can view and edit all clients within that branch.

User roles and permissions

The way in which users can interact with Mifos is specified by their user role or roles, which are defined by the MFI. Roles are specified based on predefined system activities and permissions, as follows:

• Activity. An activity is any action performed in the Mifos system, such as creating a new entity, changing the state of an entity, creating a fee type, waiving a fee, etc.
• Permission. Permissions are defined for each single activity or group of activities that can be performed in Mifos. Critical system activities are assigned individual permissions while those less critical are assigned group permissions. Read or view permissions are granted by default, depending on a user’s scope [link]. For example, loan officers can only view the details of those clients assigned to them.
• Role. Roles are groups of permissions which are created, defined, and named by the MFI and used throughout the organization. Mifos ships with a predefined role, called “admin”. The admin role has all permissions and can be used to create other roles.

A user can be assigned any number of roles and will be granted the permissions of each. For example, if one role gives a user a Create permission for a particular record and another gives him Modify permission for that record, he’ll be able to both create and modify the record.

Permissions cannot be granted outside a role. If a user needs permissions outside a role, a new role can be created to give him those permissions.

Role modification. Permissions associated with a role can be modified. If a role is modified, all users associated with the role inherit the change. A role can also be deleted. When this happens, all users assigned to that role will lose permissions associated with that role on their next login. However, if a user has the same permission granted through another role that is still Active, he retains the permission.

last modified 2009-12-16 07:27

Fees Definitions

Introduction

MFIs can charge fees for various services offered, such as membership fees, account charges, etc. Fees can be applied to loan accounts, and to client, group, and center accounts.  At this time, Mifos does not support savings account fees.

In addition to fees, penalties can be charged on loan accounts. While fees are charged for the various services offered by an MFI, penalties are charged to penalize the customers for deviating from the rules of repayment.

Specific types of fees, such as a monthly membership fee for client accounts, are referred to as fees.  For loan accounts, fees are included in the product definition. Mifos does not match the periodicity of a fee with a loan repayment schedule.

Fees are defined using the Define new fees link on the Admin tab.  In addition to naming the fee and identifying the type of account it applies to, a frequency is specified. For fees that are to be applied periodically, the schedule is defined. For fees to be applied on a one-time basis, the time is defined. The fee and amount and the accounting code to which it should be applied is also defined.

Fee Attributes

An MFI defines a fee according to the attributes provided in the following table. All attributes in the table are mandatory.

Edits. Users with appropriate permissions can make changes only to the state of the fee and to the fee rate. A fee can be changed from Active to Inactive or vice versa, although fees cannot be deleted from Mifos. For fees attached to loans, changes can be made to the flat rate or to the percentage and base used for calculating the fee. When a fee is changed, the change is automatically applied to new accounts and must be reapplied to existing accounts.

General process for applying fees

Once a fee is defined, it appears as an option whenever a user creates an account of the type for which the fee was defined. For example, for client accounts, only fees assigned to categories Clients and All Customers are visible. Users can attach any of the available fees to the account.  If the fee is a Loan fee and defined as a calculated value, then the amount is then calculated per the fee definition and added into the repayment installment schedule.

An LO can apply multiple fees to an account, and can waive the next installment only of a fee payment. An LO cannot waive an amount that has already been paid. An LO can also remove a fee from an account altogether. Interest is never charged on a fee amount.

Note the following:

• Overdue fees. A fee amount is considered overdue when the fee payment is not entered in Mifos on the expected payment date. For example, a periodic fee type with periodicity of one month is applied to a loan account, and the next payment date is October 15th; if the payment is not received on October 15th, the system considers this fee amount as overdue.
• One-time fees. A user can also charge a one-time miscellaneous feel to a loan account or a client account. This amount is added to the next payment amount.

For specific information about applying fees to different types of accounts, see Account Management

Out of Scope

• Amortization of fees over account term.
• Different grace period for fees vs. loan.
• Combination of periodic fee type and frequency equals to % of the amount.
• Group of fees like client creation fee bucket, training fee bucket, etc
• Fees waived for all clients/accounts for a limited period of time.
• New fee type to bulk accounts, after an account is instantiated

Product Definitions

Introduction

A product is a financial offering by an MFI to its clients:

• Product Type. Mifos supports the following two product types: loans and savings. An MFI can offer loans to clients or groups with active accounts. It can offer savings accounts to client, groups, and centers.
• Categories. An MFI can define product categories, which are logical groupings of products that can be used for reporting purposes. MFIs can define any number of product categories, containing any number of products, at any time. Products not assigned to any category will belong to Other by default. Product categories are defined from the Define new category link on the Admin tab.
• Products. Products are the different offerings belonging to a product type, such as personal loan, agricultural loan, cattle loan or voluntary or mandatory savings, which are defined in terms of interest rates, minimum and maximum loan amount, etc. When a user creates a loan or savings account, the defaults of the product are inherited by the account.

Loan product

Loan products are defined from the Define new loan product linkon the Admin tab, according to the attribute definitions provided in the attribute table that follows. Loan products can have interest applied in one of three ways: flat, declining balance, and declining balance with equal principal installment.  See Interest calculations for loan accounts for more information.

Loan defaults based on previous loan amount

An MFI can specify that default loan amounts are calculated in one of three ways:

• Same for all loans. Using this method, loan history is not taken into consideration. Users specify minimum, maximum, and default loan amounts, which is the same for all loan amounts.
• By last loan amount. Using this method, the ranges are defined based on the loan history of the client, since a client should be eligible for increasingly larger loans. Users specify the minimum, maximum, and default values for the range of the last loan amount paid by the client.  Up to six ranges can be entered, with the first range starting at 0. For example, if the first end range is 3000, then the start range in the second row is 3001.
• By loan cycle. Using this method, loan cycles, i.e., the number of successfully repaid loans are used to determine a loan amount. The user enters the maximum, minimum, and default loan amounts for each loan cycle (values can be entered for the following cycles: 0, 1, 2, 3, 4, and >4).

The values entered for whichever method is chosen for both the loan amount field and the number of installment field should be for successfully repaid loans, not rescheduled loans, and should apply to loans based on the same product. Note that previous loans can have late payments and still be considered successfully repaid.

Loan default definitions can be modified after they have been created. Changes are effective immediately and will affect new loan accounts only.

If your MFI is set up to have more than 1 currency, you can specify a currency for the loan product during creation.  This is currency will be inherited in all loan accounts created from that loan product.  Mifos does not display currency of values throughout, so it is recommended to denote currency in the name of the Loan Product.  See Currency Denominated Loan Products for more details.

Savings products

Savings products are defined from the Define new savings product linkon the Admin tab, according to the attribute definitions provided in the attribute table that follows. Note savings products are defined as either mandatory or voluntary.

Attributes for products

Attributes for product categories, all products, and attributes specific for loan products and savings products are provided in the following tables.

Product Categories

Product categories are logical groupings of products which can be used for reporting purposes. Product categories can be created anytime.

• System has no limit on the number of product categories that can be created or the number of products that can be put in each category. Therefore, a user can create any number of product categories and a product category can have any number of products under it.
• A category called “Other” will be present by default in the Mifos system. If the product does not fall into any of the defined product categories, it can be put in the “Other” category. This category can be modified like any other category.

Attributes for Product Category Creation

Products

At the lowest level of product hierarchy, products are the different offerings of a product type to the MFI clients. Products are defined in terms of interest rates, minimum and maximum loan amount and purpose of the loan. Personal loan, Agricultural loan, Cattle loan etc, are a few examples of Products. The sections below detail out the flexibility provided by the Mifos system in defining these products.

Attributes for Product Definition

The table below lists down the attributes common for loans and savings. Following this, the attributes specific to each product type has been listed down under the respective sections.

Attributes for Loan Product Definition

Attributes for Savings Product Definition

Listed below are the attributes specific to the Savings product type.

Product states

Status of a product can be changed at the product definition level. At any given time, a product can be in either an Active or Inactive state:

A product can change the status multiple times. There are no restrictions on state changes.

Restrict product mix

By default, a client can have multiple loans or savings accounts of multiple products. An MFI can restrict the mix of products their clients are allowed by clicking Define product mix from the Admin tab.  Mifos checks for violations of this list at the time of loan disbursal.

By default products can mix with all other products, including itself.

Grace periods for loans

An initial grace period is the time between the disbursal date of a loan and the collection of the first regular payment. One, and only one, of the following grace types can be defined for a loan product and, once defined, cannot be modified:

• None.   No grace period allowed
• Grace on all repayments. The client is not required to start repayment until the grace period ends. Interest is not charged during this period. In other words, grace is given on both principal and interest. Start date for loan repayment schedule is essentially pushed out.
• Principal only grace.  The grace is given on the principal repayments and not on the interest. The client is required to make regular interest payments but is not required to make payments against the principal during the grace period.

A user can modify the grace period for a loan account before the grace period ends for that account. However, grace periods cannot be inserted within a loan payment period, that is, a grace period can exist only before the repayment of the loan starts.

Grace periods cannot be applied to variable loan installments or loan products with interest rate type Declining Balance - Interest Recalculation.  MIFOS-4742.

Currency-Denominated Loan Products

Introduction

An MFI could currently have loan products in 2 currencies.  They need a way to track both in their own currencies.  This feature implements basic multicurrency support and also sets the basis for full multicurrency support in the future.

User Stories (Epics)

Goals

• Ability to configure Mifos to have a default currency and additional currency
• Ability to select a currency when creating loan products.
• Ability to set appropriate rounding rules per currency
• Loans will inherit currency definition from the loan product it's created from.
• Ability to select a currency for fees created for loans only.

Non-Goals

The following items will not be addressed in this release:

• Support for 2 currencies with performance history - if Performance History involves rolling up values in 2 different currencies, then that item will not be displayed
• Support multiple currencies for client, group, or centers  - they will all use default currency (fees)
• Support multiple currencies for savings
• Support multiple currencies in Collection Sheet Entry
• Displaying additional currency labels anywhere in Mifos
• Support for multiple currencies in fees other than loan fees

Definitions and Terminology

• Mandatory fields will be preceded by *
• Links are italicized
• Buttons are Button

Currency Denominated Loan Products

This feature will allow minimal multiple currency support in Mifos.

Use Cases

Administrator configures Mifos for multiple currencies

Actors

•  Administrator

Preconditions

•  None

Basic Flow

1. Administrator edits the configuration file and sets the default currency to USD and additional currency to LBP.
2. Administrator updates relevant accounting settings such as rounding amount for each currency accordingly.  Administrator updates settings for the additional currency that differ from the settings for the default currency.

Post-conditions

• Mifos can have 2 currencies now.

Alternative Flows

Administrator does not configure Mifos for multiple currencies.

1. Administrator does not have additional currency set in configuration file.

Post-conditions

• There are no options for currencies in Mifos.  The user has no knowledge that Mifos can have 2 currencies.

Validations

• None

Administrator creates a loan product in a currency other than the Default

Actors

• Administrator

Preconditions

• Mifos has been configured to have a default currency of USD and an additional currency of LBP.

Basic Flow

1. Administrator logs onto Mifos and navigates to creating loan products.
2. Administrator creates new Loan Product A and specifies LBP as the currency for the loan product.
3. Mifos saves Loan Product A.

Post-conditions

• All loans created from Loan Product A use LBP.

Alternative Flows

• None

Administrator creates a loan fee in the secondary currency and attaches to Loan Product A.

Actors

•  Administrator

Preconditions

• Mifos has been configured to have a default currency of USD and an additional currency of LBP.
• Loan Product A has LBP as its currency defined.

Basic Flow

1. Administrator logs onto Mifos and navigates to creating fees.
2. Administrator creates new loan fee Fee A and specifies LBP as the currency for the loan fee if the loan fee is a specific amount, not a % of calculation.
3. Mifos saves Fee A.
4. Administrator navigates to edit Loan Product A and is able to attach Fee A to the loan product.

Post-conditions

• None

Alternative Flows

Administrator tries to attach a loan fee in different currency than Loan Product A.

1. Administrator goes to edit Loan Product A.  Administrator adds Fee B of a different currency to Loan Product A.  Administrator hits Preview.
2. Mifos displays error message - A fee of a different currency cannot be attached to this loan product.

Loan Officer creates a loan account in secondary currency

Actors

•  Loan Officer

Preconditions

•  Mifos has been configured to have a default currency of USD and an additional currency of LBP.

Basic Flow

1. LO logs onto Mifos and navigates to create a new loan account.
2. LO selects a loan product of the secondary currency.  LO saves the new loan.

Post-conditions

• New loan account is in secondary currency.

Alternative Flows

Loan Officer attaches a loan fee of secondary currency to a loan account

1. At step 2 of workflow, LO attaches new loan fee also of the same currency to the loan account.  Options under Fees available only include fees of the same currency as the loan account.
2. Mifos saves the loan.  The loan has a fee in the same currency attached.

Loan Officer applies charges to an existing loan account

1. LO navigates to an existing loan account and clicks on Apply Charges.
2. LO chooses a fee to attach.  The only options available are those of the same currency.

Loan Officer disburses and repays loan in secondary currency

Actors

•  Loan Officer

Preconditions

• Mifos has been configured to have a default currency of USD and an additional currency of LBP.
• Loan accounts in secondary currency have been created.

Basic Flow

1. LO logs onto Mifos and navigates to an existing loan that hasn't been disbursed.
2. LO disburses loan.

Post-conditions

• Loan disbursal is in secondary currency
• Repayment schedule is all in secondary currency

Alternative Flows

LO enters in values for amounts that do not correspond to the settings in Configuration

Preconditions

• Mifos has been configured to have a default currency of USD and an additional currency of LBP.
• Loan accounts in secondary currency have been created.
• Mifos has been configured to have digits after decimal for LBP to be 0.

Alternate Flow

1. At step 2 of Basic Flow, LO tries to enter a value for loan disbursal that has more digits after decimal than 0.
2. Mifos throws an error message that this is invalid.

Accountant imports file of transactions in secondary currency

Actors

•  Accountant

Preconditions

• Mifos has been configured to have a default currency of USD and an additional currency of LBP.
• Loan products and accounts in secondary currency have been created.

Basic Flow

1. Accountant logs onto Mifos and navigates to Import Bank Transactions.
2. Accountaint imports a file with all loan transactions for loans in LBP.
3. Mifos imports the file of transactions.

Post-conditions

• All loan accounts in that file have been updated accordingly with the transactions in that currency.

Alternative Flows

User Stories

Currency Denominated Loan Products Functional Requirements

Update configuration settings

Add ability to define a new loan product of secondary currency

Add ability to define a loan fee of secondary currency

Create new Loan account with Loan Product with a different Currency

Attach loan fee of secondary currency to loan account

Disabled Functionality

Reports

Validations around accounting settings for new currencies

Other Assumptions

LSIM

• LSIM will be on - but should work on or off

GLIM

• GLIM will be on for Al M's configuration

QA Considerations

• Performance History - for fields where there needs to be rollup of 2 currencies, will display a msg instead.
• Create multiple loan accounts - should still work regardless of currency of loan products
• Import Bank Transactions - make sure this works

Standard Considerations

Security (Permissions, Roles, and Data Scope)

Impacts to System

Globalization/Localization

Logging

Change Log

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.

Performance

Setup and Installation

New Installations

Backward Compatibility and Upgrades

Hosting Support

Configuration

Customers

last modified 2010-05-14 09:23

Meetings

• Introduction
• Meeting definitions
• Meeting changes

Introduction

MFIs working under the group lending model, rather than a teller model, conduct regular meetings to provide a platform for interaction for their centers and groups. At these meetings, questions are answered, loans are disbursed and loan repayments and savings deposits are collected. Trainings can also be scheduled or take place at these meetings.

Beginning with version 1.1 of Mifos, repayment schedules and loan disbursals no longer need to coincide with meeting schedules.  This feature is called LSIM (Loan Schedule Independent of Meeting) and an MFI can specify this during system setup.

Meeting schedules are set up for a center, if one exists, or for a group.  Clients not belonging to a group can have individual meeting schedules.

If LSIM is turned off, meeting times are mandatory for any client/group/center to be Active. Meeting times are not mandatory if LSIM is turned on.  Clients can have only a single meeting schedule at any time. Currently, all clients, regardless of whether or not they belong to a group, must have a meeting assigned to them.

If an MFI ties repayment schedules to meetings, the client loan repayment schedule is spread evenly over a specified number of meetings, and the frequency of payments must match the frequency of meetings, if repayment occurs at meeting times.  If LSIM is turned on, this is not required.

Meeting definitions

Meeting schedules are defined when a center account is created. Client inherits the meeting schedule from the group and the group in turn inherits the meeting schedule from the center (if center hierarchy exists).

A meeting schedule definition includes the meeting location and the meeting frequency, which can be specified in terms of weeks or months. When defining meetings in terms of weeks, the user can specify the frequency (every <x> weeks) and the day of the week. When defining meetings in terms of months, the user can specify either every <x> day of the month or the <x>  <day> of every <x> month.

Users are not allowed schedule meetings on non-working days.  Mifos will prevent this from happening.  Non-working days are set in configuration.  [Link to config]  Meetings also cannot be scheduled on a holiday. However, these days are included in calculations. If a repayment or meeting falls on a holiday, it is shifted depending on the repayment rule set when the holiday was defined.  Repayment rules available are “Next working day”, “Next meeting/repayment day”, or "Same day". 

Meeting changes

Meetings can be changed only by the office that created them. If Definition of a week is modified and more days are included in the working week (by changing working days in System Configuration), existing meeting schedules and repayment schedules are not affected or recalculated. If the meeting schedule itself is changed, repayment dates of existing loan accounts are updated but repayment amounts will not be updated. Meetings can only be defined or changed at the highest level, i.e., at the center (if it exists), group if the client is a group member, and at the individual level only if the client does not belong to a group.

Meetings can be changed (irrespective of the state of loan accounts) in the following ways only:

• Weeks: only the day of the week can change; number of weeks cannot be changed
• Months: day number and the day of the week can be changed; number of months cannot be changed. For example, first Monday of every one month can be changed to third Tuesday of every one month. Day 2 of every five months can be changed to day 7 of every five months (only the bolded entries can be modified).

In Mifos 1.5.0 and beyond, when changing a center meeting date in an installment “period”, the change will always be applied in the next installment “period”, where a period is the frequency of your meeting schedule and the repayment falls in.

For example, if you have a weekly meeting on Wednesdays currently, and you change the meeting date to Thursday, the current working week will still keep the original repayment days of Wednesday. Your meeting date will be changed next working week to Thursday. This is regardless of whether or not a repayment has past this week. In this particular example, today (March 1st), this week’s meeting will still occur on March 3rd, but next week’s repayment will now be on March 10th. Working week and workdays are defined by your Mifos configuration.

The same applies for monthly meetings. In this example, you normally have a meeting date on the 20th of every month, and you change the meeting date to the 5th of every month. In the current month (March), your meeting date will still fall on March 20th. However, in April, the following month, the meeting date will be on April 5th.

Checklists

Introduction

An MFI can set up checklists that are displayed whenever users attempt to change the state of accounts. A checklist consists of a list of tasks that are required in order to change a state. A user must check each box in the checklist before the system will make the requested change.

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 can be associated with all workflows for accounts and client records.

Checklists are optional, and an MFI can define them for the destination states (not dependent on source states) for the following types of accounts: client, group, center, loan and savings. For example, an MFI might define a checklist for the Pending Approval state of a loan account. A user can then make sure each condition on the checklist has been satisfied before he changes the loan account to the Pending Approval state.

Note the following:

• Checklists cannot be defined for the following states: centers—Active state; groups and clients—Partial Application state.
• Checklists are not displayed during creation of client, group, center, loan, and savings accounts.
• Checklists are not attached to individual customer records or accounts, but are displayed in between state changes.
• Checklists can be modified or made inactive.
• Only the latest version of a checklist is maintained in the system. Older versions of a checklist are not maintained.

Attributes of Checklists

Checklists must be defined (through the Define new checklist link on the Admin tab) and saved, 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 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

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

Moratoriums

Release: Mifos 1.6

Branch Level Holidays

Center Accounts

Center Accounts

Group Accounts

Client Accounts

Introduction

As either individuals or as members of groups, clients are the end beneficiaries of microfinance services. Clients are typically recruited, assigned to and managed by a loan officer at a particular BO. If they belong to a group, they inherit the loan officer from the group.

Before clients can receive loans, set up savings accounts, or be charged fees, client accounts must be created for them in Mifos.

Users with appropriate permissions can create a new client record by clicking the Create new client link on the Quick start navigation pane of the Home tab.

Note the following

• Periodic and one-time center fees can be pre-defined from the Admin tab.  These can be defined to be automatically charged to any newly created center, appearing on the "Client Charges" page.  An LO can remove one or more of these fees for a particular center account and edit the fee amount if it is a one-time fee. If a fee is removed from one account, it does not affect other accounts. In addition, an LO can apply pre-defined fees as well as miscellaneous fees or penalties on the account after it's been created. These charges will be added in the next payment.
• At the same time, up to three savings accounts that can be automatically created for the client.  The accounts are created when the client is moved into active state.

Attributes for Client Accounts

The following table of client attributes is divided into three sections: personal information, available during creation of a client record; MFI related information, available during creation of a client record; attributes/actions that are viewable and editable only after creation from the client account details page.

Attributes marked mandatory for Partial state in the table are the minimum requirements to create a record. Pending Approval is an optional state; if this state is hidden, the attributes marked mandatory for Pending state should be considered mandatory for the Active state.  Note:  We have not thoroughly tested Mifos with the "Pending Approval" state hidden.  We do not recommend hiding this state.

Note that only the following fields are mandatory for On Hold, Cancelled, and Closed states: First Name, Last Name, DOB, Loan officer, Meeting. Also, fields that cannot be edited after Active state are not editable in Closed and On Hold states either.

Notes on attributes

• Formed by. The Formed by attribute is an additional attribute required to address the fact that the LO who manages a client may not be the same one who created the client. This field is mandatory in all states and the value cannot be modified once specified. It is displayed in the details and edit pages as read-only information. All active loan officers (both LO and non-LO) in the branch where the client record is being created are listed in a drop down list. This list is not affected by the data scope of the user. The LO assigned to the client is the default.
• Poverty status. This attribute can be used by MFIs to produce reports on the poverty status of its clients. It is required for all states by default, although an MFI can make it optional. The default options, which are available in a drop-down list and can be changed by the MFI, are: Very Poor, Poor, and Non-poor. This attribute is defined at client creation and can be modified at any time from the edit personal information page. The information is labeled Poverty Status and displayed with the client personal information.

Personal details

• Name. Client, user, father, and spouse names can consist of the following fields: First Name, Middle Name, Second Last, Last Name. The first and last names are mandatory. An MFI can choose whether to collect the middle two; if they aren’t collected, the fields will not be displayed. An MFI specifies the sequence in which the names are displayed. Once defined, names are always displayed in this order, whether in search results, detail pages, or reports. This sequence does not affect how Mifos sorts results, which is as follows:
  • First Name (Middle Name, if it exists) Last Name (Second Last Name, if it exists)
  • Last Name (Second Last Name, if it exists), First Name (Middle Name, if it exists)
• Addresses. Clients can have multiple addresses.

Client Family details
If this feature is turned on (see Configuration Guide)

• Name
• Birthdate

MFI related details

• External ID Number. This can be a government ID, national ID, or social security number. It is un-editable after a client enters an Active state. An MFI can choose whether to display this field.
• Client Trained. Training is an MFI-wide setting and indicates whether a client has been trained. It has no correlation to the group training flag. A client can be marked as Trained only once, and only one Training Date is saved per client record. When a client is marked as trained, a training date must be specified. Once the training date is saved, it cannot be edited or re-entered.
• Assigned to Group. This is the ID of the group that the client has been assigned to. This field is visible only if the client is eligible for group-based membership. A client can be added to an existing group and can belong to only one group at a time. If a client belongs to a group, the LO and meeting schedule of the group are inherited by the client. Clients cannot change groups if they have active loans. A client’s group can be closed if all clients in the group are either in Cancelled or Closed state.
• Meeting Day. A client inherits the meeting day from the group. If the client is not part of any group, the client can have an individual meeting schedule. [For details, see Meetings.]
• Fee Type and Miscellaneous Charges. Miscellaneous fees or penalties can be charged to clients and stored in the client accounts. These are one-time charges. Penalties are not charged for overdue fees. In addition, predefined fee types can be applied to the client accounts. [For details, refer Fees.]

Client Record States

When a client record is created, it is processed through various states, as illustrated below.

 A user manually changes a client record state in Mifos.  Between state changes a checklist is displayed if one has been defined. Mifos validates the fields as described in the attributes table above. Every change in state is entered in the change log, along with the date and user ID of the user making the change.  For details, refer to Change Logs and Application Logs.

As illustrated, a client record can reside in the following states. All states are mutually exclusive:

Notes on client states:

• When a client record is created, it can be either saved in Partial Application state or Pending Approval state. If Pending Approval (an optional state) is not included by the HO, a user with required permissions can save the new client record in Active state.  [This has not be fully tested
• An Active client record must have an LO and a meeting time.  A client record can be saved in Partial or Pending Approval without an LO assigned or meeting time defined.
• There is no restriction on the number of times a client state can be changed.
• If a client state is changed to Cancelled/Closed, the associations with the LO, group, and meeting remain.
• There is no Deleted state. All client records are kept in the system.
• A blacklisted client can be moved to Active, but a permanent flag gets attached to the client record to indicate that the client has been previously blacklisted. This flag is viewable on the client account details page.
• When a client record is closed, the system stops applying any periodic fee linked to the client record. Transactions can no longer be made to the record. Miscellaneous penalty or any amount due remains.

Client Account Details

Once a user with the appropriate permissions has entered the data to create a client, the user then previews the entire set of information in one screen, to validate the data. This is a mandatory step. When the user approves the preview page, the client’s data is saved in the database. Error checking for mandatory fields and valid data is performed. If any invalid entry is found or any mandatory fields have been left empty, an error message is displayed.

When a client record is created, Mifos checks the system for duplicate records, based on Government ID. If a client record with the same Government ID already exists in any state other than Closed, an error is display and the new record is not created. If a Government ID is not present, the system checks for duplicates based on Name and DOB [and father/spouse name?]. If this information matches an existing record, the user must change the name (for example, by adding a middle name) before the new record is created.  In either case, if a matching record is found in Closed state, a warning is displayed to the user to review the existing record before continuing.

The client account details page includes the following information:

• Current accounts for the client
• Closed accounts
• A link to the details page for the group to which the client is assigned
• A link to the details page for the center to which the client is assigned
• MFI information, including training details, group membership, and meeting details for each client
• Personal information
• Associated notes
• Most recent set of transactions.
• A link to summarized historical data

All data, except the system-generated Client ID, Government ID, and DOB can be modified. Government ID and DOB fields can only be modified in Partial Application state. A client’s group membership can be edited or removed, as long as neither the group nor the client have active loan or savings accounts.  Every time a client record is edited or its state is changed, the user is required to preview the changes before they are saved.

Change logs track the following changes made to the client records: Date of change, Changed by, Fields changed, Old value, New value. These logs are viewable from the client details page. Changes are displayed in a single list on one or more pages.

Historical Data

Historical information is available by clicking the View Summarized Historical Data link at the bottom of the account details page.

• The attributes for historical data given in table below are editable at any time and Mifos system validates these attributes.
• The system allows users to enter details of a single loan only, which is usually the last loan taken by the client or the group.
• None of the fields are mandatory.
• This information is stored for reference purposes only and should be confused with historical data that is migrated into Mifos’ database.  Mifos does not use or incorporate this data to update the client record.  For example, the loan cycle number listed here is not added to the loan cycle number tracked by Mifos.
• Since most MFIs decide to migrate their data from their legacy system into the Mifos database, we do not expect this feature to be heavily used.

Performance History

Mifos tracks the performance of each client and provides the following metrics, which are displayed on the client’s detail pages in the performance history box.

The following parameters are used to track the performance of each client by the system:

Notes on loan cycle per product

• Separate loan counters for each product are maintained for each client. For example, if the client has taken two agricultural loans and three cattle loans, her performance history displays a loan cycle for educational loan=2; loan cycle for cattle loan=3.
• The counter is incremented when a loan account is approved and decremented for rescheduled loans or written off loans.
• The loan cycle number from historical data is not included in any of the above counters.

Assigning Clients to a Group

New clients can be added to a group by clicking the Add Client link on the group account details page. An individual can belong to only one group at any time.

The following rules apply to the relationship between group states and client states:

• An individual state should be equal to, or behind the state of the group:
  • If Group state = Partial Application, the group can have clients who are in Partial state only.
  • If Group state = Pending Approval, the group can have clients in Partial Application or Pending Approval states only.
  • If Group state = Approved, the group can have clients in Partial Application, or Pending Approval, or Approved or On Hold states.
• If a group is On Hold, the clients are not affected; new clients can be assigned to On Hold groups and client records can be Closed.
• If a group is Active, a client belonging to that group can be Closed.
• If clients are Active, the group cannot be closed before assigning the clients to another group or closing them.
• If clients are in Closed/Cancelled state, the group can be closed.
• If any client in the group is On Hold, the group cannot be closed unless that client is Closed or assigned to another group.
• If a group status is changed from Pending Approval to Cancelled, the system changes the Pending Approval status of any clients of the group to Partial Application.
• Clients in states other than Closed and Cancelled can be assigned a position in the center or the group.

Adding group memberships for existing clients

Existing clients that do not belong to a group can be assigned to a group, as long as their client status is neither closed or cancelled and they do not have an active loan. The group status much be equal to or higher than the client status.

• If the client status is Approved/active or on hold, the client can only be transferred into groups with Approved/active status
• If the client status is pending approval,  the client can only be transferred into groups with Approved/active or pending approval status
• If the client status is partial application, the client can only be transferred into groups with Approved/active, pending approval or partial application status

Group membership is assigned via the Edit meeting schedule/Add group link on the client details page. When a group is selected, the system validates that the client does not have an active loan or savings account and adds the client information to the group account details and updates the group performance metrics.

Changes are made to deposits due from the group: if the group’s mandatory savings account is calculated per individual, the amounts are recalculated based n the new number of clients. The client inherits the meeting schedule and the loan officer of the assigned group.

Removing group memberships for existing clients

Group membership for an existing client can be removed. This can be done by clicking the Edit/Remove group membership link.

The user can optionally assign another loan officer at this point, and enter notes about the removal. When the user clicks Submit, the system prompts the user if the client is active and no loan officer was assigned. If the client was a title holder in the group, the system alerts the user that the title position is now empty. The system then removes the group membership from the client record.

After a client is removed from a group, the performance history details on the group details page is updated with the new number of client members and the individual loan size and total loan portfolio fields are recalculated. If the group’s mandatory savings account is calculated per client, the amount is recalculated based on the change in the number of client members.

Moving Clients

A client can be reassigned to any of the following: 

• Another group, as long as the client does not have any loan or savings accounts in states other than Cancelled/Closed. When the client is transferred to another group, the LO and meeting schedule are inherited from the new group. 
• Another branch, as long as the client’s loan and savings accounts in the current branch are closed or canceled. All the client information is transferred along with the Client System ID. When a client is moved to another branch, the user must select a new loan officer after the client is moved.  Please see Issue #1555 in the issue tracker.
• Another LO within the same branch.  An independent client (a client that does not belong to a group) can be transferred to another LO within the same branch.

Loan Accounts