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 >