[
https://issues.apache.org/jira/browse/FINERACT-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16801199#comment-16801199
]
Vishwas Babu A J commented on FINERACT-720:
-------------------------------------------
[~kangbreder] :
1)
[SchedulerJobsTest.java|https://github.com/apache/fineract/pull/536/files#diff-38d6eccc76ab694890ecee7e470c772a]
is the Integration test for all scheduled jobs, this would test applying
annual fees too
2) The scheduler job is designed to run for all accounts, i.e you cannot run it
for a single account
I would suggest that you pick up some other issue. This issue seems to have
been around for a long time, apparently hasn't caused issues for anybody and
with the fix made for the upcoming 1.3 release, it shall not cause errors as
long as the applyAnnualFee batch job is run before applyChargeDue /
organization does not create backdated savings accounts
> Recurring Integration Test failures around Applying Annual Fees and Other Fee
> Types on Savings accounts
> -------------------------------------------------------------------------------------------------------
>
> Key: FINERACT-720
> URL: https://issues.apache.org/jira/browse/FINERACT-720
> Project: Apache Fineract
> Issue Type: Sub-task
> Reporter: Vishwas Babu A J
> Priority: Trivial
>
> Fineract consists of two separate methods (and associated API's and batch
> jobs) for Applying Annual and Savings Charges
> inSavingsAccountWritePlatformServiceJpaRepositoryImpl, namely
> * applyAnnualFee : Applies any due annual Fee (only once) for an active
> savings account
> * applyChargeDue : Applies any due fee (including annual fee) till it is
> completely paid for a savings account
> The crux of the cause of intermittent failure of test cases is as follows:
> An annual charge is applied on a savings account for say the 1st of Jan 2015
> and then applyAnnualFee batch job is run on the same as on Feb 2th 2019. This
> results in the charge being paid as on 1st Jan 2015 and the next due date
> being set to 1st Jan 2016. This behavior is probably incorrect and I would
> presume that the charge would have to be paid for the years 2016, 2017,2018
> and 2019 as well and the next due date should be set to 1st Jan 2020.
> Next, when at any point in time, when the applyChargeDue test case is run, it
> recognizes the Annual fee charge due on 1st Jan 2016 and tries to repay the
> same as on today's date. However, existing validation in this method throws
> an exception.
> Based on an initial observation, it looks like the following fixes would need
> to be made
> # Running applyAnnualFee should pay of *all* annual fees due on the account
> as of today's date
> # applyChargeDue should not try to pay annual fees
> The change required for 1 has been made and it fixes the observed test case
> failure. The change of 2 has not been made for now, as I am not a 100% sure
> why the code is written in this way in the first place and in the absence of
> sufficient integration tests, do not want to possibly introduce any side
> effects.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)