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 <sara...@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.gopin...@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 < >> 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! <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.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! <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 < >> sara...@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 >> > > > > >> > > > >> > > >> > >> >
