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