Web Client: Transactions Do Not Always Close When Bill Fully Paid

Bug #1781274 reported by John Amundson on 2018-07-11
This bug affects 10 people
Affects Status Importance Assigned to Milestone

Bug Description

Evergreen 3.0.8 - Web Client

We are noticing that sometimes when a bill is fully paid, (balance_owed=0), the transaction stays open and attached LOST items are not updated to Lost & Paid.

I am not sure if this also occurs on overdue fines.

This only happens occasionally, and I have not been able to reliably duplicate it. More details follow.

First a little background since the issue is related to billing and 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.

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 I am not sure if the batch payment is just correlation or causation.

Dawn Dale (ddale) wrote :

I can confirm this issue though we cannot reproduce it on command. I am unsure of the trigger for the bug but occasionally we have a bill that does not close when payment is made in full. The item will remain on the patron account as lost. I add $.01 and pay $.01 to the bill to force it to close.

John Amundson (jamundson) wrote :

I want to update this bug and say that I've noticed that this isn't just limited to LOST bills, but to others, as well, (i.e. overdue fines). I'm editing the title to reflect this. We still haven't figured out why, but one thing seemingly remains constant. The transaction that fails to close is part of a single payment that applied to multiple transactions

summary: - Web Client: Transactions Do Not Always Close When Bill Fully Paid (AKA
- Lost and Paid Status Not Updating Correctly)
+ Web Client: Transactions Do Not Always Close When Bill Fully Paid
Lindsay Stratton (lstratton) wrote :

I just encountered the same behavior described by John (2019-03-18) where 1 Lost item payment out of 3 paid in the same transaction did not close appropriately, while the others did.

Can also confirm Dawn's (2018-07-11) strategy of adding a bill to force the transaction to close.

Changed in evergreen:
status: New → Confirmed
Jason Stephenson (jstephenson) wrote :

I just saw it with 8 overdue transactions. Looking at the data, it was the last circulation paid that did not close.

Michele Morgan (mmorgan) wrote :

There appears to be a floating point number problem that is at least partially responsible for this bug.

I found activity.log entries for applied payments that look like this:

2019-08-12 18:16:10 brick3 osrf_websocket_translator: [ACT:142032:./osrf_websocket_translator.c:785:15656423361420321156] [] [] open-ils.circ open-ils.circ.money.payment "60fc9b26b9fdc7c0c0ccdcda0eb660fe", {"userid":"1983487","note":"","payment_type":"forgive_payment","check_number":null,"payments":[[15447046,1.3],[4909522,1],[5048999,0.1],[4909625,0.55],[4909684,0.2],[4909685,0.1999999999999998]],"patron_credit":0,"cc_args":null}, "1473201970.2223321125.3967675516"

Bill 4909685 was the one that did not close, the balance owed was $.20.

The bug can be reproduced using grocery bills as follows.

Retrieve a patron that owes no money.

Add a billing of $.90
Add a billing of $.10
Select both billings
Enter $1 in payment received and Apply the payment

Click on History in the billings screen. Turn on the Total Billed and Transaction Finish Time column and note that the $.10 bill has zero balance owed, but does not have a transaction finish time.

Patch is forthcoming.

Michele Morgan (mmorgan) on 2019-12-20
Changed in evergreen:
assignee: nobody → Michele Morgan (mmorgan)
Jason Stephenson (jstephenson) wrote :

Just for the sake of confirmation, I see something similar on my test server, for a set of transactions where 1 did not close.

Dec 17 14:08:41 jasontest gateway: [ACT:8848:osrf-websocket-stdio.c:559:1576609687884811] [] [] open-ils.circ open-ils.circ.money.payment "dd5dca573955c2122984690a3df04e90", {"userid":"681166","note":"","payment_type":"cash_payment","check_number":null,"payments":[[91988672,0.1],[91988674,0.1],[91989090,0.1],[91989092,0.1],[91989095,0.1],[91989098,0.1],[91989257,1],[91989259,0.9999999999999996]],"patron_credit":0,"cc_args":null}, "1575935128.494926180.04070332971"

The transaction 91989259 is the one that did not close.

Michele Morgan (mmorgan) wrote :

Branch as promised is at:


To test:

Use the steps above to reproduce, noting the lack of Transaction Finish Time.
Apply the patch.
Use the same steps above and note that the post patch payments resulted in both transactions getting a Transaction Finish Time.

Changed in evergreen:
assignee: Michele Morgan (mmorgan) → nobody
tags: added: pullrequest
Michele Morgan (mmorgan) on 2019-12-20
Changed in evergreen:
milestone: none → 3.5-alpha
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers