Dhanno98 commented on PR #5940: URL: https://github.com/apache/fineract/pull/5940#issuecomment-4776477092
> > > @adamsaghy @Dhanno98 In any entity and scenario if the calculated charge amount is zero (after rounding) that charge should not be created. In your latest example, "Allow the transaction but skip creating/applying the charge, similar to silent return," sounds right to me. Any transactions associated with charges should not be affected. Hence withdraw transaction happens with no charge posting in the above example > > > > > > Hi @bharathcgowda @adamsaghy One follow-up question regarding future charges. > > For percentage-based future charges (withdrawal/redeem), I understand that the charge definition should be stored and, when the calculated amount rounds to zero, the transaction should continue and the charge should simply not be applied. > > For flat future charges (for example a Shares Flat Redeem Charge of 0.5 in a currency with 0 decimal places), the rounded charge amount is known to be zero already at attachment time and can never become non-zero later. > > Currently, the existing behavior appears to allow such a Flat Redeem Charge to be attached to the share account without any validation. During the attachment flow, the configured charge amount (0.5 in this example) is stored as-is and no currency rounding is performed. The amount is only passed through `Money.of()` later during the redeem-shares flow, where the calculated charge amount becomes 0 and is effectively not applied. > > For this scenario, what should be the expected behavior: > > > > 1. Keep the current behavior: allow the charge to be attached as-is and, during redemption, simply ignore it if the rounded amount becomes 0, similar to Percentage of Redeem Charges. > > 2. Round the flat redeem charge during attachment and reject it if the amount rounds to 0 by throwing a validation exception in the charge attachment flow itself. > > I dont think we should reject and throw error if charge became 0... @bharathcgowda thoughts? Thanks @adamsaghy. The current implementation in this PR already follows that behavior for Share Redeem Charges and Savings Percentage Withdrawal Charges. These charges continue to be attached and stored as configured. When they are later applied, the calculated charge amount goes through the existing `Money` rounding rules and, if the rounded amount becomes 0, the transaction proceeds normally and the charge is simply not applied. So Share Flat Redeem Charges that eventually round to 0 during the Redeem Shares flow are currently not rejected during attachment. I've also updated the PR with the latest changes and fixes. -- 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]
