fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Binny Gopinath Sreevas <binny.gopin...@gmail.com>
Subject Re: Extending the Client Data
Date Mon, 11 Apr 2016 11:18:01 GMT
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