fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Saransh Sharma <sara...@theupscale.in>
Subject Re: Extending the Client Data
Date Mon, 11 Apr 2016 12:01:23 GMT
What i see is that adding validation is a must but how are we going to do,
it i mean raising an error on the DB has to be coded inside core? or is
there any other method to do, it

On Mon, Apr 11, 2016 at 5:21 PM Saransh Sharma <saransh@theupscale.in>
wrote:

> For, organisation, it will be easier that they will be able to create
> fields and validation based on the requirements, they have but then will it
> be easier integrating these things with UI
>
> On Mon, Apr 11, 2016 at 5:16 PM 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
>> > > > >
>> > > >
>> > >
>> >
>>
>

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