Re: Extending the Client Data

[Binny Gopinath Sreevas]

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

Re: Extending the Client Data

[Sander van der Heyden]

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!  
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!  
> > Postal address: Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam,
> > The 

Re: Extending the Client Data

[Binny Gopinath Sreevas]

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!  
> Postal address: Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam,
> The Netherlands
>
> On Fri, Apr 8, 2016 at 11:21 PM, Saransh Sharma 
> 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
> >
>

[jira] [Updated] (FINERACT-137) Created parent GL account is not displaying properly in the dropdown while creating the GL Account

[subramanyasn (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

subramanyasn updated FINERACT-137:
--
Attachment: Create GL Account page.png

> Created parent GL account is not displaying properly in the dropdown while 
> creating the GL Account
> --
>
> Key: FINERACT-137
> URL: https://issues.apache.org/jira/browse/FINERACT-137
> Project: Apache Fineract
>  Issue Type: Bug
>  Components: Accounting
>Reporter: subramanyasn
>Assignee: Markus Geiss
> Attachments: Create GL Account page.png
>
>
> 1. Create a GL account for Assets and Account usage as Header.
> 2. Create a GL account for Assets, account usage as Detail and parent as 
> created above.
> 3. It is allowing to create the GL account for assets with Account usage as 
> detail. 
> > If the Header is more than 12 in entities then it is not getting displayed 
> > in the drop down under Parent while creating the GL account.
> > The Header accounts created is getting displayed under Parent dropdown for 
> > all account types. it should get filtered according to the account types. 
> > Eg. If the account type is Equity only equity related header accounts 
> > should get displayed under parent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (FINERACT-137) Created parent GL account is not displaying properly in the dropdown while creating the GL Account

[subramanyasn (JIRA)]

subramanyasn created FINERACT-137:
-

 Summary: Created parent GL account is not displaying properly in 
the dropdown while creating the GL Account
 Key: FINERACT-137
 URL: https://issues.apache.org/jira/browse/FINERACT-137
 Project: Apache Fineract
  Issue Type: Bug
  Components: Accounting
Reporter: subramanyasn
Assignee: Markus Geiss


1. Create a GL account for Assets and Account usage as Header.
2. Create a GL account for Assets, account usage as Detail and parent as 
created above.
3. It is allowing to create the GL account for assets with Account usage as 
detail. 
> If the Header is more than 12 in entities then it is not getting displayed in 
> the drop down under Parent while creating the GL account.
> The Header accounts created is getting displayed under Parent dropdown for 
> all account types. it should get filtered according to the account types. Eg. 
> If the account type is Equity only equity related header accounts should get 
> displayed under parent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Clarification on Validator Classes for Multiple Rescheduling of a Loan

[Sander van der Heyden]

Hi all,

Ignore my response, I was responding to the wrong thread, and not paying
attention, still early here I guess...

In terms of rescheduling, I think the current solution would need to be
tested very carefully before it can be considered stable (or not), and
therefore I'd recommend doing that before we merge the commit. Might also
be good to add one or 2 test cases for the multiple reschedules to ensure
that we have it covered there as well.

S


Sander van der Heyden

CTO Musoni Services




Mobile (NL): +31 (0)6 14239505
Skype: s.vdheyden
Website: musonisystem.com
Follow us on Twitter!  
Postal address: Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam,
The Netherlands

On Mon, Apr 11, 2016 at 11:17 AM, Sander van der Heyden <
sandervanderhey...@musoni.eu> wrote:

> Hi Agris,
>
> You can already do all of this by using the current datatables, where you
> can add all fields necessary to the clients data that you want to capture.
> So the update is not really a requirement to get this done, a large number
> of MFI's are already using the system with all of these fields added in.
>
> Thanks,
> Sander
>
>
> Sander van der Heyden
>
> CTO Musoni Services
>
>
>
>
> Mobile (NL): +31 (0)6 14239505
> Skype: s.vdheyden
> Website: musonisystem.com
> Follow us on Twitter!  
> Postal address: Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam,
> The Netherlands
>
> On Mon, Apr 11, 2016 at 10:58 AM, Agris Varpins <
> agris.varp...@mtgcapital.ch> wrote:
>
>> Good morning, all!
>> Thank you all for you inputs! So what is the verdict regarding this
>> update? Will it work? Or if not, can it be easily adjusted and perfected so
>> that it does? I cannot overstate hot important this fix is for us and we
>> are really looking to solve this issue as soon as possible,
>> Looking forward to you feedback.
>> Best regards,
>> Agris
>>
>> On Mon, Apr 11, 2016 at 9:09 AM, Sander van der Heyden <
>> sandervanderhey...@musoni.eu> wrote:
>>
>>> Hi all
>>>
>>> The main reason we put in the restrictions around allowing only one
>>> reschedule, was to also enable users to undo them easily if they were made
>>> by mistake. I think that is something that can be solved, but would require
>>> a bit of extra work ensuring that the correct old schedules are grabbed and
>>> reapplied to the loan.
>>>
>>> S
>>>
>>>
>>> Sander van der Heyden
>>>
>>> CTO Musoni Services
>>>
>>>
>>>
>>>
>>> Mobile (NL): +31 (0)6 14239505
>>> Skype: s.vdheyden
>>> Website: musonisystem.com
>>> Follow us on Twitter!  
>>> Postal address: Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam,
>>> The Netherlands
>>>
>>> On Fri, Apr 8, 2016 at 5:46 PM, Ed Cable  wrote:
>>>
 Sander, have you had a chance to review this thread?

 Andris' team is in need of this feature and wanted to get feedback on
 the approach they've taken to see if they can continue with that or they
 need to follow the path that was proposed by Pramod.

 Ed

 On Wed, Apr 6, 2016 at 9:38 AM, Ed Cable  wrote:

> Zack and Robert have been working on contributing a fix to add the
> ability to reschedule a loan multiple times.
>
> They have taken a different approach than what Pramod had previously
> outlined so we wanted to discuss their proposed fix with Sander and his
> team who have provided the initial fix to reschedule a loan a single time.
>
> Ed
>
> On Mon, Apr 4, 2016 at 9:32 PM, Adi Raju <
> adi.r...@confluxtechnologies.com
> 
> > wrote:
>
>> Hi Robert,
>>
>>
>>
>> Validator classes generally only perform API parameter validations,
>> in other words they are the first check point before proceeding to more
>> costlier DB or calculation tasks.
>>
>> All that is done in this change is that the validation at the first
>> check point is removed.
>>
>> These checkpoints were added by earlier developers because they
>> haven’t addressed those scenarios in further calculations.
>>
>> If the core code works for multi-reschedule, they wouldn’t have put
>> this check in the first place.
>>
>>
>>
>> I really doubt this solution is working as it is supposed to be. Have
>> you been able to test it against expected schedule and its values post
>> reschedule action? Does other like retrieve/approve/reject reschedule 
>> APIs
>> work with this solution?
>>
>>
>>
>> +Sander, who can help us with more clarifications on why such
>> validations were added.
>>
>>
>>
>> Regards,
>>
>> Adi
>>
>>
>>
>>
>>
>> *From:* robert wizglobal [mailto:rob...@wizglobal.co.ke
>> 

[jira] [Commented] (FINERACT-33) % on Interest Charge for Savings

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/FINERACT-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15234783#comment-15234783
 ] 

ASF GitHub Bot commented on FINERACT-33:


GitHub user pramodn02 opened a pull request:

https://github.com/apache/incubator-fineract/pull/69

FINERACT-33 : savings withhold tax changes



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/pramodn02/incubator-fineract FINERACT-33

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-fineract/pull/69.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #69


commit 3015747f3d0ddce9287035ccba6609f497865eaf
Author: pramod 
Date:   2016-04-11T09:14:59Z

FINERACT-33 : savings withhold tax changes




> % on Interest Charge for Savings
> 
>
> Key: FINERACT-33
> URL: https://issues.apache.org/jira/browse/FINERACT-33
> Project: Apache Fineract
>  Issue Type: Improvement
>  Components: Charges, Savings
>Reporter: Dayna Harp
>Assignee: Markus Geiss
>
> EPIC: https://mifosforge.jira.com/browse/MIFOSX-2423
> BACKGROUND: https://mifosforge.jira.com/browse/MIFOSX-1886
> BACKGROUND: https://mifosforge.jira.com/browse/MIFOSX-1342
> Currently in the application we don't have option to add "Charge calculation" 
> as % interest for savings charges. 
> Eg. If 1 is the balance in savings account and interest posted is 1000, 
> then let us say collect 1% as tax from the interest (then it is 10). 
> > While creating the savings charge it self the Charge calculation dropdown 
> > should be displayed with %interest. and that charge should be allowed to 
> > utilize in the account also.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] incubator-fineract pull request: FINERACT-33 : savings withhold ta...

[pramodn02]

GitHub user pramodn02 opened a pull request:

https://github.com/apache/incubator-fineract/pull/69

FINERACT-33 : savings withhold tax changes



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/pramodn02/incubator-fineract FINERACT-33

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-fineract/pull/69.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #69


commit 3015747f3d0ddce9287035ccba6609f497865eaf
Author: pramod 
Date:   2016-04-11T09:14:59Z

FINERACT-33 : savings withhold tax changes




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Clarification on Validator Classes for Multiple Rescheduling of a Loan

[Sander van der Heyden]

Hi Agris,

You can already do all of this by using the current datatables, where you
can add all fields necessary to the clients data that you want to capture.
So the update is not really a requirement to get this done, a large number
of MFI's are already using the system with all of these fields added in.

Thanks,
Sander


Sander van der Heyden

CTO Musoni Services




Mobile (NL): +31 (0)6 14239505
Skype: s.vdheyden
Website: musonisystem.com
Follow us on Twitter!  
Postal address: Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam,
The Netherlands

On Mon, Apr 11, 2016 at 10:58 AM, Agris Varpins  wrote:

> Good morning, all!
> Thank you all for you inputs! So what is the verdict regarding this
> update? Will it work? Or if not, can it be easily adjusted and perfected so
> that it does? I cannot overstate hot important this fix is for us and we
> are really looking to solve this issue as soon as possible,
> Looking forward to you feedback.
> Best regards,
> Agris
>
> On Mon, Apr 11, 2016 at 9:09 AM, Sander van der Heyden <
> sandervanderhey...@musoni.eu> wrote:
>
>> Hi all
>>
>> The main reason we put in the restrictions around allowing only one
>> reschedule, was to also enable users to undo them easily if they were made
>> by mistake. I think that is something that can be solved, but would require
>> a bit of extra work ensuring that the correct old schedules are grabbed and
>> reapplied to the loan.
>>
>> S
>>
>>
>> Sander van der Heyden
>>
>> CTO Musoni Services
>>
>>
>>
>>
>> Mobile (NL): +31 (0)6 14239505
>> Skype: s.vdheyden
>> Website: musonisystem.com
>> Follow us on Twitter!  
>> Postal address: Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam,
>> The Netherlands
>>
>> On Fri, Apr 8, 2016 at 5:46 PM, Ed Cable  wrote:
>>
>>> Sander, have you had a chance to review this thread?
>>>
>>> Andris' team is in need of this feature and wanted to get feedback on
>>> the approach they've taken to see if they can continue with that or they
>>> need to follow the path that was proposed by Pramod.
>>>
>>> Ed
>>>
>>> On Wed, Apr 6, 2016 at 9:38 AM, Ed Cable  wrote:
>>>
 Zack and Robert have been working on contributing a fix to add the
 ability to reschedule a loan multiple times.

 They have taken a different approach than what Pramod had previously
 outlined so we wanted to discuss their proposed fix with Sander and his
 team who have provided the initial fix to reschedule a loan a single time.

 Ed

 On Mon, Apr 4, 2016 at 9:32 PM, Adi Raju <
 adi.r...@confluxtechnologies.com
 
 > wrote:

> Hi Robert,
>
>
>
> Validator classes generally only perform API parameter validations, in
> other words they are the first check point before proceeding to more
> costlier DB or calculation tasks.
>
> All that is done in this change is that the validation at the first
> check point is removed.
>
> These checkpoints were added by earlier developers because they
> haven’t addressed those scenarios in further calculations.
>
> If the core code works for multi-reschedule, they wouldn’t have put
> this check in the first place.
>
>
>
> I really doubt this solution is working as it is supposed to be. Have
> you been able to test it against expected schedule and its values post
> reschedule action? Does other like retrieve/approve/reject reschedule APIs
> work with this solution?
>
>
>
> +Sander, who can help us with more clarifications on why such
> validations were added.
>
>
>
> Regards,
>
> Adi
>
>
>
>
>
> *From:* robert wizglobal [mailto:rob...@wizglobal.co.ke
> ]
>
> *Sent:* 04 April 2016 22:13
> *To:* Adi Raju  
> >
> *Cc:* Zack Wizglobal  >;
> Ed Cable  >;
> pra...@confluxtechnologies.com
> ;
> Agris Varpins  

[GitHub] incubator-fineract pull request: MIFOSX-2405

[samridhigupta]

GitHub user samridhigupta opened a pull request:

https://github.com/apache/incubator-fineract/pull/68

MIFOSX-2405

modified rest calls to save and fetch status of client identifiers. Added 
ability to mark Client Identifier as Active or Inactive. 
Modified table, added new columns and changed constraints.
To complete the story MIFOSX-2405 another pull request is created for 
community app.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/samridhigupta/incubator-fineract develop

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-fineract/pull/68.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #68


commit abc529056372039aa264ba11dc65411323c9227c
Author: guptas9 
Date:   2016-04-11T08:12:52Z

added licence headers

commit d6668d2e896061ad05cb1ef603af7f5295d3019e
Author: guptas9 
Date:   2016-04-11T08:13:44Z

MIFOSX-2405 : modified rest calls to save and fetch status of client 
identifiers. Added ability to mark Client Identifier as Active or Inactive




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Extending the Client Data

[Sander van der Heyden]

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!  
Postal address: Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam,
The Netherlands

On Fri, Apr 8, 2016 at 11:21 PM, Saransh Sharma 
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
>