👍 On Thu, Jul 17, 2025 at 10:11 AM James Dailey <jamespdai...@gmail.com> wrote:
> Those are significant issues! Maybe this should be broken into a few > tickets and described there first in detail. > > > > On Thu, Jul 17, 2025 at 5:24 AM Ádám Sághy <adamsa...@gmail.com> wrote: > >> Hi Bharath, >> >> *Yes, please proceed as the PR and the related stories aren’t providing >> much clarity at this point.* >> >> Hi Lizbeth, >> >> I have a general understanding of this story and the associated PR, but I >> have to say I’m not a fan of the current naming—“Savings Accounts >> Improvements.” It’s very vague and doesn’t accurately describe what this >> work is about. >> >> Regarding the PR itself, I have some major concerns: >> >> *Blockers:* >> >> - >> >> The PR is extremely large—80 files changed and 2,403 lines added. >> - >> >> The code is very difficult to follow: there is almost no >> documentation or comments, and many methods are several hundred lines >> long, >> each handling 10–20 different tasks. >> - >> >> I have serious reservations about both the technical and business >> logic. >> - >> >> There are no tests included. *Without proper testing, there is no way >> it can be merged!* >> >> Without a significant refactor and reworking of the logic, I don’t see >> how this can be properly reviewed or approved. >> >> Could you please break up the logic into much smaller, more manageable >> pieces that are easier to understand, with clear, self-explanatory code? >> >> >> Thank you! >> >> Regards, >> >> Adam >> >> On 2025. Jul 15., at 7:47, Bharath Gowda <bgo...@mifos.org> wrote: >> >> Hi Adam, Arnold, >> >> I was also a part of these enhancements for the savings module. >> Will be happy to clarify any functional questions or concerns on the >> functionality/enhancements made as part of it. >> >> >> >> Regards, >> Bharath >> Lead Implementation Analyst | Mifos Initiative >> PMC Member | Apache Fineract >> Mobile: +91.7019635592 >> http://mifos.org <http://facebook.com/mifos> >> <http://www.twitter.com/mifos> >> >> >> On Mon, Jul 14, 2025 at 11:48 PM Ádám Sághy <adamsa...@gmail.com> wrote: >> >>> Hi >>> >>> Sorry for being slow, I am still digesting the raised pull request and >>> the description you have shared. >>> >>> Regards, >>> Adam >>> >>> >>> On 2025. Jul 14., at 19:40, LIZBETH ANGELICA MARTINEZ CEJA < >>> liz.marti...@fintecheando.mx> wrote: >>> >>> Hello Fineract Community, >>> Is there any comment about the previous email? >>> >>> El vie, 11 jul 2025 a las 14:03, LIZBETH ANGELICA MARTINEZ CEJA (< >>> liz.marti...@fintecheando.mx>) escribió: >>> >>>> Hi Fineract Community, >>>> >>>> We would like to share a recent contribution to the platform related to >>>> improvements in savings account behavior: >>>> >>>> PR: https://github.com/apache/fineract/pull/4837 >>>> JIRA: https://issues.apache.org/jira/browse/FINERACT-2312 >>>> >>>> This pull request introduces an approach to accruals handling for >>>> savings accounts. In cases where a deposit or withdrawal occurs after >>>> accruals have been generated, the system will now remove all accruals from >>>> the transaction date onward without regenerating them. This change aims to >>>> improve both data consistency and system performance while avoiding >>>> duplication or misalignment in accounting records. >>>> >>>> >>>> Savings Account Improvements >>>> PR: https://github.com/apache/fineract/pull/4837 >>>> >>>> Savings products can now be configured with accrual accounting. Any >>>> savings account can record accrual transactions. >>>> To reproduce, follow the steps below for interest-related issues. >>>> >>>> - >>>> >>>> Create the Savings product according to the configuration >>>> >>>> >>>> - Create a retroactive and active savings account >>>> >>>> >>>> - Run the job: admin->systems->Manage jobs →Add Accrual >>>> Transactions For Savings >>>> >>>> >>>> - RunPost interest for Savings job, if the above works do not work. >>>> >>>> >>>> - (Ideally, the accumulation transaction for the savings should be >>>> added, which should be published >>>> >>>> >>>> - Check the accounting entry for the created savings account >>>> accrual transaction >>>> >>>> Currently, overdraft savings account transactions are not supported >>>> using accrual-based accounting entries. >>>> We need to support accrual accounting entries for overdrafts. Interest >>>> transactions and overdraft accrual transactions must be recorded using >>>> accrual accounting. >>>> Acceptance criteria: >>>> The accounting entry for the overdraft interest transaction is modified >>>> to support accrual accounting. >>>> It is an existing transaction: changes were made to the accounting >>>> entries to support accrual accounting. >>>> Overdraft transaction that is posted to the savings account through the >>>> work “Post interest for savings. >>>> A new overdraft accrual transaction type was integrated to debit the >>>> interest import. >>>> A new transaction type will be introduced and new accounting entries >>>> have been added. >>>> Overdraft accrual transactions are recorded only for accounts that are >>>> in overdraft status. >>>> The accumulation transaction is published by the same job “Add Accrual >>>> Transactions For Savings" with the frequency established for the job. >>>> To play >>>> >>>> 1. >>>> >>>> Create a savings product like the one attached. >>>> >>>> >>>> 1. Create a retroactive savings account and activate it and some >>>> deposit or withdrawal amount. >>>> >>>> >>>> 1. Run the job “Add Accrual Transactions For Savings”. >>>> >>>> The first day of each month the work must be carried out "Post >>>> interest for savings” >>>> >>>> >>>> >>>> Currently the system only calculated the accruals once a day and if a >>>> deposit or withdrawal was made it did not calculate the new accrual. With >>>> the implementation, when calculating the accrual, if several withdrawals >>>> and/or deposits are made in one day, it must calculate the accrual several >>>> times. >>>> Accrual is recorded on the same date when a deposit is made at the end >>>> of the day. >>>> The accrual is recorded on the same date when a withdrawal is made at >>>> the end of the day. >>>> The system should repeat the day's accrual if the balance changes that >>>> day due to a deposit or withdrawal. >>>> For example >>>> To play >>>> >>>> 1. >>>> >>>> Set billing date: June 5, 2025 >>>> >>>> >>>> 1. Create/approve/activate the overdraft account as of June 2, 2025 >>>> >>>> >>>> 1. Deposit 10,000 starting June 2nd >>>> >>>> >>>> 1. Make accruals >>>> >>>> >>>> 1. Deposit 10,000 starting June 3rd >>>> >>>> >>>> 1. Make accruals >>>> >>>> >>>> 1. Withdraw 40,000 starting June 4th >>>> >>>> >>>> >>>> >>>> We’ve also included detailed documentation to support the proposed >>>> changes, including the use case and technical details. >>>> >>>> We invite the community to review the proposal and share any feedback, >>>> questions, or concerns. >>>> >>>> Best regards, >>>> >>>> Lizbeth Martínez >>>> >>> >>> >> -- -- Paul
