Redesign Accounts, Schedules and Meetings

Introduction

Presently in mifos Accounts have been implemented with concrete implementations for LoanAccount, SavingsAccount and CustomerAccount.

These account implementations are tied to a concept of 'Schedules'.

Based on the GK growth figures, the LoanAccount and the CustomerAccount are the most heavily used.

We propose that the persistence of this 'schedule' information is not required and the information can be calculated on the fly when needed.

Secondly, the implementation is tightly coupled to 'Meeting' information. This was to support mifos customers who wanted their customer repayments to be mapped to their Loan Officers assigned 'Meeting's. However we also have customers that may wish to work more like the tradition TellerModel whereby a customer can just make a repayment at anytime and not be constrained to a 'Meeting'. As a result, GLIM/LSIM became a needed feature.

Thirdly, not all functionality to handle coupling between repayments and schedules is part of the 'domain model'. Instead it was placed in 'Batch Jobs' that run overnight and ensure there are schedules available for customer and savings accounts. GenerateMeetingsForCustomerAndSavingsTask, the batch job that generates customer (and savings) schedules has become very unpredictable as GK increase customers. As at early Jan 2010, it takes an average of 3 hours and sometimes has gone for 7 or more hours.

Removing customer schedules would remove this batch job entirely. Two steps that could be done prior to this though are

1. Sungard's Holiday query fix
2. Change the initial query to only pick up customers that need additional schedules. I think these two would bring the batch job to 15 - 30 mins or less. It would be better gone though... and of course customer_schedule impacts non-batch mifos as well.

Keith W Note: GenerateMeetingsForCustomerAndSavingsTask

For some reason I previously thought that this task was generating loan schedules but its not. It is only to do with customer schedules and savings schedules.

Loan schedules doesnt need this because: loans have an end date, the current use of customer schedules (and savings) is neverending for active customers

Thus it makes more sense to look into removing customer_schedules first and decoupling it from CustomerAccount. Having looked at the code, this ties back to Customer creation flow.

Impacted Features of Customer Schedules

Customer CreationCustomer AccountsCollection Sheet 'retrieval'

Benefits

Will tackle the problem area behind most of why GenerateMeetingsForCustomerAndSavingsTask takes so long. This will also go along way to cleaning up design around customer, customer account and fees that interact with them.

Having achieved this it will give us more information/confidence on how to approach saving and loan schedules.

Customer Schedules Work

See CenterCustAction.create see ClientCustAction see GroupCustAction

1. refactor customer creation, customer account creation flow (CenterCustAction.create) to service facade + spi + api
2. refactor customer creation / customer account creation flow #. fees applied during center creation are passed on to CustomerAccount
3. refactor customer account #. break current CustomerAccount --> CustomerSchedule --> CustomerFeeSchedule relationship off entirely #. put in place another relationship to manage customerAccount fees and collection/payment of fees

NOTE:
When customer is created, a meeting is established between the customer and the loan officer..i.e. the loan officer will visit center on a given date.
Question - does this mean all groups and clients with center inherit meeting date or is there a need for individual groups to have a seperate meeting date, in which case the loan officer actually has two different meeting schedules with the center/group?

Impacted Features of Loan Schedules

Loan Account CreationLoan Account DisbursementLoan Account repaymentLoan Redo ReversalGLIM/LSIMCollection Sheet 'retrieval'ReportingAnd probably a few more

Benefits

Scalability:

1. the 25:1 ratio of loan_schedules and loans will no longer exist removing a good deal of data from the database
2. creation/loan repayments performance should improve.. (and most likely fetchs of loans)
3. And importantly REMOVES the need completely for batch jobs to do with schedule generation/update

Clean Design:

1. A clean SPI and API around loan accounts will emerge
2. A clean seperation of the POJO implmentation of loan_account and its DAO
3. Clean integration test around loan_account DAOs and unit tests around loan_accounts
4. Clean this TellerModel versus BranchVisitationModel (theres no reason why both can't be supported at same time)
5. As a result we would clean up Group loan Independent of Meeting (GLIM/LSIM)

Loan Schedules Work

Web

1. Move business logic/knowlege from struts actions into service facade for each struts action class around accounts.

Domain

1. Extract a clean domain services for accounts
2. Tackle each of impacted areas of functionality but do not replace existing implementation (swap it out for 'LoanAccountNew')

   1. Hook in new implementation for accounts and schedules and remove old.