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 Tue, 12 Apr 2016 10:26:01 GMT
Hi Ed, Binny,

I agree with both of you that ideally some of this data does become part of
the core tables, however, even looking at 'address', I see differences
between our clients, ranging from GPS Coordinates, free-text address
description (no addresses in most slums), or complete town > region > state
approaches. So what would we then choose as the basics? And would we allow
users to extend those themselves as they see fit?

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 5:47 PM, Ed Cable <edcable@mifos.org> wrote:

> My thought FWIW, given I don't have the close perspective of the end user
> requirements like Sander and Binny do would be a blend of what Sander and
> Binny are both proposing.
>
> I agree with all the points Sander made about avoiding clutter and
> implementing the checks and improvements his team has already completed but
> I also agree with Binny that something like a client address field is
> common and fundamental across all organizations that if we drew a hard line
> at how many additional fields (i.e. just address, etc.) we add to the core
> client record, we won't stray too far down the path of excessive clutter
> that should be in data tables.
>
>
> On Mon, Apr 11, 2016 at 4:46 AM, Binny Gopinath Sreevas <
> binny.gopinath@gmail.com> wrote:
>
> > 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 <
> > sandervanderheyden@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!  <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
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
>
> --
> *Ed Cable*
> Director of Community Programs, Mifos Initiative
> edcable@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
>
> *Collectively Creating a World of 3 Billion Maries | *http://mifos.org
> <http://facebook.com/mifos>  <http://www.twitter.com/mifos>
>

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