Refactoring of Fees/Fines Actions

Design Document on Wiki

The Vega team has identified major refactoring of functionality related to fees/fines. During the past few months they've discovered multiple issues, some of which are posing significant risks but can't be addressed without design changes.

Calculations on FE
Initially fee/fine actions were implemented in such a way that all calculations are happening on FE while BE acts as a simple CRUD service for storing results of these calculations. Not only is this approach an anti-pattern, it is also not safe and, considering we're talking about financial data, poses a significant risk. Anyone who can use Postman or Fiddler can write anything he or she wants to the DB (provided they have access to the platform). We were following this pattern for some time, but now it feels like we're just creating more technical debt because all of this will need to be refactored.

Bugs
While working on UIU-1139 Max has found a bug (UIU-1626) on the fee/fine details page that allows, among other things, to overpay a fine by any amount. It is a bug in the UI architecture that leads to account data not being updated on the screen after PUT request to the server. Account state will remain the same as it was when the user has loaded the page. No matter what actions you'll do, the system will allow you. But when you reload the page you'll see that the client was charged hundreds of dollars instead of ten. This bug is not easy to fix and, again, it feels like by fixing it we're just investing in a bad design. (Note: This is a regression--it did not occur in Edelweiss.)

Double vs. BigDecimal
In February Vega created a technical debt ticket MODFEE-29. Java type "double" is being used for monetary values, which is dangerous because it might potentially lead to wrong calculation results. This issue can be fixed independently, but if we're going to start major refactoring of Fees/fines it should also be part of it.