[Mifos-developer] FW: Design approach for auto-creation of savings accounts

[Emily T. <em...@em...>]

Hi Folks,

I didn't see this email go through on the mailing list yesterday so am
resending.  Apologies if this creates duplicates.  If other folks haven't
seen postings that they haven't seen, send me an email directly/privately so
I can follow-up.

Thanks,
Emily.

-----Original Message-----
From: Emily Tucker 
Sent: Tuesday, July 25, 2006 4:41 PM
To: 'Developer'
Subject: Design approach for auto-creation of savings accounts

Hi Everyone,
 
We are specing out a feature for Grameen Koota-- automatically created
savings accounts when a client is moved into "active" state.  Details of
this feature can be found here:
https://mifos.dev.java.net/issues/show_bug.cgi?id=376
 
According to Aditi, the best way to implement this feature is to create the
savings accounts when the client record is created in either partial
application or pending approval states and "hide" these accounts until the
client is activated.  Kiran describes the approach below.

Forwarding onto the list as an fyi.

I have one additional question for Kiran: What happens if the client never
gets activated?  Do we have these accounts sitting around or are they
removed?

Thanks for the clarification, Kiran!
Emily.
________________________________

From: Kiran Chakravarthy [mailto:ki...@ad...]
Sent: Monday, July 24, 2006 8:13 AM
To: Emily Tucker
Cc: Manesh G; Swati Rathi
Subject: RE: Grameen Koota feature requests

Emily,

The reason to have the account created in a new state instead of the
offering being stored as part of the customer thereby delaying the account
creation was this:

In the domain object of customer, we currently store the accounts that the
customer object relates to. These account domain objects in turn hold the
reference to product offering they are related to. In case we need to store
the product offerings the user has chosen without the accounts being created
then the customer domain object would have to hold a reference to these
offering objects (the reason being there would be a table to hold the
customer against the offerings and since we don't do sql calls we need to
get this information from the object only). Now there would be reference to
the product offerings from customer domain object and the account objects as
well. Hence the thought was not to hold the reference of offerings in the
customer and instead create accounts itself which are any way part of the
customer object. These accounts could be in a different state so as to
differentiate with the accounts created otherwise. The customer domain
object would have the business logic of changing the state of these account
objects internally when its state gets changed to active.

 

kiran