Yes, I verified that the value in action.circulation.recurring_fine is
greater than 0.

More information on the error:

Here is what I have so far --
---money.usr_summary.total_owed and * in money.billable_xact_summary -
matches the web and xul client data for the user.
---* in reporter.overdue_circs for the user shows the correct rules, fines,
etc in place
---Pulling everything by date from money.billing in separate reports for
several days in a row each show the rules applied to the items for this
patron as well as a host of others, so it gives the illusion that the fines
are being calculated daily. However there is no history table for item
charges that I could find, like there is for item status changes, etc. so I
cannot think of a way to pull a list showing individual charges per item
per day to verify they are being calculated per day and not when the status
change triggers it. Am I missing something - is there a way to pull that

I've also tried looking in auditor.asset_copy_history as well as other
locations. All information I get back shows the same thing.

The items to this particular patron were due on 3/14/19, and were charged
for 9 days and then it appears to have stopped. Each item had not yet hit
the max fine rule, they stopped at 36% of it. The items have not yet been
returned, but in other instances of this issue, when the status of the item
changes the fees/fines are calculated and then presented to the patron --
which can come as a surprise to patrons and staff since if they had checked
their account before turning the items in, they could have a wildly
different amount due like in this case.

The dates this stopped displaying do not appear to correspond to the dates
I did server maintenance or restarted services.

When I look at the circ, recurring and max fine rules they all look normal
and correct as they haven't been changed in years. The recurrence interval
is set to 1 day. This particular patron does have some lost items on their
account as well, and when I checked we do not have things like 'max payment
allowed' configured under library settings so there shouldn't be an issue
with hitting something like a patron max cap if there is even such a thing,
and regardless that wouldn't explain the other patron accounts that are
doing the same thing that don't have large additional fees on their account.

To add to the confusion, I restarted the log server the night of the 28th
which hosts the script and since then an additional day's
fees have been added to the items checked out to that patron, but not for
every day since that restart - which leads me to believe it's potentially
the fine_generator not running correctly, and yet, why did it add one day
and not all the days that were missing? And why are there no errors in

I checked the open bug reports and don't see anything matching what I'm
seeing in this case.

Is anyone else having this issue?

On Thu, Mar 28, 2019 at 10:33 AM JonGeorg SageLibrary <> wrote:

> I'm trying to isolate an issue with our overdue fines not working. It
> seems sporadic. There are no errors in the syslog, and the cron job is
> running every 25 minutes without errors. Some libraries are reporting the
> fines not accruing, but it seems hit and miss. I've restarted postgreSQL on
> the database server a couple of times in the past couple of weeks due to
> high CPU load, and did install Ubuntu 16.04 updates/security patches but
> none of that should have affected anything. I even reviewed the screen
> capture of the session where I installed updates and didn't see anything
> unusual. We are running Evergreen 3.1.7 although we're going to upgrade to
> 3.1.10 on the 10th.
> Does anyone have suggestions on additional things to check?
> -Jon

Reply via email to