Hi Àdàm, If I have understood you well, I believe this would very beneficial. For example, I am involved in some data reconciliation exercise. You find that a client's loan was input in the system with incorrect parameters. A user went ahead approved the loan and settled it in some cases even overpaid it using the client's savings (by transfer). Since there is no api to reverse a settled loan, it means that I have delete the loan form the database and all its related transactions and put it afresh with the correct parameters. This takes a lot of time.
It would be nice if such a loan can be reversed in one or two steps. Regards. Wilfred. On Wed, 15 Jun 2022, 11:54 Ádám Sághy, <adamsa...@gmail.com> wrote: > Hi Community, > > I hope you don’t mind my enthusiasm so far :) > > During my experience with Fineract, I was always wondering whether the > loan transactions can be refactored to be immutable. > > Technically speaking it could be done by 2 steps: > • Deprecate the “is_reversed” flag > • During any reversal, create a new transaction entry > instead > • Relocate the calculated portions fields to somewhere else > • ” m_loan_transaction_repayment_schedule_mapping” table > is already maintaining some of these portions, maybe it can be improved to > hold all of them > > However, it may sound easy from a technical point of view, it would be > quite a major change behind the curtains and will have an effect on many > things. > > I still think that it would be beneficial to go ahead with it for the > following reasons: > • Transaction immutability was and is an important concept of > accounting and any payment system > • Fineract can have a common, generic way of handling payments and > charges by creating a new transaction for every financial activity, > including the reversal of any of those transactions > • We will have a posting date and value date for transaction > reversals (which is missing as of right now…) > • We can have the order of the transactions (right now, if we have > T1 and T2, and T1 was reversed, we cannot be absolutely sure whether T1 was > reversed before or after T2) > • We don’t need to maintain historical entries for loan > transactions if they are following a pattern of transactional data > immutability > • The original and reversal entries can be retrieved via API (if > needed) > > I was wondering what is the community aspect of the idea to make the loan > transactions immutable. > > What would be the impact? > Would it fit for the actual requirements? > Would you guys and your clients be happy about this change? > > Regards, > Adam
