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
data?

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 fine_generator.pl 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
syslog?

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?
-Jon

On Thu, Mar 28, 2019 at 10:33 AM JonGeorg SageLibrary <
jongeorg.sagelibr...@gmail.com> 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