Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 7272B2009F2 for ; Thu, 5 May 2016 22:07:07 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 70D2A160A04; Thu, 5 May 2016 20:07:07 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id F1F701609F9 for ; Thu, 5 May 2016 22:07:05 +0200 (CEST) Received: (qmail 42632 invoked by uid 500); 5 May 2016 20:07:05 -0000 Mailing-List: contact dev-help@fineract.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@fineract.incubator.apache.org Delivered-To: mailing list dev@fineract.incubator.apache.org Delivered-To: moderator for dev@fineract.incubator.apache.org Received: (qmail 87864 invoked by uid 99); 5 May 2016 19:15:53 -0000 X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.28 X-Spam-Level: * X-Spam-Status: No, score=1.28 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=intrasofttechnologies-com.20150623.gappssmtp.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intrasofttechnologies-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=D8f6q0QNM8+b549To8O+7sSA4glKeX8CA0P2PJtRe4E=; b=VnZQBnp0bNfK3iPK+fqMY1WEFHIFAYCNMbSTEIfv+NZS4THfIzjCVr1jyKbrZRzuRi 0p0gy8/5S+K/08s0pmSKOlZP5/zSQMwt2HLMnYVGsC0l2tSNJ1IrA5MmjN5++CkiDQ2g YeTtHCPwpfKa6WzfIJLFwj36zsEAHNTKYeMR3iMGvjp9wCtxXbyY+pO7jeNSl/YjwPNh hAh+e8lva0IKQzrKm+uO8qo62yQyf26FCYQXvY7u+Y0ybKCwAUTR9Zp0bmpgdsqDrxd4 1o6VrDL6s4RTZoUvwm+4zZuR58Bv6pKYDS+kUuxMYM0PKlvltPy417P1mFmf/O2tkKll 03VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=D8f6q0QNM8+b549To8O+7sSA4glKeX8CA0P2PJtRe4E=; b=e+7kdk+DaFtx1LsXq8qYz2zSqe3N+CkITp7SB+8vvukZdXgKSPCqeY/J3QD+PAxvQ6 b6dWLp0dEfNaiCaBX6puqQLnQeGDYN6vOuK6SZf5/VP7RjGVRGNrypRoiayjZmFC0Opt +CEbYK+x0Ld/uuWbVf/JI4RQertCDXPi//JewZajHbwNtAK7L/RnIIY/sjGFMp/eFqeJ gww+IujdTa6GuG1EcfCWLAIZ/+8p2bb8B4BiZtfxt7A7J+d6QEuxn74vwT6t+SEn4kL5 EIdbgzRBxWUOZeIz37uJKZMbRvGvqtSxVvcxfLe/b3+oFi6I1piAzNrRVbhpsaEeR4ee OhIA== X-Gm-Message-State: AOPr4FWHWjZXq1VkUcgu62H7BdVApK2qMcvdEMqm6cADhY5kWVdcgzF6XrtjZOO/C1tDyA== X-Received: by 10.28.143.11 with SMTP id r11mr5491673wmd.46.1462475742399; Thu, 05 May 2016 12:15:42 -0700 (PDT) From: "Zayyad A. Said" To: Cc: "'Sangamesh N'" , , "Ed Cable" References: <005d01d1a55b$00897370$019c5a50$@intrasofttechnologies.com> In-Reply-To: Subject: RE: Loan Fees Bug Date: Thu, 5 May 2016 22:15:53 +0300 Message-ID: <039601d1a702$8cd53050$a67f90f0$@intrasofttechnologies.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0397_01D1A71B.B2279870" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLd9TyrtQQO2xtj3hFEwX97KVFgzwMmuFduAnzrl74CO9jTJp1THm5Q Content-Language: en-gb archived-at: Thu, 05 May 2016 20:07:07 -0000 ------=_NextPart_000_0397_01D1A71B.B2279870 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0398_01D1A71B.B2279870" ------=_NextPart_001_0398_01D1A71B.B2279870 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Devs, =20 Anyone who was able to look into this?=20 Kindly advise way forward. =20 Regards; =20 =20 ******* Zayyad A. Said | Chairman & C.E.O =20 Cell No.: +254 716 615274 | Skype: zsaid2011 Email: zayyad@intrasofttechnologies.com=20 =20 Email banner =20 From: Zayyad A. Said [mailto:zayyad@intrasofttechnologies.com]=20 Sent: 04 May 2016 19:15 To: 'Sander van der Heyden'; 'dev@fineract.incubator.apache.org' Cc: 'Sangamesh N' Subject: RE: Loan Fees Bug =20 Sander, =20 If this is how it=E2=80=99s been functioning for the last two years, = then I must say we have all been in darkness for quite some time. The = system should not function like this. =20 If I charge a client in June for example, that income needs to be = reported in June which is the month the fee was charged and not before. = It beats the logic to report that income in the month when there was = last payment (say April) in the account. =20 << If the fee is applied after the payment and no backdates are made, = this won't cause any weird bookings, but as soon as you start backdating = or adjusting older payments the reprocessing of the schedule will = re-allocate the payments like this.>> Please note in the sample I gave in my email, the charge was actually = applied on 1st May 2016 and paid same day after the payment of 15th = April 2016 had already been made. =20 I strongly recommend someone to carefully analyze this situation and = propose right solution otherwise the system would not be giving right = financial reports which are key to the Financial Institutions. =20 Regards; =20 =20 ******* Zayyad A. Said | Chairman & C.E.O =20 Cell No.: +254 716 615274 | Skype: zsaid2011 Email: zayyad@intrasofttechnologies.com=20 =20 Email banner =20 From: Sander van der Heyden [mailto:sandervanderheyden@musoni.eu]=20 Sent: 03 May 2016 22:55 To: dev@fineract.incubator.apache.org Cc: Zayyad A. Said; Sangamesh N Subject: Re: Loan Fees Bug =20 Hi Zayyad, =20 This is not a bug, but actually existing functionality that has worked = like this at least for the last year or so. We've been educating our = users on this for quite some time.=20 =20 The logic behind this is very much tied to the structure in the system. = Because loan payments and charges are all linked to schedule = instalments, any loan fee that is set up as "Specified due date" is = actually tied to the loan instalment it falls into, and therefore = (depending on the payment order picked), it will be paid off as soon as = the first payment 'hits' that instalment, which in your case is that = payment from earlier on. =20 If the fee is applied after the payment and no backdates are made, this = won't cause any weird bookings, but as soon as you start backdating or = adjusting older payments the reprocessing of the schedule will = re-allocate the payments like this. =20 I completely understand that this is seen as 'undesirable' behaviour, = but this is also quite a core bit of code around the charges, that would = need to be redesigned to change this. If this is therefore core-team = development effort, I propose to treat this as a known error / = improvement and not rush into revamping part of the charges code without = also considering other improvements (or creating bugs while solving = others). But keen to hear other thoughts on this from the other devs?=20 =20 Thanks, Sander Sander van der Heyden CTO Musoni Services =20 Mobile (NL): +31 (0)6 14239505 Skype: s.vdheyden Website: musonisystem.com Follow us on Twitter!=20 Postal address: Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam, = The Netherlands =20 On Tue, May 3, 2016 at 6:50 PM, Ed Cable wrote: Zayyad, =20 Since this is potentially a bug in the core Fineract platform, i'm = directly the conversation to that mailing list - we'll continue the = conversation there.=20 = = =20 =20 On Tue, May 3, 2016 at 9:43 AM, Zayyad A. Said = wrote: Hi Devs, =20 We seem to be having a bug on fees applied after a loan payment is done. = The fee income seem to be reported in the previous schedule when the = last payment was done. =20 To reproduce this check out this account = https://demo3.openmf.org/#/viewloanaccount/42 (mifos/password) for = client Allen E. =20 Two different charges were applied on 1st May 2016 i.e. Loan Extension = of 600/=3D and Penalty of 1000/=3D and were also paid same day (You can = verify from the charges tab). =20 If you view them on Transactions tab, these fees shows to have been = collected on 15th April 2016 which was the date partial payment was = done to this loan account. =20 This poses a very serious challenge in proper accounting of income as = this income is now reported in a different month and not the actual = month when it was charged and paid. =20 Please look into this urgently and would appreciate if it can be a given = a top priority to have it fixed. =20 Your feedback will be appreciated. =20 Regards; =20 =20 ******* Zayyad A. Said | Chairman & C.E.O =20 Cell No.: +254 716 615274 | Skype: = zsaid2011 Email: zayyad@intrasofttechnologies.com=20 =20 =20 =20 =20 --=20 Ed Cable Director of Community Programs, Mifos Initiative edcable@mifos.org | Skype: edcable | Mobile: +1.484.477.8649 = =20 =20 Collectively Creating a World of 3 Billion Maries | http://mifos.org = =20 =20 =20 ------=_NextPart_001_0398_01D1A71B.B2279870 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Devs,

 

Anyone who was able to look into this?


Kindly advise way forward.

 

Regards;

 

 

*******<= span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222'= >

Za= yyad A. Said | Chairman & C.E.O

 

Cell No.: +254 716 615274 | = Skype: zsaid2011

Email: zayyad@intrasofttechnologies.com 

 

3D"Email

 

From:= Zayyad A. = Said [mailto:zayyad@intrasofttechnologies.com]
Sent: 04 May = 2016 19:15
To: 'Sander van der Heyden'; = 'dev@fineract.incubator.apache.org'
Cc: 'Sangamesh = N'
Subject: RE: Loan Fees = Bug

 

Sander,

 

If this is how it=E2=80=99s been functioning for the last two years, = then I must say we have all been in darkness for quite some time. The = system should not function like this.

 

If I charge a client in June for example, that income needs to be = reported in June which is the month  the fee was charged and not = before. It beats the logic to report that income in the month when there = was last payment (say April) in the account.

 

<< If the fee = is applied after the payment and no backdates are made, this won't cause = any weird bookings, but as soon as you start backdating or adjusting = older payments the reprocessing of the schedule will re-allocate the = payments like this.>>

Please note in the sample I gave in my email, the charge was actually = applied on 1st May 2016 and paid same day after the payment = of 15th April 2016 had already been = made.

 

I strongly recommend someone to carefully analyze this situation and = propose right solution otherwise the system would not be giving right = financial reports which are key to the Financial = Institutions.

 

Regards;

 

 

*******<= span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222'= >

Za= yyad A. Said | Chairman & C.E.O

 

Cell No.: +254 716 615274 | = Skype: zsaid2011

Email: zayyad@intrasofttechnologies.com 

 

3D"Email

 

From:= Sander van = der Heyden [mailto:sandervanderheyden@mu= soni.eu]
Sent: 03 May 2016 22:55
To: dev@fineract.incubator.= apache.org
Cc: Zayyad A. Said; Sangamesh = N
Subject: Re: Loan Fees Bug

 

Hi = Zayyad,

 

This is not a bug, but actually existing functionality = that has worked like this at least for the last year or so. We've been = educating our users on this for  quite some = time. 

 

The logic behind this is very much tied to the = structure in the system. Because loan payments and charges are all = linked to schedule instalments, any loan fee that is set up as = "Specified due date" is actually tied to the loan instalment = it falls into, and therefore (depending on the payment order picked), it = will be paid off as soon as the first payment 'hits' that instalment, = which in your case is that payment from earlier = on.

 

If the fee is applied after the payment and no = backdates are made, this won't cause any weird bookings, but as soon as = you start backdating or adjusting older payments the reprocessing of the = schedule will re-allocate the payments like = this.

 

I = completely understand that this is seen as 'undesirable' behaviour, but = this is also quite a core bit of code around the charges, that would = need to be redesigned to change this. If this is therefore core-team = development effort, I propose to treat this as a known error / = improvement and not rush into revamping part of the charges code without = also considering other improvements (or creating bugs while solving = others). But keen to hear other thoughts on this from the other = devs? 

 

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 Tue, = May 3, 2016 at 6:50 PM, Ed Cable <edcable@mifos.org> wrote:

Zayyad,

 

Since this is potentially a bug in the core Fineract = platform, i'm directly the conversation to that mailing list - we'll = continue the conversation there. 

 

On Tue, = May 3, 2016 at 9:43 AM, Zayyad A. Said <zayyad@intrasofttechnologies.com> = wrote:

Hi = Devs,

 <= /o:p>

We seem to = be having a bug on fees applied after a loan payment is done. The fee = income seem to be reported in the previous schedule when the last = payment was done.

 <= /o:p>

To = reproduce this check out this account https://demo3.openmf.org/#/viewloanaccount/42 = (mifos/password) for client Allen E.

 <= /o:p>

Two = different charges were applied on 1st May 2016 i.e. Loan = Extension of 600/=3D and Penalty of 1000/=3D and were also paid same day = (You can verify from the charges tab).

 <= /o:p>

If you view = them on Transactions tab, these fees shows to have been collected on = 15th April 2016 which was the date  partial payment was = done to this loan account.

 <= /o:p>

This poses = a very serious challenge in proper accounting of income as this income = is now reported in a different month and not the actual month when it = was charged and paid.

 <= /o:p>

Please look = into this urgently and would appreciate if it can be a given a top = priority to have it fixed.

 <= /o:p>

Your = feedback will be appreciated.

 <= /o:p>

Regards;

 <= /o:p>

 <= /o:p>

*******<= o:p>

Za= yyad A. Said | Chairman & C.E.O

 

Cell No.: +254 = 716 615274 | Skype: zsaid2011

Email: zayyad@intrasofttechnologies.com <= /o:p>

 

 <= /o:p>

 <= /o:p>



 

-- =

Ed = Cable

Director of Community Programs, Mifos Initiative

edcable@mifos.org | Skype: edcable | Mobile: = +1.484.477.8649

 

Collectively Creating a World of 3 Billion Maries = | http://mifos.org  

 

 

------=_NextPart_001_0398_01D1A71B.B2279870-- ------=_NextPart_000_0397_01D1A71B.B2279870--