Hi John, We have this happen occasionally as well. I am not sure if there is a bug report on it or not though. If you open a bug report I will confirm it. What I do is I add $.01 to the bill and then pay $.01 to force the bill to close. I do not know why the bill does not close originally as we cannot reproduce it on command either.
Thanks, Dawn Dale PINES Services Specialist, Circulation Georgia Public Library Service 1800 Century Place Suite 150 Atlanta, GA 30345 404-235-7136 dd...@georgialibraries.org * The GPLS office is in the midst of relocating so it may be difficult to reach us by phone at times. Please use the Help Desk when you need to contact us: https://help.georgialibraries.org On Tue, Jul 10, 2018 at 12:30 PM, John Amundson <jamund...@cwmars.org> wrote: > Hi, All: > > Our consortium upgraded to the web client, 3.0.8, over Memorial Day > weekend. > > Since then we have had 3 reports, (all within the last few weeks), of a > problem that I cannot seem to pin down/replicate. > > I can open a Launchpad bug with these details, as well, but I first wanted > to try the list to see if anyone else has seen this or had any insight > before filing. > > First a little background since the issue is related to billing, > specifically the LOST status, and I know there is variation in how this > status is used. We use LOST to represent an item that was either a) marked > "lost (by patron)", or b) has been overdue for 28 days or more. In both > cases, when an item becomes lost, the item price is billed and a lost item > block is placed on the patron record. > > Normally when a lost item is paid, the following happens: > > - The balance owed on the bill is reduced to 0, and the bill is moved > to the History tab. > - The bill is updated with a transaction finish time of the last > payment. > - The item moves to status Lost & Paid. > - The item no longer appears attached to the patron's account. > - The lost item block is lifted from the account. > > However, on rare occasions in the web client, we are seeing something > different. In these instances, when a lost item is paid, the following > happens: > > - The balance owed on the bill is reduced to 0, and the bill is moved > to the History tab as expected. > - The bill is NOT updated with a transaction finish time, (the field > is blank). > - The item continues to stay in status Lost. > - The item continues to appear in the patron's Items Out list. > - The lost item block stays on the patron's account. > > I have tried and tried again to duplicate this, but I have not been > (un)successful, though I know there is truth to these reports because I > have seen the aftermath, (i.e. item bill fully paid but still on > account/blocked). > > The items do not seem share common histories, (i.e. one was marked lost > manually, the others organically, one of the transactions was renewed 2 > times, the others no renewals, one of the items was deleted, the others not > deleted). The only commonality I've found is that in each report, the > bill was part of a larger group of bills paid. In the most recent report, > 5+ billed items were paid for with the same payment; all but one updated > correctly. > > However, I have tested this on my side with a variety of cases, (all lost, > mixed billing types, etc), and every single time the payment/bill is > processed correctly, so at that point, batch bill pay enters into the > causation vs correlation debate in relation to this issue. > > So, anyone else seeing something similar? Should I just go straight to > filing a bug report? > > Thanks in advance, > > John Amundson > <http://www.cwmars.org> > > John Amundson | Library Applications Associate III | CW MARS > > jamund...@cwmars.org | 508-755-3323 x322 <%28508%29%20755-3323> > > http://www.cwmars.org >