My point is that a charge must be linked to a financial account, not to a client.
Regards El jue., 19 de marzo de 2026 9:07 p. m., Ashhar Ahmad Khan < [email protected]> escribió: > @Victor - that is a fair question. > > The specific scenario I had in mind is this: a charge has been > applied to a client and a partial payment has already been made > against it. The charge should no longer apply - perhaps it was > applied incorrectly or the client situation has changed. > > In that state, delete fails. Once any payment exists the DB > rejects the deletion via the FK constraint on > m_client_charge_paid_by, and the service surfaces this as > "cannot be deleted as transactions have been made on the > same charge". > > Waive is also not quite the right fit semantically. It zeros > the remaining outstanding and creates a waiver transaction > in the client's transaction history - client transactions > are only created as a result of charge payments or waivers, > so this would show up as an explicit forgiveness event. > That implies the institution chose to forgive a valid debt, > which is not accurate for a charge that should not have > been applied in the first place. > > Inactivation fills that gap - marking the charge as no > longer applicable while preserving the existing payment > history exactly as-is, without creating any additional > transaction records. > > That said I could easily be missing context on how this > scenario is handled today, and would genuinely appreciate > any guidance from those who know the project better. > > Happy to close or adjust based on whatever direction makes > sense here. > > > On Fri, Mar 20, 2026 at 8:05 AM VICTOR MANUEL ROMERO RODRIGUEZ < > [email protected]> wrote: > >> @Ashhar I think that endpoint should not be used anymore. >> >> @Bharath Gowda <[email protected]> Is there any use case for this >> endpoint? /clients/{id}/charges ? >> >> Best regards >> >> Victor >> >> >> El jue, 19 mar 2026 a las 20:27, Ashhar Ahmad Khan (<[email protected]>) >> escribió: >> >>> Hi all, >>> >>> While going through the client module I noticed that >>> POST /clients/{clientId}/charges/{chargeId}?command=inactivate >>> has never worked. The command routes correctly through the API layer, >>> but no handler was registered for CLIENTCHARGE|INACTIVATE, so it >>> always throws UnsupportedCommandException. The service method was >>> also a stub returning null with a "functionality not yet supported" >>> comment. >>> >>> I opened a PR to implement the missing handler and service logic: >>> https://github.com/apache/fineract/pull/5655 >>> >>> One thing I wanted to get feedback on before it gets reviewed - >>> undoPayment() and undoWaiver() on ClientCharge unconditionally set >>> status = true, which means undoing a prior payment on an inactivated >>> charge would silently reactivate it. In the PR I treated inactivation >>> as a terminal state and blocked undo on inactive charges. >>> >>> Happy to hear if there is a different intended behavior here. >>> >>> Thanks >>> Ashhar >>> >>
