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.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 > > > > > > > > > > > > > > > -- *Ed Cable* Director of Community Programs, Mifos Initiative edca...@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>
