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 <edca...@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.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> >
