The branch is two commits, one with minimal changes for easier reading, then a second with some general code reformatting/refactoring/commenting to clean things up. Commit one shows the concept, but you really want both.
In essence, it takes the tack of making lost and long-overdue billing exclusive events; once one has happened the other cannot. Any attempt to mark something lost after it is already long-overdue will change the item status and potentially process other lost-based events and penalties (configuration dependent), but it will not touch the billing.
I think this strategy has a great advantage in it's simplicity while still covering known use cases. We do not need to concern ourselves with every possible interaction lost fines/fees/voids/payments/credits and long-overdue fines/fees/voids/payments/credits, as you just get one or the other.
Okay, I pushed a branch here:
http:// git.evergreen- ils.org/ ?p=working/ Evergreen. git;a=shortlog; h=refs/ heads/user/ dbwells/ lp1562061_ avoid_lost_ rebilling
The branch is two commits, one with minimal changes for easier reading, then a second with some general code reformatting/ refactoring/ commenting to clean things up. Commit one shows the concept, but you really want both.
In essence, it takes the tack of making lost and long-overdue billing exclusive events; once one has happened the other cannot. Any attempt to mark something lost after it is already long-overdue will change the item status and potentially process other lost-based events and penalties (configuration dependent), but it will not touch the billing.
I think this strategy has a great advantage in it's simplicity while still covering known use cases. We do not need to concern ourselves with every possible interaction lost fines/fees/ voids/payments/ credits and long-overdue fines/fees/ voids/payments/ credits, as you just get one or the other.
Dan