[OPEN-ILS-GENERAL] Web Client - Lost and Paid Not Updating Correctly

[Dawn Dale]

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
ddale at 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 <jamundson at 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
>
> jamundson at cwmars.org | 508-755-3323 x322 <%28508%29%20755-3323>
>
> http://www.cwmars.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20180711/330334d0/attachment-0001.html>