@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 >> >
