Re: [Mifos-developer] Portfolio at Risk

[Sander van der Heyden]

Hi Zayyad,

Ah now I get you, you are completely right, that's indeed a bug then.

Sander



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 10 March 2017 at 14:20, Zayyyad A. Said <zay...@intrasofttechnologies.com
> wrote:

> Hi Sander,
>
>
>
> The definition given by CGAP and what I had actually put across means the
> same thing.
>
>
>
> Here is your definition of PAR:
>
> Portfolio at risk. The value of all loans outstanding that have one or
> more installments of principal past due more than a certain number of days.
>
>
>
> Here is my explanation of PAR:
>
> PAR is how much does the MFI stand to lose if all delinquent clients
> completely default and thus its calculated by taking sum of all unpaid
> balance for loan with past due repayments divided by total outstanding
> balance.
>
>
>
> By using the statement how much the MFI stand to lose, am referring to the
> actual principal amount at risk of being lost if the loans with any
> instalment past due is defaulted and not any income.
>
>
>
> Lets look at the below example:
>
>
>
> Disbursed Amount of MFI: 10,000,000/=
>
> Principal in Arrears: 50,000/=
>
> No. of Loans in Arrears: 25
>
> Outstanding Principal for the 25 Loans in Arrears: 200,000/=
>
> Outstanding Principal for all Loans: 5,000,000/=
>
>
>
> The PAR here will be calculated by taking 200,000/= divide it by
> 5,000,000/= which should give you 4%.
>
>
>
> The calculation of PAR in the reports currently is done as Principal in
> Arrears / Outstanding Principal which if you use the example above the
> calculation will be like 50,000 / 5,000,000 which will give you 1%.
>
>
>
> I believe this helps you understand the issue I was trying to raise.
>
>
>
> Regards;
>
>
>
> ***
>
> Zayyad A. Said | Chairman & C.E.O
>
>
>
> Cell No.: +254 716 615274 | Skype: zsaid2011
>
> Email: zay...@intrasofttechnologies.com
>
>
>
>
>
>
>
> -Original Message-
> From: Sander van der Heyden [mailto:sandervanderhey...@musonisystem.com]
> Sent: 10 March 2017 04:00 PM
> To: Mifos software development <mifos-develo...@lists.sourceforge.net>
> Cc: dev@fineract.incubator.apache.org
> Subject: Re: [Mifos-developer] Portfolio at Risk
>
>
>
> Hi Zayyad,
>
>
>
> Sorry to jump in here, but this is not a bug or problem, or indeed a
> definition mismatch. The definition used by CGAP (and every MFI and funder
> we've worked with so far):
>
>
>
> Portfolio at risk. The value of all loans outstanding that have one or
> more installments of principal past due more than a certain number of days.
> *This item includes the entire unpaid principal balance, including both
> past-due and future install- ments, but not accrued interest*. It also does
> not include loans that have been restructured or rescheduled.
>
> Source: B3 in this document:
>
>  <https://www.cgap.org/sites/default/files/CGAP-Consensus-
> Guidelines-Definitions-of-Selected-Financial-Terms-
> Ratios-and-Adjustments-for-Microfinance-Sep-2003.pdf>
> https://www.cgap.org/sites/default/files/CGAP-Consensus-
> Guidelines-Definitions-of-Selected-Financial-Terms-
> Ratios-and-Adjustments-for-Microfinance-Sep-2003.pdf
>
>
>
> This is the most widely accepted definition of PAR with just principal
> overdue as percentage of principal outstanding, as the MFI doesn't "lose"
>
> any income it has not actually earned yet. So it is also in line with what
> you've stated above:"how much does the MFI stand to lose if all delinquent
> clients completely default".
>
>
>
> Thanks,
>
> Sandfer
>
>
>
>
>
>
>
> 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>
> https://twitter.com/musonimfi> Postal address: Hillegomstraat 12-14,
> office 0.09, 1058 LS, Amsterdam, The Netherlands
>
>
>
> On 10 March 2017 at 13:45, Zayyyad A. Said <zayyad@intrasofttechnologies.
> com
>
> > wrote:
>
>
>
> > I need Total Outstanding Balance for Loans in Arrears.
>
> >
>
> >
>
> >
>
> >
>
> > ***
>
> > Zayyad A. Said | Chairman & C.E.O
>
> >
>
> > Cell No.: +254 716 

Re: [Mifos-developer] Portfolio at Risk

[Sander van der Heyden]

Hi Zayyad,

Sorry to jump in here, but this is not a bug or problem, or indeed a
definition mismatch. The definition used by CGAP (and every MFI and funder
we've worked with so far):

Portfolio at risk. The value of all loans outstanding that have one or more
installments of principal past due more than a certain number of days. *This
item includes the entire unpaid principal balance, including both past-due
and future install- ments, but not accrued interest*. It also does not
include loans that have been restructured or rescheduled.
Source: B3 in this document:
https://www.cgap.org/sites/default/files/CGAP-Consensus-Guidelines-Definitions-of-Selected-Financial-Terms-Ratios-and-Adjustments-for-Microfinance-Sep-2003.pdf

This is the most widely accepted definition of PAR with just principal
overdue as percentage of principal outstanding, as the MFI doesn't "lose"
any income it has not actually earned yet. So it is also in line with what
you've stated above:"how much does the MFI stand to lose if all delinquent
clients completely default".

Thanks,
Sandfer



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 10 March 2017 at 13:45, Zayyyad A. Said <zay...@intrasofttechnologies.com
> wrote:

> I need Total Outstanding Balance for Loans in Arrears.
>
>
>
>
> ***
> Zayyad A. Said | Chairman & C.E.O
>
> Cell No.: +254 716 615274 | Skype: zsaid2011
> Email: zay...@intrasofttechnologies.com
>
>
>
> -Original Message-
> From: Sampath Kumar G [mailto:samp...@confluxtechnologies.com]
> Sent: 10 March 2017 01:44 PM
> To: dev@fineract.incubator.apache.org
> Cc: Mifos software development <mifos-develo...@lists.sourceforge.net>
> Subject: Re: Portfolio at Risk
>
> Hi Zayyad,
>
> For loan balance arrears, do you need total arrears or only the principal
> arrears amount?
>
> Thanks and regards,
> Sampath
>
>
> ​
> *Conflux Technologies Pvt Ltd <http://www.confluxtechnologies.com/> *
>
> #304, 2nd Floor, 7th Main Road
>
> HRBR Layout 1st Block
>
> Bengaluru, Karnataka, 560043 INDIA
>
>
> Disclaimer: The information contained in this e-mail message and any
> files/attachment transmitted with it is confidential and for the sole use
> of the intended recipient(s) or entity identified. If you are not the
> intended recipient, please email: supp...@confluxtechnologies.com and
> destroy/delete all copies and attachment thereto along with the original
> message. Any unauthorised review, use, disclosure, dissemination,
> forwarding, printing or copying of this email or any action taken in
> reliance on this e-mail is strictly prohibited and is unlawful. The
> recipient acknowledges that Conflux Technologies Private Limited or its
> subsidiaries and associated companies are unable to exercise control or
> ensure or guarantee the integrity of/over the contents of the information
> contained in e-mail transmissions. Before opening any attachments, please
> check.
>
> On Fri, Mar 10, 2017 at 2:59 PM, Zayyyad A. Said <
> zay...@intrasofttechnologies.com> wrote:
>
> >
> >
> > Devs,
> >
> >
> >
> > I have noted that the reports showing Portfolio at Risk % are not
> > really reporting the right PAR but Arrears Rate.
> >
> >
> >
> > There is a difference between the two:
> >
> >
> >
> > PAR is how much does the MFI stand to lose if all delinquent clients
> > completely default and thus its calculated by taking sum of all unpaid
> > balance for loan with past due repayments divided by total outstanding
> > balance.
> >
> >
> >
> > Arrears rate determine what percentage of the portfolio is overdue and
> > this is simple principal overdue divided by principal outstanding
> > (what the reports are currently reporting as PAR now).
> >
> >
> >
> > I would like to add “Loan Balance in Arrears” in the below code, could
> > someone please guide me on how I can do that?
> >
> >
> >
> > *select* *concat*(*repeat*("..",
> >
> > ((*LENGTH*(mo.`hierarchy`) - *LENGTH*(*REPLACE*(mo.`hierarchy`, '.',
> > ''))
> > - 1))), mo.`name`) *as* "Office/Branch", *x*.currency *as* Currency,
> >
> > *x*.client_count *as* "No. of Clients", *x*.active_loan_count *as* "No.
> > Active Loans", *x*. loans_in_arrears_count *as* "No. of Loans in
> > Arrears",
> >
> > *x*.principal *as* "Total Loans Disbursed"

Re: Please help evaluate Fineract's readiness for graduation

[Sander van der Heyden]

Hi Myrle,

Looks like a plan! Have added my name back to the Maturity Evaluation, and
also agree to the Graduation resolution so far, and obviously would very
much like to see you as the chair of the PMC!

Thanks for taking lead on this!
Sander



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 15 February 2017 at 17:20, Myrle Krantz <myrle.kra...@kuelap.io> wrote:

> Hello Fineracters,
>
> I believe we've made enough progress to start the process of graduation.
>
> Because I believe that we are ready for graduation, I've created a draft
> "Graduation Resolution"
>
>
> https://cwiki.apache.org/confluence/display/FINERACT/Graduation+Resolution
>
> Please review especially the following points:
> * the proposed list of initial members, (I want verification from *every*
> *initial* *member*)
> * their associations, and
> * the proposed chair of the PMC. (Myrle Krantz)
>
> I've adjusted the Maturity Evaluation.  Anywhere that I changed the
> estimation of maturity, I removed people's approval, so please check me and
> add your name back if you agree with the changed evaluation.  When you're
> looking at the maturity evaluation, you'll see that we aren't perfect.  I
> do not believe the incubator provides us value in addressing the remaining
> issues, so I'm not treating them as blockers for graduation.
>
> https://cwiki.apache.org/confluence/display/FINERACT/Maturity+Evaluation
>
> Once changes and discussions have settled down, and once we have a final
> list of initial members, I will call a vote on submitting our graduation to
> the incubator.  My goal is that our graduation resolution be submitted to
> the ASF board by the March board meeting.
>
> Greets,
> Myrle
>
>
> On Wed, Feb 15, 2017 at 1:32 AM, Ed Cable <edca...@mifos.org> wrote:
>
> > Just doing a check-in as to where we stand.
> >
> > Nazeer has been addressing some of the outstanding points and has
> recently
> > posted some additional release management documentation which can be
> viewed
> > at https://cwiki.apache.org/confluence/pages/viewpage.
> > action?pageId=67640333
> >
> > I have pushed the changes to the Apache Fineract website github repo and
> > these have been merged the but the website is not reflecting the edits I
> > made.
> >
> > Nazeer has requested feedback on the Findbugs Implementation he has ready
> > go go.
> >
> > 2 active threads are being discussed related to security and backwards
> > compatibility.
> >
> > We are also evaluating a couple additional committers and will soon be
> > ready to call for graduation if our mentors too fee we are ready.
> >
> > Ed
> >
> >
> >
> > On Fri, Jan 27, 2017 at 10:14 AM, Jim Jagielski <j...@jagunet.com> wrote:
> >
> > > Makes sense.
> > > > On Jan 25, 2017, at 10:52 PM, Shaik Nazeer <nazeer.shaik@
> > > confluxtechnologies.com> wrote:
> > > >
> > > > Instead of modifying Fineract website on every Fineract releases, can
> > we
> > > link required details to Fineract wiki pages?
> > > > For example latest release details can be found at
> > > https://cwiki.apache.org/confluence/display/FINERACT/Release+Folders
> > > >
> > > > Thanks,
> > > > Nazeer
> > > > -Original Message-
> > > > From: Markus Geiß [mailto:mge...@mifos.org]
> > > > Sent: 26 January 2017 01:55
> > > > To: Ed Cable
> > > > Cc: dev (dev@fineract.incubator.apache.org)
> > > > Subject: Re: Please help evaluation Fineract's readiness for
> graduation
> > > >
> > > > Hey Ed,
> > > >
> > > > the Apache Fineract website is a github repo you'll find at Apache's
> > > github mirror.
> > > >
> > > > Simply fork it, create a new branch, do the needed changes and send a
> > PR.
> > > >
> > > > Best wishes,
> > > >
> > > > Markus Geiss
> > > > Chief Architect
> > > > RɅĐɅЯ, The Mifos Initiative
> > > >
> > > > On Jan 24, 2017 15:58, "Ed Cable" <edca...@mifos.org> wrote:
> > > >
> > > >> Markus,
> > > >>
> > > >> Nazeer is continuing to work on addressing the areas of concern
> > > >> related to QU10, QU40, and RE50.
> > > >>
&g

Re: Discussion of Backwards Compatibility for Apache Fineract Maturity Evaluation

[Sander van der Heyden]

Hi Ed,

I think all devs already know this, but it basically comes down to the way
new functionality is introduced in the API, in the current way we add
mandatory parameters, or make them dependent on each other between
versions. If a user then upgrades and tries to just run the same API calls
he or she will get errors thrown back. This is where one would normally
ensure new params are non mandatory and always complementary to previous
functionality instead of mandatory. This is a bit of extra work and
therefore frequently skipped.

The other alternative is the api versioning we have but have not actually
implemented in any way, where you could create a v1.1 or something similar
of the API that contains the 'breaking' calls, users ready to switch or in
need of the new feature use it, others stick on the other one.

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!  <https://twitter.com/musonimfi>
Postal address: Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam,
The Netherlands

On 12 January 2017 at 20:16, Ed Cable <edca...@mifos.org> wrote:

> Hi all,
>
> I"m going to start a couple different threads so we can gather additional
> feedback and discuss how we can improve on some of the areas of our Apache
> Fineract evaluation.
>
> In this thread I wanted to discuss backwards compatibility.
>
> Criteria for QU40: *The project puts a high priority on backwards
> compatibility and aims to document any incompatible changes and provide
> tools and documentation to help users transition to new features.*
>
> Sander's Evaluation: Insufficient, while we have structures in place that
> would support versioning of API's etc this has not been done at all, and as
> such backwards compatibility is not great, this is also not helped by not
> clearly stating which breaking changes are part of a given release.
>
> Sander, could you elaborate with more specifics so that Nazeer, Adi and
> others can identify how these concerns can be addressed.
>
> Ed
>
>
>
> --
> *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>
>

Re: Please help evaluation Fineract's readiness for graduation

[Sander van der Heyden]

Hi Myrle,

Thanks for doing the first round of this, I've added my name to a lot of
your evaluations and extended a few as well. I've still left a few blank,
as I am not 100% clear on them and would therefore prefer to wait for a few
more opinions on them.

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!  <https://twitter.com/musonimfi>
Postal address: Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam,
The Netherlands

On 3 January 2017 at 12:21, Myrle Krantz <mkra...@mifos.org> wrote:

> Hi all,
>
> Apache has a project maturity model which can be used to evaluate readiness
> for graduation.  It's a guide rather then a set of requirements, but I
> believe we can use it.  I've used it to create a page evaluating *our*
> readiness:
>
> https://cwiki.apache.org/confluence/display/FINERACT/Maturity+Evaluation
>
> The evaluation is not finished.  Apache Fineract needs the following from
> you:
> * Evaluate the criteria which I did not evaluate.  I've highlighted them in
> blue.
> * Check the evaluation of the criteria which already have one.  If your
> evaluation differs, document your disagreement. If you agree with the
> evaluation, add your committer id.
> * On those criteria in which Apache Fineract still has work to do before
> graduation (highlighted in red), check if you can do that work.  I've left
> at least one low-hanging fruit in there.  Who will find it first?
> * If you feel we need to add a criteria, add it, and explain why.
>
> Once we have met all criteria, we should propose ourselves for graduation.
>
> Looking at our current state, we've made tremendous progress since we
> entered incubation in December 2015, and I'd like us to make the push for
> those last few bits in 2017.  I believe that, if we as a community wish to,
> we can achieve this in the first quarter of this year.
>
> Greets,
> Myrle
>
>
>
> *Myrle Krantz*
> Solutions Architect
> RɅĐɅЯ, The Mifos Initiative
> mkra...@mifos.org | Skype: mkrantz.mifos.org | http://mifos.org
> <http://facebook.com/mifos>  <http://www.twitter.com/mifos>
>

Re: Issues in interest recalculation

[Sander van der Heyden]

Hi Adi,

Thanks for your feedback, but not sure whether we can make this calculation
work, see attached excel using the same logic. It works fine for working
out instalment one, but does leave us with a 0.4 difference on the second
instalment compared to today's schedule. Could you let me know where we are
going wrong, or whether this is actually a bug?

Thanks,
Sander



On 12 December 2016 at 06:20, Adi Raju <adi.r...@confluxtechnologies.com>
wrote:

> Interest calculation on future dates will be based on the assumption that
> payment has been made up-to-date and assuming no arrears.
> Interest on the unpaid or compounded amount will be calculated and
> provided as part of schedule only till as of that day.
>
> So in the example,
> EMI is due on 1st  Dec and 2nd Jan. No repayment is made as of today
> (12/12).
> So interest calculation will be as follows:
> Interest on compounded amount as of 1 Dec for 11 days (1st to 12th of dec)
> Plus
> Interest on amount as per original schedule for 21 days (13th dec to 2nd
> of jan)
>
> As and when interest recalculation job runs every day, interest will be
> revised to include calculations as of that day.
>
> Regards,
> Adi Raju
>
> Principal Architect, Conflux Technologies Pvt Ltd
> Address: #304, 2nd Floor, 7th Main Road, HRBR Layout 1st Block, Bengaluru,
> Karnataka, 560043 INDIA
>
>
> Disclaimer: The information contained in this e-mail message and any
> files/attachment transmitted with it is confidential and for the sole use
> of the intended recipient(s) or entity identified. If you are not the
> intended recipient, please email: supp...@confluxtechnologies.com and
> destroy/delete all copies and attachment thereto along with the original
> message. Any unauthorised review, use, disclosure, dissemination,
> forwarding, printing or copying of this email or any action taken in
> reliance on this e-mail is strictly prohibited and is unlawful. The
> recipient acknowledges that Conflux Technologies Private Limited or its
> subsidiaries and associated companies are unable to exercise control or
> ensure or guarantee the integrity of/over the contents of the information
> contained in e-mail transmissions. Before opening any attachments, please
> check.
>
>
>
> -Original Message-
> From: Sander van der Heyden [mailto:sandervanderhey...@musonisystem.com]
> Sent: 09 December 2016 22:08
> To: dev@fineract.incubator.apache.org
> Cc: A good place to start for users or folks new to Mifos.
> Subject: Re: Issues in interest recalculation
>
> Hi Adi,
>
> Thanks for your feedback, makes sense on the early payments and I agree
> the duplicate instalments is a bug. Looks like the holiday/workingdays
> config is ignored for that bit. However I think we'll indeed need to
> introduce this in the payment schedules as well. In addition I found
> another strange scenario which is: https://demo.openmf.org/#/
> viewloanaccount/321
>
> Can you explain to me how the calculation for the interest for the 2nd
> instalment is made, so the first instalment which was due 8 days ago is now
> overdue by 8 days and interest (should have) compounded as well. However I
> cannot work out the formula used to get to that amount of interest, when
> running the same example for a loan just 1 day overdue, I was able to work
> out the amount, but only as long as I calculated 2 extra days. Is there any
> docs on this on the wiki (I could not spot them).
>
> 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!  <https://twitter.com/musonimfi> Postal address:
> Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam, The Netherlands
>
> On 8 December 2016 at 06:23, Adi Raju <adi.r...@confluxtechnologies.com>
> wrote:
>
> > Hi Sander
> >
> > PSB
> >
> > Regards,
> > Adi Raju
> >
> > Principal Architect, Conflux Technologies Pvt Ltd
> > Address: #304, 2nd Floor, 7th Main Road, HRBR Layout 1st Block,
> > Bengaluru, Karnataka, 560043 INDIA
> >
> >
> > Disclaimer: The information contained in this e-mail message and any
> > files/attachment transmitted with it is confidential and for the sole
> > use of the intended recipient(s) or entity identified. If you are not
> > the intended recipient, please email: supp...@confluxtechnologies.com
> > and destroy/delete all copies and attachment thereto along with the
> > original message. Any unauthorised review, use, disclosure,
> > dissemination, forwarding, printing or copying of this email or any
> > action taken in reliance on this e-mail 

Re: Issues in interest recalculation

[Sander van der Heyden]

Hi Adi,

Thanks for your feedback. I already left some test cases on the demo (but
have updated the same product in between so you'll need to check the
derived data for these). I'll work on some more cases that we've seen
locally tomorrow, but these are the ones that were already there.


*Incorrect interest in Loan Schedule for first instalment when making an
early payment*
See https://demo.openmf.org/#/viewloanaccount/302, where you see 3.85 of
interest paid on the summary and loan transactions, yet the 3.85 is still
due on the instalment and if you look at the schedule via the API is
reported as outstanding interest (which the transaction has already paid).


*Interest recalculation causes incorrect schedule with
duplicate instalments*
For the daily loans with duplicate instalments see:
https://demo.openmf.org/#/viewloanaccount/304, where you can see that 2
payments fall due on the same day. If you undo disburse the loan and
preview the schedule before disbursement you'll not see duplicate payments
on the same day.

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!  <https://twitter.com/musonimfi>
Postal address: Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam,
The Netherlands

On 7 December 2016 at 11:20, Adi Raju <adi.r...@confluxtechnologies.com>
wrote:

> Hi Sander,
>
> Interest recalculation is allowed only when "Calculate interest for exact
> days in partial period" is enabled in product definition.
> Consider the scenario: holidays calendar is empty, all days are considered
> working days and payments are always on time, you will see the interest
> applied equally with interest rate 1% considering 12%pa interest with
> monthly payment period.
>
> In case there is any date difference due to holidays/working days
> consideration or early payments etc, the calculation happens as follows:
> Assume installment is falling on 1st Feb, but due to holiday the
> installment is postponed to 2nd Feb and consider 12%pa interest rate.
> Interest for the whole month of Jan is calculated at 1% and interest for
> the 1 additional day in Feb is calculated as 1%*(1/28).
> For the installment on 1st Mar, interest is calculated as 1%*(27/28) would
> be used.
> This is how the current interest recalculation happens to make sure the
> interest is collected for each and every day.
> And partial interest for any day is calculated based on the number of days
> in the loan installment period.
>
> I am unable to reproduce other issues that you have mentioned. Looks like
> they are linked to some other factors as well. If you can reproduce them on
> demo.openmf.org and provide with loan ids or relevant details, we can get
> back with clarifications or verify if it is really a bug.
>
> Regards,
> Adi Raju
>
> Principal Architect, Conflux Technologies Pvt Ltd
> Address: #304, 2nd Floor, 7th Main Road, HRBR Layout 1st Block, Bengaluru,
> Karnataka, 560043 INDIA
>
>
> Disclaimer: The information contained in this e-mail message and any
> files/attachment transmitted with it is confidential and for the sole use
> of the intended recipient(s) or entity identified. If you are not the
> intended recipient, please email: supp...@confluxtechnologies.com and
> destroy/delete all copies and attachment thereto along with the original
> message. Any unauthorised review, use, disclosure, dissemination,
> forwarding, printing or copying of this email or any action taken in
> reliance on this e-mail is strictly prohibited and is unlawful. The
> recipient acknowledges that Conflux Technologies Private Limited or its
> subsidiaries and associated companies are unable to exercise control or
> ensure or guarantee the integrity of/over the contents of the information
> contained in e-mail transmissions. Before opening any attachments, please
> check.
>
>
>
>
> -Original Message-
> From: Sander van der Heyden [mailto:sandervanderhey...@musonisystem.com]
> Sent: 05 December 2016 17:06
> To: dev@fineract.incubator.apache.org; A good place to start for users or
> folks new to Mifos.
> Subject: Issues in interest recalculation
>
> Hi All,
>
> We've been doing a relatively extensive round of testing on interest
> recalculation loans and found the following issues (on demo.openmf.org).
> All of the cases below have:
> - Interest recalculation on
> - Interest calculation = same as repayment period
> - Amortization set to Equal instalments
> - Advance payments set to Reduce EMI Amount
> - No grace periods
> - No sliding interest rates, or multi-disbursements
> - No fixed EMI amounts
>
> I've not yet created JIRA items on it, because I was wondering whether
> other people had seen th

Re: Business Event Processor

[Sander van der Heyden]

Hi guys,

+1 on all of Markus' points. I do think there is a real need to deal with
synchronous events in a better way especially as the current
implementations are diverse and indeed do not take (sufficient) advantages
of re-using data already available and go back to querying the DB.

On Data Driven Authorization, I feel it's indeed one of those topics where
everyone seems to have a different picture of what we are trying to
achieve. From my side I think the current break-up between branches and
assigning users and roles to that is already quite a good way of doing it,
it's just been implemented in a lazy way with many steps skipped in
reports, but also in various API calls.

When it comes to role-based authorisation on loan amounts etc, I think the
current credit checks feature we use is already a nice step forward, if you
were to replace that by using Spring Expressions instead of SQL you could
already achieve a lot of this in a very customisable way without completely
overhauling the entire authorisation logic. Similar things can apply to
savings products, this would then leave approving of clients etc, which I
think is much less of an issue, mainly as you can still verify a lot of
these before you actually take deposits or provide funds to the customer.

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 7 December 2016 at 09:18, Markus Geiß <markus.ge...@live.de> wrote:

> Hey Adi,
>
> thanks for the reply. ; o)
>
> Triggering SMS or sending notifications are features that should happen
> asynchronous, because they are executed after a business logic was
> successfully executed. For validation we may should think about utilizing
> what the Spring framework has to offer instead of implementing it ourselves.
>
> We may should try to find consensus on Data Driven Authorization within
> the community, given the configuration is usually very complex and the real
> benefit is questionable.
>
> Cheers
>
> Markus
>
> -Original Message-
> From: Adi Raju [mailto:adi.r...@confluxtechnologies.com]
> Sent: Wednesday, December 7, 2016 05:59 AM
> To: dev@fineract.incubator.apache.org
> Subject: RE: Business Event Processor
>
> Hi Markus,
>
> This proposal is mainly intended to help any synchronous processing
> requirements.
> For eg, In case of validation failure the API(command) should fail.
> I do not see ActiveMQ of help here.
>
> Data Driven Authorisation as such is bigger feature umbrella, in that we
> want to control data visibility even in the read APIs based on different
> business rules.
> In the example provided, "Data Driven Authorisation" was a simple
> validation feature request, which requires allowing an API based on role
> and not just permission assigned to the App User.
>
> Regards,
> Adi Raju
>
> Principal Architect, Conflux Technologies Pvt Ltd
> Address: #304, 2nd Floor, 7th Main Road, HRBR Layout 1st Block, Bengaluru,
> Karnataka, 560043 INDIA
>
>
> Disclaimer: The information contained in this e-mail message and any
> files/attachment transmitted with it is confidential and for the sole use
> of the intended recipient(s) or entity identified. If you are not the
> intended recipient, please email: supp...@confluxtechnologies.com and
> destroy/delete all copies and attachment thereto along with the original
> message. Any unauthorised review, use, disclosure, dissemination,
> forwarding, printing or copying of this email or any action taken in
> reliance on this e-mail is strictly prohibited and is unlawful. The
> recipient acknowledges that Conflux Technologies Private Limited or its
> subsidiaries and associated companies are unable to exercise control or
> ensure or guarantee the integrity of/over the contents of the information
> contained in e-mail transmissions. Before opening any attachments, please
> check.
>
>
>
> -Original Message-
> From: Markus Gei? [mailto:markus.ge...@live.de]
> Sent: 05 December 2016 20:51
> To: dev@fineract.incubator.apache.org
> Subject: RE: Business Event Processor
>
> Hey,
>
> why not utilizing an existing event queue, e.g. ActiveMQ, to get this
> feature in. I don't see any real benefit of creating our own mechanism for
> this.
>
> And I believe we are mixing requirements/features here, e.g. data driven
> auth is not an event feature ... so it should not be modeled to become one.
>
> Cheers
>
> Markus
>
> From: Adi Raju [mailto:adi.r...@confluxtechnologies.com]
> Sent: Monday, December 5, 2016 10:14 AM
> To: dev@fineract.incubator.apache.org
> Subject

Issues in interest recalculation

[Sander van der Heyden]

Hi All,

We've been doing a relatively extensive round of testing on interest
recalculation loans and found the following issues (on demo.openmf.org).
All of the cases below have:
- Interest recalculation on
- Interest calculation = same as repayment period
- Amortization set to Equal instalments
- Advance payments set to Reduce EMI Amount
- No grace periods
- No sliding interest rates, or multi-disbursements
- No fixed EMI amounts

I've not yet created JIRA items on it, because I was wondering whether
other people had seen these and there was a work-around by specifying the
right params? Also when trying to debug some of this I think the
calculations have now been made so incredibly complex that it is very hard
to fix some of these without creating other bugs in exchange.

*Daily interest on Same as Repayment period*
On monthly loans, even though same as repayment period is selected, the
interest calculation seems to happen on a daily basis. We see jumps up and
down in the schedule, which should not happen especially before any
payments are made, as in that case the interest calculation should be
identical for each month (we are using same as repayment period) and
therefore the interest amount should always drop month over month, with
principal going up.

*Incorrect interest in Loan Schedule for first instalment when making an
early payment*
When setting up any interest recalculation loan, and making an early
payment on the first instalment, this updates the schedule with all of it
going to principal, leaving the interest outstanding. However the actual
transaction does split part of it to interest and so does the loan summary.
In subsequent instalments this no longer happens.

*Interest recalculation causes incorrect schedule with duplicate
instalments*
On a daily loan, when an installment was originally due on a weekend day,
it get's pushed forward, skipping that day correctly. However in
recalculation this is no longer happening therefore introducing 2
installments on the same date one with a 0 length. So what happens is
pre-correction you have an instalment on the 3rd of December, then one on
the 5th (skipping sunday). After the payment and recalculation it has 2
instalments due on the 5th, one with 0 days and no interest.

*Single instalment loans do not recalculate*
When a loan with 1 instalment is created and the client prepays on that one
instalment, interest is not recalculated.

*Early payment of all principal throws an EMI error*
When repaying the full principal due on the loan in an early instalment it
throws an EMI error, which should not happen, there is still a bit of
interest to pay, but no more principal. This means the schedule should just
show that interest remaining (or close the loan as there is no interest).


Thanks,
Sander

Re: Speaker's notes from the Shark Tank ApacheCon EU

[Sander van der Heyden]

Hi Myrle,

Looks like you had a busy week with the presentations! I think you hit the
nail on the head with the feedback, from my side I think re-engaging the
community will be most important point here. I definitely think the past
year or so there has been a lot of confusion amongst the community.
Obviously of MifosX vs Fineract, where do people feel they 'belong', but
also on the confusion of Gen 2 vs Gen 3 and how that linked to the
projects. While it is clear to us, and presumably to Conflux as well it is
something that still seems to need more clarification. Once the community
become more active and cohesive again I would say we are in a much better
position for graduation.

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 21 November 2016 at 15:19, Myrle Krantz <mkra...@mifos.org> wrote:

> Hi all,
>
> On Friday I gave a five minute presentation to the incubation Shark Tank.
> The idea behind the shark tank is to take a critical look in public at
> whether a podling is ready for graduation.  Here are the notes I used to
> prepare for this short presentation:
>
> https://cwiki.apache.org/confluence/display/FINERACT/Shark+Tank+Notes
>
> You'll note that at the end, I included some of the things I felt we needed
> to improve/complete before we can call ourselves a mature project.
>
> What do you, the Apache Fineract developers, feel is left to do?
>
> Greets,
> Myrle
>
>
> *Myrle Krantz*
> Solutions Architect
> RɅĐɅЯ, The Mifos Initiative
> mkra...@mifos.org | Skype: mkrantz.mifos.org | http://mifos.org
> <http://facebook.com/mifos>  <http://www.twitter.com/mifos>
>

Re: Workflow using Datatable Verification

[Sander van der Heyden]

Hi Ed, Adi,

The following (grouped) commits are the key improvements we've made to the
datables:

   - Commit for "Datatable Entity Check" can be found here -
   https://github.com/Musoni/mifosx/commit/340bac4fd8bc492250e9a85debea64
   7403355955
   
<https://github.com/Musoni/mifosx/commit/340bac4fd8bc492250e9a85debea647403355955>
   - Commit for "Display Conditions and Expressions" can be found here -
   https://github.com/Musoni/mifosx/commit/d091526457862df250930cc7328d1a
   4661350742
   
<https://github.com/Musoni/mifosx/commit/d091526457862df250930cc7328d1a4661350742>


The first one is all about the checks around datatables, ensuring certain
entires are there before a loan/client/whatever action can take please in
the system. The other one is an implementation of Spring Expression Library
(spel) to do display conditions on fields (Eg Field B has a condition to
only show: If FieldA has value) as well as formula's allowing you to do
summary fields that sum multiple values, for instance: Field C = Field A /
Field B * 100 or similar.

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!  <https://twitter.com/musonimfi>
Postal address: Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam,
The Netherlands

On 2 November 2016 at 20:47, Ed Cable <edca...@mifos.org> wrote:

> Hi all,
>
> Glad this conversation is front and center once again as it's been a
> priority of mine going back for almost a year now to get workflows in place
> via data tables using as many contributions from partners and the community
> that we can.
>
> Now that Adi has a proposed design in place, hopefully we can take some
> concrete steps in moving forward.
>
> Sander, can you identify the commits so Adi can analyze.
>
> Based on that analysis along with the proposed design from Adi, I would
> like to set up a call with Adi, Sander, and anyone else along with Markus
> to give his blessing to the approach we should take.
>
> Markus is in Indonesia all this week so let's target a meeting for mid to
> early next week.
>
> Ed
>
> On Tue, Nov 1, 2016 at 11:58 PM, Adi Raju <adi.raju@confluxtechnologies.
> com>
> wrote:
>
> > Hi Sander,
> >
> > It was long holiday weekend for us in india, so couldn't reply earlier.
> >
> > We couldn’t identify the commits for this feature on musoni code base.
> > The work here, is almost 50-50 split between UI and platform.
> > Since UI we cannot take from musoni, we decided to go on with our own API
> > design, though the idea is same as done in musoni systems.
> >
> > If you can help us identify commits, we will analyse the code and take a
> > call on copying the code over to fineract.
> >
> > Regards,
> > Adi
> >
> > -Original Message-
> > From: Sander van der Heyden [mailto:sandervanderhey...@musonisystem.com]
> > Sent: 28 October 2016 14:59
> > To: dev@fineract.incubator.apache.org
> > Subject: Re: Workflow using Datatable Verification
> >
> > Hi Adi,
> >
> > Have you checked our existing commits on this? I think a lot of the
> > functionality is already there, but needs to be squashed and committed
> and
> > might need some patching up in terms of naming.
> >
> > 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!  <https://twitter.com/musonimfi> Postal address:
> > Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam, The Netherlands
> >
> > On 28 October 2016 at 11:11, Adi Raju <adi.r...@confluxtechnologies.com>
> > wrote:
> >
> > > Hi All,
> > >
> > >
> > >
> > > I have put down requirements, user story breakdown and
> > > Design/Implementation approach for the 'Workflow using Datatable
> > > Verification' feature planned in the near future.
> > >
> > > Please find the documentation at
> > > https://cwiki.apache.org/confluence/display/FINERACT/
> > > Workflow+using+Datatabl
> > > e+Verification
> > >
> > > Request your review and comments.
> > >
> > >
> > >
> > > Regards,
> > >
> > > Adi
> > >
> > >
> >
> >
>
>
> --
> *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>
>

Re: Workflow using Datatable Verification

[Sander van der Heyden]

Hi Adi,

Have you checked our existing commits on this? I think a lot of the
functionality is already there, but needs to be squashed and committed and
might need some patching up in terms of naming.

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!  <https://twitter.com/musonimfi>
Postal address: Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam,
The Netherlands

On 28 October 2016 at 11:11, Adi Raju <adi.r...@confluxtechnologies.com>
wrote:

> Hi All,
>
>
>
> I have put down requirements, user story breakdown and
> Design/Implementation
> approach for the 'Workflow using Datatable Verification' feature planned in
> the near future.
>
> Please find the documentation at
> https://cwiki.apache.org/confluence/display/FINERACT/
> Workflow+using+Datatabl
> e+Verification
>
> Request your review and comments.
>
>
>
> Regards,
>
> Adi
>
>

Re: MIFOSX - 16.06.01.RELEASE

[Sander van der Heyden]

Hi Mexina,

What are your logs saying?

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!  <https://twitter.com/musonimfi>
Postal address: Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam,
The Netherlands

On 20 July 2016 at 11:40, Mexina M Daniel <mex...@singo.co.tz> wrote:

> Hello Devs
>
> I have installed Mifos X 16.06.01 successfully but when i login it gives
> the error " Couldn't connect to server. Make sure you are using correct
> settings" and even when i try to acceess
> https://localhost:8443/fineract-provider i get http status 404 error.
>
> In server.xml i have edited the driverClassName to "com.mysql.jdbc.Driver"
> and also placed "mysql-connector-java-5.1.39-bin.jar" in the lib folder.
>
> Can anyone help me with this?
>
> Thanks in advance.
> Mexina
>
>
> --
> Mexina M Daniel
> Lead Software Developer
> Research & Development
>
> Tel:+255 222 618 511 | Mob: +255 712 110 791
>
> Singo Africa Limited
> Block G,Mbezi Beach B| 7 Nakawale Road| P.O.Box 78908| 14121 Dar es Salaam
>
> singo.co.tz
>
> Lets grow together
>
>

Re: Configuring template to pull Guarantor Data

[Sander van der Heyden]

Hi Adi,

Nice one :-)

BTW: Did you need to add a new mapper for this one? Is the guarantor info
not included in the associations=all of the loan already?

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 Thu, Jul 7, 2016 at 8:56 AM, Adi Raju <adi.r...@confluxtechnologies.com>
wrote:

> Hi All,
>
>
>
> I have created a sample template by name “Sample Guarantors Template” on
> https://demo.openmf.org, which is able to iterate on the guarantors.
>
> Please have a look at it for sample implementation.
>
> As Sander pointed out, implementation is based on mustache syntax and a
> proper syntax should work.
>
> The problem I see is with the editor input box that we are using on the UI.
>
> If we start typing mustache syntax directly, editor is interpreting it as
> text and converting them into something else.
>
> I did the coding on notepad and copied the text into the editor and it has
> started working.
>
> I am not even a successful user of this input box, so regular users should
> be able to figure out proper way to add the template structure.
>
>
>
> Regards,
>
> Adi
>
>
>
> From: Ashok [mailto:as...@confluxtechnologies.com]
> Sent: 07 July 2016 10:28
> To: Adi Raju <adi.r...@confluxtechnologies.com>; Nazeer Shaik <
> nazeer.sh...@confluxtechnologies.com>
> Cc: dev@fineract.incubator.apache.org
> Subject: Re: Configuring template to pull Guarantor Data
>
>
>
> Hi Adi/Nazeer,
>
>
>
> Can you take a look at what Sander has metioned.
>
>
>
> The requirement from Amit is to display list of Guarantors associated with
> a loan account.
>
>
>
>
>
>
> Regards,
> Ashok
>
>
>
> On Thu, Jul 7, 2016 at 8:33 AM, Amit Sharma <amkrsha...@gmail.com  amkrsha...@gmail.com> > wrote:
>
> Hi All,
>
> It would be great if someone can recommend the correct mapper and mapper
> key for this.
>
> Thanks,
> Amit Sharma
>
> On Wed, Jul 6, 2016 at 12:12 PM, Sander van der Heyden <
> sandervanderhey...@musoni.eu <mailto:sandervanderhey...@musoni.eu> >
> wrote:
>
> > Hi Ashok,
> >
> > Have not yet digged into the code for this, but we are also looking at a
> > feature implementation which would use UGD and potentially extend it
> with a
> > bit more user-friendly generation of the various mappers. Therefore I was
> > reading up on the various items and wiki pages on this and ran into this
> > e-mail.
> >
> > When looking at this, was the issue in 'our' implementation of the
> mustache
> > library? Or in the fact that we've got the wrong object types available?
> > According to the Mustache docs this should be available, and the java
> libs
> > I quickly checked now do seem to also support it, so might be a matter of
> > correctly passing in the mappers?
> >
> > Sander
> >
> >
> > Sander van der Heyden
> >
> > CTO Musoni Services
> >
> >
> >
> >
> > Mobile (NL): +31 (0)6 14239505
> > Skype: s.vdheyden
> > Website: musonisystem.com <http://musonisystem.com>
> > Follow us on Twitter!  <https://twitter.com/musonimfi>
> > Postal address: Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam,
> > The Netherlands
> >
> > On Wed, Jul 6, 2016 at 8:17 AM, Amit Sharma <amkrsha...@gmail.com
> <mailto:amkrsha...@gmail.com> > wrote:
> >
> > > Thanks Ashok.
> > >
> > > Though I am not a techie, I have run it myself and found it working
> under
> > > loan documents.
> > >
> > > I have used the Mapper Key:"guarantor" and the Mapper value: "
> > > loans/{{loanId}}/guarantors/1?tenantIdentifier=default" . Instead of
> > > passing the {{guarantorId}}, I hardcoded it to 1 (the first guarantor
> in
> > > the systeme)and I have been able to pick the value
> "guarantor.firstname"
> > > and "guarantor.lastname".
> > >
> > > The problem then to me appears to be how does {{guarantorId}} get
> > populated
> > > in the template, {{loan.guarantorId}} isnt working, what would be the
> > > alternative.
> > >
> > > Thanks,
> > > Amit Sharma
> > >
> > > On Wed, Jul 6, 2016 at 10:51 AM, Ashok <as...@confluxtechnologies.com
> <mailto:as...@confluxtechnologies.com> >
> > > wrote:
> > >
> >

Re: Configuring template to pull Guarantor Data

[Sander van der Heyden]

Hi Ashok,

Have not yet digged into the code for this, but we are also looking at a
feature implementation which would use UGD and potentially extend it with a
bit more user-friendly generation of the various mappers. Therefore I was
reading up on the various items and wiki pages on this and ran into this
e-mail.

When looking at this, was the issue in 'our' implementation of the mustache
library? Or in the fact that we've got the wrong object types available?
According to the Mustache docs this should be available, and the java libs
I quickly checked now do seem to also support it, so might be a matter of
correctly passing in the mappers?

Sander


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 Wed, Jul 6, 2016 at 8:17 AM, Amit Sharma <amkrsha...@gmail.com> wrote:

> Thanks Ashok.
>
> Though I am not a techie, I have run it myself and found it working under
> loan documents.
>
> I have used the Mapper Key:"guarantor" and the Mapper value: "
> loans/{{loanId}}/guarantors/1?tenantIdentifier=default" . Instead of
> passing the {{guarantorId}}, I hardcoded it to 1 (the first guarantor in
> the systeme)and I have been able to pick the value "guarantor.firstname"
> and "guarantor.lastname".
>
> The problem then to me appears to be how does {{guarantorId}} get populated
> in the template, {{loan.guarantorId}} isnt working, what would be the
> alternative.
>
> Thanks,
> Amit Sharma
>
> On Wed, Jul 6, 2016 at 10:51 AM, Ashok <as...@confluxtechnologies.com>
> wrote:
>
> > Hi Amit,
> >
> > Adding array or hash map is currently not supported in loan documents, we
> > tried to included array object but we got similar error.
> >
> > Either we need to enhance the loan documents to support array and hashmap
> > or go with a custom pentaho report. I suggest second option which gives
> > better control over format and the content of loan document.
> > On Wed, 6 Jul 2016 at 9:48 AM, Amit Sharma <amkrsha...@gmail.com> wrote:
> >
> > > In the loan documents we need details of the Guarantor, I am using the
> > loan
> > > based  template to configure this and have used the "Mapper Key:
> > guarantor"
> > > and the "Mapper value: ::
> > >
> >
> loans/{{loanId}}/guarantors/{{loan.guarantorId}}?tenantIdentifier=default"
> > > . When I try to pick the value " guarantor.firstname" its throwing the
> > > exception "cannot deserialize instance of java.util.HashMap out of
> > > STRAY_ARRAY token"
> > >
> > > --
> > > stay beautiful,
> > > Amit Sharma
> > >
> > --
> > Regards,
> > Ashok
> >
> > Sent from mobile device
> >
>
>
>
> --
> stay beautiful,
> Amit Sharma
>

Re: Microservices

[Sander van der Heyden]

Hi guys,

First of all I think it's great that this discussion is now happening on
the public mailing list. It will first of all generate a lot of good
reading material for people looking to catch up on it later.

To put it very blunt, I think the ultimate decision to move to a new model
has indeed been made a while back before even starting the conversion into
an apache project. And from my side that is been a very good decision, as
we've seen that the current codebase has grown very rapidly over the last
few years, but also has grown increasingly complex. Part of this is due to
very free interpretation of the current architecture by the various devs
over time (including myself ;-)), but another part is also the scaling part
of the system.

As ever change won't come without it's challenges, and ultimately every use
of the current Fineract platform can decide to switchover to the new
infrastructure at a time they choose. If you are really against the
architecture design, or have built a very large proprietary ecosystem which
is tightly coupled into the current codebase, then there is always the
option to stay on the current Fineract version and continue to develop it
on your own, obviously without the large community that's currently there.

>From our side I want to first see a decent proof of concept, that shows
that the battles we are currently having in scaling the platform for our
customers are properly addressed. If that works, we will definitely hop on
and start contributing to it to ensure that any part of functionality that
we currently use which is not covered sufficiently will be addressed. But
until that time I'll be eagerly awaiting (and reading along) with these
threads to see the various updates and documents come forward.

@Keith: Great to see your back to dipping your toes into the project again!
I've picked up on your question to raise some of these in a separate thread
so will do so in the coming week or so (when I get some time to properly
write them down).

Sander

On Tue, May 24, 2016 at 11:23 AM, Keith Woodlock 
wrote:

> Myrle,
>
> Sounds like Markus/you have been on this journey for a while already.
> Everything sounds great. Be very interested in seeing it come together.
>
> For that reason I think the sooner you are transparent about where the code
> is the better so the community can take a look also and help out where
> possible.
>
> regards,
> Keith.
>
>
>
> On Tue, May 24, 2016 at 9:07 AM, Myrle Krantz  wrote:
>
> > Hey Keith,
> >
> > I’ll start with the easy questions:
> >
> > * Have I done this before? Yes.  But no woman is an island.  I’m happy to
> > have qualified advice.
> >
> > * Where will Markus and I be saving our work? We’ll send you a pointer
> once
> > we feel it would be productive for others to look at it.  Until we have a
> > common understanding of the design and technologies sharing code would be
> > fruitless.
> >
> > I thought about your suggestion for a general approach.  I agree we
> should
> > start with a limited scope, and I like your component break down.  I
> would
> > refine that as follows:  Since it’s always been important that
> > Mifos/Fineract is multi-tenanted, I think the best place to start is
> with a
> > service for tenant allocation and service orchestration.  From there, a
> > service for user/permission provisioning would be the obvious next step.
> > Together these represent your service 1.  Splitting them is not a
> > fundamentally different design.  It is cleaner though, since the user
> > management would be within a tenant, and the only service that should be
> > “tenant-aware” is the one that does tenant allocation.  For your second
> > service, you suggest attacking loans next.  Savings is just as important
> as
> > loans, and fundamentally equivalent (just black numbers versus red ones).
> > So after tenant allocation and user creation were complete, the next
> > bare-bones service should be a ledger.  Savings and loans products would
> > then be part of a fourth service for describing product offerings.
> Again,
> > I’ve taken what you represented as one service and made two out of it.
> >
> > All the services except the tenant creation service should treat all data
> > addition/adjustment as a command, just like you originally designed it
> for
> > Mifos.  That approach has worked well and we should stick to it.  But
> > command processing should be asynchronous for *everything*.  High volumes
> > of write operations in *any* service should not throttle capacity for any
> > other service.  The tenant creation service is the one service that can’t
> > use the command pattern, because commands are serialized to a database
> the
> > tenant creation service provisions.
> >
> > These are the components I just described:
> >
> > A.) A command module for writing and handling commands which would be
> used
> > by all services.  This is a compile time dependency.
> >
> > B.) A tenant service 

Re: Loan Create API

[Sander van der Heyden]

Hi Zayyad,

Making it mandatory would be an api-breaking change for all other
consumers, and is as such not recommendable. What I'd propose is to:
- Default the loanofficer to the one for the client/group the loan is
attached to if it is not provided.
- Possibly add a config switch to disable this behaviour for existing users
who don't use loanofficers (for instance in P2P lending etc).

This way we wouldn't break existing functionality and would also have a
more flexible solution.

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, May 16, 2016 at 7:42 PM, Zayyad A. Said <
zay...@intrasofttechnologies.com> wrote:

> Devs,
>
>
>
> Looks like will need a change of this API
> https://demo.openmf.org/api-docs/apiLive.htm#loans_create to include loan
> officer as Mandatory field.
>
>
>
> We have a client who has integrated a USSD app with Mifos X and their
> members do apply for loans from their mobile phones.
>
>
>
> The challenge becomes tracking business performance per officer. Most of
> the reports configured require loan officer ID in m_loan and if you look at
> the loans booked from the USSD app it doesn’t post staff id.
>
>
>
> Is this something that can be taken up in the upcoming release?
>
>
>
> Regards;
>
>
>
>
>
> *
>
> *Zayyad A. Said | Chairman & C.E.O*
>
>
>
> Cell No.: +254 716 615274 | Skype: *zsaid2011*
>
> Email: zay...@intrasofttechnologies.com
>
>
>
> [image: Email banner]
>
>
>

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

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!  <https://twitter.com/musonimfi>
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!  <https://twitter.com/musonimfi>
> 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!  <https://twitter.com/musonimfi>
>>> Postal address: Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam,
>>> The Netherlands
>>>
>>> On Fri, Apr 8, 2016 at 5:46 PM, Ed Cable <edca...@mifos.org> 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 <edca...@mifos.org> 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
>>>>> <https://web.chilipiper.com/link/mifos.org/57053b41e4b02bbec5bc216d?link=bWFpbHRvJTNBYWRpLnJhanUlNDBjb25mbHV4dGVjaG5vbG9naWVzLmNvbQ==>
>>>>> > 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.
>>>>>>
>>>>>&g

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!  <https://twitter.com/musonimfi>
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!  <https://twitter.com/musonimfi>
>> Postal address: Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam,
>> The Netherlands
>>
>> On Fri, Apr 8, 2016 at 5:46 PM, Ed Cable <edca...@mifos.org> 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 <edca...@mifos.org> 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
>>>> <https://web.chilipiper.com/link/mifos.org/57053b41e4b02bbec5bc216d?link=bWFpbHRvJTNBYWRpLnJhanUlNDBjb25mbHV4dGVjaG5vbG9naWVzLmNvbQ==>
>>>> > 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
>>>>>
>>>>>
>>>>>
>>>>

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

Re: [Mifos-users] Explanation about Interest Calculation

[Sander van der Heyden]

Hi Adi,

Thanks, now added on JIRA: https://issues.apache.org/jira/browse/FINERACT-59

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 Wed, Mar 2, 2016 at 11:38 AM, Adi Raju <adi.r...@confluxtechnologies.com>
wrote:

> Hi Sander,
>
> Changes are done in sync with our initial discussion for "same as
> repayment" option. It's working fine for declining balance loans. It's not
> working in case of flat loans, which is a bug. Please raise an issue(for
> tracking) and we will provide a fix.
>
> Regards,
> Adi
> On 02-Mar-2016 3:42 pm, "Sander van der Heyden" <
> sandervanderhey...@musoni.eu> wrote:
>
> > Hi George,
> >
> > I completely agree, from our end one of the key reasons people use flat
> > interest loans (or essentially all fixed schedule loans) is that you can
> > have standardised products, repayment amounts etc. And this change
> diverts
> > away from it, and therefore for the cases we've tested so far, we are
> > unable to get the same schedules without indeed requiring the data entry
> > teams to change the way they are working, or making hard-coded UI
> > modifications for it.
> >
> > @Adi: Do you plan to make sure that the flat loans will just keep using
> the
> > same way of calculating as before for "Same as repayment Period", and for
> > people who do want to get the period included, they can use the 'daily'
> > calculation type? I believe this is also what I proposed initially, so
> was
> > wondering if that was the fix you were proposing, or whether it would
> work
> > differently?
> >
> > Have cc'ed the Fineract dev list now, and happy to write it up on the
> JIRA
> > there, but think it is good we are clear on the proposed solution as
> well.
> >
> > 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!  <https://twitter.com/musonimfi>
> > Postal address: Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam,
> > The Netherlands
> >
> > On Tue, Mar 1, 2016 at 9:34 AM, Georges Lteif <
> georgeslt...@almajmoua.org>
> > wrote:
> >
> > > Hello Sander
> > > exactly as you mentioned,
> > > this is a weird behaviour for our loan as we can't tell our clients
> that
> > > your last repayment would change based on when our finance would
> disburse
> > > your loan right?
> > >
> > > it should be something really fixed
> > >
> > > Another question also is that the person doing data entry has to know
> the
> > > date of the disbursement right?
> > > since if a client was created on the 1st of May and the disbursement
> date
> > > set by the data entry personnel is 2nd of May
> > >
> > > the finance cannot disburse it before the 2nd right? for any reason
> > > they have to wait?
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> --
> > > Site24x7 APM Insight: Get Deep Visibility into Application Performance
> > > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> > > Monitor end-to-end web transactions and take corrective actions now
> > > Troubleshoot faster and improve end-user experience. Signup Now!
> > > http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
> > > ___
> > > Mifos-users mailing list
> > > mifos-us...@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/mifos-users
> > >
> > >
> >
>

Re: Expression language to extend datatables

[Sander van der Heyden]

Hi Markus,

Thanks for your input, would you have any specific business rule engines in
mind?

One of the things we had in mind on that would be the same way we use the
current templates and for instance the previews of loanschedules, where you
can just get a preview of the result without having to store data straight
away. This way (online) consumers can use it without re-implementing logic.

Sander




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 Thu, Feb 25, 2016 at 11:27 AM, Markus Geiß <markus.ge...@live.de> wrote:

> Hey,
> hope this finds you well. ; o)
> I think using a language specific expression language will force consumers
> notusing Java for the client implementation to re-implement the logic.
> Maybe an approach using a business rule engine, returning the name of
> therule in the meta data and allow a call to the back end with the rule
> name andthe entity/object reference to use, is a solution that broadens the
> usage.
> In this case the same logic to execute the rule can be used for ad hoc
> andserver side adjustment.
>
> Best,
>
> Markus
>
> .::YAGNI likes a DRY KISS::.
>
> > From: sandervanderhey...@musoni.eu
> > Date: Wed, 24 Feb 2016 16:19:41 +0100
> > Subject: Re: Expression language to extend datatables
> > To: dev@fineract.incubator.apache.org
> >
> > Hi Keith,
> >
> > Hope you are well?! Long time!!
> >
> > Ultimately the goal is to get the calculated data stored in the actual
> > datatable so that it can be used in reports, custom loan checks etc. So
> > therefore what I would expect to happen as an API consumer is:
> > - When pulling the template API for a certain datatable the configured
> > expression will come back as metadata (same way field types or
> > mandatory/non-mandatory is given back). This would allow any consumer of
> > that API to also implement the same expression library in (for instance)
> a
> > Web UI or (offline) Android app and give instant results in their UI.
> > - When saving the backend will expect this field to be empty (not
> > submitted) and will evaluate the expression.
> > - Any time the record is updated the expression will be evaluated again.
> > - Potentially adding an endpoint/ability to just get back the generated
> > results for a table, without storing, to allow online consumers to work
> > with the results without implementing the same expression lib.
> >
> > As there is already quite some work done around datatables by conflux and
> > musoni in extending the features, adding metadata to it, this seems like
> a
> > logical next step, although we can also debate whether it might be a
> point
> > where the datatables would be 'forked' into a separate endpoint more
> > focussed on user-forms.
> >
> > So from our end the datatable>rule relationship would mainly be that the
> > datatable metadata contains a user-defined expression which can be
> > maintained using the CRUD on the datatables endpoint itself and is stored
> > in the metadata as a (tiny)text field.
> >
> > All in all, this would be extending datatables quite significantly and
> > therefore I think it would be good to agree on the need for doing that as
> > part of a 'fork' of the datatables endpoint into a separate 'user-forms'
> > endpoint, also keeping in mind other requests we've got on this such as:
> > - conditional fields (Field B is only required if Field A has a value)
> > - field types such as GPS or a document upload
> >
> > And obviously this also comes with a sensible decision on which
> expression
> > library to use, and other ideas around the various items listed above.
> >
> > So very curious to hear some thoughts. In terms of timelines we'll be
> > looking to pick most if this up in Q2 .
> >
> > Sander
> >
> > On Wed, Feb 24, 2016 at 10:54 AM, Keith Woodlock <
> keithwoodl...@gmail.com>
> > wrote:
> >
> > > Hi Sander,
> > >
> > > >> We've been using the datatables quite extensively with more and
> more of
> > > our
> > > >> clients, and have also been extending it a bit to make it more
> suitable
> > > for
> > > >> offline use on a tablet etc.
> > >
> > > Very good. Be interesting to hear more of what you did to support the
> > > offline scenarios. I must take a look at the code area to see it.
> > >
> > > >> 

Re: [GitHub] incubator-fineract pull request: Connector changes from mysql to d...

[Sander van der Heyden]

Hi Markus,

I think I agree with Keith on this one, mainly because it seems like we are
only replacing to satisfy the licensing requirements, while we already know
most implementations will be using either MariaDB or MySQL connector. I can
see that it's nice to have it part of the package, but is referencing it in
a gradle dependency in breach with the license?

Sander


Sander van der Heyden

CTO Musoni Services




Mobile (NL): +31 (0)6 14239505
Mobile (Kenya): +254 (0)707211284
Skype: s.vdheyden
Website: musonisystem.com
Follow us on Twitter!  <https://twitter.com/musonimfi>
Postal address: Hillegomstraat 12-14, office 1.11, 1058 LS, Amsterdam,
The Netherlands

On Mon, Feb 8, 2016 at 1:19 PM, Markus Geiß <markus.ge...@live.de> wrote:

> Integration tests are part of our current work too and they need to run
> with a
> JDBC driver ...
>
> Aside from that I agree that we may can ommit a driver from our source
> release.
>
> If this is the case could one of our mentors weigh in and let us know if
> it is
> compliant with the license policies to use a non-compliant library in a
> test
> environment. If this is the case, it would also fix our Hibernate issue,
> but prevent
> us from releasing a binary/distribution.
>
> Best,
>
> Markus
>
> .::YAGNI likes a DRY KISS::.
>
> > Date: Mon, 8 Feb 2016 12:15:11 +
> > Subject: Re: [GitHub] incubator-fineract pull request: Connector changes
> from mysql to d...
> > From: keithwoodl...@gmail.com
> > To: dev@fineract.incubator.apache.org
> >
> > Markus,
> >
> > Yes - I still feel if you just ommited the connector from any release and
> > updated installation instructions you wouldnt have to make any code
> changes
> > or do any testing - Having the platform supported and tested agaisnt the
> > Drizzle Driver isnt that useful I would of thought.
> >
> > Keith.
> >
> > On Mon, Feb 8, 2016 at 12:12 PM, Markus Geiß <markus.ge...@live.de>
> wrote:
> >
> > > Good point!
> > >
> > > Let me create an issue ... we may face something similar with
> Hibernate.
> > >
> > > Best,
> > >
> > > Markus
> > >
> > > .::YAGNI likes a DRY KISS::.
> > >
> > > > Date: Mon, 8 Feb 2016 12:11:28 +
> > > > Subject: Re: [GitHub] incubator-fineract pull request: Connector
> changes
> > > from mysql to d...
> > > > From: keithwoodl...@gmail.com
> > > > To: dev@fineract.incubator.apache.org
> > > >
> > > > Markus,
> > > >
> > > > Yes Markus, you should be able to do that.
> > > >
> > > > I dont see an apache fineract issue (to watch) for this work but if
> you
> > > let
> > > > me know when its finished I'd be happy to give a go at going through
> the
> > > > (production/test) installation instructions.
> > > >
> > > > Keith.
> > > >
> > > > On Mon, Feb 8, 2016 at 12:00 PM, Markus Geiß <markus.ge...@live.de>
> > > wrote:
> > > >
> > > > > The whole Core Team including our QA and Support will do testing
> the
> > > > > next few days to ensure all is working.
> > > > >
> > > > > I'm also not happy with it, given the huge test effort we have,
> but it
> > > > > would always
> > > > > be feasible to replace the default driver with anything you like
> to use
> > > > > for your
> > > > > 'distribution'. ; o)
> > > > >
> > > > > Best,
> > > > >
> > > > > Markus
> > > > >
> > > > > .::YAGNI likes a DRY KISS::.
> > > > >
> > > > > > Date: Mon, 8 Feb 2016 11:51:13 +
> > > > > > Subject: Re: [GitHub] incubator-fineract pull request: Connector
> > > changes
> > > > > from mysql to d...
> > > > > > From: keithwoodl...@gmail.com
> > > > > > To: dev@fineract.incubator.apache.org
> > > > > >
> > > > > > Hi Markus,
> > > > > >
> > > > > > Thats pretty frustrating. Did you consider retaining mysql
> > > connector/j
> > > > > > driver to use for development / testing and excluding from
> release
> > > > > > artifact. It would become one of the installation instructions to
> > > > > download
> > > > > > the driver then to use the software.
> > > > > >
> > > > > > I only say this