Extending circ due date can result in exceeding max fines

Bug #1786312 reported by Bill Erickson
26
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
Undecided
Unassigned

Bug Description

Confirmed in Evergreen 2.12 and 3.1.

Steps to reproduce:

1. Find a circulation which is actively accruing overdue fines, but has not reached max fines.

2. Staff modifies the due date to be some time in the future via the "Edit Due Date" action in the staff client.

3. Once the new due date is exceeded, the circulation will start accruing overdue fines again.

4. The fine generator will keep adding overdue fines as if the original overdues didn't exist, ultimately resulting in overdues totaling the original (pre-due date extended) overdues plus the max fine amount.

==

To approximate in concerto:

1. Run the fine generator.
2. Note circ ID 7 has a max fine amount of $0.70 and total billed of $0.70.
3. Set stop_fines and stop_fines_time to NULL on circ ID 7 (or find a circ that's still accruing).
4. Run the fine generator again.
5. Now circ ID 7 have a max_fine setting of $0.70 and a total billed amount of $1.40.

Revision history for this message
Bill Erickson (berick) wrote :

IRC discussion for reference:

http://irc.evergreen-ils.org/evergreen/2018-08-09#i_371513

The gist is we want to continue the practice of resuming overdues after the newly applied due_date without back-filling overdues, however we also want to know the amount billed as overdue fines from all existing fines before applying new ones, not just those that were created after the new due date.

Revision history for this message
Blake GH (bmagic) wrote :

Confirmed

Changed in evergreen:
status: New → Confirmed
Revision history for this message
Bill Erickson (berick) wrote :

Just ran into this today as a result of a lot of COVID-related manual due date adjustments. Should be a simple thing to retain the current logic while also reporting the correct amount billed so far by the patron.

Changed in evergreen:
assignee: nobody → Bill Erickson (berick)
milestone: none → 3.5.2
Revision history for this message
Bill Erickson (berick) wrote :
tags: added: pullrequest
Changed in evergreen:
assignee: Bill Erickson (berick) → nobody
Changed in evergreen:
milestone: 3.5.2 → 3.6.1
Changed in evergreen:
milestone: 3.6.1 → 3.6.2
Changed in evergreen:
milestone: 3.6.2 → 3.6.3
Changed in evergreen:
milestone: 3.6.3 → 3.6.4
Changed in evergreen:
milestone: 3.6.4 → 3.7.2
Changed in evergreen:
assignee: nobody → Terran McCanna (tmccanna)
Changed in evergreen:
assignee: Terran McCanna (tmccanna) → nobody
Revision history for this message
Erica Rohlfs (erohlfs) wrote :

I should have noted during feedback week that I'm actively testing this bug. The fine generation is being a bit slow to reach max fines.

Changed in evergreen:
assignee: nobody → Erica Rohlfs (erohlfs)
Revision history for this message
Michele Morgan (mmorgan) wrote :

I know Erica is looking at this fix, but I am trying to reproduce the bug in a master circa 3.7.1 system without the fix, and am not able to. Possibly, I could be missing something.

I cannot reproduce it when I follow the steps in the description to approximate it in Concerto. Here are my steps:

- Verify that action.circulation.id 7 has stop_fines and stop_fines_time set.

- Update action.circulation.id 7 to have stop_fines_time and stop_fines of NULL:

update action.circulation
set stop_fines = NULL,
stop_fines_time = NULL
where id = 7

- Run the fine generator

- Note that the total overdue fines due for the transaction has not changed

- Check stop_fines and stop_fines_time in the circ

select stop_fines_time, stop_fines
from action.circulation
where id = 7

This reveals that stop_fines = MAXFINES and stop_fines_time is the time the fine generator was run.

I will attempt to modify the due date in a circulation as described in the first procedure and rerun the fine generator when the new due date has passed.

I did note that when I choose a circulation in the client that has acheived MAXFINES and choose Edit Due Date under Actions, the circulation retains the MAXFINES stop_fines and stop_fines_time.

Revision history for this message
Erica Rohlfs (erohlfs) wrote :

Noting that I was testing the patch over several weeks. It did not recreate a scenario where charges were still applying after max fines. In reading Michele's comment, I'm wondering if the Library Setting Truncate fines to max fine amount's value plays a role in what users experience.

Changed in evergreen:
assignee: Erica Rohlfs (erohlfs) → nobody
tags: added: circ-billing
removed: billing
no longer affects: evergreen/3.4
no longer affects: evergreen/3.5
Changed in evergreen:
milestone: 3.7.2 → 3.7.3
Revision history for this message
Terran McCanna (tmccanna) wrote :

Bill, do you have any advice on how to create the scenario that this would fix?

no longer affects: evergreen/3.6
Changed in evergreen:
milestone: 3.7.3 → none
Revision history for this message
Bill Erickson (berick) wrote :

I left out the most important part: you have update the due date as well.

1. Run the fine generator as usual

You should see this:

evergreen=# select sum(amount) from money.billing where xact = 7;
-[ RECORD 1 ]
sum | 0.70

2. Modify Circ 7 to change its due date and clear stop fines data

evergreen=# update action.circulation set stop_fines = null, stop_fines_time = null, due_date = now() - '2 weeks'::interval where id = 7;

3. Run the fine generator again.

Then you'll see this:

evergreen=# select sum(amount) from money.billing where xact = 7 and not voided;
-[ RECORD 1 ]
sum | 1.40

====

Note that clearing the stop fines data is only necessary in this contrived example. In the wild, this happens to circulations that are still accruing fines.

Revision history for this message
Bill Erickson (berick) wrote :

Rebased branch pushed here:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1786312-due-date-extend-exceed-max-fines-v2

Includes a fix to the logic where "gt" should have been used instead of ">".

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.