fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sander van der Heyden <sandervanderhey...@musoni.eu>
Subject Re: Extending the Client Data
Date Mon, 11 Apr 2016 11:26:11 GMT
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!  <https://twitter.com/musonimfi>
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.gopinath@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 <
> sandervanderheyden@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!  <https://twitter.com/musonimfi>
> > Postal address: Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam,
> > The Netherlands
> >
> > On Fri, Apr 8, 2016 at 11:21 PM, Saransh Sharma <saransh@theupscale.in>
> > 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
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message