Savings Products
When defining a new savings product, various pieces of information are entered. The ones relevant to the collection sheet functionality are:
Applicable for (mandatory) :- This defines whether the product can be attached tosavingsaccounts forClients,GroupsORCenters.
Type of Deposits (mandatory) :- This defines whether deposits are Mandatory or Voluntary.
Mandatory or Recommended amount for deposit :- The mandatory (for mandatory type of deposits) or recommended (for voluntary type of deposits) amount to deposit.
Amount applies to :- If ‘applicable for’ is Groups then a choice must be made between ‘Per Individual’ and ‘Complete Group’. ‘Complete Group’ means that a deposit or withdrawal can only be made against a group level ‘customer’, whereas ‘Per Individual’ means that deposits and withdrawals can be made by each client in the group as well as the group itself. If ‘applicable for’ is Clients then it is not relevant to choose between ‘Per Individual’ and ‘Complete Group’. If ‘applicable for’ isCentersthen the system also does not allow a choice but, in practice, results in a ‘Per Individual’ choice. On the collection sheet, a center savings account allows deposits for all clients in the center and the center itself (but not groups). From here on a ‘Per Individual’ account means a group savings account which has been set to ‘Per Individual’ or any center savings account.
NOTE: Center, Group and Client are all types of Customers. Centers may contain many Groups. Groups may contain may Clients. It is possible to configure mifos to not have Centers... leaving Groups as the top of the hierarchy.
No fees can be attached to a savings product (this can be done for loan products and customer accounts)
Like loans, some GL accounting information needs to be entered.
Savings Accounts
This savings product definition results in the following types of savings accounts:
Center Mandatory – always ‘Per Individual’
Center Voluntary - always ‘Per Individual’
Group Mandatory (Complete Group)
Group Mandatory (Per Individual)
Group Voluntary (Complete Group)
Group Voluntary (Per Individual)
Client Mandatory
Client Voluntary
Savings Account Use in Collection Sheet
Schedules (a set of installments)
When a non- ‘Per Individual’savings account is activated, a set of 10 unpaid installment date entries is created for it.
When a ‘Per Individual’ savings account is activated, a set of 10 uppaid installment date entries is created for each client (but not for the group or center itself).
Each schedule syncs up with the customer meeting schedule that is common for all customers in a center/group hierarchy.
Mifos handles the situation when one or more installments (or meeting dates) are missed by the loan officer.
It is not possible to see how the savings balance is derived by looking at the schedules because ‘unscheduled’ deposits are not shown on the schedules (they are shown on the account_trxn table)
Scheduled and Non-Scheduled deposits
A scheduled deposit is one which covers one or more outstanding installments.
A non-scheduled deposit is one for which there is no outstanding installment.
Because ‘Per Individual’ savings accounts don’t have a schedule created for the group (or center), all deposit amounts entered for the group (or center) are treated as non-scheduled deposits.
If a deposit is entered that is larger than the current installment(s) amount due then Mifos first deals with the amount due as a scheduled deposit(s) and then, with the remainder, creates a non-scheduled deposit.
This idea of schedule and non-scheduled deposits is never made apparent to the user. I can’t see why it is needed at all. It does complicate the code and results in more account_trxns and financial_trxns.
Mandatory and Voluntary
A mandatory savings account keeps track of what should be deposited. It doesn’t prevent a user from under or overpaying but will add the unpaid amount to the amount expected to be deposited at the next installment (meeting). Overpayments are treated as unscheduled deposits.
A voluntary savings account merely lists the single recommended amount (regardless of whether one or more meetings have been missed by the loan officer). If any deposit is made the installment is marked paid. If an overpayment is made it is treated as an unscheduled deposit.
What About When the 10 Installments Run Out?
They don’t run out. As also occurs with customer accounts, a batch job pumps in another set of 10 installments when the end of the current 10 approaches. Over time this causes mifos to slow down when processing savings and customer accounts.
Technical Notes
A deposit or withdrawal does quite a bit of work within Mifos
Savings_account |
Update savings_balance |
|
Savings_performance |
Update total_deposits or total_withdrawals |
|
Savings_activity_details |
Create an entry per deposit maintaining balance_amount |
|
Saving_schedule |
Update outstanding entries |
Deposits only |
Account_payment |
Create an entry per deposit |
|
Account_trxn |
For each deposit, create one entry for each installment paid (or partially paid) off. Plus one entry for any amount left over. |
|
Savings_trxn_detail |
As in account_trxn (is a one-to-one subtype). Also maintains balance column |
|
Financial_trxn |
A pair of debit/credit entries for each account_trxn |
|
Differences between 1.3 and Current Version
1. 1.3 allows for a non-scheduled payment (or a withdrawal) to be made for a collection sheet that has no outstanding installments. The current version doesn’t. In practice, this means if someone has completed a collection sheet for center X for 18/11/2009 (and met the mandatory or recommended amount for a savings deposit Y) and then thinks ‘bother, I forgot to deposit/withdraw from savings account Y’… they can’t until the next collection sheet becomes due.
- On the plus side, if anyone ever was interested in seeing the correct balance order on tables savings_activity_details and savings_trxn_detail… that now works.
- The payment_date on table account_payment used to be set to today’s date in 1.3. Now it is set to the meeting date (also known as the transaction date).