2.0, 1.6, Transactions not closing for LOST items once xact has been re-opened for modified billings.

Bug #758982 reported by Steve Callender on 2011-04-12
This bug affects 6 people
Affects Status Importance Assigned to Milestone

Bug Description

Steps to replicate this issue,

Check-out an item and mark lost.
Add forgive payment to balance out bill.

At this point, the xact_finish is stamped and the xact is closed.

Check-in the item, returning it back to circulation.

If the void lost fee's on check-in is set in the org settings, then the xact is re-opened (xact_finish removed) and the lost fees and/or processing fees are voided, leaving a negative balance on the xact.

At this point, the lost item reappears in the Lost item section on the user account. Adding billings to make up for the negative balance will 0 out the balance, but the xact does not close.

Possible solution would be to have the system identify non-refundable payments related to lost fee's and void them at the time of check-in of a lost item.

Also the software needs to better handle the closing of transactions when the balance reaches 0, so they are not stuck open indefinitely.

On a side note, if the item goes into the positive billing amounts and then brought down to 0, the transaction will close, it just appears to be if an item is in the negative, and then brought up to 0, it doesn't close.

So for example, the item above that is in a stuck state with 0 billings, I added a random bill amount to it which brought the item back to the bills screen. I then just simply voided out that bill, and then the transaction was closed and item removed from the lost list.

Michael Peters (mrpeters) wrote :

Confirmed. Happens very often in Evergreen Indiana.

Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
Rogan Hamby (rhamby) wrote :

I can confirm this issue exists for SC LENDS as well. We have independently discovered and documented this bug exactly as Steve has reported it.

Ben Shum (bshum) wrote :

We're starting to notice this more now that our A/T for automatically marking items lost is working and people are returning lost items to Evergreen despite having paid off the bill previously. Tricky problem...

Ben Shum (bshum) on 2011-10-28
Changed in evergreen:
importance: Medium → High
Jason Stephenson (jstephenson) wrote :

Sounds like one solution would be to not void billings when the xact_finish is set.

Another would be YAOUS to indicate if libraries issue refunds. If the setting is FALSE, then xact_finish billings are not voided at checkin. If TRUE, then they are.

I am inclined to the first solution, though I could see people wanting a setting to control this, since it is a change to the default behavior, though it is arguable if the current behavior is a bug or not.

Please vote if you prefer option 1, the hammer approach, or option 2, the ratchet approach (YAOUS!).

I have found that either refunding the payment or adding a new bill to offset the amount of the refund both work as work arounds to the problem in the mean time.

tji@sitka.bclibraries.ca (tji) wrote :

This perhaps is the most reported problem in Sitka. Our workaround is adding 2 dummy billings: one to make the balance 0, the other to be voided to close the transaction. Very confusing process.

Solution 2 is preferred. From user's perspective, solution 1 will impose constriction on library's options. There are libraries issuing refund. Patrons are treated equally on returning their lost books regardless they made the payment or not.

Other solution? I wonder whether lost transaction can work the same way as as overdue transaction. Once the item is checked in, the item disappears from Items Out, leaving all the bills on Bills screen.

Bill Erickson (berick) wrote :

I see two issues here. The first is that xact_finish should be set when the balance once again reaches zero (from the negative side). This is an important first step and should be a relatively simple fix. (I'll see if I can work up a patch).

For the second issue, whether to issue refunds after the transaction is closed, I'm also inclined to go with option 2 (org setting).

For general bug cataloging, IMO issue 1 is a bug and issue 2 is a feature.

Jason Stephenson (jstephenson) wrote :

Sounds good to me.

Jason Stephenson (jstephenson) wrote :

I tried Bill's patch on a 2.0 test system, and it appears to resolve the problem of closing LOST transactions.

I'll commit this to 2.0 (if I have the permission already, not sure).

I don't think we want the new org_setting in 2.0, so I'll set the 2.0 target to fix committed after.

Jason Stephenson (jstephenson) wrote :

Nope. Looks like I can't commit to rel_2_0, yet.

I signed off and pushed to a collab branch in the meantime:


tags: added: pullrequset
tags: added: pullrequest
removed: pullrequset
Mike Rylander (mrylander) wrote :

Picked into master, 2.2 and 2.1. Thanks, Bill!

Changed in evergreen:
status: Confirmed → Fix Committed
Ben Shum (bshum) on 2012-07-01
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers