Transactions made to client, loan, and or savings accounts - either entered individually on account details, or using collection sheets.
After a Loan account is in Approved status, transactions can be made to the account. These transactions include the following:
In addition, loan disbursals can be reversed.
A loan repayment schedule is set up at the time of . In addition to the amount of the loan repayment, the collection installment amounts may include MFI fees, penalties, and other adjustments. When a loan state is changed to Disburse to LO (or Approved, if Disburse to LO is not used by the HO), the loan can be issued to the client. The transaction is entered in Mifos through a Disburse loan link which is displayed on the loan details page once the loan is approved. Alternatively, disbursals can be entered in Mifos using the
Loan amounts are disbursed in full only.
The following details are captured when the loan is disbursed:
Miscellaneous fee or miscellaneous penalty charged to the account before disbursal is added to the first installment.
When the disbursal entry is made, the account activity is updated, the repayment dates in the repayment schedule is updated as per the date of disbursal, and the disbursal date is changed to the date entered by the user.
Transaction entries are updated with the loan amount, including interest and/or fees, and the status of the loan account is changed to Active in good standing.
When a loan officer returns from a meeting or otherwise receives a payment, he/she or a data entry clerk enters the collection details in Mifos and the system updates the relevant records. To record a payment, the user clicks the Apply payment link under Transactions on the loan account details page.
The system enters the current date for the Date of Transaction. The user enters the amount of the payment and, optionally, the receipt ID and date of receipt. When completed, the user previews the payment information and then saves it. Once the payment is recorded the payment is broken into principal, interest, fees, and penalty components, which are displayed in a table on the account details page. The account balance, amount paid and total amount remaining, and the next payment details are updated accordingly.
The loan account details page shows the total amount due on the next scheduled payment date. The user can click the View installment details link to see the total amount broken into the following components for both the current installment and overdue amounts: principal, interest, fees, and penalty.
After a loan is disbursed, a client can at any time repay the loan in a single payment. To record a total repayment, the user clicks the Repay loan link in the Transaction box on the loan details page. The system calculates the total amount due as of the current date, including principal, interest, fees and penalties, as follows:
Note on holidays: In case a holiday is added after the disbursal of the loan and the original calculation of the repayment schedule, one installment can be shifted to the next repayment date. For example, payment on 1st Jan is shifted to 1st Feb. In this case, if an early repayment is done on or before 31st Jan, it will not consider the interest amount, which would have been due on 1st Jan if Jan 1st were not a holiday.
The user specifies the mode of payment, and optionally the receipt ID and date for the total amount due. The system updates the account summary table with the amounts applied to principal, interest, fees and penalties and changes the account state to Closed – Obligation met.
A client may at any time make a payment that is not in the amount due on a specific date. For example, a client may make a partial payment when she’s short of cash or an overpayment when she has a surplus. A user records these payments in the same way he/she records normal installment payments, by clicking the Apply payment link in the Transaction box of the account details page. However, in these cases, the user needs to modify the default amount shown for the payment to reflect the actual payment amount before previewing and submitting the payment.
The implications of payments that do not match the amount due are described in the following paragraphs.
A partial payment is first applied against the penalty due. If the amount exceeds the penalty, it is applied against the fee due, followed by the interest due and then the principal. The system updates the account activity and transaction history entries. If the user clicks the View repayment schedule link, he/she sees that the partial payment is reflected in both the Installments paid and Installments due sections of the table. The Date paid for an installment is displayed only when the entire installment has been received.
Primary Flow- Partial Payment
Before the system accepts an early payment, it validates that the date of transaction is between the last payment date and the current date, and that the amount entered is not greater than the total amount outstanding for the loan. The amount paid is first applied to the current installment. The remaining amount is then applied to the penalty due, if any, for the next installment. An excess at this point is applied to the fee due, followed by the interest due, and then the principal. The system updates the account activity and transaction history entries. If the user clicks the View repayment schedule link, he/she sees that the early payment is reflected in both the Installments paid and Installments due sections of the table.
Primary Flow- Early Payment
Mifos provides Principal Pre-payment option for Loan accounts with ‘Declining Balance’ or ‘Declining Balance-Equal Principal Installment’ interest rate type.
This option allows you to make more than one transaction on the same day, even if there is a payment applied for interest on the same date.
Principal Pre-payment option gives also a possibility to make principal pre-payment on non-meeting date (i.e. on a date on which there is no entry in the loan schedule table) or if the duration of the loan went beyond what was entered into loan schedule table by Mifos.
Primary Flow- Principal pre-payments
Mifos allows backdated payments if the settings allow it. The system calculates and displays the total amount due as of the current date. If a backdated payment is paid, the user manually calculates the amount due as of the transaction date. The system verifies the date and amount. If the amount entered is not equal to the amount due as of the transaction date, the system does not accept the payment.
The date of payment can be between the date of the last meeting and the current date.
Alternate Flow- Backdated Payment
Client may make payment greater then remaining balance of the loan (an overpayment). Sometimes it is only a few dollars over, sometimes an entire extra installment is mistakenly paid. Handling overpayment of remaining loan balance is available in Mifos and the MIS will track this so that action can be taken to return the overpayment portion to clients in future.
Primary Flow- Overpayment
1. Overpayment situation only happens when repaying the last payment of a loan.
2. System detects an Overpayment during bulk payment upload.
3. The system closes the loan account and makes an entry in the new database table with details such as loan account number, overpayment amount, date and time, status of the overpayment and payment id (to be able to track the overpayment is linked to which payment).
4. On the loan page, the system displays the amount of the overpayment. Adjacent to this, there is a button labeled 'Clear' which is available for a user to manually clear the amount in case the last repayment was adjusted for some reason. The click of this button allows user to specify how much amount he would want to clear off.
5. Each loan can have more than one overpayment.
If an installment payment is missed, it is displayed in the overdue information, and the Total Amount Due includes the missed installment. For example, if a client has to repay $100 (principal = $80 and Interest = $20) every month, and she defaults for the month of August, then for the month of September, the following amounts are displayed in the Next Payment details:
Principal Due= $80
Interest Due = $20
Penalty Due = $2 (for the missed/defaulted installment)
Principal Overdue= $80 (for the missed/defaulted installment)
Interest Overdue = $20 (for the missed/defaulted installment)
Total Amount Due= $202
While the payment is entered, the system accepts either $202 or no payment at all.
To rectify errors, the full amount of the last amount paid can be nullified by clicking the Apply adjustment link from the Transactions box on the account details page, the repayment schedule page, or the next installment details page. Multiple repayments can be reversed by reversing each payment amounts one at a time.
Users adjusting loan payments for a loan already of the status Closed – met obligation, must have a specific permission to do so.
When the user clicks the Apply adjustment link, he indicates that the last payment should be reverted, and includes a note describing the reason for the adjustment. These notes are stored with the transaction history, rather than with the Recent notes or All notes for the client. After the adjustment has been previewed and submitted, the user can click the Apply adjustment link again, to reverse the previous payment, and so on, until only the first payment remains.
Once an adjustment is made, the system breaks down the last amount paid into its components and updates the respective amounts where required. For example, if the last amount was paid for principal, interest and fees together, the system breaks the total amount into these amounts and subtracts it from the principal paid till date, the interest paid till date, and the fee paid till date, and adds it to the loan balance of principal, interest, and fees to pay.
After each adjustment, the system updates the following:
Alternate Flow - Adjusting payments
Data entry errors can result in loans that are created and disbursed to a wrong client/group or recorded against the incorrect client. Or a loan account of the incorrect product can be created and disbursed to a client. The error might not be detected until after multiple repayments have been recorded.
To correct this type of error, a user with the appropriate permissions can reverse the loan disbursal and all payments made again the loan, as long as the loan is within the user’s data scope. The loan must be in an Active in good standing or Active in bad standing states only.
The user clicks the Reverse Loan Disbursal link on the Admin tab, enters the reason for the reversal in the Notes box, and then previews the change before saving it. Mifos changes the loan account state to Cancelled with the flag Loan reversed, and reverses any payments that have been made along with the reversal of the loan disbursal. The notes are included in both the account notes and the adjustment notes, and the change is logged in the account activity. All relevant counters, such as the loan cycle, are decremented and the loan is not included in loan counts for reports. The loan is moved to the Canceled state, with a reason flag of “reversed.”
If several payments have already been collected, the user can use the Redo Loan Disbursal link to recreate a loan and historical payments.
After an error has been made and the loan reversed as a result, as explained in Reversing loan disbursals, a user with appropriate permissions can redo the loan disbursal by opening an account for the correct client with the correct product selected. The loan disbursed should be reversed first before being redone.
To do this, the user clicks the Redo Loan Disbursal link on the Admin tab and selects the client for whom the account is to be redone. The system validates that the client is within the user’s data scope and displays the Redo Loan Account page. Red warning text indicates that the user is redoing the loan account.
The user enters the loan account information. Note that the user is able to enter a disbursal date in the past.
When the user clicks Continue, the Redo Loan Account Installment page is displayed, on which the Actual Payment Date and Actual Amount paid are user-editable. After the user previews and submits the loan account information, the account is flagged as redone and the loan is immediately moved to Active in Good Standing.
- User has permission to perform this action.
- Results outside the user's data scope should not be shown to the user.
- Note: The system should allow the user to enter a disbursal date in the past.
- Two fields Actual Payment Date and Actual Amount paid are user editable.
- It is possible to choose the mode of payment.
Redo Loan Disbursal: UI screens are accessible
To view the screens, download and extract the zip folder, click on admin.htm, and if your browser gives you a warning select "Accept blocked content". Click on the Redo Loan Disbursal link under Manage Accounts and follow the user flow below.
Fees and penalties can be applied at either the loan account or at a client/group/center account. When are created, predefined charges () may be attached to the account. These charges are in the form of periodic or one-time fees, and one-time miscellaneous fees or penalties. The amount due at any given time is displayed under Account information on the client detail page.
To record a charge payment for a client account, the user clicks the Apply charges link on the client details page and enters the amount, date of transaction, mode of transaction, receipt ID and date.
In addition to the fee types inherited by the loan account from product definition, user can apply other predefined fee types to the account and also apply a Misc fee to the account.
To calculate the next payment due, system will consider all the fee types applied to the account and the misc fee amount applied to the account, if any, and calculates the “Payment Due amounts”.
User can also apply a “Misc penalty” amount to the account. If a miscellaneous penalty amount is applied to the account, the same is included in the upcoming/today’s payment due for the account.
Fee installments and penalty installments can be waived and the same amount will be reduced from the next installment details
Client, Group, and Center accounts may also have fees and penalties attached. Fees predefined as applies to that account can be attached to the account. They are due at the next meeting day when applied. Fee payments can be applied before the next meeting day. Partial payments of fees due can also be applied. See Early Repayment of Fees for detailed scenarios.
Types of Fees/Penalties
When a Loan Officer returns from the field, the officer has to enter the collection sheet details in the system. Alternatively, he can provide the details to a non-loan officer who can enter the data for him. After necessary validations, the system updates the relevant records with the transaction details provided by the LO/user.
Steps to enter a center’s data in collection sheet entry. User can enter this feature from Enter Collection Sheet Data link in Mifos in the left navigation pane.
The collection sheet entry form will have the following data:
|Sl. No.||Column Name||
|1||Client/Group Name, Client/Group ID||Client Name should be only First and last name.|
|2||Loan Product 1, 2…||
System calculated values should be pre-filled
These can be edited by the users.
|3||Savings Account 1, 2…||
Mandatory deposit amount for savings account 1 due till the current date.
For voluntary savings accounts, this amount will only have the latest amount due and will not include the amounts due from past meetings.
System calculated values should be pre-filled. The amount can be edited by the user.
|4||Loan Account 1, 2…||System calculated values for Loan amount due to be disbursed to the client/group. The amount will be editable.|
|5||Savings Account 1, 2…||User-entered- Withdrawals made in the field clients/groups/centers|
|6||Client Charges||System calculated- Fee/Misc fee/ Misc penalty charged to client/group/center account and due|
Drop down with the following options:
Present (P), Late (L), Absent (A), Approved Absence (AA).
Collection Sheet Entry displays disbursals due on a meeting. If the transaction date is modified to a date other than the last meeting date, Mifos updates the disbursal date for that loan account and regenerates the repayment schedule as per the new disbursal date.
Al Majmoua currently handles all repayments of loans by clients by having clients deposit their repayments directly at a bank, and then Al Majmoua is able to download online a file of these recorded transactions to import their MIS. They need the ability to do this in Mifos as well. See related Business requirements for more detail.
|Priority||User Story||Section in FR|
|1||As a user (accountant) at the HO, I want to be able to import a XLS of bank transactions from Audi Bank into Mifos so that all details for our clients' payments are accurately recorded in Mifos|
|1||As a loan officer at a BO, I want to be able to see the clients at branch have paid their loans in Mifos|
|2||As a user (accountant) at the HO, I want to be able to import a XLS of bank transactions from any bank into Mifos so that all details for our clients' payments are accurately recorded in Mifos|
The following items will not be addressed in this release:
This feature is in the Admin section and will allow the User to import bank transactions
|Priority||Size||User Stories||Mingle card #|
|1||X-Small||As a User, I can give permission to import bank transactions.|
|1||Small||As a User, I can click on Import Bank Transactions and see options to import my file (Audi Bank).|
|1||Small||As a User, I can confirm that I want to import the data into Mifos.|
|1||Medium||Populate all data from file import in Mifos|
|2||Medium||As a User, I can click on Import Bank Transactions and see options to import my file (generic)|
|FR#||Pri||Description||Comments / Mockups|
|1.1||P1||Add new permission "Can import transactions" under the Bulk subsection in Permissions. The ADMIN role should by default have this permission checked.|
|1.2||P1||Assumption is the only check when the user imports transactions is if they have this permission checked in their role. There is no checking of their data scope and hierarchy. Ie: If the user is a Loan Officer in BO1, and has this permission checked in their role, then they are allowed to import any bank file, and there is no check that the data they are importing is only for their branch office.|
|1.3||P2||If one day we implement importing transactions per branch, then permission should also check for data scope. Ie, can only import data for a particular branch.|
|FR#||Pri||Description||Comments / Mockups|
|2.1||P1||Add Manage Imports section with Import Transactions link in Admin section|
New Import Data Transactions Screen with following fields:
* Import format (dropdown)
* Select import file (browse for select file)
|2.3||P1||Import format Field will have two options: Audi Bank (tab delimited) and Audi Bank Excel 97 formats|
|2.4||P1||Screen has buttons Continue and Cancel. Clicking on Continue imports the file selected and Mifos does validations and brings User to Review & Submit screen. Clicking on Cancel returns User to Admin screen.|
If there is no import plugin for the MFI, then the Import Format options will be blank and if the User tries to import a file and Continue, the following error message will be displayed at the top. Also if the User does not select a plugin even if there are options then the following error message will be displayed.
Please select the import type.
If there is no Mode of Payment configured in Mifos to be the same as the first cell of that file (in this case, should always be Bank Audi sal), then an error message will be thrown on the Import screen:
No payment type found named <bank>
where <bank> is the first cell of that file.
|FR#||Pri||Description||Comments / Mockups|
|3.1||P1||Audi Bank import file is currently in Excel. Al Majmoua will save these as a tab-delimited file first before importing into Mifos.|
|3.2||P1||Audi Bank import file first few lines contain description of file. These are to be ignored. Only data after row of column headings will be imported.|
|3.3||P1||Import file will have columns in below table|
|3.4||P1||There will be bare basic error checking - to successfully import the data.|
If a row with C (for Credit in D/C column) contains a cell that's missing a required field, Mifos displays an error message for each row this occurs.
Row <#> is missing data.
where the row # is the original row # of the import file.
If any value under Trans.Date column is not in format of YYYY/MM/DD if User is using TSV importer, then Mifos displays an error message for each row this occurs.
Transaction date value in Row <#> does not follow expected format (YYYY/MM/DD).
where the row # is the original row # of the import file.
No error message will be thrown to validate date format when using Excel importer since the importer will check for correct date format automatically.
If any value under the Serial column is not numeric (ie text or special character) then Mifos displays an error message for each row this occurs.
Serial value in Row <#> does not follow expected format.
where the row # is the original row # of the import file.
If any value under the Description column does not follow the format PMTMAJ<2 letter code><5 digit loan id for external id> or <7 digit account id> or <15 digit loan id for Mifos loan id> then Mifos displays an error message for each row this occurs. Mifos should throw an error message when:
Check if the same file name has been imported. If so, then throw an error message and reject the whole import.
Same file name has been imported. Please import a different file.
After clicking on Continue, Mifos will display the Review & Submit screen with the following:
Review the information below. Click Submit if you want to continue with import or click Edit to make changes. Click Cancel to return to Admin page without submitting information.
Import file name: <name of file>
Import Status: <#> rows contained no errors and will be imported.
where <#> is the number of valid rows being imported.
If any error messages apply, then Mifos adds the messages line by line.
The following rows contained errors and will not be imported:
User can then either
|3.13||P1||If User clicks on Submit, Mifos imports the file and displays confirmation screen - see mockup ->|
|3.14||P1||There is no option to revert a file upload once it has been submitted.|
|3.15||P1||There is no checking of duplicate rows (see 3.9)|
|3.16||P1||Currency of values imported is directly inherited from the loan product that the loan account is mapped to.|
If there are no rows found with import data, the following error message should be thrown:
No rows found with import data.
|Column Name||Required||Description||Comments||Validations||Range||Example||Maps to Mifos|
|Trans.Date||Yes||Payment date||Validate date is in range (see above)||YYYY/MM/DD (for tab-delimited files)||2009/09/01||Transaction Date|
|Serial||Yes||reference number for the transaction||Only validate value is numeric (see above)||1234567||Serial Number (internal field in DB)|
|Value Date||No||Ignore this column|
|Reference||No||Ignore this column|
|D/C||Yes||Debit or Credit||Only import rows with C||No validation - only import rows with C||D or C||C||None|
|Amount||Yes||transaction amount||can be in USD or LBP, currency is not indicated||Only validate amount is a number||numeric number||2577||Transaction amount|
|Balance||No||ignore||Ignore this column|
|Description||Yes||contains the loan id||
Only import rows with A, Z, or C in the 2nd letter of <two-letter-code>
Need to extract the loan id from this row
loan id is 5 digits or 15 digits
|Only validate if the loan id can be extracted for rows with A, Z, or C - so if format is incorrect and loan id cannot be extracted, display error message (see above)||PMTMAJ <two-letter-code><5 digit external loan id> or <7 digits account id> or <15 digit mifos loan id><space><two-digit LA code> <client name>||
PMTMAJ EC12345 82 Joe Smith
PMTMAJ 1234567 82 Joe Smith
PMTMAJ 1234567890123456 82 Joe Smith
|FR#||Pri||Description||Comments / Mockups|
|4.1||P1||Assumption: All transaction detail is for loan repayments (loan fees, interest, principal). There is no data in file for loan disbursals, savings withdrawals or deposits, client, group or center fees, or client attendance.|
|4.2||P1||Trans.Date is actual repayment date recorded|
|4.3||P1||Amount that is being paid - pre-payments and partial payments are allowed. Amount in file is applied in the following order - Penalties, Fees, Interest, Principal.|
|4.4||P1||Trans. Date cannot be after today in Mifos|
|4.5||P1||Mode of Payment must be configured in Mifos to have Bank Audi sal, which will be the mode of payment used for all transactions in that import.|
|4.6||P1||If there is an overpayment, Mifos should thrown an error.|
|Does the user need to be in a particular user hierarchy to use this feature?||No|
|Does the office hierarchy affect use of this feature?||No|
|Are you using any existing permissions to control this feature?||No|
|Are you adding any new permissions or changing existing permission to control this feature?||Yes - adding new permission Can import bank transactions|
|Are you using any existing activities to control this feature?||No|
|Are you adding any new activities or changing existing activities to control this feature?||No|
|Are there any special considerations for upgrade scenarios? What will be the default value for new permissions?||No special considerations. Default value is checked in ADMIN role and unchecked for all other roles.|
|What will be the default values for default roles in a new installation?|
|Does this feature affect Bulk Loan Creation? How?||No|
|Does this feature affect Collection Sheet Entry? How?||No|
|Does this feature affect Redo Loans?||No|
|Does this feature affect Undo Loans?||No|
|Will this feature support users localizing data that they enter?|
|Does this feature involve any date/time related data, and if so how should conversions be handled?|
|Is there currency or other numeric data ? If so does it require any special handling or validation?|
|Do changes to the data that is collected or stored by the new feature have to be fully logged by the system?||Yes|
|Does the administrator configuring the system need the ability to turn on or off logging for this feature?||No|
|Is the feature currently logged but the structure of the logged records changing?||No|
Provide any relevant information about reporting requirements for the new features and answer the questions below, providing detail to explain any particular area when necessary.
|Does the feature affect any existing reports?||No|
|Does the feature require adding any new reports?||No|
|Will the feature be a high use-case scenario?||No|
|Will the feature have potential for high concurrency?||No|
|Does the feature include complex UI or data gathering logic that will be used by a significant portion of the user base?||No|
|Does the feature contain risks of database connection timeout or ASP page timeout?|
|Will the feature contain any bulk insert/update/delete transactions?|
|Will the feature contain any caching mechanisms or cache refreshing mechanisms?||Unclear|
|Could the feature result in a large amount of data being sent to the client or between the database and web server?||Yes|
|Would users on a low bandwidth connection likely face issues with a part of this feature?||Depends on size of file|
|Does the feature affect existing batch jobs or require adding any new batch jobs?||Unclear|
|Will the feature include demo data?||No|
|Does the feature require any data to be gathered at setup runtime?||No|
|Is there any data conversion that needs to be done as part of an upgrade?|
|Will customers lose data or will the way existing data is stored change significantly?||No|
|Will another feature, workflow or portion of the data model be deprecated as a result of this new feature?||No|
|Will existing role permissions be changed or impacted by this feature? If so provide details in the security section.||ADMIN role should be updated to have this permission checked.|
|Will existing customers need to learn a new UI process or change the way they use the system as a result of this new feature?||No|
|If different user groups are using the same database, are there concerns over the sharing of data related to the feature?|
|Are there expected to be performance related issues with having many customers sharing the same hardware in support of this feature?|
|Does this feature require changes to configuration files?||No|
|If so, is this feature enabled or disabled by default?||N/A|
can we get the bank to only put loan id in the description field? No
|Audi Bank||Generic Import|
|Faster||Restricts us to adding one bank at a time in the future||Can accommodate all 5 of Al Majmoua's banks||Will take longer to implement|
When a savings account is in Approved status, the following types of transactions can be made to the account:
Each of the transaction entries described here is made against the correct GL Code, according to the chart of accounts defined for the HO. The transactions are not included in the change logs.
For mandatory savings accounts, the total due, including amounts not paid in past meetings, and the date, are displayed on the account details page. If the mandatory deposits are specified as per group member, then deposits made against Non-specified do not reduce the amounts to be deposited by each group member. This is applicable to all center savings accounts as well.
For voluntary savings accounts, a recommended amount is displayed on the account details page.
The user specifies the following when making a deposit/withdrawal:
For mandatory accounts, the amount deposited can be less than or equal to or greater than the mandatory deposit amount, with the following implications:
The system records the date of transaction and the username. The user previews and saves the information. The system performs basic error checking and records the transaction date and the user name and records the transaction and updates the savings account balance.
Note : Even though the current account balance is shown as one value (sum of all debits minus all credits), the system can detect if, for example, an adjustment is made, whether it was a withdrawal or a reduction of interest earned .[correct?]
To rectify errors/mismatches, users with appropriate permissions can modify or nullify the amount last paid. The system then reverses the last entry (withdrawal or deposit) and creates another transaction for the new deposit. The corresponding financial transactions entries (DR/CR) are made.
For mandatory accounts:
For voluntary accounts:
For group/center savings accounts, if the last transaction is nullified, it is adjusted against the client who made the transaction.
Bulk entry. For center savings accounts, there can be multiple deposits and/or withdrawals. For adjustments, the system picks up the amount under the non-specified option of the center account as the last transaction. If this is empty, the system allows an adjustment on the transaction made for the last client. A similar rule applies to group savings accounts.
More on interest posting and calculations here
This section records all amounts that were deducted or added to the account.
The details recorded are: