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
