[jira] [Created] (FINERACT-2107) Transaction type - Interest refund
Bharath Gowda created FINERACT-2107: --- Summary: Transaction type - Interest refund Key: FINERACT-2107 URL: https://issues.apache.org/jira/browse/FINERACT-2107 Project: Apache Fineract Issue Type: Improvement Reporter: Bharath Gowda Attachments: GPL Interest Refund Calculations (1).xlsx h4. *Background and details:* As a User, I expect the system to calculate and post an interest refund when a merchant refund posts so that we are only charging the customers interest on the net purchase amount. Will require build out of process to calculate the amount of interest to refund. Ensure payment allocation rules allow for unique payment allocation for this transaction type. As a merchant refund is posted, there should be a system calculated credit for interest charged to the loan based on maturity date. This would be posted to the loan as a credit adjustment type “Interest Refund”. *Acceptance criteria* * Add new transaction type * Loan product template retrieve the supported options for configuring when Interest refund txn to be created * Interest refund txn triggering configuration can be stored on loan product * We should be able to define allocation rules for “Interest Refund” transaction UC scenarios attached -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-2104) Accrual Activity Posting on Installment date
Bharath Gowda created FINERACT-2104: --- Summary: Accrual Activity Posting on Installment date Key: FINERACT-2104 URL: https://issues.apache.org/jira/browse/FINERACT-2104 Project: Apache Fineract Issue Type: Improvement Reporter: Bharath Gowda Attachments: accrual activity scenarios v4 (1).xlsx *Background and Details* Currently Fineract posts accrual for loan accounts based on two jobs. post accrual transactions and post periodic accrual. One job posts accruals as of Installment date and the other posts as on the run date but with the available configurations we cannot have split of accrual posting as of the Installment date with daily accrual postings. Hence we are posting a monthly accrual activity that posts Installment wise accrual that is being calculated as of that installment *Acceptance Criteria* # System should have a new non-monetary transaction type named accrual activity transaction # The transaction will be posted on the Installment due_date for Installment’s INCOME portion amount ## Example: Interest, fees and Penalties Income portions # A job +business step is required to support this functionality ## Job + business step to support this functionality! # Transaction will be posted only for the active loans as on Installment due-date only ## If a Loan in pre-closed - one entry will be posted as of the last transaction date ## If the pre-closed loan is re-opened again (due to new disbursement or chargeback) the accrual activity should be created for the next installments till current date ( interest amount to be calculated from previously posted accrual activity on the earlier preclose date) # The transaction will be reverse and replayed when ever the INCOME portion amount is changed during schedule recalculations- like any other transaction ## example reversal of an older repayment # System should store/send both previous and new INCOME portion values during reverse and replay # Transaction will have no Accounting entries, no affect on balances or on repayment schedule changes # Configuration at loan product level is required for enabling or disabling this transaction posting Usecases attached below -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-2092) New transaction type - Payment Waiver
Bharath Gowda created FINERACT-2092: --- Summary: New transaction type - Payment Waiver Key: FINERACT-2092 URL: https://issues.apache.org/jira/browse/FINERACT-2092 Project: Apache Fineract Issue Type: Improvement Reporter: Bharath Gowda h3. Background and Details Payment Waiver is a transaction type regularly used by entities who offer BNPL products to waiver payments amount of their customers who meet their internal regulations and policies h3. Configuration # User should be able to configure payment allocations for the Payment waiver transaction type at loan product level ## both at loan product creation and modify level h3. Transaction requirements # User should be able to pass a new transaction on a Active/Closed loan account through API # User should be able to undo/modify the transaction posted # Transaction amount should obey the payment allocation order set at the “advance allocation strategy” # Reverse replay will work the same as of any other transaction type # Charge-back can be done on payment waiver transaction type This transaction type working is same as of “goodwill credit transaction” and “refund transaction” h3. Schedule Requirements # Repayment schedule allocation for Payment Waiver will happen as per the advance repayment strategy set. same as goodwill credit,refund transaction allocations # Reverse replay allocation will work the same h3. UI changes # User should be configure “Payment Waiver” transaction in Advance Payment Strategy at Loan product level (both at product creation/modify level) # User should be able to post “payment Waiver” transaction on the active/closed loan account ## “payment waiver” transaction should be visible on the transaction tab ## User should be able to undo/modify the transaction on the UI ## User should be able to do charge-back from the UI # UI actions similar to goodwill credit transaction h3. Accounting Entries Journal entries to be passed for 'Payment Waiver' transaction for loan account *For non charge-off loan accounts* ||Entry Type ||Accounting Type in Loan Product ||GL-Code ||GL-Name in Loan Product ||Type of CoA ||Logic for calculating the Amount for passing the entries || |Debit|Income from Interest (Income section)|404000|Interest Income|Income|Total Amount entered for 'Payment Waiver' transaction| |Credit|Loan portfolio (Asset secion)|112601|Loans Receivable|Asset|total Principal portion which got allocated| |Credit|Interest Receivable(Asset Portion)|112603|fees/Interest Receivable|Asset|total interest portion which got allocated| |Credit|Fees Receivable (fees portion|112603|fees/Interest Receivable|Asset|total fees portion which got allocated| *Reversal entry for Non charge-off loan account* ||Entry Type ||Accounting Type in Loan Product ||GL-Code ||GL-Name in Loan Product ||Type of CoA ||Logic for calculating the Amount for passing the entries || |Credit|Income from Interest (Income section)|404000|Interest Income|Income|Total Amount entered for 'Payment Waiver' transaction| |Debit|Loan portfolio (Asset secion)|112601|Loans Receivable|Asset|total Principal portion which got allocated| |Debit|Interest Receivable(Asset Portion)|112603|fees/Interest Receivable|Asset|total interest portion which got allocated| |Debit|Fees Receivable (fees portion|112603|fees/Interest Receivable|Asset|total fees portion which got allocated| *For charge-off loan accounts* ||Entry Type ||Accounting Type in Loan Product ||GL-Code ||GL-Name in Loan Product ||Type of CoA ||Logic for calculating the Amount for passing the entries || |Debit|Income from Interest (Income section)|404000|Interest Income|Income|Total Amount entered for 'Payment Waiver' transaction| |Credit|Income from charge-off Interest (Income secion)|404001|Interest income charge off|Asset|total Principal portion which got allocated| |Credit|Income from charge-off Interest (Income secion)|404001|Interest income charge off|Asset|total interest portion which got allocated| |Credit|Income from charge-off Interest (Income secion)|404001|Interest income charge off|Asset|total fees portion which got allocated| *Reversal entry for charge-off loan account* ||Entry Type ||Accounting Type in Loan Product ||GL-Code ||GL-Name in Loan Product ||Type of CoA ||Logic for calculating the Amount for passing the entries || ||Entry Type ||Accounting Type in Loan Product ||GL-Code ||GL-Name in Loan Product ||Type of CoA ||Logic for calculating the Amount for passing the entries || |Credit|Income from Interest (Income section)|404000|Interest Income|Income|Total Amount entered for 'Payment Waiver' transaction| |Debit|Income from charge-off Interest (Income secion)|404001|Interest income charge off|Asset|total Principal portion which got allocated| |Debit|Income from charge-off
[jira] [Commented] (FINERACT-1957) Unpredicatable assignment of running balances to withdrawal transactions that are happening on the same involving withdrawal charges
[ https://issues.apache.org/jira/browse/FINERACT-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840434#comment-17840434 ] Bharath Gowda commented on FINERACT-1957: - [~kigred.developer] looks like a valid issue and explanation looks OK for developer to start. It would much clear if there was a reproducible steps as well as an additional support because as you mentioned it is happening only at sometimes..so if that time is clear it could me more easier to fix I believe. > Unpredicatable assignment of running balances to withdrawal transactions that > are happening on the same involving withdrawal charges > > > Key: FINERACT-1957 > URL: https://issues.apache.org/jira/browse/FINERACT-1957 > Project: Apache Fineract > Issue Type: Improvement > Components: Savings >Affects Versions: 1.7.3, 1.7.2, 1.8.3, 1.8.2 >Reporter: Kigenyi Wilfred >Assignee: Francis Guchie >Priority: Major > Fix For: 1.10.0 > > Attachments: WithdrawalTransactions1.png, WithdrawalTransactions2.png > > > Consider a savings a account that has automatic withdraw charges of 1%. When > a withdraw transaction of happens it will automatically cause a withdrawal > charge transaction to happen at the same time. Both these transactions will > be listed on the account but running balances on the two transactions are > some times interchanged. > Attached is a screenshot of case. > In the ScreenShot1, the latest transaction (with ID = 71890) is not assigned > the correct account balance and that balance is instead assigned to the > second last transaction (id = 718889) > In the ScreenShot2, the latest transaction is assigned the correct account > balance which is correct. However this behavior is unpredictable in other > words one one cannot reliably tell the account balance by looking at the > running balance of the latest transaction. There should be consistence, that > is, the latest transaction on account should reliably be assigned the current > account balance. > This inconsistency can lead errors when when determining the opening and > closing balance when making a report about an account considering an opening > date and a closing date. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-2074) savings module: System is posting Interest on a Zero balance savings account account
Bharath Gowda created FINERACT-2074: --- Summary: savings module: System is posting Interest on a Zero balance savings account account Key: FINERACT-2074 URL: https://issues.apache.org/jira/browse/FINERACT-2074 Project: Apache Fineract Issue Type: Bug Affects Versions: 1.9.0 Reporter: Bharath Gowda Attachments: savings product configuration.png, transactions.png In a very particular Usecase system is posting Interest on the savings account where the balance amount is zero To reproduce # create a simple savings product(product configuration shared in attachment) # create a savings account from that product and do the transactions as attached in the transaction screenshot to reproduce you can login and check the test loan account reproduced here [https://advancly-dev.mifos.community/#/clients/13/savings-accounts/171/transactions] mifos/password -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-2063) Enable repayment of overdue installments
[ https://issues.apache.org/jira/browse/FINERACT-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17828320#comment-17828320 ] Bharath Gowda commented on FINERACT-2063: - [~kigred.developer] [~adamsaghy] [~francisguchie] [~ikimbrah] I think the idea is good but I don't feel comfortable in changing the existing behavior of standing instructions My suggestion We can introduce a new checkbox (collect overdue installment first) in the standing instruction configuration when enabled the job will collect the oldest unpaid installments first(depending on the balance in savings account) When the checkbox is disabled- it only collects the installment amount that is due on that current day(existing behavior) and by default the checkbox should be disabled to retain the existing behavior as default. Thoughts? > Enable repayment of overdue installments > > > Key: FINERACT-2063 > URL: https://issues.apache.org/jira/browse/FINERACT-2063 > Project: Apache Fineract > Issue Type: Improvement > Components: Loan >Affects Versions: 1.9.0 >Reporter: Kigenyi Wilfred >Priority: Minor > Fix For: 1.10.0 > > > Currently the standing instruction task will only execute a transfer if the > loan installment in question is for the exact date as the date on which the > task is running. This means that if for example a client had an installment > due for the day before (or several days before), that installment will not be > settled if the client deposits funds on his savings account today or the next > day. > The thinking is that installments should be settled as longs as they are not > in the future, that is if the are today or they are overdue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1964) Fixed Deposit Enhancement- calculcate Interest during the FD creation phase
[
https://issues.apache.org/jira/browse/FINERACT-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826975#comment-17826975
]
Bharath Gowda commented on FINERACT-1964:
-
[~adamsaghy] [~ruhiu] [~uddyangoyal] I think the formula and strategy used is
correct for calculating and checking the interest during the creation phase.
I could still see small amount difference when the actual FD account is created
In this example
Formula gave:13448.89
system gave(after creation)" 13450.15
Difference is around 1.26
The difference could be because of lot of other parameters considered like
Interest calculation using, No of days in a year, and rounding on each interest
postings and calculation, FD starting day.. etc
So I believe we can go ahead with this formula for showing the result before
creating the FD account but we should also show a message on the screen that
"This is an approximate calculated amount - it may vary slightly when the
account is created"
Thoughts?
> Fixed Deposit Enhancement- calculcate Interest during the FD creation phase
>
>
> Key: FINERACT-1964
> URL: https://issues.apache.org/jira/browse/FINERACT-1964
> Project: Apache Fineract
> Issue Type: Improvement
>Reporter: Bharath Gowda
>Priority: Major
> Attachments: image-2024-03-13-07-23-46-822.png,
> image-2024-03-13-07-25-22-987.png
>
>
> *As a* user
> *I want system* to calculate the interest of the Fixed deposit account before
> the account creation
> *in order to* give flexibility to the customers to know their liability
> before account creation
> h4. *Background and details:*
> Need to add a new capability to calculate *interest for fixed deposit
> savings* based on the interest posting period and interest compounding period
> before the creation of the fixed deposit saving.
> This enhancement will empower the customers to have a comprehensive preview
> of the interest that will be accrued at the maturity of their fixed deposit
> savings, enabling them to make informed decisions.
> To achieve this,an API endpoint is required that can perform the interest
> calculation for fixed deposit savings. The API endpoint should accept
> parameters such as the {*}principal amount, interest rate, tenure, interest
> posting period, and interest compounding period{*}. Upon receiving these
> inputs through a POST request, the endpoint should conduct the necessary
> calculations and return the maturity amount and interest earned in the
> response.
> UI button “{*}calculate Interest{*}” should be available on create fixed
> deposit account view screen for users to know the interest after entering all
> the parameteres
>
> Ex API:
> *POST* /api/calculate-fixed-deposit-interest
> *Request Body:*
> {
> "principal_amount": 1, // The initial amount deposited
> "interest_rate": 5, // Annual interest rate (in percentage)
> "tenure": 12, // Number of months for which the FD is held
> "interest_posting_period": 3, // Posting period of interest (in months)
> "interest_compounding_period": 1 // Compounding period of interest (in
> months)
> }{*}Response Body:{*}
> {
> "maturity_amount": 10512.5, // Total amount at maturity (including interest)
> "interest_earned": 512.5 // Interest earned during the tenure
> }
> *Acceptance criteria*
> # I want to be able to calculate the interest on Fixed deposit during
> account creation phase
> # a button should be available on the UI for users to calculate and show the
> interest based on the parameters entered ({*}principal amount, interest rate,
> tenure, interest posting period, and interest compounding period{*})
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FINERACT-2062) Use 48 weeks in a year when interest rate is per month
[ https://issues.apache.org/jira/browse/FINERACT-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825700#comment-17825700 ] Bharath Gowda commented on FINERACT-2062: - [~adamsaghy] we will not get these scenarios when we use the Interest Method as "declining balance" as it considers the "repayment calculation period" for calculation the interest But for Interest Method as "FLAT" it only considers the interest rate and the amount. So Even though it looks weird I am not able to think of an alternative solution for the problem [~kigred.developer] has described. Just a thought? Will it help if we add the capability of adding the interest rate per week instead of using 48 weeks in a year calculation only when the Interest method is "FLAT"? > Use 48 weeks in a year when interest rate is per month > -- > > Key: FINERACT-2062 > URL: https://issues.apache.org/jira/browse/FINERACT-2062 > Project: Apache Fineract > Issue Type: Improvement > Components: Loan >Affects Versions: 1.9.0 >Reporter: Kigenyi Wilfred >Priority: Minor > Fix For: 1.10.0 > > > Given that the interest rate period on a loan is monthly and client has > chosen to make weekly repayments, it makes more sense to assume that there > are 4 weeks in the month and 12 months in the year which comes to 48 weeks > rather than assuming the traditional 52 weeks in the year. > For example if a loan has a flat interest rate of 2% Per month and the > principal is 1000 and the repayments are weekly, weekly interest is currently > computed as follows: > interest per week = (0.02*12*1000)/52 = 4.61538 > it would make more sense if interest per month is computed as follows: > interest per week = (0.02*12*1000)/48 = 5 > > In other words there is no need for computing weeks in a year when we are > dealing with a month. There are 4 weeks in a month and this assumption > calculates a more reasonable figure as compared to when we compute weeks in > year. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1964) Fixed Deposit Enhancement- calculcate Interest during the FD creation phase
[
https://issues.apache.org/jira/browse/FINERACT-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825357#comment-17825357
]
Bharath Gowda commented on FINERACT-1964:
-
[~adamsaghy] thanks for your review on this ticket. Yes I am ok with the
implemntation is done through GET Request.
> Fixed Deposit Enhancement- calculcate Interest during the FD creation phase
>
>
> Key: FINERACT-1964
> URL: https://issues.apache.org/jira/browse/FINERACT-1964
> Project: Apache Fineract
> Issue Type: Improvement
>Reporter: Bharath Gowda
>Priority: Major
>
> *As a* user
> *I want system* to calculate the interest of the Fixed deposit account before
> the account creation
> *in order to* give flexibility to the customers to know their liability
> before account creation
> h4. *Background and details:*
> Need to add a new capability to calculate *interest for fixed deposit
> savings* based on the interest posting period and interest compounding period
> before the creation of the fixed deposit saving.
> This enhancement will empower the customers to have a comprehensive preview
> of the interest that will be accrued at the maturity of their fixed deposit
> savings, enabling them to make informed decisions.
> To achieve this,an API endpoint is required that can perform the interest
> calculation for fixed deposit savings. The API endpoint should accept
> parameters such as the {*}principal amount, interest rate, tenure, interest
> posting period, and interest compounding period{*}. Upon receiving these
> inputs through a POST request, the endpoint should conduct the necessary
> calculations and return the maturity amount and interest earned in the
> response.
> UI button “{*}calculate Interest{*}” should be available on create fixed
> deposit account view screen for users to know the interest after entering all
> the parameteres
>
> Ex API:
> *POST* /api/calculate-fixed-deposit-interest
> *Request Body:*
> {
> "principal_amount": 1, // The initial amount deposited
> "interest_rate": 5, // Annual interest rate (in percentage)
> "tenure": 12, // Number of months for which the FD is held
> "interest_posting_period": 3, // Posting period of interest (in months)
> "interest_compounding_period": 1 // Compounding period of interest (in
> months)
> }{*}Response Body:{*}
> {
> "maturity_amount": 10512.5, // Total amount at maturity (including interest)
> "interest_earned": 512.5 // Interest earned during the tenure
> }
> *Acceptance criteria*
> # I want to be able to calculate the interest on Fixed deposit during
> account creation phase
> # a button should be available on the UI for users to calculate and show the
> interest based on the parameters entered ({*}principal amount, interest rate,
> tenure, interest posting period, and interest compounding period{*})
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FINERACT-2018) Savings module: Exception Error messages should show the related account No as well where ever account ID is shown
[ https://issues.apache.org/jira/browse/FINERACT-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17819091#comment-17819091 ] Bharath Gowda commented on FINERACT-2018: - [~pushkal-9], [~josealbertohm] was working on the same and he is currently assigned to the ticket. Let me get update from him on the same and let you know > Savings module: Exception Error messages should show the related account No > as well where ever account ID is shown > -- > > Key: FINERACT-2018 > URL: https://issues.apache.org/jira/browse/FINERACT-2018 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Bharath Gowda >Assignee: Jose Alberto Hernandez Maldonado >Priority: Major > > In Savings module - Exception Error messages should show the related account > No as well where ever account ID is shown > For example > 1.Create a savings account and block the deposit > 2.Do account transfer of money from another savings account to the blocked > savings account > Error message shows that "savings ID ** is blocked" > for a User savings Acccount ID is more readable than the savings ID hence we > need to include the Account Number as well in all the error messages that are > displaying the savings ID -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1964) Fixed Deposit Enhancement- calculcate Interest during the FD creation phase
[
https://issues.apache.org/jira/browse/FINERACT-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814395#comment-17814395
]
Bharath Gowda commented on FINERACT-1964:
-
No You can take up this ticket [~uddyangoyal]
Thank you for looking into this
> Fixed Deposit Enhancement- calculcate Interest during the FD creation phase
>
>
> Key: FINERACT-1964
> URL: https://issues.apache.org/jira/browse/FINERACT-1964
> Project: Apache Fineract
> Issue Type: Improvement
>Reporter: Bharath Gowda
>Priority: Major
>
> *As a* user
> *I want system* to calculate the interest of the Fixed deposit account before
> the account creation
> *in order to* give flexibility to the customers to know their liability
> before account creation
> h4. *Background and details:*
> Need to add a new capability to calculate *interest for fixed deposit
> savings* based on the interest posting period and interest compounding period
> before the creation of the fixed deposit saving.
> This enhancement will empower the customers to have a comprehensive preview
> of the interest that will be accrued at the maturity of their fixed deposit
> savings, enabling them to make informed decisions.
> To achieve this,an API endpoint is required that can perform the interest
> calculation for fixed deposit savings. The API endpoint should accept
> parameters such as the {*}principal amount, interest rate, tenure, interest
> posting period, and interest compounding period{*}. Upon receiving these
> inputs through a POST request, the endpoint should conduct the necessary
> calculations and return the maturity amount and interest earned in the
> response.
> UI button “{*}calculate Interest{*}” should be available on create fixed
> deposit account view screen for users to know the interest after entering all
> the parameteres
>
> Ex API:
> *POST* /api/calculate-fixed-deposit-interest
> *Request Body:*
> {
> "principal_amount": 1, // The initial amount deposited
> "interest_rate": 5, // Annual interest rate (in percentage)
> "tenure": 12, // Number of months for which the FD is held
> "interest_posting_period": 3, // Posting period of interest (in months)
> "interest_compounding_period": 1 // Compounding period of interest (in
> months)
> }{*}Response Body:{*}
> {
> "maturity_amount": 10512.5, // Total amount at maturity (including interest)
> "interest_earned": 512.5 // Interest earned during the tenure
> }
> *Acceptance criteria*
> # I want to be able to calculate the interest on Fixed deposit during
> account creation phase
> # a button should be available on the UI for users to calculate and show the
> interest based on the parameters entered ({*}principal amount, interest rate,
> tenure, interest posting period, and interest compounding period{*})
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (FINERACT-1964) Fixed Deposit Enhancement- calculcate Interest during the FD creation phase
[
https://issues.apache.org/jira/browse/FINERACT-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814395#comment-17814395
]
Bharath Gowda edited comment on FINERACT-1964 at 2/5/24 3:10 PM:
-
No, You can take up this ticket [~uddyangoyal]
Thank you for looking into this
was (Author: bgowda):
No You can take up this ticket [~uddyangoyal]
Thank you for looking into this
> Fixed Deposit Enhancement- calculcate Interest during the FD creation phase
>
>
> Key: FINERACT-1964
> URL: https://issues.apache.org/jira/browse/FINERACT-1964
> Project: Apache Fineract
> Issue Type: Improvement
>Reporter: Bharath Gowda
>Priority: Major
>
> *As a* user
> *I want system* to calculate the interest of the Fixed deposit account before
> the account creation
> *in order to* give flexibility to the customers to know their liability
> before account creation
> h4. *Background and details:*
> Need to add a new capability to calculate *interest for fixed deposit
> savings* based on the interest posting period and interest compounding period
> before the creation of the fixed deposit saving.
> This enhancement will empower the customers to have a comprehensive preview
> of the interest that will be accrued at the maturity of their fixed deposit
> savings, enabling them to make informed decisions.
> To achieve this,an API endpoint is required that can perform the interest
> calculation for fixed deposit savings. The API endpoint should accept
> parameters such as the {*}principal amount, interest rate, tenure, interest
> posting period, and interest compounding period{*}. Upon receiving these
> inputs through a POST request, the endpoint should conduct the necessary
> calculations and return the maturity amount and interest earned in the
> response.
> UI button “{*}calculate Interest{*}” should be available on create fixed
> deposit account view screen for users to know the interest after entering all
> the parameteres
>
> Ex API:
> *POST* /api/calculate-fixed-deposit-interest
> *Request Body:*
> {
> "principal_amount": 1, // The initial amount deposited
> "interest_rate": 5, // Annual interest rate (in percentage)
> "tenure": 12, // Number of months for which the FD is held
> "interest_posting_period": 3, // Posting period of interest (in months)
> "interest_compounding_period": 1 // Compounding period of interest (in
> months)
> }{*}Response Body:{*}
> {
> "maturity_amount": 10512.5, // Total amount at maturity (including interest)
> "interest_earned": 512.5 // Interest earned during the tenure
> }
> *Acceptance criteria*
> # I want to be able to calculate the interest on Fixed deposit during
> account creation phase
> # a button should be available on the UI for users to calculate and show the
> interest based on the parameters entered ({*}principal amount, interest rate,
> tenure, interest posting period, and interest compounding period{*})
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (FINERACT-2019) deposit button not working on RD account
[ https://issues.apache.org/jira/browse/FINERACT-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharath Gowda closed FINERACT-2019. --- Resolution: Fixed > deposit button not working on RD account > > > Key: FINERACT-2019 > URL: https://issues.apache.org/jira/browse/FINERACT-2019 > Project: Apache Fineract > Issue Type: Bug >Reporter: Bharath Gowda >Assignee: Jose Alberto Hernandez Maldonado >Priority: Major > Attachments: image.png > > > deposit button not working on RD account > To reproduce > # create and active a RD account > # try to deposit the amount > it throws a error message > > Expected result: user should be able to do deposit on the RD account > > screenshot > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-2019) deposit button not working on RD account
[ https://issues.apache.org/jira/browse/FINERACT-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814346#comment-17814346 ] Bharath Gowda commented on FINERACT-2019: - [~uddyangoyal] it was a back-end issue I guess and it was fixed by [~josealbertohm] . Closing this ticket accordingly > deposit button not working on RD account > > > Key: FINERACT-2019 > URL: https://issues.apache.org/jira/browse/FINERACT-2019 > Project: Apache Fineract > Issue Type: Bug >Reporter: Bharath Gowda >Assignee: Jose Alberto Hernandez Maldonado >Priority: Major > Attachments: image.png > > > deposit button not working on RD account > To reproduce > # create and active a RD account > # try to deposit the amount > it throws a error message > > Expected result: user should be able to do deposit on the RD account > > screenshot > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (FINERACT-2033) View charge page does not show minimum and maximum charge cap values
[
https://issues.apache.org/jira/browse/FINERACT-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bharath Gowda closed FINERACT-2033.
---
Resolution: Not A Bug
> View charge page does not show minimum and maximum charge cap values
>
>
> Key: FINERACT-2033
> URL: https://issues.apache.org/jira/browse/FINERACT-2033
> Project: Apache Fineract
> Issue Type: Bug
>Reporter: Bharath Gowda
>Priority: Major
> Attachments: Fineract_Charges.mp4, charges1.png, charges2.png,
> image-2023-12-25-19-27-19-425.png, image-2023-12-25-19-30-26-668.png
>
>
> Go to Admin/Products/Charges
> Select applies to savings
> !image-2023-12-25-19-27-19-425.png!
> Fill the other fields making sure to set the min and max values
> Submit
> Once the fee has been created, open the fee and note the min/max values are
> not shown
> h2. Expected Behaviour
> Min and Max values should be displayed on the view fee page
> h2. Actual Behaviour
> Min and max values are not displayed
>
> So Api: /charges
>
> When we created the charge, we sent the minCap and maxCap
> !image-2023-12-25-19-30-26-668.png!
> When we try to get details: API : api/v1/charges/4?template=false
> {
> "id": 4,
> "name": "ascdasd",
> "active": false,
> "penalty": false,
> "freeWithdrawal": false,
> "freeWithdrawalChargeFrequency": 0,
> "restartFrequency": 0,
> "restartFrequencyEnum": 0,
> "isPaymentType": false,
> "currency": \{
> "code": "USD",
> "name": "US Dollar",
> "decimalPlaces": 2,
> "displaySymbol": "$",
> "nameCode": "currency.USD",
> "displayLabel": "US Dollar ($)"
> },
> "amount": 1223.00,
> "chargeTimeType": \{
> "id": 1,
> "code": "chargeTimeType.disbursement",
> "value": "Disbursement"
> },
> "chargeAppliesTo": \{
> "id": 1,
> "code": "chargeAppliesTo.loan",
> "value": "Loan"
> },
> "chargeCalculationType": \{
> "id": 1,
> "code": "chargeCalculationType.flat",
> "value": "Flat"
> },
> "chargePaymentMode": \{
> "id": 0,
> "code": "chargepaymentmode.regular",
> "value": "Regular"
> }
> }
>
> There is no minCap and maxCap
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FINERACT-2033) View charge page does not show minimum and maximum charge cap values
[
https://issues.apache.org/jira/browse/FINERACT-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813702#comment-17813702
]
Bharath Gowda commented on FINERACT-2033:
-
Yes. Have updated the same accordingly.
> View charge page does not show minimum and maximum charge cap values
>
>
> Key: FINERACT-2033
> URL: https://issues.apache.org/jira/browse/FINERACT-2033
> Project: Apache Fineract
> Issue Type: Bug
>Reporter: Bharath Gowda
>Priority: Major
> Attachments: Fineract_Charges.mp4, charges1.png, charges2.png,
> image-2023-12-25-19-27-19-425.png, image-2023-12-25-19-30-26-668.png
>
>
> Go to Admin/Products/Charges
> Select applies to savings
> !image-2023-12-25-19-27-19-425.png!
> Fill the other fields making sure to set the min and max values
> Submit
> Once the fee has been created, open the fee and note the min/max values are
> not shown
> h2. Expected Behaviour
> Min and Max values should be displayed on the view fee page
> h2. Actual Behaviour
> Min and max values are not displayed
>
> So Api: /charges
>
> When we created the charge, we sent the minCap and maxCap
> !image-2023-12-25-19-30-26-668.png!
> When we try to get details: API : api/v1/charges/4?template=false
> {
> "id": 4,
> "name": "ascdasd",
> "active": false,
> "penalty": false,
> "freeWithdrawal": false,
> "freeWithdrawalChargeFrequency": 0,
> "restartFrequency": 0,
> "restartFrequencyEnum": 0,
> "isPaymentType": false,
> "currency": \{
> "code": "USD",
> "name": "US Dollar",
> "decimalPlaces": 2,
> "displaySymbol": "$",
> "nameCode": "currency.USD",
> "displayLabel": "US Dollar ($)"
> },
> "amount": 1223.00,
> "chargeTimeType": \{
> "id": 1,
> "code": "chargeTimeType.disbursement",
> "value": "Disbursement"
> },
> "chargeAppliesTo": \{
> "id": 1,
> "code": "chargeAppliesTo.loan",
> "value": "Loan"
> },
> "chargeCalculationType": \{
> "id": 1,
> "code": "chargeCalculationType.flat",
> "value": "Flat"
> },
> "chargePaymentMode": \{
> "id": 0,
> "code": "chargepaymentmode.regular",
> "value": "Regular"
> }
> }
>
> There is no minCap and maxCap
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FINERACT-2033) View charge page does not show minimum and maximum charge cap values
[
https://issues.apache.org/jira/browse/FINERACT-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813647#comment-17813647
]
Bharath Gowda commented on FINERACT-2033:
-
[~uddyangoyal] [~ruhiu] Thank you for debugging this issue.
The condition that is present now i.e to have maxcap and mincap only for %
parameters is valid and as per the business use case. we cannot have it open
without any condition because when the chargeCalculationType is set to FLAT
then there is no use for mincap and maxcap values as the charge value always
remains the same amount.
But in % based on any amount the value might change hence the mincap and maxcap
are required for % amount and implemented only for that.
This issue was initially raised here thinking it could be a back-end issue..but
after analysis this was an UI issue that was addressed under the ticket
[https://github.com/openMF/web-app/issues/1923]
But this ticket was not updated accordingly.
Let me know if you have any questions
> View charge page does not show minimum and maximum charge cap values
>
>
> Key: FINERACT-2033
> URL: https://issues.apache.org/jira/browse/FINERACT-2033
> Project: Apache Fineract
> Issue Type: Bug
>Reporter: Bharath Gowda
>Priority: Major
> Attachments: Fineract_Charges.mp4, charges1.png, charges2.png,
> image-2023-12-25-19-27-19-425.png, image-2023-12-25-19-30-26-668.png
>
>
> Go to Admin/Products/Charges
> Select applies to savings
> !image-2023-12-25-19-27-19-425.png!
> Fill the other fields making sure to set the min and max values
> Submit
> Once the fee has been created, open the fee and note the min/max values are
> not shown
> h2. Expected Behaviour
> Min and Max values should be displayed on the view fee page
> h2. Actual Behaviour
> Min and max values are not displayed
>
> So Api: /charges
>
> When we created the charge, we sent the minCap and maxCap
> !image-2023-12-25-19-30-26-668.png!
> When we try to get details: API : api/v1/charges/4?template=false
> {
> "id": 4,
> "name": "ascdasd",
> "active": false,
> "penalty": false,
> "freeWithdrawal": false,
> "freeWithdrawalChargeFrequency": 0,
> "restartFrequency": 0,
> "restartFrequencyEnum": 0,
> "isPaymentType": false,
> "currency": \{
> "code": "USD",
> "name": "US Dollar",
> "decimalPlaces": 2,
> "displaySymbol": "$",
> "nameCode": "currency.USD",
> "displayLabel": "US Dollar ($)"
> },
> "amount": 1223.00,
> "chargeTimeType": \{
> "id": 1,
> "code": "chargeTimeType.disbursement",
> "value": "Disbursement"
> },
> "chargeAppliesTo": \{
> "id": 1,
> "code": "chargeAppliesTo.loan",
> "value": "Loan"
> },
> "chargeCalculationType": \{
> "id": 1,
> "code": "chargeCalculationType.flat",
> "value": "Flat"
> },
> "chargePaymentMode": \{
> "id": 0,
> "code": "chargepaymentmode.regular",
> "value": "Regular"
> }
> }
>
> There is no minCap and maxCap
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (FINERACT-2031) Holiday not working as expected with setting "reschedule to next repayment date"
[
https://issues.apache.org/jira/browse/FINERACT-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bharath Gowda resolved FINERACT-2031.
-
Resolution: Fixed
> Holiday not working as expected with setting "reschedule to next repayment
> date"
>
>
> Key: FINERACT-2031
> URL: https://issues.apache.org/jira/browse/FINERACT-2031
> Project: Apache Fineract
> Issue Type: Bug
>Reporter: Bharath Gowda
>Assignee: Vinodh Kumar Katukota
>Priority: Major
> Fix For: 1.10.0
>
>
> Holiday not working as expected with setting "reschedule to next repayment
> date"
>
> To Reproduce
> # Create a 15 days frequency repayment schedule loan account with repayments
> starting from 1st January.
> # Create a holiday with "{*}from date{*}" & "{*}to date{*}" as 1st January
> and "{*}repayment schedule type{*}" as "reschedule to next repayment date"
> # Run the scheduler job and check the loan account repayment schedule
> # check the loan account repayment schedule
> The schedule is not getting changed
> *Expected Result*
> Schedule should shift all the remaining installments to next repayment date
> as per the loan frequency
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FINERACT-2031) Holiday not working as expected with setting "reschedule to next repayment date"
[
https://issues.apache.org/jira/browse/FINERACT-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800713#comment-17800713
]
Bharath Gowda commented on FINERACT-2031:
-
[~2vinodhkumar] yes you are right.
Thanks for raising the PR for the same. I have requested Adam to review the PR.
> Holiday not working as expected with setting "reschedule to next repayment
> date"
>
>
> Key: FINERACT-2031
> URL: https://issues.apache.org/jira/browse/FINERACT-2031
> Project: Apache Fineract
> Issue Type: Bug
>Reporter: Bharath Gowda
>Priority: Major
> Fix For: 1.10.0
>
>
> Holiday not working as expected with setting "reschedule to next repayment
> date"
>
> To Reproduce
> # Create a 15 days frequency repayment schedule loan account with repayments
> starting from 1st January.
> # Create a holiday with "{*}from date{*}" & "{*}to date{*}" as 1st January
> and "{*}repayment schedule type{*}" as "reschedule to next repayment date"
> # Run the scheduler job and check the loan account repayment schedule
> # check the loan account repayment schedule
> The schedule is not getting changed
> *Expected Result*
> Schedule should shift all the remaining installments to next repayment date
> as per the loan frequency
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (FINERACT-2033) View charge page does not show minimum and maximum charge cap values
Bharath Gowda created FINERACT-2033:
---
Summary: View charge page does not show minimum and maximum charge
cap values
Key: FINERACT-2033
URL: https://issues.apache.org/jira/browse/FINERACT-2033
Project: Apache Fineract
Issue Type: Bug
Reporter: Bharath Gowda
Attachments: image-2023-12-25-19-27-19-425.png,
image-2023-12-25-19-30-26-668.png
Go to Admin/Products/Charges
Select applies to savings
!image-2023-12-25-19-27-19-425.png!
Fill the other fields making sure to set the min and max values
Submit
Once the fee has been created, open the fee and note the min/max values are not
shown
h2. Expected Behaviour
Min and Max values should be displayed on the view fee page
h2. Actual Behaviour
Min and max values are not displayed
So Api: /charges
When we created the charge, we sent the minCap and maxCap
!image-2023-12-25-19-30-26-668.png!
When we try to get details: API : api/v1/charges/4?template=false
{
"id": 4,
"name": "ascdasd",
"active": false,
"penalty": false,
"freeWithdrawal": false,
"freeWithdrawalChargeFrequency": 0,
"restartFrequency": 0,
"restartFrequencyEnum": 0,
"isPaymentType": false,
"currency": \{
"code": "USD",
"name": "US Dollar",
"decimalPlaces": 2,
"displaySymbol": "$",
"nameCode": "currency.USD",
"displayLabel": "US Dollar ($)"
},
"amount": 1223.00,
"chargeTimeType": \{
"id": 1,
"code": "chargeTimeType.disbursement",
"value": "Disbursement"
},
"chargeAppliesTo": \{
"id": 1,
"code": "chargeAppliesTo.loan",
"value": "Loan"
},
"chargeCalculationType": \{
"id": 1,
"code": "chargeCalculationType.flat",
"value": "Flat"
},
"chargePaymentMode": \{
"id": 0,
"code": "chargepaymentmode.regular",
"value": "Regular"
}
}
There is no minCap and maxCap
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (FINERACT-2032) Maker and Checker Functionality not working
Bharath Gowda created FINERACT-2032: --- Summary: Maker and Checker Functionality not working Key: FINERACT-2032 URL: https://issues.apache.org/jira/browse/FINERACT-2032 Project: Apache Fineract Issue Type: Bug Reporter: Bharath Gowda Attachments: Screen Recording 2023-12-24 at 12.56.13 PM.mov h2. Steps to Reproduce # enable maker-checker at the admin-> system->configuration level # go to admin->system->configure maker and checker tasks. * make sure "activate client" is checked # Now go and create a client # client on activate client -System will activate the client by bypassing the maker and checker rule h2. Expected Behaviour System should hold the activation in pending and user with checker permission should approve or reject from "checker inbox and tasks menu *NOTE:* *1.This is working as expected in old version may be in 1.6 but currently not working on develop branch,* you can check the working behavior at the [https://dev.mifos.io/] 2. This is not an UI issue Attachement contains the screenrecording of the issue[^Screen Recording 2023-12-24 at 12.56.13 PM.mov] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-2032) Maker and Checker Functionality not working
[ https://issues.apache.org/jira/browse/FINERACT-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharath Gowda updated FINERACT-2032: Fix Version/s: 1.10.0 > Maker and Checker Functionality not working > --- > > Key: FINERACT-2032 > URL: https://issues.apache.org/jira/browse/FINERACT-2032 > Project: Apache Fineract > Issue Type: Bug >Affects Versions: 1.8.4 >Reporter: Bharath Gowda >Priority: Major > Fix For: 1.10.0 > > Attachments: Screen Recording 2023-12-24 at 12.56.13 PM.mov > > > h2. Steps to Reproduce > # enable maker-checker at the admin-> system->configuration level > # go to admin->system->configure maker and checker tasks. > * make sure "activate client" is checked > # Now go and create a client > # client on activate client > -System will activate the client by bypassing the maker and checker rule > h2. Expected Behaviour > System should hold the activation in pending and user with checker permission > should approve or reject from "checker inbox and tasks menu > *NOTE:* > *1.This is working as expected in old version may be in 1.6 but currently not > working on develop branch,* > you can check the working behavior at the [https://dev.mifos.io/] > 2. This is not an UI issue > > Attachement contains the screenrecording of the issue[^Screen Recording > 2023-12-24 at 12.56.13 PM.mov] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-2032) Maker and Checker Functionality not working
[ https://issues.apache.org/jira/browse/FINERACT-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharath Gowda updated FINERACT-2032: Affects Version/s: 1.8.4 > Maker and Checker Functionality not working > --- > > Key: FINERACT-2032 > URL: https://issues.apache.org/jira/browse/FINERACT-2032 > Project: Apache Fineract > Issue Type: Bug >Affects Versions: 1.8.4 >Reporter: Bharath Gowda >Priority: Major > Attachments: Screen Recording 2023-12-24 at 12.56.13 PM.mov > > > h2. Steps to Reproduce > # enable maker-checker at the admin-> system->configuration level > # go to admin->system->configure maker and checker tasks. > * make sure "activate client" is checked > # Now go and create a client > # client on activate client > -System will activate the client by bypassing the maker and checker rule > h2. Expected Behaviour > System should hold the activation in pending and user with checker permission > should approve or reject from "checker inbox and tasks menu > *NOTE:* > *1.This is working as expected in old version may be in 1.6 but currently not > working on develop branch,* > you can check the working behavior at the [https://dev.mifos.io/] > 2. This is not an UI issue > > Attachement contains the screenrecording of the issue[^Screen Recording > 2023-12-24 at 12.56.13 PM.mov] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-2031) Holiday not working as expected with setting "reschedule to next repayment date"
Bharath Gowda created FINERACT-2031:
---
Summary: Holiday not working as expected with setting "reschedule
to next repayment date"
Key: FINERACT-2031
URL: https://issues.apache.org/jira/browse/FINERACT-2031
Project: Apache Fineract
Issue Type: Bug
Reporter: Bharath Gowda
Holiday not working as expected with setting "reschedule to next repayment date"
To Reproduce
# Create a 15 days frequency repayment schedule loan account with repayments
starting from 1st January.
# Create a holiday with "{*}from date{*}" & "{*}to date{*}" as 1st January and
"{*}repayment schedule type{*}" as "reschedule to next repayment date"
# Run the scheduler job and check the loan account repayment schedule
# check the loan account repayment schedule
The schedule is not getting changed
*Expected Result*
Schedule should shift all the remaining installments to next repayment date as
per the loan frequency
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (FINERACT-2031) Holiday not working as expected with setting "reschedule to next repayment date"
[
https://issues.apache.org/jira/browse/FINERACT-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bharath Gowda updated FINERACT-2031:
Fix Version/s: 1.10.0
> Holiday not working as expected with setting "reschedule to next repayment
> date"
>
>
> Key: FINERACT-2031
> URL: https://issues.apache.org/jira/browse/FINERACT-2031
> Project: Apache Fineract
> Issue Type: Bug
>Reporter: Bharath Gowda
>Priority: Major
> Fix For: 1.10.0
>
>
> Holiday not working as expected with setting "reschedule to next repayment
> date"
>
> To Reproduce
> # Create a 15 days frequency repayment schedule loan account with repayments
> starting from 1st January.
> # Create a holiday with "{*}from date{*}" & "{*}to date{*}" as 1st January
> and "{*}repayment schedule type{*}" as "reschedule to next repayment date"
> # Run the scheduler job and check the loan account repayment schedule
> # check the loan account repayment schedule
> The schedule is not getting changed
> *Expected Result*
> Schedule should shift all the remaining installments to next repayment date
> as per the loan frequency
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (FINERACT-2029) Client Image upload and capture not working
[
https://issues.apache.org/jira/browse/FINERACT-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bharath Gowda closed FINERACT-2029.
---
Resolution: Not A Bug
Not a Bug.
Issue exists on hosted solutions where the directly permission issues exists.
hence closing the issue
> Client Image upload and capture not working
> ---
>
> Key: FINERACT-2029
> URL: https://issues.apache.org/jira/browse/FINERACT-2029
> Project: Apache Fineract
> Issue Type: Bug
>Reporter: Bharath Gowda
>Priority: Major
> Fix For: 1.9.0
>
>
> Client Image upload not working
> To reproduce
> # create a client
> # upload client Image or capture a new image
> # and submit
> The API is throwing following error
> API https://{}/fineract-provider/api/v1/clients/571/images
> Error
> # defaultUserMessage: "Errors contain reason for domain rule violation."
> # developerMessage: "Request was understood but caused a domain rule
> violation."
> # errors: [\{,…}]
> # httpStatusCode: "403"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (FINERACT-2030) Document upload not working at client view screen
[
https://issues.apache.org/jira/browse/FINERACT-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bharath Gowda closed FINERACT-2030.
---
Resolution: Not A Bug
Not a Bug.
Issue exists on hosted solutions where the directly permission issues exists.
hence closing the issue
> Document upload not working at client view screen
> -
>
> Key: FINERACT-2030
> URL: https://issues.apache.org/jira/browse/FINERACT-2030
> Project: Apache Fineract
> Issue Type: Bug
>Reporter: Bharath Gowda
>Priority: Major
> Fix For: 1.9.0
>
>
> Documents upload not working at client view screen
> To Reproduce
> # Go to Active client
> # go to document tab and try adding any document and from identity screen
> try adding a document to a Identity
> System is throwing following error
> # defaultUserMessage: "Errors contain reason for domain rule violation."
> # developerMessage: "Request was understood but caused a domain rule
> violation."
> # errors: [\{,…}]
> # httpStatusCode: "403"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (FINERACT-2030) Document upload not working at client view screen
Bharath Gowda created FINERACT-2030:
---
Summary: Document upload not working at client view screen
Key: FINERACT-2030
URL: https://issues.apache.org/jira/browse/FINERACT-2030
Project: Apache Fineract
Issue Type: Bug
Reporter: Bharath Gowda
Fix For: 1.9.0
Documents upload not working at client view screen
To Reproduce
# Go to Active client
# go to document tab and try adding any document and from identity screen try
adding a document to a Identity
System is throwing following error
# defaultUserMessage: "Errors contain reason for domain rule violation."
# developerMessage: "Request was understood but caused a domain rule
violation."
# errors: [\{,…}]
# httpStatusCode: "403"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (FINERACT-2029) Client Image upload and capture not working
[
https://issues.apache.org/jira/browse/FINERACT-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bharath Gowda updated FINERACT-2029:
Fix Version/s: 1.9.0
> Client Image upload and capture not working
> ---
>
> Key: FINERACT-2029
> URL: https://issues.apache.org/jira/browse/FINERACT-2029
> Project: Apache Fineract
> Issue Type: Bug
>Reporter: Bharath Gowda
>Priority: Major
> Fix For: 1.9.0
>
>
> Client Image upload not working
> To reproduce
> # create a client
> # upload client Image or capture a new image
> # and submit
> The API is throwing following error
> API https://{}/fineract-provider/api/v1/clients/571/images
> Error
> # defaultUserMessage: "Errors contain reason for domain rule violation."
> # developerMessage: "Request was understood but caused a domain rule
> violation."
> # errors: [\{,…}]
> # httpStatusCode: "403"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (FINERACT-2029) Client Image upload and capture not working
Bharath Gowda created FINERACT-2029:
---
Summary: Client Image upload and capture not working
Key: FINERACT-2029
URL: https://issues.apache.org/jira/browse/FINERACT-2029
Project: Apache Fineract
Issue Type: Bug
Reporter: Bharath Gowda
Client Image upload not working
To reproduce
# create a client
# upload client Image or capture a new image
# and submit
The API is throwing following error
API https://{}/fineract-provider/api/v1/clients/571/images
Error
# defaultUserMessage: "Errors contain reason for domain rule violation."
# developerMessage: "Request was understood but caused a domain rule
violation."
# errors: [\{,…}]
# httpStatusCode: "403"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FINERACT-1958) Down payment
[
https://issues.apache.org/jira/browse/FINERACT-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793792#comment-17793792
]
Bharath Gowda commented on FINERACT-1958:
-
[~ruhiu]
The Interest calculation is based on the current Principal balance.
If we take your example
When you disburse a loan of 12000 and collect a downpayment of 2400 on the same
day then your principal balance is 9600 as of 1st Jan.
Hence the 1st Feb interest will be calculated on the 9600 balance and not 12000.
The current behavior is correct and is the expected behavior.
> Down payment
>
>
> Key: FINERACT-1958
> URL: https://issues.apache.org/jira/browse/FINERACT-1958
> Project: Apache Fineract
> Issue Type: New Feature
>Reporter: Mihaly Dallos
>Assignee: Mihaly Dallos
>Priority: Major
> Labels: PepperSoup
> Fix For: 1.10.0
>
> Attachments: Screenshot 2023-11-06 at 12.22.50.png
>
>
> {panel}
> *As a* user
> *I want to* be able to configure the down-payment option for the
> disbursements at the loan product level
> *in order to* collect the down-payment amount at the time of disbursement.
> {panel}
> h4. *Background and details:*
> Based on the loan product configuration it should be possible to collect same
> day payment as the first instalment.
> It should allow to collect multiple down payments for multiple disbursements
> of the same account.
> *Notes/Assumptions*
> # Down-payments are similar to Instalments in the system where amount
> allocations, repayment fulfilment works same as Instalment
> # Down-payment will be treated as an Instalment during calculation of
> overdue, arrears and delinquencies
> # When Payment allocation is introduced - repayment on down-payments will
> follow as per the new allocations
> # Specified due-date charges when added will be allocated to the next
> down-payment or instalment
> # When the second disbursement is reversed - the down-payment also will be
> reversed
> # It will be possible to reschedule the down-payments same as Instalments
> # Down-payment once enabled for loan product- it will be applied for all
> loan accounts of that product and all disbursements of those loan accounts
> # Down-payment % once defined at the loan product - the same % will applied
> to all disbursements of those loan accounts
> # Charge-back if applied on one of the repayments - the charge-back amount
> will be added to the next down-payment or Instalment which ever is next
> {panel:title=*Acceptance criteria*}
> # As a user I should be able to configure the down-payment option at the
> loan product level
> ## Down-payment can be configured to be collected at %[ ] amount of
> disbursement amount
> ## Option to collect down-payment automatically or should be collected
> manually by the user should be available (automatic repayment of down-payment
> [V] ){panel}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (FINERACT-2019) deposit button not working on RD account
[ https://issues.apache.org/jira/browse/FINERACT-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharath Gowda reassigned FINERACT-2019: --- Assignee: Jose Alberto Hernandez Maldonado > deposit button not working on RD account > > > Key: FINERACT-2019 > URL: https://issues.apache.org/jira/browse/FINERACT-2019 > Project: Apache Fineract > Issue Type: Bug >Reporter: Bharath Gowda >Assignee: Jose Alberto Hernandez Maldonado >Priority: Major > Attachments: image.png > > > deposit button not working on RD account > To reproduce > # create and active a RD account > # try to deposit the amount > it throws a error message > > Expected result: user should be able to do deposit on the RD account > > screenshot > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-2019) deposit button not working on RD account
Bharath Gowda created FINERACT-2019: --- Summary: deposit button not working on RD account Key: FINERACT-2019 URL: https://issues.apache.org/jira/browse/FINERACT-2019 Project: Apache Fineract Issue Type: Bug Reporter: Bharath Gowda Attachments: image.png deposit button not working on RD account To reproduce # create and active a RD account # try to deposit the amount it throws a error message Expected result: user should be able to do deposit on the RD account screenshot -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-2018) Savings module: Exception Error messages should show the related account No as well where ever account ID is shown
Bharath Gowda created FINERACT-2018: --- Summary: Savings module: Exception Error messages should show the related account No as well where ever account ID is shown Key: FINERACT-2018 URL: https://issues.apache.org/jira/browse/FINERACT-2018 Project: Apache Fineract Issue Type: Improvement Reporter: Bharath Gowda Assignee: Jose Alberto Hernandez Maldonado In Savings module - Exception Error messages should show the related account No as well where ever account ID is shown For example 1.Create a savings account and block the deposit 2.Do account transfer of money from another savings account to the blocked savings account Error message shows that "savings ID ** is blocked" for a User savings Acccount ID is more readable than the savings ID hence we need to include the Account Number as well in all the error messages that are displaying the savings ID -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-2017) Holiday not working as expected
[ https://issues.apache.org/jira/browse/FINERACT-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharath Gowda updated FINERACT-2017: Priority: Blocker (was: Major) > Holiday not working as expected > --- > > Key: FINERACT-2017 > URL: https://issues.apache.org/jira/browse/FINERACT-2017 > Project: Apache Fineract > Issue Type: Bug >Reporter: Bharath Gowda >Priority: Blocker > Attachments: holidays.mov > > > To reproduce > # Create a holiday with start and end date as 10th Nov 2023 and repayments > scheduled to a specified due date = 11th Nov 2023 > 2. Create a loan account with disbursement date as 13th Oct 2023. This will > create a loan with repayments that fall on 13th of every month > 3. Run the apply holiday job to loans job > Pre-conditions: > The following configurations are turned on: > - reschedule-repayments-on-holidays > Issue: > Upon job run, the repayment schedule for this loan gets updated to 11th Nov > 2023, even though the repayment was not due on 10th but 13th I observed that > if another holiday is created with a different specified date, all loans in > the system get updated with that date as the repayment date > > Expected Result- > Only the Schedule that falls between the holiday period should be rescheduled -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-2017) Holiday not working as expected
Bharath Gowda created FINERACT-2017: --- Summary: Holiday not working as expected Key: FINERACT-2017 URL: https://issues.apache.org/jira/browse/FINERACT-2017 Project: Apache Fineract Issue Type: Bug Reporter: Bharath Gowda Attachments: holidays.mov To reproduce # Create a holiday with start and end date as 10th Nov 2023 and repayments scheduled to a specified due date = 11th Nov 2023 2. Create a loan account with disbursement date as 13th Oct 2023. This will create a loan with repayments that fall on 13th of every month 3. Run the apply holiday job to loans job Pre-conditions: The following configurations are turned on: - reschedule-repayments-on-holidays Issue: Upon job run, the repayment schedule for this loan gets updated to 11th Nov 2023, even though the repayment was not due on 10th but 13th I observed that if another holiday is created with a different specified date, all loans in the system get updated with that date as the repayment date Expected Result- Only the Schedule that falls between the holiday period should be rescheduled -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-225) If Loan rescheduling page is submitted with out checking any checkboxes then error message displayed is not proper
[ https://issues.apache.org/jira/browse/FINERACT-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767579#comment-17767579 ] Bharath Gowda commented on FINERACT-225: [~edcable] Not able to reproduce and not getting any error. The system is going through the reschedule without any changes to the repayment schedule. > If Loan rescheduling page is submitted with out checking any checkboxes then > error message displayed is not proper > -- > > Key: FINERACT-225 > URL: https://issues.apache.org/jira/browse/FINERACT-225 > Project: Apache Fineract > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: subramanyasn >Priority: Minor > Labels: 2019-mifos-gsoc, GCI-2019, Triage, Volunteer, gsoc, p2 > Fix For: 3.0.0 > > Attachments: Reschedule loan.png > > > Error message displayed as > "validation.msg.rescheduleloan.graceOnPrincipal.cannot.be.blank" if no check > box is checked. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-1981) Multi Disbursement Repayment Schedule calculation Enhancement
Bharath Gowda created FINERACT-1981: --- Summary: Multi Disbursement Repayment Schedule calculation Enhancement Key: FINERACT-1981 URL: https://issues.apache.org/jira/browse/FINERACT-1981 Project: Apache Fineract Issue Type: Improvement Reporter: Bharath Gowda Attachments: Repayment schedule handling for mutli disubrsements.xlsx *Background and Details* The Legacy Repayment schedule calculation in Fineract for Multi Tranche Loan is Recalculating and regenerating the schedule for the whole disbursement amount (all tranche included when ever a new disbursement comes in) There should be an option where the Disbursement amount should be distributed to the future installments only and should not recalculate the schedule or installments that happened before the disbursement date This is the expected behavior for products like Wallets, Digital lending, Line of Credit. Same can be achieved through configuration where the Legacy calculation is not impacted -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1981) Multi Disbursement Repayment Schedule calculation Enhancement
[ https://issues.apache.org/jira/browse/FINERACT-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharath Gowda updated FINERACT-1981: Attachment: Repayment schedule handling for mutli disubrsements.xlsx > Multi Disbursement Repayment Schedule calculation Enhancement > - > > Key: FINERACT-1981 > URL: https://issues.apache.org/jira/browse/FINERACT-1981 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Bharath Gowda >Priority: Major > Attachments: Repayment schedule handling for mutli disubrsements.xlsx > > > *Background and Details* > The Legacy Repayment schedule calculation in Fineract for Multi Tranche Loan > is Recalculating and regenerating the schedule for the whole disbursement > amount (all tranche included when ever a new disbursement comes in) > There should be an option where the Disbursement amount should be distributed > to the future installments only and should not recalculate the schedule or > installments that happened before the disbursement date > This is the expected behavior for products like Wallets, Digital lending, > Line of Credit. > Same can be achieved through configuration where the Legacy calculation is > not impacted -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-580) Dashboard summary
[ https://issues.apache.org/jira/browse/FINERACT-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763788#comment-17763788 ] Bharath Gowda commented on FINERACT-580: [~edcable] Yes you are right but we will have to discuss with Pushpendra for more details > Dashboard summary > - > > Key: FINERACT-580 > URL: https://issues.apache.org/jira/browse/FINERACT-580 > Project: Apache Fineract > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: sangamesh >Priority: Major > Labels: GSOC, appears-unactionable, p1 > Fix For: 3.0.0 > > > Dashboard summary- Dashboard is not working as expected it doesn't show's up > the values. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-513) Reverse Overdue Charges Application
[ https://issues.apache.org/jira/browse/FINERACT-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763787#comment-17763787 ] Bharath Gowda commented on FINERACT-513: [~edcable] this feature is not valid anymore. as we have introduced the features like charge refund, waiver reversals and charge adjustments . > Reverse Overdue Charges Application > --- > > Key: FINERACT-513 > URL: https://issues.apache.org/jira/browse/FINERACT-513 > Project: Apache Fineract > Issue Type: Improvement > Components: Charges, Loan, System >Affects Versions: 1.8.0 >Reporter: Adriana Pinto >Priority: Major > Labels: Triage, external, gsoc, p1 > Fix For: 3.0.0 > > Attachments: FINERACT-513.pdf > > > We've been working on having a complete functionality of our approach, but we > got an issue at the moment of applying overdue charges when running the job: > Is there any workaround to reverse the overdue charges application? > This is necessary, because the overdue charges are being applied daily, but > if the repayment is made before applying the charges, but it is not > registered at the system, we need to reverse the calculation and "remove" > this charges from the final outstanding. > +*Current Business behaviour*+: When the client makes a repayment, it might > not be registered in the system until some days or weeks later, then the > overdue charges if are applied daily, have to be reversed from de current > date until the date the repayment was done. > Then, it is the approach we are looking for. > We had already figured out the "Waiving charges" process, but it would work > better if there was a job doing the contrary process of applying overdue > charges, like "Reverse overdue charges" by date or any moment in a specified > time. > **The attachment (FINERACT-513.pdf) shows the funtionality in a more specific > way. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-520) The field for "is staff" in the client creation does not store data
[ https://issues.apache.org/jira/browse/FINERACT-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763786#comment-17763786 ] Bharath Gowda commented on FINERACT-520: [~edcable] not able to reproduce the issue. value is getting retained > The field for "is staff" in the client creation does not store data > > > Key: FINERACT-520 > URL: https://issues.apache.org/jira/browse/FINERACT-520 > Project: Apache Fineract > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: Mexina Daniel >Priority: Major > Labels: Triage, Volunteer, client, gsoc, p2 > Fix For: 3.0.0 > > > When you create a client and select the field "is staff", it is selected but > after submission and come again to edit, you find the field not selected, > which shows the value was not stored. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-302) Principal Threshold (%) for Last Installment is not working as expected
[ https://issues.apache.org/jira/browse/FINERACT-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763783#comment-17763783 ] Bharath Gowda commented on FINERACT-302: [~edcable] it is working as expected as far as the product settings I tested with. but it would have been helpful if we knew the exact product config where the issue is coming. > Principal Threshold (%) for Last Installment is not working as expected > --- > > Key: FINERACT-302 > URL: https://issues.apache.org/jira/browse/FINERACT-302 > Project: Apache Fineract > Issue Type: Bug > Components: Loan >Reporter: Santosh Math >Assignee: Nayan Ambali >Priority: Major > Labels: Triage, Volunteer, fineract-gci, gsoc, p1 > Fix For: 3.0.0 > > Attachments: Scr-664.png, Screenshot from 2018-12-23 22-13-02.png, > Screenshot from 2018-12-23 22-14-34.png > > > Reported by Subramanya at https://mifosforge.jira.com/browse/MIFOSX-2031 > Original Desription: > 1. Create loan product with out mentioning any thing in the "Principal > Threshold (%) for Last Instalment" - by default it is getting set to zero > Instead it should get set to 50% > 2, Create a client and submit new loan application wit the above mentioned > loan product on 01 Jan 2015 with interest recalculation -> Approve and > disburse on same date. > 3. The last installment is getting collected more amount than EMI. > If the "Principal Threshold (%) for Last Instalment" is set to zero then then > the last installment should never be combined with the previous installment > even if the last installment amount is of a very small value. > But here it is displaying the amount>last installment amount -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-425) Jobs configurable by loans / savings product and office.
[ https://issues.apache.org/jira/browse/FINERACT-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762423#comment-17762423 ] Bharath Gowda commented on FINERACT-425: [~edcable] My thoughts, given the improvements like workflow jobs and COB, I believe this enhancement request is not valid. > Jobs configurable by loans / savings product and office. > > > Key: FINERACT-425 > URL: https://issues.apache.org/jira/browse/FINERACT-425 > Project: Apache Fineract > Issue Type: Improvement > Components: Job Scheduler, Organization >Affects Versions: 1.8.0 >Reporter: Avik Ganguly >Priority: Major > Labels: Triage, features, gsoc, p2, scalability > Fix For: 3.0.0 > > > Allow saving key-value pairs against each job. Key populated in front-end can > be a free text field or an enum consisting of Loan Product / Savings Product > / Office. If pre-defined key is selected, populate corresponding list of > existing loan product / savings product / office in value field's dropdown. > The jobs can receive this key-value pair as a function parameter by setting > arguments on the jobDetailFactoryBean created in the function > createJobDetail(ScheduledJobDetail) in the class JobRegisterServiceImpl. > If the following jobs has above parameters passed to it, it should add > corresponding office/product filter where clause to its read query. > Add Accrual Transactions > Add Periodic Accrual Transactions > Add Accrual Transactions For Loans With Income Posted As Transactions > Generate Loan Loss Provisioning > Post Interest for Savings > Update Loan Summary > This feature can be made more useful with node-aware scheduler as different > nodes can be configured to perform the job for different products/offices > resulting in distribution of load. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-348) Issues when doing a "Close-As-Rescheduled" on a loan
[ https://issues.apache.org/jira/browse/FINERACT-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharath Gowda updated FINERACT-348: --- Affects Version/s: 1.9.0 (was: 1.8.0) > Issues when doing a "Close-As-Rescheduled" on a loan > - > > Key: FINERACT-348 > URL: https://issues.apache.org/jira/browse/FINERACT-348 > Project: Apache Fineract > Issue Type: Improvement > Components: Loan >Affects Versions: 1.9.0 >Reporter: Santosh Math >Priority: Critical > Labels: Triage, gsoc, p2 > Fix For: 3.0.0 > > > Reported by Binny at https://mifosforge.jira.com/browse/MIFOSX-1205 > Original Description: > When closing a loan using the "Close (as Rescheduled)" button, the loan > account is closed, but there are no transactions or accounting entries made > for this closure. This not correct. > The following should be done: > 1) A new transaction should be visible to user under transactions to show > that the loan was closed as rescheduled rather than leaving the loan as is > without any changes. This means that Mifos X should mkae a new entry > m_loan_transaction table - with transaction_type_enum = 7 and amount as the > total outstanding amount (principal + interest + fees). > 2) Ensure that the right accounting entries are made when closing the loan as > "closed (as rescheduled)". This involves: > For loan products: capturing another General Ledger account head under > “Rescheduled in Suspense” – for example: “Rescheduled Loans Suspense Account” > When closing as loan as rescheduled, passing the following entries: > a) For Cash Accounting: > Debit: Rescheduled Loan Suspense Account (with only principal outstanding > amount) > Credit: Loan portfolio > b) For Accrual (upfront): > Debit: Rescheduled Loan Suspense Account (sum of outstanding principal + > interest + fees + penalties) > Credit: Loan portfolio (with principal outstanding amount) > Credit: Interest Receivable (with interest outstanding amount) > Credit: Fees Receivable (with fees outstanding amount) > Credit: Penalties Receivable (with penalties outstanding amount) > c) For Accrual (periodic): > Debit: Rescheduled Loan Suspense Account (sum of outstanding principal + > interest receivable accounted + fees receivable accounted + penalties > receivable accounted) > Credit: Loan portfolio (with principal outstanding amount) > Credit: Interest Receivable (with interest receivable accounted) > Credit: Fees Receivable (with fees receivable accounted) > Credit: Penalties Receivable (with penalties receivable accounted) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-348) Issues when doing a "Close-As-Rescheduled" on a loan
[ https://issues.apache.org/jira/browse/FINERACT-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762422#comment-17762422 ] Bharath Gowda commented on FINERACT-348: [~edcable] I have not come across this feature request from any one from the community. But since the feature is already half developed..it is good to complete the transaction and journal entry part of it. > Issues when doing a "Close-As-Rescheduled" on a loan > - > > Key: FINERACT-348 > URL: https://issues.apache.org/jira/browse/FINERACT-348 > Project: Apache Fineract > Issue Type: Improvement > Components: Loan >Affects Versions: 1.8.0 >Reporter: Santosh Math >Priority: Critical > Labels: Triage, gsoc, p2 > Fix For: 3.0.0 > > > Reported by Binny at https://mifosforge.jira.com/browse/MIFOSX-1205 > Original Description: > When closing a loan using the "Close (as Rescheduled)" button, the loan > account is closed, but there are no transactions or accounting entries made > for this closure. This not correct. > The following should be done: > 1) A new transaction should be visible to user under transactions to show > that the loan was closed as rescheduled rather than leaving the loan as is > without any changes. This means that Mifos X should mkae a new entry > m_loan_transaction table - with transaction_type_enum = 7 and amount as the > total outstanding amount (principal + interest + fees). > 2) Ensure that the right accounting entries are made when closing the loan as > "closed (as rescheduled)". This involves: > For loan products: capturing another General Ledger account head under > “Rescheduled in Suspense” – for example: “Rescheduled Loans Suspense Account” > When closing as loan as rescheduled, passing the following entries: > a) For Cash Accounting: > Debit: Rescheduled Loan Suspense Account (with only principal outstanding > amount) > Credit: Loan portfolio > b) For Accrual (upfront): > Debit: Rescheduled Loan Suspense Account (sum of outstanding principal + > interest + fees + penalties) > Credit: Loan portfolio (with principal outstanding amount) > Credit: Interest Receivable (with interest outstanding amount) > Credit: Fees Receivable (with fees outstanding amount) > Credit: Penalties Receivable (with penalties outstanding amount) > c) For Accrual (periodic): > Debit: Rescheduled Loan Suspense Account (sum of outstanding principal + > interest receivable accounted + fees receivable accounted + penalties > receivable accounted) > Credit: Loan portfolio (with principal outstanding amount) > Credit: Interest Receivable (with interest receivable accounted) > Credit: Fees Receivable (with fees receivable accounted) > Credit: Penalties Receivable (with penalties receivable accounted) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-336) Fund Mapping page Points to Advanced Search page
[ https://issues.apache.org/jira/browse/FINERACT-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762420#comment-17762420 ] Bharath Gowda commented on FINERACT-336: >From the history of the ticket Its a front end (web-app) fix we have to do..I >have created the same in the git hub https://github.com/openMF/web-app/issues/1861 > Fund Mapping page Points to Advanced Search page > > > Key: FINERACT-336 > URL: https://issues.apache.org/jira/browse/FINERACT-336 > Project: Apache Fineract > Issue Type: Improvement > Components: Organization >Affects Versions: 1.8.0 >Reporter: Santosh Math >Priority: Critical > Labels: gsoc, large, p1 > Fix For: 3.0.0 > > Attachments: fundmapping.png > > > Reported by Ed Cable at https://mifosforge.jira.com/browse/MIFOSX-2795 > Original Description: > Hi all, > I think this bug has been existent for several months now as we actually > documented it as intended functionality at > https://mifosforge.jira.com/wiki/display/docs/Fund+Mapping > If you got to Admin >> Organization >> Fund Mapping, clicking the link takes > you to > https://demo4.openmf.org/#/advsearch > rather than the intended page on fund mapping (i'm not sure which it is). > On a similar note, I don't think this advance search link is accessible from > the search menu although it should be there or in the quick links. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-314) If Tranche disbursement charge payment mode is Account transfer then after first disbursement the charge collection is improper
[ https://issues.apache.org/jira/browse/FINERACT-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762416#comment-17762416 ] Bharath Gowda commented on FINERACT-314: Issue exists > If Tranche disbursement charge payment mode is Account transfer then after > first disbursement the charge collection is improper > --- > > Key: FINERACT-314 > URL: https://issues.apache.org/jira/browse/FINERACT-314 > Project: Apache Fineract > Issue Type: Bug > Components: Charges >Affects Versions: 1.8.0 >Reporter: Santosh Math >Priority: Minor > Labels: Triage, gsoc, p2 > Fix For: 3.0.0 > > Attachments: 91.png, 93.png > > > Reported by Subramanya at https://mifosforge.jira.com/browse/MIFOSX-2194 > Original Description: > 1. Create Tranche disbursement charge with Charge Payment Mode as Account > transfer. > 2. Create Tranche loan product with 2 tranches and above created charge > attached > 3. Create Savings product and create a client with active savings product > above created. > 4. For the same above client submit new loan application with the above > savings account and Tranche disbursement charge attached while submitting the > application, tranche attached on 01 August 2015 and amount is 5000, 2nd > tranche on 01 September 2015 and amount is 5000 -> Approve and disburse the > first tranche on 01 August 2015. > > In Summary page displaying as both tranche disbursement charges as due > > In Repayment schedule is displaying properly > > In Transactions page and In Charges page both Tranche disbursement charges > > are displaying as collected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-307) Accruals accounting does not accrue income on loans closed prematurely
[ https://issues.apache.org/jira/browse/FINERACT-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762379#comment-17762379 ] Bharath Gowda commented on FINERACT-307: [~edcable] this issue is fixed. > Accruals accounting does not accrue income on loans closed prematurely > -- > > Key: FINERACT-307 > URL: https://issues.apache.org/jira/browse/FINERACT-307 > Project: Apache Fineract > Issue Type: Bug > Components: Loan >Affects Versions: 1.8.0 >Reporter: Santosh Math >Priority: Major > Labels: Triage, p2 > Fix For: 3.0.0 > > > Reported by Sander at https://mifosforge.jira.com/browse/MIFOSX-2093 > Original Description: > If a customer makes the final payment before the end of the loan schedule the > loan status changes to closed, and the balance reports 0, which is correct. > These loans are non-recalculating and accrue interest in line with their > schedules (periodic). As such all interest portions are booked into the > Interest Receivable account. > However because of the closed status the accruals batch job no longer > generates the periodic accruals for this loan (query excludes any status > which is not active). As a result a part of this income will remain in the > Interest receivable account indefinitely, which is not the expected > behaviour. We would either expect the accruals to continue in line with the > schedule, or for the accrual to be generated alongside the final (closing) > transaction of the loan. > The quick-fix for this is to adjust the batch job to look not just look at > loan status but also at any loan where the interest accrual date is smaller > than the expected maturity date. > As a permanent fix we should investigate whether new accounting types/rules > need to be defined for this scenario to also book this prepaid income as a > liability instead of an asset account, such as Prepaid Interest received. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1948) Loan repayment by account transfer transaction type should not be withdrawal
[ https://issues.apache.org/jira/browse/FINERACT-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750197#comment-17750197 ] Bharath Gowda commented on FINERACT-1948: - [~ikimbrah] from what I understand, if we are looking into this # to distinguish between the actual withdrawal and loan repayment # to support during the dispute cases both are already available with the withdrawal function itself as at the back-end, the withdrawal is linked to the loan repayment and from the UI - if you click on the withdrawal it shows all the loan details to which amount is transferred to. So I really do not see any business use case or a change in the scenario to introduce a new transaction type all together. That is my opinion . but we can always take rest of the community opinion by voting on the mailing list and then decide > Loan repayment by account transfer transaction type should not be withdrawal > > > Key: FINERACT-1948 > URL: https://issues.apache.org/jira/browse/FINERACT-1948 > Project: Apache Fineract > Issue Type: Improvement >Affects Versions: 1.7.0, 1.8.1, 1.7.2, 1.8.2, 1.8.3 >Reporter: ibrahim kimbugwe >Assignee: Francis Guchie >Priority: Major > Fix For: 1.9.0, 1.8.4 > > Attachments: image-2023-07-31-23-11-05-824.png > > > When a user transfers money from a savings account to pay off a loan, the > transaction type is tagged as a withdrawal yet this is a loan repayment. The > transaction type should be adjusted to suit the transaction as it gets handy > for repayments with standing instructions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-657) Enhancement of Standing Instruction dealing with insufficient fund in Savings Account
[ https://issues.apache.org/jira/browse/FINERACT-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750192#comment-17750192 ] Bharath Gowda commented on FINERACT-657: [~ikimbrah] the business logic looks fine to me, thank for sharing the details. > Enhancement of Standing Instruction dealing with insufficient fund in > Savings Account > -- > > Key: FINERACT-657 > URL: https://issues.apache.org/jira/browse/FINERACT-657 > Project: Apache Fineract > Issue Type: Improvement > Components: Loan, Savings >Affects Versions: 1.8.0, 1.8.1, 1.8.2, 1.7.3 >Reporter: Santosh Math >Assignee: Francis Guchie >Priority: Major > Labels: p2 > Fix For: 1.9.0 > > > (Original Description By Zayyad in mailing list) > Current Behaviour: > If there isn't sufficient funds in the linked savings account, Scheduler jobs > for "Execute Standing Instruction" gets failed. And the repayment doesn't > happen. > Expected Behaviour: > We have had an enquiry before that if the linked savings doesn’t have enough, > then the system should recover the whole amount available in the account and > once the account is credited with any other amount the same is deducted until > the amount due is fully collected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1948) Loan repayment by account transfer transaction type should not be withdrawal
[ https://issues.apache.org/jira/browse/FINERACT-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749660#comment-17749660 ] Bharath Gowda commented on FINERACT-1948: - Hi [~francisguchie] my two cents Even if you enable standing instruction technically what it means is withdrawing from savings account and making repayment on to the loan account. So I do not see any logical change in the transaction behavior to introduce it as a new transaction type. Besides when you click on the withdrawal, it contains all the detail of the linked loan and repayment it made to. >From my side I do not see this change add major value to the feature. > Loan repayment by account transfer transaction type should not be withdrawal > > > Key: FINERACT-1948 > URL: https://issues.apache.org/jira/browse/FINERACT-1948 > Project: Apache Fineract > Issue Type: Improvement >Affects Versions: 1.7.0, 1.8.1, 1.7.2, 1.8.2, 1.8.3 >Reporter: ibrahim kimbugwe >Assignee: Francis Guchie >Priority: Major > Fix For: 1.9.0, 1.8.4 > > Attachments: image-2023-07-31-23-11-05-824.png > > > When a user transfers money from a savings account to pay off a loan, the > transaction type is tagged as a withdrawal yet this is a loan repayment. The > transaction type should be adjusted to suit the transaction as it gets handy > for repayments with standing instructions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-1964) Fixed Deposit Enhancement- calculcate Interest during the FD creation phase
Bharath Gowda created FINERACT-1964:
---
Summary: Fixed Deposit Enhancement- calculcate Interest during the
FD creation phase
Key: FINERACT-1964
URL: https://issues.apache.org/jira/browse/FINERACT-1964
Project: Apache Fineract
Issue Type: Improvement
Reporter: Bharath Gowda
*As a* user
*I want system* to calculate the interest of the Fixed deposit account before
the account creation
*in order to* give flexibility to the customers to know their liability before
account creation
h4. *Background and details:*
Need to add a new capability to calculate *interest for fixed deposit savings*
based on the interest posting period and interest compounding period before the
creation of the fixed deposit saving.
This enhancement will empower the customers to have a comprehensive preview of
the interest that will be accrued at the maturity of their fixed deposit
savings, enabling them to make informed decisions.
To achieve this,an API endpoint is required that can perform the interest
calculation for fixed deposit savings. The API endpoint should accept
parameters such as the {*}principal amount, interest rate, tenure, interest
posting period, and interest compounding period{*}. Upon receiving these inputs
through a POST request, the endpoint should conduct the necessary calculations
and return the maturity amount and interest earned in the response.
UI button “{*}calculate Interest{*}” should be available on create fixed
deposit account view screen for users to know the interest after entering all
the parameteres
Ex API:
*POST* /api/calculate-fixed-deposit-interest
*Request Body:*
{
"principal_amount": 1, // The initial amount deposited
"interest_rate": 5, // Annual interest rate (in percentage)
"tenure": 12, // Number of months for which the FD is held
"interest_posting_period": 3, // Posting period of interest (in months)
"interest_compounding_period": 1 // Compounding period of interest (in months)
}{*}Response Body:{*}
{
"maturity_amount": 10512.5, // Total amount at maturity (including interest)
"interest_earned": 512.5 // Interest earned during the tenure
}
*Acceptance criteria*
# I want to be able to calculate the interest on Fixed deposit during account
creation phase
# a button should be available on the UI for users to calculate and show the
interest based on the parameters entered ({*}principal amount, interest rate,
tenure, interest posting period, and interest compounding period{*})
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (FINERACT-1963) New Receipt field for account transfer transaction
Bharath Gowda created FINERACT-1963:
---
Summary: New Receipt field for account transfer transaction
Key: FINERACT-1963
URL: https://issues.apache.org/jira/browse/FINERACT-1963
Project: Apache Fineract
Issue Type: Improvement
Reporter: Bharath Gowda
*As a* user
*I want to* capture the receipt details while doing the transfer funds from the
savings account
*in order to* capture the receipt details provided by the customer
h4. *Background and details:*
A new field called "{*}receiptNumber{*}" should be part of the transfer
payload. This addition will serve as the "externalReference" for transfers made
between accounts.
*Account Transfer with noReceipt No:*
*Request URL:*
[https://corebanking-api.test.vggdev.com/fineract-provider/api/v1/accounttransfers]
*Request Method:* POST
*Request Payload:*
{
"fromAccountId": "50784",
"fromAccountType": 2,
"toOfficeId": 1,
"toClientId": 77018,
"toAccountType": 2,
"toAccountId": 188546,
"transferAmount": "5",
"transferDate": "31 July 2023",
"transferDescription": "Test funds Transfer",
"locale": "en",
"dateFormat": "dd ",
"fromClientId": 76589,
"fromOfficeId": 1
}
Need to add new parameter "receiptNumber": "382VDDksi3eekdie" to this API
*Acceptance criteria*
# As a user I should be able to capture receipt number while doing fund
transfer from savings account
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (FINERACT-1962) Accrual Posting Enhancement for Arrears loans
Bharath Gowda created FINERACT-1962: --- Summary: Accrual Posting Enhancement for Arrears loans Key: FINERACT-1962 URL: https://issues.apache.org/jira/browse/FINERACT-1962 Project: Apache Fineract Issue Type: Improvement Reporter: Bharath Gowda *As a* user *I want* the system to stop accruing interest on loan accounts which are in arrears *in order to* _meet the business and regulatory requirements_ h4. *Background and details:* Fineract currently does not consider the arrears tag of the loan for posting the accrual transactions. The system will post the accrual for all active loan accounts irrespective of arrears or not *Acceptance criteria* # As a user I should be able to stop the accrual posting on the loan accounts that are in arrears # I should be able to configure the accrual posting at the loan product level where we can have check back to enable and disable accrual posting for the arrears loan. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-1961) Fixed Deposit Account Enhancements
Bharath Gowda created FINERACT-1961: --- Summary: Fixed Deposit Account Enhancements Key: FINERACT-1961 URL: https://issues.apache.org/jira/browse/FINERACT-1961 Project: Apache Fineract Issue Type: Improvement Reporter: Bharath Gowda *As a* user *I want to* _be able to undo an active Fixed Deposit account_ *in order to* give the flexibility to reverse an FD account that has been active by mistake h4. *Background and details:* Currently in Fineract once the fixed deposit account is made active, there is no provision or flexibility to undo the action as we can currently do for loan accounts *Acceptance criteria* # As a user I should be able to undo an active Fixed Deposit account ## When undo is done all the transactions of the FD account should be reversed automatically ## Accounting GL entries posted with respect to the FD account should also be reversed ## charge and its respective accounting entries associated with the FD account should be reversed as well # Should be able to undo active Fixed Deposit account from UI as well -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-1960) Periodic Accrual Accounting for Savings product
Bharath Gowda created FINERACT-1960: --- Summary: Periodic Accrual Accounting for Savings product Key: FINERACT-1960 URL: https://issues.apache.org/jira/browse/FINERACT-1960 Project: Apache Fineract Issue Type: Improvement Components: Savings Reporter: Bharath Gowda *As a* user *I want to* _configure periodic accural accounting for Savings products_ *in order to* _have accural accounting journal entries for Savings accounts_ h4. *Background and details:* Fineract supports only cash-based accounting entries for deposit products there is a need for accrual accounting for products *Acceptance criteria* # user should be able to confiugre periodic accural accounting for Savings products # Monetory transactions should post accrual jounral entries for savings accounts # Refer below wiki for complete requirement # user should be able to configure this from the Webapp UI as well. [https://cwiki.apache.org/confluence/display/FINERACT/Periodic+Accrual+Accounting+option+for+Deposit+Products] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1950) Disallow backdated transactions after COB
[ https://issues.apache.org/jira/browse/FINERACT-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749518#comment-17749518 ] Bharath Gowda commented on FINERACT-1950: - [~ikimbrah] Great, thank you for the update. > Disallow backdated transactions after COB > - > > Key: FINERACT-1950 > URL: https://issues.apache.org/jira/browse/FINERACT-1950 > Project: Apache Fineract > Issue Type: Improvement >Reporter: ibrahim kimbugwe >Assignee: Francis Guchie >Priority: Major > Fix For: 1.9.0 > > > We need to have a global configuration to disallow backdated transactions for > a given period without necessarily closing an accounting period in the > closing entries. > A use case of a teller not being allowed to post a backdated transaction on a > customer after the till was balanced or after COB. The accountant can however > have the right to post GL transactions on a back date. > > This should however be set as a global configuration that can be turned on > and off. > > [~francisguchie] and [~bgowda] and [~eroemma] what do you think of this > improvement? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-1952) Writing off a loan is not creating properly the final accrual transaction and journal entries
Bharath Gowda created FINERACT-1952: --- Summary: Writing off a loan is not creating properly the final accrual transaction and journal entries Key: FINERACT-1952 URL: https://issues.apache.org/jira/browse/FINERACT-1952 Project: Apache Fineract Issue Type: Bug Reporter: Bharath Gowda While writing off a loan if there are not yet accrued interest, fee, or penalty, it shall be calculated and create the proper accrual transaction and journal entries. *Actual behavior* - Final Accrual calculation (and transaction) is not happening - recalculateAccruals method call is “dummy” the loan is not Active by the time this method is called To reproduce # create a loan account with periodic accrual accounting enabled # disburse and write-off the loan before running the accrual jobs. Here system will not post any accrual transaction for that loan account and the job will not post accrual transaction for written off loan account -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1952) Writing off a loan is not creating properly the final accrual transaction and journal entries
[ https://issues.apache.org/jira/browse/FINERACT-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743907#comment-17743907 ] Bharath Gowda commented on FINERACT-1952: - [~francisguchie] would love to hear your thoughts on this > Writing off a loan is not creating properly the final accrual transaction and > journal entries > - > > Key: FINERACT-1952 > URL: https://issues.apache.org/jira/browse/FINERACT-1952 > Project: Apache Fineract > Issue Type: Bug >Reporter: Bharath Gowda >Priority: Minor > > While writing off a loan if there are not yet accrued interest, fee, or > penalty, it shall be calculated and create the proper accrual transaction and > journal entries. > *Actual behavior* > - Final Accrual calculation (and transaction) is not happening > - recalculateAccruals method call is “dummy” the loan is not Active by the > time this method is called > > To reproduce > # create a loan account with periodic accrual accounting enabled > # disburse and write-off the loan before running the accrual jobs. > Here system will not post any accrual transaction for that loan account and > the job will not post accrual transaction for written off loan account -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1949) Access customer information accross a multiple branch institution
[ https://issues.apache.org/jira/browse/FINERACT-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742704#comment-17742704 ] Bharath Gowda commented on FINERACT-1949: - [~ikimbrah] Thanks for the explanation. one suggestion is let's make it configurable with the current working hierarchy system as default. > Access customer information accross a multiple branch institution > - > > Key: FINERACT-1949 > URL: https://issues.apache.org/jira/browse/FINERACT-1949 > Project: Apache Fineract > Issue Type: Improvement >Affects Versions: 1.7.0, 1.8.3 >Reporter: ibrahim kimbugwe >Priority: Major > Fix For: 1.9.0 > > > Currently, the fineract allows a scope of branch teams to access branch > information unless they're added at head office. This feature should however > be extended to make sure that customers of a particular branch can be served > at another branch. Cases include doing deposits and withdrawals. > [~francisguchie] and [~bgowda] whats your take on this? > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1950) Disallow backdated transactions after COB
[ https://issues.apache.org/jira/browse/FINERACT-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741561#comment-17741561 ] Bharath Gowda commented on FINERACT-1950: - [~ikimbrah] +1 from my side. this is a practical challenge being faced currently. if we segregate the closure for portfolio and accounting it will ease the operational overheads. especially during month ends and year ends > Disallow backdated transactions after COB > - > > Key: FINERACT-1950 > URL: https://issues.apache.org/jira/browse/FINERACT-1950 > Project: Apache Fineract > Issue Type: Improvement >Reporter: ibrahim kimbugwe >Priority: Major > Fix For: 1.9.0 > > > We need to have a global configuration to disallow backdated transactions for > a given period without necessarily closing an accounting period in the > closing entries. > A use case of a teller not being allowed to post a backdated transaction on a > customer after the till was balanced or after COB. The accountant can however > have the right to post GL transactions on a back date. > > This should however be set as a global configuration that can be turned on > and off. > > [~francisguchie] and [~bgowda] and [~eroemma] what do you think of this > improvement? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1949) Access customer information accross a multiple branch institution
[ https://issues.apache.org/jira/browse/FINERACT-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741555#comment-17741555 ] Bharath Gowda commented on FINERACT-1949: - [~ikimbrah] you mean we need to allow the access of "branch B" to a user who is under "branch A" even though branch B doesn't come under the "branch A" hierarchy? I think it is not a big change, however, what is the priority or the volume request for this change? I believe most organizations follow hierarchy and never came across this use case or request before > Access customer information accross a multiple branch institution > - > > Key: FINERACT-1949 > URL: https://issues.apache.org/jira/browse/FINERACT-1949 > Project: Apache Fineract > Issue Type: Improvement >Affects Versions: 1.7.0, 1.8.3 >Reporter: ibrahim kimbugwe >Priority: Major > Fix For: 1.9.0 > > > Currently, the fineract allows a scope of branch teams to access branch > information unless they're added at head office. This feature should however > be extended to make sure that customers of a particular branch can be served > at another branch. Cases include doing deposits and withdrawals. > [~francisguchie] and [~bgowda] whats your take on this? > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1945) UI Shows Duplicate Scheduler Jobs - a reason some jobs are failing
[ https://issues.apache.org/jira/browse/FINERACT-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741552#comment-17741552 ] Bharath Gowda commented on FINERACT-1945: - [~francisguchie] thanks for sharing the analysis. was any analysis done on the solution part? are we able to reproduce this in all instances? currently, I am not facing this issue in any of the instances that I am working on. > UI Shows Duplicate Scheduler Jobs - a reason some jobs are failing > -- > > Key: FINERACT-1945 > URL: https://issues.apache.org/jira/browse/FINERACT-1945 > Project: Apache Fineract > Issue Type: Bug >Affects Versions: 1.7.3 >Reporter: Francis Guchie >Assignee: Francis Guchie >Priority: Major > Attachments: image-2023-06-20-19-40-27-163.png, > image-2023-06-20-19-45-07-790.png > > > Jobs are failing to run and I think it is the Jobs that are duplicated on the > UI. > Something to consider trouble shooting > !image-2023-06-20-19-40-27-163.png! > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1945) UI Shows Duplicate Scheduler Jobs - a reason some jobs are failing
[ https://issues.apache.org/jira/browse/FINERACT-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735596#comment-17735596 ] Bharath Gowda commented on FINERACT-1945: - [~francisguchie] I do not think it is a UI issue, can you check in the DB if the jobs data is duplicated? having duplicate jobs may be the reason for jobs to run multiple times and appear twice on UI. One more point observed is all the jobs have the same trigger time. that may be the cause of the lock exception you are getting. alter the cron expression as per the priority of the job to run one after another. > UI Shows Duplicate Scheduler Jobs - a reason some jobs are failing > -- > > Key: FINERACT-1945 > URL: https://issues.apache.org/jira/browse/FINERACT-1945 > Project: Apache Fineract > Issue Type: Bug >Affects Versions: 1.7.3 >Reporter: Francis Guchie >Priority: Major > Attachments: image-2023-06-20-19-40-27-163.png, > image-2023-06-20-19-45-07-790.png > > > Jobs are failing to run and I think it is the Jobs that are duplicated on the > UI. > Something to consider trouble shooting > !image-2023-06-20-19-40-27-163.png! > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1944) interest recalculation only when client pays early - do not recalculate if payment is on time or late (so that interest remains the same)
[ https://issues.apache.org/jira/browse/FINERACT-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735112#comment-17735112 ] Bharath Gowda commented on FINERACT-1944: - [~francisguchie] yes, it is a viable enhancement to the loan module provided that it is added as a configurable option under loan products. For example: Like a checkbox option inside the "interest recalculation section" of the loan product configuration. users who whats their loan to calculate interest like this can enable the checkbox and use it. > interest recalculation only when client pays early - do not recalculate if > payment is on time or late (so that interest remains the same) > - > > Key: FINERACT-1944 > URL: https://issues.apache.org/jira/browse/FINERACT-1944 > Project: Apache Fineract > Issue Type: New Feature >Reporter: Francis Guchie >Priority: Major > > As a client of a financial institution i would like to see the following > among others for my loan > * *Interest Method: Declining Balance* > * *Interest recalculation: Enabled* - When I pay my installments before due > date, the system should follow the standard of recalculating my interest > downwards. When I pay late the system does not recalculate (or lets say it > does but ignores updating my interest upwards. > [~ikimbrah] [~bgowda] is this a viable new feature? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1911) Assign Data Table to Transaction (Savings)
[
https://issues.apache.org/jira/browse/FINERACT-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733158#comment-17733158
]
Bharath Gowda commented on FINERACT-1911:
-
[~peter.santa] [~mkkor] [~jdailey] thanks for providing the feedback and
details on the need for storing additional details at the transaction level.
Just a thought, could we not build out a separate module/feature or an
extension to transactions(am not saying of adding details to
m_loan_transaction) instead of touching the data table feature?
I am not an expert on design and coding part, but I believe this could simplify
a lot of things from what I understand from the requirement.
as the scenarios of having data being captured at the transaction level would
be less compared to entities, we could have well thought 6 to 7 fixed fields
(like fields required explained above) for "transactions related extra details
extension" and may not require the dynamic fields capability that data table
offers
again this is just another point of view and thought from my side but what
Muthu proposed also looks fine and would meet the requirement.
> Assign Data Table to Transaction (Savings)
> --
>
> Key: FINERACT-1911
> URL: https://issues.apache.org/jira/browse/FINERACT-1911
> Project: Apache Fineract
> Issue Type: New Feature
> Components: Data Tables
>Reporter: Peter Santa
>Priority: Major
> Labels: BeanSalad
>
> h1. Background
> Currently data tables can be assigned to several entity types, but
> transaction is not an option.
> h1. Goal
> The context is mainly Transactions of {*}Saving Accounts{*}, but it would be
> great to implement the feature generally.
> The goal would be to make it possible to
> * {*}assign data table to transactions{*}, and
> * support multi-row and single-row tables - as it is already supported for
> data tables that could be assigned to other entities.
> h1. Acceptance Criteria
> * it is supported to assign *data tables to Transaction entities* of - at
> least - savings accounts, and the solution fits into the current data table
> conception
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FINERACT-1912) Transaction query - Advanced
[
https://issues.apache.org/jira/browse/FINERACT-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17732442#comment-17732442
]
Bharath Gowda commented on FINERACT-1912:
-
[~peter.santa] [~mkkor]
I think it is good to build a UI for data table queries as well for this change.
I have added a UI [ticket |https://github.com/openMF/web-app/issues/1769]for
the same, this will benefit community users who use Mifos UI
> Transaction query - Advanced
>
>
> Key: FINERACT-1912
> URL: https://issues.apache.org/jira/browse/FINERACT-1912
> Project: Apache Fineract
> Issue Type: New Feature
> Components: Savings
>Reporter: Peter Santa
>Assignee: James Dailey
>Priority: Major
> Labels: BeanSalad
>
> h1. Background
> Currently transactions of a Saving Account cannot be filtered - either all of
> them are in the response (using ...?associations=all), or none of them.
> Pagination and sorting is not supported.
> h1. Goal
> For Transactions related to - at least - Savings Account, support having:
> * pagination - following the concept in Fineract, implemented already for
> other entities
> * sorting - following the concept in Fineract, implemented already for other
> entities
> * filtering for
> ** transaction date:
> *** greather-than-or-equal
> *** less-than-or-equal
> ** amount
> *** greather-than-or-equal
> *** less-than-or-equal
> ** deposit/withdraw
> ** externalId - if FINERACT-1760 is already implemented
> The filtering parameters should be applied with "AND" relation.
> The response should have the transaction details on a similar way, as it is
> in the transactions array of:
> {{{}{}}}{color:#212121}/savingsaccounts/<{color}{{{}account_id>{}}}{color:#212121}?associations=all{color}
> h1. Solution Concept
> Have the solution concept aligned between
> * FINERACT-1910
> * FINERACT-1912
> * FINERACT-1915
> The API should support passing the required parameters.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FINERACT-1747) Have an API endpoint to query values from Data Table
[
https://issues.apache.org/jira/browse/FINERACT-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17732440#comment-17732440
]
Bharath Gowda commented on FINERACT-1747:
-
UI [ticket |https://github.com/openMF/web-app/issues/1768]for this feature
> Have an API endpoint to query values from Data Table
>
>
> Key: FINERACT-1747
> URL: https://issues.apache.org/jira/browse/FINERACT-1747
> Project: Apache Fineract
> Issue Type: New Feature
> Components: Data Tables
>Reporter: Peter Santa
>Assignee: Zoltán Nébli
>Priority: Major
> Labels: BeanSalad
>
> h1. Background
> It is needed to be able to find rows in a Data Table, based on a value in a
> specified column, and get the whole row based on the given value.
> h1. Goal
> Have an API endpoint provided by Fineract, that allows filtering rows from
> Data Tables based on a value.
> h1. Solution Concept
> Implement an API endpoint in Fineract with {{GET}} method, that executes a
> query on a specified Data Table.
> E.g.:
> Data Table:
> {code:java}
> my_great_data_table{code}
> ||client_id||special_value_1||special_value_2||special_value_3||created_at||updated_at||
> |1|ABC1|DEF|GHI|...|...|
> |2|ABC2|FED|IHG|...|...|
> h3. Request
> * data table ID - {{datatable}}
> * data table filter column name - {{columnFilter}}
> * requested filter value in the column - {{valueFilter}}
> * columns, from which the value should be included in the response -
> {{resultColumns}} (comma separated column names)
> {code:java}
> ...my_great_data_table/query?columnFilter=special_value_1=ABC2=special_value_2,special_value_3{code}
> h3. Response
> {code:java}
> [
> {
> "special_value_2": "FED",
> "special_value_3": "IHG"
> }
> ] {code}
> h1. Acceptance Criteria
> * The new API endpoint accepts as input
> ** data table ID - {{datatable}}
> ** data table filter column name - {{columnFilter}}
> ** requested filter value in the column - {{valueFilter}}
> ** columns, from which the value should be included in the response -
> {{resultColumns}} (comma separated column names)
> * The response contains the list of records, that satisfy the conditions in
> the input.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FINERACT-1910) Data Table query - Advanced
[
https://issues.apache.org/jira/browse/FINERACT-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17732428#comment-17732428
]
Bharath Gowda commented on FINERACT-1910:
-
[~peter.santa] [~aru03]
I think it is good to build a UI for data table queries as well for this change.
I have added a UI [ticket |https://github.com/openMF/web-app/issues/1768]for
the same, this will benefit community users who use Mifos UI
> Data Table query - Advanced
> ---
>
> Key: FINERACT-1910
> URL: https://issues.apache.org/jira/browse/FINERACT-1910
> Project: Apache Fineract
> Issue Type: New Feature
> Components: Data Tables
>Reporter: Peter Santa
>Priority: Critical
> Labels: BeanSalad
> Attachments: dataTableAdvancedFilteringExample.txt
>
>
> h1. Background
> FINERACT-1747
> h1. Goal
> Have the querying possibilities - that have been developed with FINERACT-1747
> - extended with the following features:
> * pagination - similarly to several Fineract API endpoints
> * sorting based on given attribute
> * filter for closed (greather-than-or-equal, less-than-or-equal) interval in
> case of the following typed fields:
> ** date
> ** date and time
> ** number
> ** decimal
> ** string/text that can be parsed to numeric
> * contains search in string and text fields
> * exact match for string and text fields
> The filtering parameters should be applied with "AND" relation.
> h1. Solution Concept
> Have the solution concept aligned between
> * FINERACT-1910
> * FINERACT-1912
> * FINERACT-1915
> If multiple columns would be used as column filter, it is advisable not to
> put this number of query parameters in the url, but in the body, like
> graphql. With this, a request would look like:
> h3. URL
> GET
> {{{}url{}}}/datatables/{{{}dataTableId{}}}/query?resultColumns=column3,column6,column4=0=10=desc=transaction_date
> h3. Body
> See the attached [^dataTableAdvancedFilteringExample.txt].
> The filtering parameters should be applied with "AND" relation.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FINERACT-1911) Assign Data Table to Transaction (Savings)
[
https://issues.apache.org/jira/browse/FINERACT-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17732419#comment-17732419
]
Bharath Gowda commented on FINERACT-1911:
-
Hi [~peter.santa]
Data tables are meant to extend the data capture facility at entity levels like
client, loans, savings..etc
For example client-related employee details, loan-related types, etc
But when you say transaction level, the transaction is a tab that displays the
transaction list with respect to that entity but did not understand what is the
use case of having a data table at the transaction level
Could you give me an example of datatable at transactions and what set of data
that can be collected?
> Assign Data Table to Transaction (Savings)
> --
>
> Key: FINERACT-1911
> URL: https://issues.apache.org/jira/browse/FINERACT-1911
> Project: Apache Fineract
> Issue Type: New Feature
> Components: Data Tables
>Reporter: Peter Santa
>Priority: Major
> Labels: BeanSalad
>
> h1. Background
> Currently data tables can be assigned to several entity types, but
> transaction is not an option.
> h1. Goal
> The context is mainly Transactions of {*}Saving Accounts{*}, but it would be
> great to implement the feature generally.
> The goal would be to make it possible to
> * {*}assign data table to transactions{*}, and
> * support multi-row and single-row tables - as it is already supported for
> data tables that could be assigned to other entities.
> h1. Acceptance Criteria
> * it is supported to assign *data tables to Transaction entities* of - at
> least - savings accounts, and the solution fits into the current data table
> conception
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FINERACT-894) Scheduler Jobs Issue
[ https://issues.apache.org/jira/browse/FINERACT-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729714#comment-17729714 ] Bharath Gowda commented on FINERACT-894: [~francisguchie] as mentioned on https://issues.apache.org/jira/browse/FINERACT-657 We can use the method of completing the job for all loans (where the positive cases loans can get processed and let the system show the failed loans list at the end of the job) I believe that is how loan-related jobs work For example: interest recalculation job >From my view I do not think this should be categorized as bug, I think the best way to handle is to create it as a separate enhancement ticket with proper details of the job that needs changes. > Scheduler Jobs Issue > > > Key: FINERACT-894 > URL: https://issues.apache.org/jira/browse/FINERACT-894 > Project: Apache Fineract > Issue Type: Bug > Components: Job Scheduler >Affects Versions: 1.8.0, 1.8.1, 1.7.2, 1.8.2, 1.8.3, 1.8.4, 1.7.3 >Reporter: Bharath Gowda >Assignee: Rahul Pawar >Priority: Critical > Attachments: Local Build Succes.png, Traivs Failure.png > > > Following Scheduler Jobs are failing for the below mentioned scenario > 1.Execute standing instruction Job > 2.Pay Due Saving charge > > Scenario: > if there is a single savings account with insufficient balance, then Job is > failing and not processing its tasks for rest of the loans as well in the > system. > > Expected behavior :Jobs should successfully execute it's task for all the > accounts and show the error message of accounts for which there was > insufficient amount. > > Steps to Reproduce > :For "Pay Due Saving charge" Job > 1.Create a Basic Savings account with deposit amount 1000 and add a monthly > charge of 5000. > 2.Create second savings account with deposit amount 1000 and add a monthly > charge of 500. > > then execute the "Pay Due Saving charge" Job, system should actually post the > charge for second saving account and through the error message for first > savings account. but system is not posting the charge for any of the loans. > > :For "Execute standing instruction Job" Job > 1.For client A - create a savings account with 100 balance, create a loan > with EMI of 1000 and add a standing instruction for the client to transfer > money from savings account to loan account on duedate. > > 2.For client B - create a savings account with 1000 balance, create a loan > with EMI of 1000 and add a standing instruction for the client to transfer > money from savings account to loan account on duedate. > then execute the "Execute standing instruction Job" Job, system should > actually post the transactions from savings to loan for client B and fail for > client A(due to insufficient fund) but as of the job is failing for both > clients. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (FINERACT-657) Enhancement of Standing Instruction dealing with insufficient fund in Savings Account
[ https://issues.apache.org/jira/browse/FINERACT-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729711#comment-17729711 ] Bharath Gowda edited comment on FINERACT-657 at 6/6/23 12:12 PM: - [~francisguchie] Yes have experienced this with respect savings related jobs. As you have mentioned on https://issues.apache.org/jira/browse/FINERACT-894 We can use the method of completing the job for all loans (where the positive cases loans can get processed and let the system show the failed loans list at the end of the job) I believe that is how loan-related jobs work For example: interest recalculation job was (Author: bgowda): [~francisguchie] Yes have experienced this with respect savings related jobs. As you have mentioned on https://issues.apache.org/jira/browse/FINERACT-894 We can use the method of completing the job for all loans (where the positive cases loans can get processed and let the system show the failed loans list at the end of the job) > Enhancement of Standing Instruction dealing with insufficient fund in > Savings Account > -- > > Key: FINERACT-657 > URL: https://issues.apache.org/jira/browse/FINERACT-657 > Project: Apache Fineract > Issue Type: Improvement > Components: Loan, Savings >Affects Versions: 1.8.0, 1.8.1, 1.8.2, 1.7.3 >Reporter: Santosh Math >Assignee: Rahul Pawar >Priority: Major > Labels: p2 > Fix For: 1.9.0 > > > (Original Description By Zayyad in mailing list) > Current Behaviour: > If there isn't sufficient funds in the linked savings account, Scheduler jobs > for "Execute Standing Instruction" gets failed. And the repayment doesn't > happen. > Expected Behaviour: > We have had an enquiry before that if the linked savings doesn’t have enough, > then the system should recover the whole amount available in the account and > once the account is credited with any other amount the same is deducted until > the amount due is fully collected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-657) Enhancement of Standing Instruction dealing with insufficient fund in Savings Account
[ https://issues.apache.org/jira/browse/FINERACT-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729711#comment-17729711 ] Bharath Gowda commented on FINERACT-657: [~francisguchie] Yes have experienced this with respect savings related jobs. As you have mentioned on https://issues.apache.org/jira/browse/FINERACT-894 We can use the method of completing the job for all loans (where the positive cases loans can get processed and let the system show the failed loans list at the end of the job) > Enhancement of Standing Instruction dealing with insufficient fund in > Savings Account > -- > > Key: FINERACT-657 > URL: https://issues.apache.org/jira/browse/FINERACT-657 > Project: Apache Fineract > Issue Type: Improvement > Components: Loan, Savings >Affects Versions: 1.8.0, 1.8.1, 1.8.2, 1.7.3 >Reporter: Santosh Math >Assignee: Rahul Pawar >Priority: Major > Labels: p2 > Fix For: 1.9.0 > > > (Original Description By Zayyad in mailing list) > Current Behaviour: > If there isn't sufficient funds in the linked savings account, Scheduler jobs > for "Execute Standing Instruction" gets failed. And the repayment doesn't > happen. > Expected Behaviour: > We have had an enquiry before that if the linked savings doesn’t have enough, > then the system should recover the whole amount available in the account and > once the account is credited with any other amount the same is deducted until > the amount due is fully collected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-1906) Accrual Transaction issue for disbursement charge type
Bharath Gowda created FINERACT-1906: --- Summary: Accrual Transaction issue for disbursement charge type Key: FINERACT-1906 URL: https://issues.apache.org/jira/browse/FINERACT-1906 Project: Apache Fineract Issue Type: Bug Components: Loan Reporter: Bharath Gowda *Description* the system is not posting the accrual entries for the disbursement transaction type. *To Reproduce:* # create a loan product with accrual periodic accounting. # create, approve, and disburse a loan account under that product by adding a disbursement charge # run the “add accrual transactions” job # no accrual entry is posted for the disbursement charge *Expectation* Accrual transaction should be created for the disbursement charge on the disbursement date when the loan account is disbursed -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-1903) NullPointerException while reprocessing loan transactions if there was any partially waived installment fee
Bharath Gowda created FINERACT-1903: --- Summary: NullPointerException while reprocessing loan transactions if there was any partially waived installment fee Key: FINERACT-1903 URL: https://issues.apache.org/jira/browse/FINERACT-1903 Project: Apache Fineract Issue Type: Bug Reporter: Bharath Gowda *GIVEN* a loan is created and it has installment fee configured *AND* partial repayment was done (which not pays off the installment fee fully) *AND* the not yet paid portion of the installment fee got waived *WHEN* another repayment is done (while it is not the last) or backdated transaction or add a penalty *THEN* NPE got raised as the reverse-replay logic is handling not properly the reprocessing of partially paid and waived installment fee *Steps to reproduce* - Create a loan (1000) with 1 installment with Installment fee (10) - Do a repayment (5) - Do a waive on the installment fee - Do another repayment (after the first repayment, but before the waived fee) or add a penalty -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-1902) Writing off a loan is not creating properly the final accrual transaction and journal entries
Bharath Gowda created FINERACT-1902: --- Summary: Writing off a loan is not creating properly the final accrual transaction and journal entries Key: FINERACT-1902 URL: https://issues.apache.org/jira/browse/FINERACT-1902 Project: Apache Fineract Issue Type: Bug Reporter: Bharath Gowda While writing off a loan if there is not yet accrued interest, fee, or penalty, it shall be calculated and create the proper accrual transaction and journal entries. *Actual behavior* - Final Accrual calculation (and transaction) is not happening - recalculateAccruals method call is “dummy” the loan is not Active by the time this method is called *To Reproduce* # create a loan account with accrual accounting # write off the loan account # System will not post the accrual entries for the written off income amount -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1879) Loan Credit Committee Aproval Steps
[ https://issues.apache.org/jira/browse/FINERACT-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17683845#comment-17683845 ] Bharath Gowda commented on FINERACT-1879: - Hi [~francisguchie] or [~eroemma] or [~mkaitesi] [~ikimbrah] This sounds like an interesting enhancement but these approval steps could be very specific to an entity type. it is very much important to make enhancement generic and configurable so that the existing flow is not interrupted. Looking forward to read more details once provided, a Functional spec would be good as well to start with > Loan Credit Committee Aproval Steps > --- > > Key: FINERACT-1879 > URL: https://issues.apache.org/jira/browse/FINERACT-1879 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Francis Guchie >Assignee: Rahul Pawar >Priority: Major > > Loan processing cycle is categorized into 4 steps as opposed to 3 provided > currently > details > # application > # Approval at Branch Level > # Credit Committee Approval > # Disbursement > All these steps need have to be controlled by the Maker-Checker module. This > means we have to add another layer in between the current steps -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-1853) New Accounting Stretchy reports addition
Bharath Gowda created FINERACT-1853: --- Summary: New Accounting Stretchy reports addition Key: FINERACT-1853 URL: https://issues.apache.org/jira/browse/FINERACT-1853 Project: Apache Fineract Issue Type: Improvement Reporter: Bharath Gowda Attachments: Transaction Summary Report (1).numbers, Trial Balance Summary.numbers Trial Balance Summary Report Transaction Summary Report Two new useful accounting reports are to be included in Fineract. Attached is the report format of the same -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-384) Product Mix - for Saving Accounts
[ https://issues.apache.org/jira/browse/FINERACT-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bharath gowda updated FINERACT-384: --- Labels: Roadmap2022 gsoc p2 (was: gsoc p2) > Product Mix - for Saving Accounts > - > > Key: FINERACT-384 > URL: https://issues.apache.org/jira/browse/FINERACT-384 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Ippez Roberts >Priority: Major > Labels: Roadmap2022, gsoc, p2 > Time Spent: 10m > Remaining Estimate: 0h > > The Product mix for Loan Accounts needs to be added to cater for Savings > Products as some MFI have a policy to restrict a client from opening some > savings product together by the same client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-390) Reactivate of a group after being closed
[ https://issues.apache.org/jira/browse/FINERACT-390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bharath gowda updated FINERACT-390: --- Labels: Roadmap2022 gsoc p2 (was: gsoc p2) > Reactivate of a group after being closed > > > Key: FINERACT-390 > URL: https://issues.apache.org/jira/browse/FINERACT-390 > Project: Apache Fineract > Issue Type: Improvement > Components: Groups >Reporter: Santosh Math >Priority: Minor > Labels: Roadmap2022, gsoc, p2 > > Reported by Mexina Daniel at https://mifosforge.jira.com/browse/MIFOSX-2823 > Original Description: > When the closed group wants again to apply for a loan, in Mifos X now you > have to create another new group > For better group management, i request for new feature of be able to > reactivate a group once it has been closed. This can help to reduce many > closed groups -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-452) Loan accounts with standing instructions should not be allowed to 'Undo Disbursal' Unless standing instruction created for the loan account is deleted.
[ https://issues.apache.org/jira/browse/FINERACT-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bharath gowda updated FINERACT-452: --- Labels: Roadmap2022 gsoc2017 p2 volunteers (was: gsoc2017 p2 volunteers) > Loan accounts with standing instructions should not be allowed to 'Undo > Disbursal' Unless standing instruction created for the loan account is > deleted. > --- > > Key: FINERACT-452 > URL: https://issues.apache.org/jira/browse/FINERACT-452 > Project: Apache Fineract > Issue Type: Bug > Components: Loan >Reporter: Santosh Math >Priority: Major > Labels: Roadmap2022, gsoc2017, p2, volunteers > > Once loan is disbursed with linked savings account and standing instruction, > the application is allowing to do undo disbursal. Validation message should > be thrown as "Standing Instruction created can't undo disbursal", delete > standing instruction related to this loan account and try again" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-516) Add current password field to prevent unauthorized users from changing password of the current user #2428
[ https://issues.apache.org/jira/browse/FINERACT-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bharath gowda updated FINERACT-516: --- Labels: Roadmap2022 gsoc p2 (was: gsoc p2) > Add current password field to prevent unauthorized users from changing > password of the current user #2428 > - > > Key: FINERACT-516 > URL: https://issues.apache.org/jira/browse/FINERACT-516 > Project: Apache Fineract > Issue Type: Improvement > Components: User Management >Reporter: Santosh Math >Priority: Major > Labels: Roadmap2022, gsoc, p2 > Attachments: 29419719-81d3d36a-8378-11e7-9ad4-20074c6627cd.png > > > Reported by Nenge1 > Link, > Mifos dropdown->profile>change password (check the screenshot) > Allowing user to enter only new password increase vulnerability because the > username is visible. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-500) If holiday is defined and active for specific date or specific date range , application should not allow to define another holiday for the same date or date range
[ https://issues.apache.org/jira/browse/FINERACT-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bharath gowda updated FINERACT-500: --- Labels: Roadmap2022 gsoc p2 (was: gsoc p2) > If holiday is defined and active for specific date or specific date range , > application should not allow to define another holiday for the same date or > date range > -- > > Key: FINERACT-500 > URL: https://issues.apache.org/jira/browse/FINERACT-500 > Project: Apache Fineract > Issue Type: Improvement > Components: Organization >Reporter: Santosh Math >Priority: Minor > Labels: Roadmap2022, gsoc, p2 > > Presently the application is allowing to define two holidays for same date. > The validation error should be thrown -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-537) Audit log in and log out
[ https://issues.apache.org/jira/browse/FINERACT-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bharath gowda updated FINERACT-537: --- Labels: Roadmap2022 gsoc p2 (was: gsoc p2) > Audit log in and log out > > > Key: FINERACT-537 > URL: https://issues.apache.org/jira/browse/FINERACT-537 > Project: Apache Fineract > Issue Type: Improvement > Components: User Management >Affects Versions: 1.0.0 >Reporter: thynn win >Priority: Major > Labels: Roadmap2022, gsoc, p2 > > Currently there is an audit table and code base for logging other activities > but sign in and sign out. > We have had a couple of clients requesting audit for who is currently logged > in or at least to be able to view who logged in and logged out when. > Acceptance criteria: > Whenever a user login or logout, an entry should be made to audit table with > timestamp and username. It'd be great if you can record IP address also. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-565) Limit number of Loan Accounts for Clients
[ https://issues.apache.org/jira/browse/FINERACT-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bharath gowda updated FINERACT-565: --- Labels: Roadmap2022 beginner (was: beginner) > Limit number of Loan Accounts for Clients > - > > Key: FINERACT-565 > URL: https://issues.apache.org/jira/browse/FINERACT-565 > Project: Apache Fineract > Issue Type: New Feature > Components: Client >Affects Versions: 1.1.0 >Reporter: Janarthanan Poornavel >Priority: Major > Labels: Roadmap2022, beginner > > Need a configurable way to have the system control the number of loans that a > client can take. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-578) Year end -Accounting
[ https://issues.apache.org/jira/browse/FINERACT-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bharath gowda updated FINERACT-578: --- Labels: Roadmap2022 (was: ) > Year end -Accounting > -- > > Key: FINERACT-578 > URL: https://issues.apache.org/jira/browse/FINERACT-578 > Project: Apache Fineract > Issue Type: Bug >Reporter: sangamesh >Priority: Major > Labels: Roadmap2022 > > Year end -Accounting process- Should provide year ending wherein after year > ending all the profits and expense booked will be for that year only. But as > now it's been carried out for next year too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-679) Share Transfer And Distinctive Number
[ https://issues.apache.org/jira/browse/FINERACT-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bharath gowda updated FINERACT-679: --- Labels: Roadmap2022 (was: ) > Share Transfer And Distinctive Number > -- > > Key: FINERACT-679 > URL: https://issues.apache.org/jira/browse/FINERACT-679 > Project: Apache Fineract > Issue Type: New Feature > Components: Shares >Reporter: Girish Kumar P A >Priority: Major > Labels: Roadmap2022 > > Hi > As of now there is only the option of Redeeming the Shares back to the > Company, but the members or the clients can Transfer the Shares to another > person too. > The option is missing. > Another major addition that needs to be built is the Distinctive numbers of > the Shares > Persons holding the Shares of a firm will have the Share Certificate number > and the Distinctive (Folio) Numbers > Is it possible to develop that on the current Version ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-832) ATM Connectors
[ https://issues.apache.org/jira/browse/FINERACT-832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bharath gowda updated FINERACT-832: --- Labels: Roadmap2022 (was: ) > ATM Connectors > -- > > Key: FINERACT-832 > URL: https://issues.apache.org/jira/browse/FINERACT-832 > Project: Apache Fineract > Issue Type: New Feature > Components: System >Affects Versions: 1.3.0 > Environment: FINERACT/MIFOS >Reporter: Saul Barragan >Priority: Trivial > Labels: Roadmap2022 > > Thanks for your time, before of nothing,... > > Hello to Who may concern, > > I review the documentation of FINERACT: > [https://cwiki.apache.org/confluence/display/FINERACT/ATM+Connectors] > In specific where is the ATM Connector in the part of features in progress... > This documentation is from 2016. > The question is: Today in the last versión of FINERACT or MIFOS, ATM > Connectors is working? > > Thanks! > > Saul C. A. Barragan Vargas > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-848) Add ability to define custom interest rate in fixed and recurring deposit accounts
[ https://issues.apache.org/jira/browse/FINERACT-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bharath gowda updated FINERACT-848: --- Labels: Roadmap2022 features (was: features) > Add ability to define custom interest rate in fixed and recurring deposit > accounts > -- > > Key: FINERACT-848 > URL: https://issues.apache.org/jira/browse/FINERACT-848 > Project: Apache Fineract > Issue Type: Improvement > Components: Savings >Affects Versions: 1.1.0, 1.2.0, 1.3.0 >Reporter: Zayyad A. Said >Priority: Major > Labels: Roadmap2022, features > > Many MFIs offering Fixed Deposits and Recurring Deposits give different > interest rates to their depositors based on negotiation ability of the > depositor. > Currently interest rate chart is defined at product level with no flexibility > to amend the rate at account level making it difficult for such MFIs to use > Mifos X for their operations. > We need to have the interest rate defined when opening a deposit account that > will override the rate defined at product level. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1761) New Charge-Waiver Transaction
[
https://issues.apache.org/jira/browse/FINERACT-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bharath gowda updated FINERACT-1761:
Description:
{panel}
*As a* user with 'NEW'“ permission
*I want to* _add a new charge adjustment transaction_
*in order to* post the charge waiver benefit provided to the customer
{panel}
*User Cases/Background and details:*
The previous solution provided by Fineract of Charge waiver(for an unpaid
charge) and charge refund(for a paid charge) had its own constraints with
respect to
# Restrictions on reversal of previous transactions.
# Reverse replays for charge refunds
# Accounting.
Proposed the new solution will satisfy all the requirements with one
transaction:
# A single transaction can be used for waiving both paid and unpaid charges.
# Since it is always posted at the current date, reversal of the previous
transaction should not be a problem.
# The proper linkage between the new charge adjustment transaction with the
loan charge.
*Linking*
* The new charge adjustment transaction type requires a reference to the
charge to which it is being adjusted. This will be the transaction ID added as
a link to the loan_charge. Only the new transaction points to an existing
loan_charge.
* Details of the existing loan charge should be provided manually by the user
{panel:title=Acceptance Criteria}
# New charge adjustment transaction behaviour is the same as the goodwill
credit transaction Behaviour
# Only difference is “charge adjustment transaction should be linked to the
“loan charge account”.{panel}
was:
{panel}
*As a* user with 'NEW'“ permission
*I want to* _add a new charge waiver transaction_
*in order to* post the charge waiver benefit provided to the customer
{panel}
*User Cases/Background and details:*
The previous solution provided from Fineract of Charge waiver(for an unpaid
charge) and charge refund(for a paid charge) had its own constraints with
respect to
# Restrictions on reversal of previous transactions.
# Reverse replays for charge refunds
# Accounting.
Proposed the new solution will satisfy all the requirements with one
transaction:
# A single transaction can be used for waiving both paid and unpaid charges.
# Since it is always posted at the current date, reversal of the previous
transaction should not be a problem.
# The proper linkage between the new charge waiver transaction with the loan
charge.
*Linking*
* The new charge waiver transaction type requires a reference to the charge to
which it is being waived. This will be the transaction ID added as a link to
the loan_charge. Only the new transaction points to an existing loan_charge.
* Details of the existing transaction should be provided manually by the user
{panel:title=Acceptance Criteria}
# New chargewavier transaction behaviour is same as the goodwill credit
transaction Behaviour
# Only difference is “charge wavie transaction should be linked to the “loan
charge account”.
{panel}
> New Charge-Waiver Transaction
> -
>
> Key: FINERACT-1761
> URL: https://issues.apache.org/jira/browse/FINERACT-1761
> Project: Apache Fineract
> Issue Type: New Feature
>Reporter: Mihaly Dallos
>Priority: Major
> Labels: PepperSoup
>
> {panel}
> *As a* user with 'NEW'“ permission
> *I want to* _add a new charge adjustment transaction_
> *in order to* post the charge waiver benefit provided to the customer
> {panel}
> *User Cases/Background and details:*
> The previous solution provided by Fineract of Charge waiver(for an unpaid
> charge) and charge refund(for a paid charge) had its own constraints with
> respect to
> # Restrictions on reversal of previous transactions.
> # Reverse replays for charge refunds
> # Accounting.
> Proposed the new solution will satisfy all the requirements with one
> transaction:
> # A single transaction can be used for waiving both paid and unpaid charges.
> # Since it is always posted at the current date, reversal of the previous
> transaction should not be a problem.
> # The proper linkage between the new charge adjustment transaction with the
> loan charge.
> *Linking*
> * The new charge adjustment transaction type requires a reference to the
> charge to which it is being adjusted. This will be the transaction ID added
> as a link to the loan_charge. Only the new transaction points to an existing
> loan_charge.
> * Details of the existing loan charge should be provided manually by the user
> {panel:title=Acceptance Criteria}
> # New charge adjustment transaction behaviour is the same as the goodwill
> credit transaction Behaviour
> # Only difference is “charge adjustment transaction should be linked to the
> “loan charge account”.{panel}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (FINERACT-1761) New Charge-Waiver Transaction
[
https://issues.apache.org/jira/browse/FINERACT-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bharath gowda reassigned FINERACT-1761:
---
Assignee: Adam Saghy
> New Charge-Waiver Transaction
> -
>
> Key: FINERACT-1761
> URL: https://issues.apache.org/jira/browse/FINERACT-1761
> Project: Apache Fineract
> Issue Type: New Feature
>Reporter: Mihaly Dallos
>Assignee: Adam Saghy
>Priority: Major
> Labels: PepperSoup
>
> {panel}
> *As a* user with 'NEW'“ permission
> *I want to* _add a new charge adjustment transaction_
> *in order to* post the charge waiver benefit provided to the customer
> {panel}
> *User Cases/Background and details:*
> The previous solution provided by Fineract of Charge waiver(for an unpaid
> charge) and charge refund(for a paid charge) had its own constraints with
> respect to
> # Restrictions on reversal of previous transactions.
> # Reverse replays for charge refunds
> # Accounting.
> Proposed the new solution will satisfy all the requirements with one
> transaction:
> # A single transaction can be used for waiving both paid and unpaid charges.
> # Since it is always posted at the current date, reversal of the previous
> transaction should not be a problem.
> # The proper linkage between the new charge adjustment transaction with the
> loan charge.
> *Linking*
> * The new charge adjustment transaction type requires a reference to the
> charge to which it is being adjusted. This will be the transaction ID added
> as a link to the loan_charge. Only the new transaction points to an existing
> loan_charge.
> * Details of the existing loan charge should be provided manually by the user
> {panel:title=Acceptance Criteria}
> # New charge adjustment transaction behaviour is the same as the goodwill
> credit transaction Behaviour
> # Only difference is “charge adjustment transaction should be linked to the
> “loan charge account”.{panel}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (FINERACT-1746) Random Installments Generation Issue
[ https://issues.apache.org/jira/browse/FINERACT-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bharath gowda updated FINERACT-1746: Description: In an interest recalculation enabled loan, we are noticing the EMI of the last installment is going wrong for the following scenario To reproduce # Create the loan product as per the config attached # Have working day configured from Monday to Friday with "move to next working day" # Create a loan account and disburse with the following parameters ## Disbursement date: 28 January 2022 ## First Repayment date: 1 March 2022 ## amount: 1000 ## repayment: 12 every 1 month ## interest rate 23.9 per annum (which will get you an EMI 94.35 ## Now make the repayments in the following order ### 01-March-2022 - 94.35 ### 01-April-2022 - 94.35 ### 03-May-2022 - 94.35 ### 01-June-2022 - 94.35 ### 01-July-2022 - 94.35 ### 01-August-2022 - 94.35 ## Now check the repayment schedule & EMI & Interest ### The whole Installments would be wrong ### The last installment amount will be showing the wrong amount. ### check the interest amount collected - this is going wrong too # Check the schedule screenshot for examples was: In an interest recalculation enabled loan, we are noticing the EMI of the last installment is going wrong for the following scenario To reproduce # Create the loan product as per the config attached # Have working day configured from Monday to Friday with "move to next working day" # Create a loan account and disburse with the following parameters ## Disbursement date: 28 January 2022 ## First Repayment date: 1 March 2022 ## amount: 1000 ## repayment: 12 every 1 month ## interest rate 23.9 per annum (which will get you an EMI 94.35 ## Now make the repayments in the following order ### 01-March-2022 - 94.35 ### 01-April-2022 - 94.35 ### 03-May-2022 - 94.35 ### 01-June-2022 - 94.35 ### 01-July-2022 - 94.35 ### 01-August-2022 - 94.35 ## Now check the repayment schedule & EMI ### The whole Installments would be wrong ### The last installment amount will be showing the wrong amount. # Check the schedule screenshot for examples > Random Installments Generation Issue > > > Key: FINERACT-1746 > URL: https://issues.apache.org/jira/browse/FINERACT-1746 > Project: Apache Fineract > Issue Type: Bug > Components: Loan >Affects Versions: 1.7.0 >Reporter: bharath gowda >Priority: Critical > Attachments: after.png, before.png, last installment issue.png, loan > product.png > > > In an interest recalculation enabled loan, we are noticing the EMI of the > last installment is going wrong for the following scenario > > To reproduce > # Create the loan product as per the config attached > # Have working day configured from Monday to Friday with "move to next > working day" > # Create a loan account and disburse with the following parameters > ## Disbursement date: 28 January 2022 > ## First Repayment date: 1 March 2022 > ## amount: 1000 > ## repayment: 12 every 1 month > ## interest rate 23.9 per annum (which will get you an EMI 94.35 > ## Now make the repayments in the following order > ### 01-March-2022 - 94.35 > ### 01-April-2022 - 94.35 > ### 03-May-2022 - 94.35 > ### 01-June-2022 - 94.35 > ### 01-July-2022 - 94.35 > ### 01-August-2022 - 94.35 > ## Now check the repayment schedule & EMI & Interest > ### The whole Installments would be wrong > ### The last installment amount will be showing the wrong amount. > ### check the interest amount collected - this is going wrong too > # Check the schedule screenshot for examples -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-1746) Random Installments Generation Issue
bharath gowda created FINERACT-1746: --- Summary: Random Installments Generation Issue Key: FINERACT-1746 URL: https://issues.apache.org/jira/browse/FINERACT-1746 Project: Apache Fineract Issue Type: Bug Components: Loan Affects Versions: 1.7.0 Reporter: bharath gowda Attachments: after.png, before.png, last installment issue.png, loan product.png In an interest recalculation enabled loan, we are noticing the EMI of the last installment is going wrong for the following scenario To reproduce # Create the loan product as per the config attached # Have working day configured from Monday to Friday with "move to next working day" # Create a loan account and disburse with the following parameters ## Disbursement date: 28 January 2022 ## First Repayment date: 1 March 2022 ## amount: 1000 ## repayment: 12 every 1 month ## interest rate 23.9 per annum (which will get you an EMI 94.35 ## Now make the repayments in the following order ### 01-March-2022 - 94.35 ### 01-April-2022 - 94.35 ### 03-May-2022 - 94.35 ### 01-June-2022 - 94.35 ### 01-July-2022 - 94.35 ### 01-August-2022 - 94.35 ## Now check the repayment schedule & EMI ### The whole Installments would be wrong ### The last installment amount will be showing the wrong amount. # Check the schedule screenshot for examples -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-1745) Loan Schedule Final Installment calculation issue
bharath gowda created FINERACT-1745: --- Summary: Loan Schedule Final Installment calculation issue Key: FINERACT-1745 URL: https://issues.apache.org/jira/browse/FINERACT-1745 Project: Apache Fineract Issue Type: Bug Components: Loan Affects Versions: 1.7.0 Reporter: bharath gowda Attachments: loan product.png, schedule after issue reproducing.png, schedule before issue.png In an interest recalculation enabled loan, we are noticing the EMI of the last installment is going wrong for the following scenario To reproduce # Create the loan product as per the config attached # Have working day configured from Monday to Friday with "move to next working day" # Create a loan account and disburse with the following parameters ## Disbursement date: 6th May 2022 ## First Repayment date: 27th May 2022 ## amount: 7800 ## repay: 60 every 1 month ## interest rate 8.9 per annum (which will get you an EMI 161.08 ## Now make the repayments in the following order ### 27-May-2022 - 161.08 ### 27-June-2022 - 161.08 ### 27-Jule-2022 - 161.08 ### 30-August-2022 - 161.08 ### 01-sept-2022 - 15 ## Now check the repayment schedule EMI of the last installment it will be showing the wrong amount. # Check the schedule screenshot for examples -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1706) Chargeback transaction
[ https://issues.apache.org/jira/browse/FINERACT-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bharath gowda updated FINERACT-1706: Description: *As a* user with 'NEW'“ permission *I want to* _add a charge-back transaction on the loan account_ *in order to* post the debit to the loan account (increase the loan balance of the account) *User Cases/Background and details:* When an old transaction needs to be reversed, currently the system reverses all the latest repayments first in order to reverse the old transaction this might result in interest, and principal recalculation, and affect the accounting ledger closing entries. If we introduce the new transaction named chargeback it will increase the loan balance and the amount would be collected in the upcoming repayments This approach is also helpful in covering the refund scenarios for organizations that refund back the amount for the customers who were excess collected or disputes raised. We can have two types and can be managed at the payment_type level • REPAYMENT_ADJUSTMENT_CHARGEBACK • REPAYMENT_ADJUSTMENT_REFUND *Acceptance criteria* # Functionally both types behave the same with respect to loan treatment, hence a single transaction type with different 'payment types' will work to meet 2 use-cases. # Chargeback Transactions should have linkage to the original transaction which was raised as a dispute transaction # A chargeback transaction will increase the current loan balance and adds to the next installment and collects back by the next repayment. # A Chargeback Transaction when posted a bill will be due to be collected as on the current date # The overdue calculation, Delinquency calculation will begin from the chargeback addition date # When there are 2 chargebacks the Delinquency calculation will happen from the last not fully paid chargeback date. # Chargeback transactions should have the ability to post full or partial amounts as per the user’s request # A Chargeback Transaction can be posted in multiple types on the same loan account # A chargeback transaction can be posted on the closed loan account. when posted on the closed loan account, the loan should be reopened with the principal balance to pay # Extra installments created after maturity should have a flag that it’s not a real installment. Validations for now # A Chargeback Transaction should be allowed only for zero interest bearing loan accounts and # No Changes on Penalities calculations for post-maturity chargeback installments # Chargeback transactions once posted cannot be reversed The attached excel document will explain the different use cases of schedule behavior based on charge-back transactions And the following will be the accounting treatment for the chargeback transaction(for both cash-based and accrual cases) Journal entries to be passed for chargeback transaction ||Entry Type||Accounting Type in Loan Product||GL-Code||GL-Name in Loan Product||Type of CoA||The logic for calculating the Amount for passing the entries|| |Debit|Loan portfolio(Asset section)|112601|Loans Receivable|Asset|Sum of Principal components of the chargeback transaction| |Credit|Fund source(Asset section)|145023|Suspense/Clearing account|Liability|Sum of Principal components of the chargeback transaction| was:TODO: add the description > Chargeback transaction > -- > > Key: FINERACT-1706 > URL: https://issues.apache.org/jira/browse/FINERACT-1706 > Project: Apache Fineract > Issue Type: New Feature >Reporter: Adam Saghy >Assignee: Adam Saghy >Priority: Major > Fix For: 1.9.0 > > Attachments: chargeback repayment schedule scenarios.xlsx > > > *As a* user with 'NEW'“ permission > *I want to* _add a charge-back transaction on the loan account_ > *in order to* post the debit to the loan account (increase the loan balance > of the account) > *User Cases/Background and details:* > When an old transaction needs to be reversed, currently the system reverses > all the latest repayments first in order to reverse the old transaction > this might result in interest, and principal recalculation, and affect the > accounting ledger closing entries. > If we introduce the new transaction named chargeback it will increase the > loan balance and the amount would be collected in the upcoming repayments > > This approach is also helpful in covering the refund scenarios for > organizations that refund back the amount for the customers who were excess > collected or disputes raised. > We can have two types and can be managed at the payment_type level > • REPAYMENT_ADJUSTMENT_CHARGEBACK > • REPAYMENT_ADJUSTMENT_REFUND > > *Acceptance criteria* > # Functionally both types behave the same with respect to loan treatment, > hence a single
[jira] [Updated] (FINERACT-1706) Chargeback transaction
[ https://issues.apache.org/jira/browse/FINERACT-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bharath gowda updated FINERACT-1706: Attachment: chargeback repayment schedule scenarios.xlsx > Chargeback transaction > -- > > Key: FINERACT-1706 > URL: https://issues.apache.org/jira/browse/FINERACT-1706 > Project: Apache Fineract > Issue Type: New Feature >Reporter: Adam Saghy >Assignee: Adam Saghy >Priority: Major > Fix For: 1.9.0 > > Attachments: chargeback repayment schedule scenarios.xlsx > > > TODO: add the description -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (FINERACT-1635) Posting transactions in the past Vs Closing entries
[ https://issues.apache.org/jira/browse/FINERACT-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17564336#comment-17564336 ] bharath gowda edited comment on FINERACT-1635 at 7/11/22 1:42 PM: -- [~francisguchie] the business date function developed by [~adamsaghy] is at the whole application layer and it will not solve the problem as the date would be applicable to the closure date as well. In short, this Business_date acts like a server date where the application treats every entry as happening as of that Business_date. This feature developed is very beneficial for any organization who would like to do past days entries by setting the business date to that date where Accounting Date, Transaction Data, and Accounting Closure Date will follow the same date function and afraid will not solve our problem. The one that I mentioned in my first comment is a different type of implementation where the business date and value date will be divided into two sections where portfolio transaction can follow the business date whereas accounting entry would follow the value date. for this, we will have to do more brainstorming on each edge case to solve our closure problem Hope this helps. was (Author: bgowda): [~francisguchie] the business date function developed by [~adamsaghy] is at the whole application layer and it will not solve the problem as the date would be applicable to the closure date as well. In short, this Business_date acts like a server date where the application treats every entry as happening as of that Business_date. This feature developed is very beneficial for any organization who would like to do past days entries by setting the business date to that date where Accounting Date, Transaction Data, and Accounting Closure Date will follow the same date function and afraid will not solve our problem. More details on the Implemented business date concept can be found in this document https://mifosforge.jira.com/wiki/spaces/PS/pages/3079733251/Introducing+Business+Date+into+Fineract+-+technical+version The one that I mentioned in my first comment is a different type of implementation where the business date and value date will be divided into two sections where portfolio transaction can follow the business date whereas accounting entry would follow the value date. for this, we will have to do more brainstorming on each edge case to solve our closure problem Hope this helps. > Posting transactions in the past Vs Closing entries > --- > > Key: FINERACT-1635 > URL: https://issues.apache.org/jira/browse/FINERACT-1635 > Project: Apache Fineract > Issue Type: Bug >Reporter: Francis Guchie >Assignee: Francis Guchie >Priority: Major > Attachments: image-2022-06-08-18-22-24-540.png > > > As opposed to many other systems, in Apache-fineract, there is not need to > run end of day end of month procedures. Thanks to cron jobs under the > scheduler jobs > However, for users that are always lagging behind due to staffing and other > challenges, the function of *closing entries* creates an avenue of fraud > also, closing entries can be *DELETED* > It would nice to add a global setting that restricts users from posting back > dated entries > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1635) Posting transactions in the past Vs Closing entries
[ https://issues.apache.org/jira/browse/FINERACT-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17564336#comment-17564336 ] bharath gowda commented on FINERACT-1635: - [~francisguchie] the business date function developed by [~adamsaghy] is at the whole application layer and it will not solve the problem as the date would be applicable to the closure date as well. In short, this Business_date acts like a server date where the application treats every entry as happening as of that Business_date. This feature developed is very beneficial for any organization who would like to do past days entries by setting the business date to that date where Accounting Date, Transaction Data, and Accounting Closure Date will follow the same date function and afraid will not solve our problem. More details on the Implemented business date concept can be found in this document https://mifosforge.jira.com/wiki/spaces/PS/pages/3079733251/Introducing+Business+Date+into+Fineract+-+technical+version The one that I mentioned in my first comment is a different type of implementation where the business date and value date will be divided into two sections where portfolio transaction can follow the business date whereas accounting entry would follow the value date. for this, we will have to do more brainstorming on each edge case to solve our closure problem Hope this helps. > Posting transactions in the past Vs Closing entries > --- > > Key: FINERACT-1635 > URL: https://issues.apache.org/jira/browse/FINERACT-1635 > Project: Apache Fineract > Issue Type: Bug >Reporter: Francis Guchie >Priority: Major > Attachments: image-2022-06-08-18-22-24-540.png > > > As opposed to many other systems, in Apache-fineract, there is not need to > run end of day end of month procedures. Thanks to cron jobs under the > scheduler jobs > However, for users that are always lagging behind due to staffing and other > challenges, the function of *closing entries* creates an avenue of fraud > also, closing entries can be *DELETED* > It would nice to add a global setting that restricts users from posting back > dated entries > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1651) Mobile Phone digit Standardization (length)
Title: Message Title bharath gowda commented on FINERACT-1651 Re: Mobile Phone digit Standardization (length) Francis Guchie This Enhancement if implemented right, will be a good addition to accepting only valid phone numbers in the system. Add Comment This message was sent by Atlassian Jira (v8.20.10#820010-sha1:ace47f9)
