adamsaghy commented on PR #5940: URL: https://github.com/apache/fineract/pull/5940#issuecomment-4742183857
> > > > > Hi @adamsaghy, I have updated the charge attachment flows locally to reject charges whose calculated amount becomes 0 after applying account currency rounding rules, instead of returning silently. > > > > > I have a question regarding future charges such as Savings Account Percentage of Withdrawal Charges and Share Account Redeem Charges. > > > > > In these cases, the charge is attached successfully first and the amount is calculated only when the business transaction occurs. If the calculated charge amount becomes 0 after rounding, what is the expected behavior: > > > > > > > > > > 1. Reject the business transaction (withdrawal/redeem) with a validation error. > > > > > 2. Allow the transaction but skip creating/applying the charge similar to silent return. > > > > > 3. Keep the current behavior and allow a 0 value charge result. > > > > > > > > > > Could you please clarify the expected behavior for these future-charge scenarios so I can align the implementation consistently across Savings and Shares? > > > > > Thank you! > > > > > > > > > > > > I see no changes, no reply on my questions and concerns.. i have stopped reviewing the PR at half time... > > > > > > > > > Hi @adamsaghy, > > > Sorry for the confusion. When I wrote that I had updated the charge attachment flows locally, I meant that the changes were only completed in my local branch and had not yet been pushed or amended into the PR. > > > My intention was to first finish addressing all of your review comments, validate everything thoroughly, and then push a single updated commit together with replies to each review comment. Because of that, I had not yet responded individually to the review feedback. > > > I realize now that my comment made it sound like the PR had already been updated, which was not the case. Sorry for causing you to spend time reopening the review. > > > I am currently working through all of the review comments and will push the updated changes together with responses shortly. > > > Regarding the future-charge scenarios, that question was meant as a design clarification while implementing the remaining changes so I can keep the behavior consistent across Savings and Shares. This is the only thing that I need to understand and resolve and then I will ammend the commit. > > > Thank you for your patience and for the detailed review feedback. > > > > > > Thank you for the clarification ;) > > Regarding zero amount: Lets use option 1 **Reject the business transaction (withdrawal/redeem) with a validation error.** > > Thank you for the clarification. > > Just to confirm the expected behavior for percentage-based future charges: > > Suppose a Savings Account has a "Percentage of Withdrawal" charge configured as 0.5%. > > When the charge is attached to the account, the percentage value (0.5%) is stored successfully because the actual charge amount is not yet known. > > Later, if a withdrawal of 100 is performed and the account currency uses 0 decimal places (for example JPY), the calculated charge amount would be: > > 0.5% × 100 = 0.5 > > which would then round to 0 according to the currency rounding rules. > > With option 1, my understanding is that the withdrawal transaction itself should be rejected with a validation error because the calculated charge amount becomes zero after rounding. > > Is that the intended behavior, even though the withdrawal amount itself is valid and only the associated charge rounds to zero? > > I just want to confirm this edge case before implementing the validation in the future-charge flows. With this use case, it’s not as straightforward as it seems. I might have been overly strict here. Just because the charge is too small, we still want to allow the withdrawal. So, if the calculated charge is zero, we simply ignore it and don’t create it. @bharathc27, what are your thoughts on this? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
