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 > > > > > > > > > >
