Close transactions after fines are voided,

Bug #965656 reported by Steve Callender on 2012-03-26
This bug affects 8 people
Affects Status Importance Assigned to Milestone

Bug Description

This was tested in 2.0 and 2.1.

When fines are voided and the balance of a transaction hits 0, the transaction really should have the xact_finish timestamped to keep things uniform on the system.

A prime example here is when an item is checked in with a backdate and the system auto-voids the fines. The xact_finish is never stamped and the transaction remains open forever.

Same thing with manually voiding fines, it does not close the transaction.

This doesn't really impact the staff client billings view since 0 balance items will not be shown, but it does impact reporting.

Robert J Jackson (rjackson) wrote :

This bug also results in not being able to delete an account. A library attempting to delete an account ends up asking for assistance in order to have the transaction closed.

Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
Changed in evergreen:
importance: Medium → Wishlist
Ben Shum (bshum) wrote :

Just encountered the deletion issue Robert mentions. This seems more bug worthy, than wishlist to me.

Confirmed for 2.2+

Changed in evergreen:
importance: Wishlist → Medium

Just another example of this happening is when a claims returned item is checked in using Amnesty to auto-void the fines, this causes the transaction to stay opened as well even though there is a stop_fines entry as well as 0 fines on the item. Same problem, just a different scenario. I imagine it's all still part of the same code though.

Jason Stephenson (jstephenson) wrote :

See also for issues with voiding in general.

Jason Stephenson (jstephenson) wrote :

In reviewing this bug description, there seems to be a discrepancy between the problem behavior reported in this bug and the solution to

That bug is reporting a problem with claims returned closing transactions when the fine balance reaches zero. This bug is reporting the opposite issue.

I see that Steve Callender reports a specific scenario that can be tested in light of the patch to 793550. I'll leave this bug in its current state pending a review of that behavior in more recent code.

Jason Stephenson (jstephenson) wrote :

It looks like backdating an overdue copy, whether fines are owed or not, causes the transaction not to close.

Jason Stephenson (jstephenson) wrote :
tags: added: pullrequest
Jason Stephenson (jstephenson) wrote :

Force pushed a rebase today. I am also basing my work for this blueprint on the rebased branch:

Changed in evergreen:
milestone: none → 2.5.0-alpha1
Remington Steed (rjs7) on 2013-08-12
Changed in evergreen:
milestone: 2.5.0-alpha1 → 2.5.0-alpha2
Ben Shum (bshum) wrote :

Picked to master, thanks Jason!

Changed in evergreen:
status: Confirmed → Fix Committed
Ben Shum (bshum) on 2013-11-11
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.

Duplicates of this bug

Other bug subscribers