Re: Extending the Client Data

[Binny Gopinath Sreevas]

Hi Sander,

I think it is a perspective. I have plans to extend the client entity with
certain frequently used attributes - like address, nominees etc. - which
will be sub-tables and not clutter the main client table. Definitely, some
other things will remain as data tables. I find this approach much easier,
consistent and simpler to handle during implementations and easier for
reporting. May not be sending a pull request to the community platform
though - as there has always been differing opinions on this.

- Binny



On Mon, Apr 11, 2016 at 4:56 PM, Sander van der Heyden <
sandervanderhey...@musoni.eu> wrote:

> Hi Binny,
>
> The way we solved this is through so-called entity datatable checks, which
> ensure that a state change of the entity (Approve Client for instance), can
> only be done if Datatable X is filled. You can then use this for generating
> UI's as well, by querying which tables need to be filled for new clients
> etc. This work is already on our github branch and will be submitted in a
> PR soon. Same for the validations of fields being present, this is already
> in the datatables, and by extending a few fieldtypes, we can easily start
> supporting validations on e-mailaddresses, phone no's etc.
>
> I'm definitely not in favour of adding more data to the core model, the
> previous system we used (when we were still working with just Musoni
> Kenya), the core client table had about 75 columns, 80% of which was empty,
> just cluttering up the model and the reports. In the 45 financial
> institutions we are working with, we literally have 45 different sets of
> fields people like to capture, whether mandatory or not. At the same time
> we also have people just using the MifosX backend for their loans, keeping
> client data etc in Salesforce, and not wanting to use all this extra
> clutter.
>
> I therefore suggest we start working on some of the issues you pointed out,
> instead of going the quick-and-dirty route on adding columns, which will
> slowly turn into more and more being added increasing the clutter. So far I
> think the issue list would be:
> - Musoni contribution for entity-checks
> - Improvement of batch API's
> - Improve ordering and workflow management around the datatables (also
> something we've worked on)
>
> S
>
>
>
>
>
> Sander van der Heyden
>
> CTO Musoni Services
>
>
>
>
> Mobile (NL): +31 (0)6 14239505
> Skype: s.vdheyden
> Website: musonisystem.com
> Follow us on Twitter!  
> Postal address: Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam,
> The Netherlands
>
> On Mon, Apr 11, 2016 at 1:18 PM, Binny Gopinath Sreevas <
> binny.gopin...@gmail.com> wrote:
>
> > Hi,
> >
> > My two cents:
> >
> > Some organizations expect address etc to be mandatory fields - Things I
> > have been asked during implementations: do not allow a client to be
> created
> > if details like address, nominees, KYC details (at least one client
> > identifier), etc are not provided. And I have heard dismay that Mifos
> does
> > not have a standard address field for offices and clients and hence it is
> > difficult to get standard reports by region or state.
> >
> > If each implementation configures these as data tables - then each
> > implementation will have to hard-wire such validations. Which becomes
> > complicated when maintaining code. Without these validations, data
> quality
> > suffers.
> >
> > I would recommend to add some common things to client (like the ones
> listed
> > above) - and make it configurable (like Sander mentioned) - so that
> entire
> > sections (like address, KYC, nominees etc.) can be turned on or off
> during
> > implementation. And if turned on - then additional validations could be
> > turned on or off -
> > For example: if address is turned on - then at least one address should
> be
> > entered by user - and within address, address-line-1 and postal-code
> would
> > be mandatory for one implementation and district/province could be
> > additionally made mandatory in another implementation.
> >
> > There are also additional things to be considered - for example: address
> > structures, etc. should be common for all countries (and we shouldn't be
> > adding something like Talukas which may be relevant only in an Indian
> > context).
> >
> > I also did consider combining data tables with the main entity using
> batch
> > APIs - so that the create-client and create-address-data-table goes
> > together in one call. But the error handling here wasn't good - difficult
> > to show meaningful error messages to users. And again was finding it
> > difficult to get a good UI layout + validations in place when using data
> > tables, without having to resort to hard-coding these on the UI.
> >
> > - Binny
> >
> >
> >
> > On Mon, Apr 11, 2016 at 1:04 PM, Sander van der Heyden <
> > sandervanderhey...@musoni.eu> wrote:
> >
> > > Hi Saranash,
> > >
> > > I think while one set of data is needed in India, other countries will
> > need
> > > other 

Re: Extending the Client Data

[Sander van der Heyden]

Hi Binny,

The way we solved this is through so-called entity datatable checks, which
ensure that a state change of the entity (Approve Client for instance), can
only be done if Datatable X is filled. You can then use this for generating
UI's as well, by querying which tables need to be filled for new clients
etc. This work is already on our github branch and will be submitted in a
PR soon. Same for the validations of fields being present, this is already
in the datatables, and by extending a few fieldtypes, we can easily start
supporting validations on e-mailaddresses, phone no's etc.

I'm definitely not in favour of adding more data to the core model, the
previous system we used (when we were still working with just Musoni
Kenya), the core client table had about 75 columns, 80% of which was empty,
just cluttering up the model and the reports. In the 45 financial
institutions we are working with, we literally have 45 different sets of
fields people like to capture, whether mandatory or not. At the same time
we also have people just using the MifosX backend for their loans, keeping
client data etc in Salesforce, and not wanting to use all this extra
clutter.

I therefore suggest we start working on some of the issues you pointed out,
instead of going the quick-and-dirty route on adding columns, which will
slowly turn into more and more being added increasing the clutter. So far I
think the issue list would be:
- Musoni contribution for entity-checks
- Improvement of batch API's
- Improve ordering and workflow management around the datatables (also
something we've worked on)

S





Sander van der Heyden

CTO Musoni Services




Mobile (NL): +31 (0)6 14239505
Skype: s.vdheyden
Website: musonisystem.com
Follow us on Twitter!  
Postal address: Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam,
The Netherlands

On Mon, Apr 11, 2016 at 1:18 PM, Binny Gopinath Sreevas <
binny.gopin...@gmail.com> wrote:

> Hi,
>
> My two cents:
>
> Some organizations expect address etc to be mandatory fields - Things I
> have been asked during implementations: do not allow a client to be created
> if details like address, nominees, KYC details (at least one client
> identifier), etc are not provided. And I have heard dismay that Mifos does
> not have a standard address field for offices and clients and hence it is
> difficult to get standard reports by region or state.
>
> If each implementation configures these as data tables - then each
> implementation will have to hard-wire such validations. Which becomes
> complicated when maintaining code. Without these validations, data quality
> suffers.
>
> I would recommend to add some common things to client (like the ones listed
> above) - and make it configurable (like Sander mentioned) - so that entire
> sections (like address, KYC, nominees etc.) can be turned on or off during
> implementation. And if turned on - then additional validations could be
> turned on or off -
> For example: if address is turned on - then at least one address should be
> entered by user - and within address, address-line-1 and postal-code would
> be mandatory for one implementation and district/province could be
> additionally made mandatory in another implementation.
>
> There are also additional things to be considered - for example: address
> structures, etc. should be common for all countries (and we shouldn't be
> adding something like Talukas which may be relevant only in an Indian
> context).
>
> I also did consider combining data tables with the main entity using batch
> APIs - so that the create-client and create-address-data-table goes
> together in one call. But the error handling here wasn't good - difficult
> to show meaningful error messages to users. And again was finding it
> difficult to get a good UI layout + validations in place when using data
> tables, without having to resort to hard-coding these on the UI.
>
> - Binny
>
>
>
> On Mon, Apr 11, 2016 at 1:04 PM, Sander van der Heyden <
> sandervanderhey...@musoni.eu> wrote:
>
> > Hi Saranash,
> >
> > I think while one set of data is needed in India, other countries will
> need
> > other sets of data, which is where the original design idea for the
> > datatables came from. Especially when also looking at the platform in a
> > broader sense and use by other types of providers, such as asset
> > financiers, P2P lenders etc.
> >
> > From my side adjusting this would be fine, as long as it is a
> post-install
> > configuration to enable/disable additional fields in the core m_client
> > table, integrated in the same way we use the datatables. But happy to
> hear
> > some other thoughts.
> >
> > S
> >
> >
> >
> > Sander van der Heyden
> >
> > CTO Musoni Services
> >
> >
> >
> >
> > Mobile (NL): +31 (0)6 14239505
> > Skype: s.vdheyden
> > Website: musonisystem.com
> > Follow us on Twitter!  
> > Postal address: Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam,
> > The 

Re: Extending the Client Data

[Binny Gopinath Sreevas]

Hi,

My two cents:

Some organizations expect address etc to be mandatory fields - Things I
have been asked during implementations: do not allow a client to be created
if details like address, nominees, KYC details (at least one client
identifier), etc are not provided. And I have heard dismay that Mifos does
not have a standard address field for offices and clients and hence it is
difficult to get standard reports by region or state.

If each implementation configures these as data tables - then each
implementation will have to hard-wire such validations. Which becomes
complicated when maintaining code. Without these validations, data quality
suffers.

I would recommend to add some common things to client (like the ones listed
above) - and make it configurable (like Sander mentioned) - so that entire
sections (like address, KYC, nominees etc.) can be turned on or off during
implementation. And if turned on - then additional validations could be
turned on or off -
For example: if address is turned on - then at least one address should be
entered by user - and within address, address-line-1 and postal-code would
be mandatory for one implementation and district/province could be
additionally made mandatory in another implementation.

There are also additional things to be considered - for example: address
structures, etc. should be common for all countries (and we shouldn't be
adding something like Talukas which may be relevant only in an Indian
context).

I also did consider combining data tables with the main entity using batch
APIs - so that the create-client and create-address-data-table goes
together in one call. But the error handling here wasn't good - difficult
to show meaningful error messages to users. And again was finding it
difficult to get a good UI layout + validations in place when using data
tables, without having to resort to hard-coding these on the UI.

- Binny



On Mon, Apr 11, 2016 at 1:04 PM, Sander van der Heyden <
sandervanderhey...@musoni.eu> wrote:

> Hi Saranash,
>
> I think while one set of data is needed in India, other countries will need
> other sets of data, which is where the original design idea for the
> datatables came from. Especially when also looking at the platform in a
> broader sense and use by other types of providers, such as asset
> financiers, P2P lenders etc.
>
> From my side adjusting this would be fine, as long as it is a post-install
> configuration to enable/disable additional fields in the core m_client
> table, integrated in the same way we use the datatables. But happy to hear
> some other thoughts.
>
> S
>
>
>
> Sander van der Heyden
>
> CTO Musoni Services
>
>
>
>
> Mobile (NL): +31 (0)6 14239505
> Skype: s.vdheyden
> Website: musonisystem.com
> Follow us on Twitter!  
> Postal address: Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam,
> The Netherlands
>
> On Fri, Apr 8, 2016 at 11:21 PM, Saransh Sharma 
> wrote:
>
> > To:Client data Added Fields
> >
> > First Question, to the PR made by anuragmath
> >
> > https://github.com/apache/incubator-fineract/pull/67
> >
> > Second Question?
> > Do we really need this?
> >
> > So what i think is
> >
> > When we collect Primary Information about the client, is only relevant,
> >
> > I don't see How fathername, emailAddress and MaritalStatus and other
> > relevant parameters are not already there in the client resource,
> >
> > Ok we can say that , We can use the dataTables approach in the fineract
> > platform but accessing that resource is easy also, its the same, but that
> > approach seems dull to me, can someone like to point why should we not
> > DataTables for these primary data pointers
> >
> > But in India we use FatherName, Religion ,MaritalStatus,Dependents, as
> well
> > where these are all primary data
> >
> > Open Discussion To Community
> >
>

Re: Extending the Client Data

[Sander van der Heyden]

Hi Saranash,

I think while one set of data is needed in India, other countries will need
other sets of data, which is where the original design idea for the
datatables came from. Especially when also looking at the platform in a
broader sense and use by other types of providers, such as asset
financiers, P2P lenders etc.

>From my side adjusting this would be fine, as long as it is a post-install
configuration to enable/disable additional fields in the core m_client
table, integrated in the same way we use the datatables. But happy to hear
some other thoughts.

S



Sander van der Heyden

CTO Musoni Services




Mobile (NL): +31 (0)6 14239505
Skype: s.vdheyden
Website: musonisystem.com
Follow us on Twitter!  
Postal address: Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam,
The Netherlands

On Fri, Apr 8, 2016 at 11:21 PM, Saransh Sharma 
wrote:

> To:Client data Added Fields
>
> First Question, to the PR made by anuragmath
>
> https://github.com/apache/incubator-fineract/pull/67
>
> Second Question?
> Do we really need this?
>
> So what i think is
>
> When we collect Primary Information about the client, is only relevant,
>
> I don't see How fathername, emailAddress and MaritalStatus and other
> relevant parameters are not already there in the client resource,
>
> Ok we can say that , We can use the dataTables approach in the fineract
> platform but accessing that resource is easy also, its the same, but that
> approach seems dull to me, can someone like to point why should we not
> DataTables for these primary data pointers
>
> But in India we use FatherName, Religion ,MaritalStatus,Dependents, as well
> where these are all primary data
>
> Open Discussion To Community
>