Related Tables

meetings, recur_on_day, recurrence_detail - two entries get created per savings offering, 1. for period of interest calculation 2. freq of interest posting
prd_offering - one entry for every product offering creation.
prd_offering_meeting - two entries which maps a savings product offering to two meeting created in "meeting" table.
savings_offerings - contains the savings product offering specific information

account - contains core account information for savings account
savings_account - contains savings specific information
savings_performance - contains details of total deposits, total withdrawals, total_interest, missed_deposits

savings_activity_details - contains details about deposit, withdrawn, interest posted and adjustments (the entries from this table are shown on the UI "View Savings Activity Details")
account_payment -

account_trxn -
savings_trxn_detail -
savings_schedule -

NOTES: About editing Savings products

On every edit operation new entries gets created in meeting tables, those should get updated not created again.
Start Date (Start Date for and Active product can not be edited so it should be read only like GL Code)
"View Change logs" seems to be working correctly for all the editable fields in "Edit Savings Product Offering"

Savings Matrix

Group Model (with Individual Tracking/Accountability): Center and Group (per individual mode)
Group Model (with no Individual Tracking/Accountability): Group (Complete Group mode)
Individual Model: Client

	Center	Group (Per Individual)	Client	Group (Complete)
Voluntary	saving_schedules created for each client (active/on hold) each client can pay anything not just the 'recommend amount' and schedule is marked as paid each client may withdraw up to 'max withdrawal' per transaction making an 'unspecified' payment payment is against the center itself and no schedule associated with client is updated overpaying a clients 'recommended deposit' means 'savings installment' is paid up to that amount and marked as paid and a 'unscheduled' payment is made for the rest of the excess against the client that paid making two entries in account_trxn.	saving_schedules created for each client (active/on hold)	saving_schedules created for client (active/on hold)	savings schedules are created for Group only, no tracking of clients can pay anything not just the 'recommend amount' and schedule is marked as paid prepayments are handled as 'unscheduled payments' against group customer. overpaying the 'recommended deposit' means 'savings installment' is paid up to that amount and marked as paid and a 'unscheduled' payment is made for the rest of the excess against the group that paid making two entries in account_trxn.
Mandatory	saving_schedules created for each client (active/on hold) each client must pay 'mandatory amount' before schedule is marked as paid each client may withdraw up to 'max withdrawal' per transaction making an 'unspecified' payment is against the center itself and no schedule associated with client is updated underpaying a clients 'mandatory deposit' means 'savings installment' remains unpaid overpaying a clients 'mandatory deposit' means 'savings installment' is paid in full and marked as paid and a 'unspecified' payment is made for the rest of the excess. The difference with this 'unspecified' payment is that it is tracked against the client and not the center in the 'account_trxn' table.	b	c	d

Interest Calculation and Posting

Introduction

When creating a SavingsProduct, the user can define how interest calucation and posting will happen.

Mifos out-of-the-box currently supports two types of interest calculation; Average Balance and Minimum Balance.

The user may also choose from two types of time period for interest calculation; Days and Months

For interest posting, only Months are supported.

Interest Calculation

At present interest calculation is carried out by an overnight batch job (SavingsIntCalcTask). It determines when to run based on the next interest calculation date value stored in savings_account -> next_int_calc_date datable table/column.

When a savings account goes active for the first time, an initial next calculation date is determine based on the start of the fiscal year which is fixed at January 1st and the interest calculation time period chosen in the savings account product definition. For interest calculation, this can be Daily (e.g. every x days) or Monthly at the end of the month (e.g. every x months on last day of month).

So interest is only calculated for any transactions that occur within a given 'interest calculation period'. The interest calculated for a given period is stored (savings_account -> int_to_be_posted) until the next interest posting date is reached whereby the sum of all calculated interest is posted to the savings account.

Interest Calculation Dates in Months

Example:

Interest calculation is determined every 3 months so based on starting from Fiscal start of year, the valid interest calculation dates are:

Jan-01 to Mar-31

Apr-01 to Jun-30

July-01 to Sep-30

Oct-01 to Dec-31

Interest Calculation Dates in Days

Interest calculation is determined every 28 days (4 weeks) so based on starting from Fiscal start of year, the valid interest calculation dates are:

Fri Jan-01 to Fri Jan 29
Sat Jan-30 to Fri Feb 26
..
..

Interest Posting

Interest posting always occurs on a monthly basis on the last day of the month.

When interest is due for posting, its takes the value from (savings_account -> int_to_be_posted) and posts it the date of last day of month.

Interest posting is handled overnight by batch job (SavingsIntPostingTask).

Interest Posting Dates in Months

Interest calculation is determined every 1 months so based on starting from Fiscal start of year, the valid interest posting dates are:

Jan-01 to Jan-31

Feb-01 to Feb-28/29

Mar-01 to Mar-31
..
..
Dec-01 to Dec-31

Interest Calculation Formula

Interest Calculation Formula	Balance	Table Used
A = P(1+r/n)	Minimum Balance	SAVINGS_TRXN_DETAIL
A = P(1+r/n)	Average Balance	SAVINGS_TRXN_DETAIL

r = R/100 x D/F

P = AvB/D or MB/D

I = P(r) only if P is greater than or equal to minimum balance required for interest calculation otherwise the interest (I) will be zero.

AvB = Total Average Balance for duration D

MB = Minimum Balance for duration D

D = Duration/Interval (Days) for which the interest is being calculated

F = Number of Days in Financial Year

P = Principal amount (initial amount) (Average/Minimum Balance)

R = Annual rate of interest (as a decimal) (defined during savings product creation)

r = Effective interest rate for the duration D

I = Interest Amount

Interest Calculation Examples

The purpose of these interest caluclation example is to describe by example how savings work in mifos. From reading through these, you should be able to understand

How and when dates for interest calucation and posting are determined
How the Average Balance algorithm works
How the Minimum Balance algorithm works
How and when interest is calculated for a given Interest Calculation Period
How and when interest is posted to a savings account

see Interest Calculation For Average Balance By Example
see Interest Calculation For Minimum Balance By Example

Interest Calculation/Posting (Notes)

Interest Calculation Date: SAVINGS_ACCOUNT.LAST_INT_CALC_DATE (fromDate), SAVINGS_ACCOUNT.NEXT_INT_CALC_DATE(toDate)

Interest Posting Date: SAVINGS_ACCOUNT.LAST_INT_POST_DATE, SAVINGS_ACCOUNT.NEXT_INT_POST_DATE

Based on the interest calculation meeting from Savings Product Offering "next interest calculation date" is set during interest calculation.

The interest calculation is done for the period determined by fromDate and toDate.

Initial (first) interest calculation has LAST_INT_CALC_DATE as null, in this case the activation date account is taken as fromDate.

Interest calculation takes place when the NEXT_INT_CALC_DATE is older than currentDate.

Interest calculation takes place when principal (P) is greater or equal to the Minimum balance required for interest calculation(Savings Product has property miniBalForIntCalc)

Calculated interest is saved in SavingsBO.interestToBePosted field after every interest calculation.

e.g. if there interest calculation period is 1 month and posting frequency is 3 month then the interest will be calculated 3 times and stored in SavingsBO.interestToBePosted. Interest Posting Batch job will pick the interest from SavingsBO.interestToBePosted.

This makes a necessary condition that Interest calculation batch job should always run before interest posting batch job.

If one interest calculation fails interest posting job has no way to determine and it will still post the interest as SavingsBO.interestToBePosted which could be zero if interest calculation job fails.

Warning

At present, once interest for a given calculation period is calculated it will never again be recalculated however it is possible for users to adjust their last transaction which could well be in the last 'calculation period' and thus the previous interest figure would be wrong.

Handy Hint

It may be just as easy to allow a user adjust ANY transaction and to calculate the interest for account based on all details every time.

Savings Schedules (Notes)

- While creating Mandatory Savings Product, you can not enter a zero amount for "Recommended amount for deposit at every meeting". But during creation of Savings Account it allows to enter zero as "Recommended amount for deposit at every meeting" which results in zero amount schedule. The transaction gets recorded for that zero due, this is probably not a bug, but it can be improved. Same situation is for Voluntary Savings Account