|
Ashok
So my initial thoughts are to go for an API improvement (no SQL fixes till we absolutely need them, whatever time we save by going the SQL way would later be spent explaining the same to specialists etc...)
I was earlier thinking that the likely scenarios would be
1) More common A holiday is entered and the user immediately/on the same day realizes that the start/end date etc are wrong and would want to edit the same
2) Less common A holiday is created and the user realizes that a mistake has happened at a later point in time
Maybe a simple fix would have been
1) For each holiday, add a flag say "repayments_rescheduled" which tracks if a batch job has processed this holiday (batch jobs by default run after past midnight)
2) As long as the holiday is not processed by the batch job, allow update and delete operations to go through
3) While we are at it, we should also allow update/delete of holidays for organizations which do not have the configuration param "reschedule-repayments-on-holidays" turned on
This would be an easy win and would probably handle the 80/20 scenario....
but realized the minute I stopped typing that this introduces more issues...
A scenario to take care of would be
We have batch jobs (end of day/user triggered) to do the actual recalculation of schedule for existing loans. Should be careful of mid day changes i.e a holiday with some definition is created, any new loan created currently automatically starts taking the holidays into consideration while calculating its schedule, what happens to these loans if the holiday schedule is changed mid day?
So I am thinking on the following lines
1) Add a flag say "holiday_activated", which tracks if a scheduled (or user run) job has processed this holiday (batch jobs by default run after past midnight)
2) As long as a holiday is not activate, do not consider them while calculating schedules for new Loan applications etc
3) As long as a holiday is not active, delete and update should happen instantaneously
4) If the holiday is active, for simplicity (or the fist cut), do not allow edits, only allow deletes.
Once the same is marked for deletion, set a flag "marked_for_deletion". We should have a new job that scans for such holidays and updates the schedules of all existing active loans.
So if a user wants to change a holiday which has already become active, he would delete the existing holiday (And manually trigger the job for
deleting if immediate execution if required) and create a new holiday with the correct definition (and manually trigger the job to reschedule payments immediately if desired)
We should also probably keep the deleted holiday around in the database with a deleted flag for easier debugging of schedule issues if and when required (I know we log all CreateUD's but still....)
|
