Applying lost and paid status at the wrong time

[Ben Shum]

Evergreen master / 2.7 series

So, we think we are seeing a situation where the following can occur and have the Lost and Paid status applied to copies prematurely.

An item is checked out, and accrues some overdue fines. The item is renewed, starting a second transaction and the first transaction remains open because the fines have yet to be paid. The second transaction goes to lost, and a lost bill gets applied and the item is marked with a status of Lost. When the library staff go to pay off the first transaction's overdues, and it closed that transaction, it also changes the copy status over to "Lost and Paid."

Looking back at the code, I think that the check for whether to change an item to "lost and paid" occurs every time a transaction closes and it only looks to see if the item is "lost" and the library setting is enabled. So in the situation described above, all those facts are true and the copy is set incorrectly, because actually the 2nd transaction's end by being paid off is what ought to have set the copy status. See changes from: http://git.evergreen-ils.org/?p=Evergreen.git;a=blobdiff;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Circ/Money.pm;h=040187630f24b95898fb9a2bbd14bb05fc091597;hp=0c1493a351ff8afc1623599bf6f316b1563cf028;hb=64d321c68b2dde3b4e83fdca36c8ccf7acec8aba;hpb=76686de7a0acd689466122a209b38d6db27e86fa

A bit confusing for end users and staff.

[Michele Morgan (mmorgan)]

Confirming this bug as I have reproduced it on our training system running 2.7.2.

The attached document shows data for an item that was checked out, reached MAXFINES, then renewed and subsequently marked Lost. The overdue fine on the parent transaction was then paid.

The parent transaction was closed, and the item status flipped to Lost and Paid, even though no portion of the Lost billing was paid.

The item's status should only change to Lost and Paid when the transaction that is being closed has a stop_fines of LOST.

[Ben Shum (bshum)]

Thanks for the testing Michele.

I've created the following working branch to attempt resolving this problem by adding an additional check to verify that the stop_fines reason for a given circ is either "LOST" or "LONGOVERDUE" before proceeding with the move to change the item status to "lost and paid".

See: user/bshum/lp1412893_lost_and_paid_fix

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/lp1412893_lost_and_paid_fix

Special thanks to Jason Stephenson for reviewing my rough perl skills...

[Kathy Lussier (klussier)]

Works for me! Signed off at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/lp1412893_lost_and_paid_fix

[Ben Shum (bshum)]

Thanks for testing Kathy, pushed fix to master and rel_2_7.