Making the loan transactions immutable

[Ádám Sághy <ad...@gmail.com>]

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

Re: Making the loan transactions immutable

[Kigred Developer <ki...@gmail.com>]

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, <ad...@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