Web Client: Transactions Do Not Always Close When Bill Fully Paid
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Medium
|
Unassigned | ||
3.3 |
Fix Released
|
Medium
|
Unassigned | ||
3.4 |
Fix Released
|
Medium
|
Unassigned |
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.
Changed in evergreen: | |
status: | New → Confirmed |
Changed in evergreen: | |
assignee: | nobody → Michele Morgan (mmorgan) |
Changed in evergreen: | |
milestone: | none → 3.5-alpha |
Changed in evergreen: | |
importance: | Undecided → Medium |
Changed in evergreen: | |
assignee: | nobody → Bill Erickson (berick) |
Changed in evergreen: | |
assignee: | nobody → Michele Morgan (mmorgan) |
Changed in evergreen: | |
milestone: | 3.5-beta → 3.5.0 |
assignee: | nobody → Jason Stephenson (jstephenson) |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
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.