Savings Products
When defining a new savings product, various pieces of information are entered. The ones relevant to the collection sheet functionality are:
...
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.
...
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.
...
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). Over payments 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
- 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 (but wasn't backdated for existing data as far as I know).
- 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).