Mifos Versions

• - Before upgrading to Mifos 2.1, you must first upgrade your 1.x version of Mifos to version 2.0! 
• Please read all relevant upgrade instructions for the version of Mifos you are running and above before proceeding with this upgrade - Past Upgrade Instructions
• If you are unsure of the version of Mifos you are using, please refer to Past Releases.

Important Notes

• There was an issue in 2.0.x and 2.1.3 and below where Loan Write Offs were being incorrectly calculated if there were future installments.  More information is in MIFOS-4948.  In your upgrade to 2.1.4, the upgrade will automatically fix any past Loan write offs done that were incorrect.  You will still note some inconsistencies in values on Account Details and Repayment Schedules - they are noted in this issue - MIFOS-5087.  This is ONLY fixed in 2.1.4.  If you are upgrading to 2.1.3 or below, this issue still exists.
• Read logging instructions if you are using an external loggerconfiguration.xml Logger Configuration
• These settings has been added in applicationConfiguration.default.properties

  # Mutability: always # Type: short # Allowed: 0-2 # The number of digits after the decimal that Mifos will carry for cashflow warning threshold. AccountingRules.DigitsAfterDecimalForCashFlowValidations=2 # Mutability: always # Type: double # Allowed: 0 - 99 # The maximum allowable cashflow warning threshold. AccountingRules.MinCashFlowThreshold=0 # Mutability: always # Type: double # Allowed: 0 - 99 # The maximum allowable cashflow warning threshold. AccountingRules.MaxCashFlowThreshold=99 # Mutability: always # Type: double # Allowed: 150 - 1000 # The maximum allowable Repayment Capacity. AccountingRules.MinRepaymentCapacity=150 # Mutability: always # Type: double # Allowed: 150 - 1000 # The maximum allowable Repayment Capacity. AccountingRules.MaxRepaymentCapacity=1000 # Mutability: always # Type: double # Allowed: 0 - 50 # The maximum allowable Indebtedness Ratio. AccountingRules.MinIndebtednessRatio=0 # Mutability: always # Type: double # Allowed: 0 - 50 # The maximum allowable Indebtedness Ratio. AccountingRules.MaxIndebtednessRatio=50 # Mutability: always # Type: double # The Maximum MPESA Disbursal Limit #MPESA.DisbursalMax=50000

Known Issues

ISSUE: Surveys to Question Group data Migration issue

http://mifosforge.jira.com/wiki/display/MIFOS/Data+Migration+for+Question+Groups#DataMigrationforQuestionGroups-KnownIssues

ISSUE: Upgrading to 2.x logs contain error OR after upgrade to 2.x enabling PPI gives error ERROR, org.hibernate.util.JDBCExceptionReporter, ?, ?, ?, Incorrect string value: '\xE0\xB2\x90\xE0\xB2\xA6...'

Instructions for users, before upgrading from 1.6.x to 2.x AND This upgrade process can be applied after upgrading to 2.x also if you don't have any rows in these tables

• questions
• question_choices

STEP 1. Login to mysql as root,

STEP 2. Run this query

select table_name,table_collation,table_schema from information_schema.tables where table_collation not like '%utf8%' and table_name like 'question%' and table_schema like '<MIFOS_DATABASE_NAME>';

STEP 3. If some rows are returned eg.

+------------------+-------------------+--------------+
| table_name       | table_collation   | table_schema |
+------------------+-------------------+--------------+
| question_choices | latin1_swedish_ci | mifos        |
| questions        | latin1_swedish_ci | mifos        |
+------------------+-------------------+--------------+

NOTE: if you get zero rows, given that you have used correct database name then you don't need to go to next step.

STEP 4. Run these queries to your Mifos database to change the character set of question tables from latin1 to be utf8

mysql> use <MIFOS_DATABASE_NAME>
mysql> alter table questions convert to character set utf8;
mysql> alter table question_choices convert to character set utf8;

STEP 5. Verify using step 2, you should not get any rows which are latin1 character set.

Ghost Savings Accounts Fixed in 2.1.3

In previous versions of Mifos, if client approval is automatic, savings accounts created during client creation were broken.  Here is a query you can run to determine if this has happened, and remove the incorrect accounts.

Identify affected accounts:

SELECT sa.account_id,a.global_account_num, a.customer_id FROM savings_account sa, account a where sa.account_id = a.account_id and a.global_account_num is null;

Delete affected accounts (assuming no transactions have been logged for the accounts):

delete from savings_account
where exists
(select 'f' from account a
where a.account_id = savings_account.account_id
and a.global_account_num is null);

delete from savings_performance
where exists
(select 'f' from account a
where a.account_id = savings_performance.account_id
and a.global_account_num is null);

delete from saving_schedule
where exists
(select 'f' from account a
where a.account_id = saving_schedule.account_id
and a.global_account_num is null);

delete from account where account.global_account_num is null;

If transactions have been created for these accounts, then ask for help on the developer list.