Comment 3 for bug 851000

What I found tonight is it seems to be an interplay between the void lost billings on checkin and lost items usable at checkin setting. Both of these have to be on at the owning library (or its ancestors) for the billings to be voided when the copy is checked in at a library that doesn't own the copy.--I think this is a bug, and I'll explain my reasons.

In looking at the code in master, the check for the lost usable at checkin setting's value is done in O::A::Circ::Circulate.pm at about line 3304. If that is false, and we're not at the library that owns the copy, we simply log a message to say that we're not changing the status to avoid problems when it goes home.

Following that is an elsif that checks for void lost billings. This only fires if the above check "fails."

Thus, it seems if we lost billings to clear without the copy going home, we set both the void lost billings and lost items usable at checkin ou settings.

If we want copies to go home before voiding lost billings, then we set lost items usable to false (or don't set it) and set void lost billings to true.

However, there is a catch. While the handle_lost routine doesn't alter the copy's status from lost under the latter conditions, the code that puts the copy into transit does change the copy's status from lost to in transit. When the copy arrives home, it is no longer lost, and therefore the code to handle lost and possibly void the billings never runs.

Two options present themselves to me immediately, and i'm sure when I'm more awake tomorrow more will pop up.

1. Is to set the lost items usable at checkin setting and forget about the "bug."

2. Is to make the check for void lost billings independent of the check for lost items becoming usable at checkin.

As for Ben's comment about backdated checkins, I don't really look how that comes into play because I am not aware that our members make heavy use of backdating. I will take a look at that tomorrow and see how it plays a role in this.