Rollback on selfcheck (3M, etc.) triggers holds?

[Tina Ji]

The issue was reported by one of our libraries that a patron trying to check out an item on hold for him on shelfcheck was prompted that the item was on hold for another patron. It turns out that the item was on hold for the reporting patron, but minutes ago the item was checked out to him and seconds later was checked in, which triggered another hold for another patron.

Scanning the database I found more circs checked out and in within seconds (2 to 10) on shelfcheck. This can not be caused by human actions. My speculation is that the checkout is rolled back due to some reason. Unfortunately the rollback checkin triggers holds, if any. I link this to the prompt I see on shelfcheck telling a patron that the item (with barcode displayed) is not properly checked out and try again.

Tina
BC Libraries Co-op

[Jason Stephenson (jstephenson)]

I suspect your self-check terminals are sending a checkin after the checkout. Check your SIP logs for messages from the self checks.

Evergreen does not roll back circulations by doing a checkin after. If a rollback occurred in the middle of a checkout, the chekcout would not have happened.

[Thomas Berezansky (tsbere)]

A double-scan of the same item with the selfcheck doing a "checkin, then checkout" to "renew" could cause this as well. First scan it checked it out, second scan it attempted to renew by checking in then out, but the checkout would then fail due to the other hold.

[Jeff Godin (jgodin)]

Tina-

My first guess is that the SIP unit failed to set security on the item itself after receiving the checkout response from the SIP server, and attempted to "cancel" the checkout by sending a checkin request with the SIP field BI=Y.

This "undo/cancel checkout" concept isn't supported in Evergreen, and would be treated as a normal checkin, and could result in a hold capture or transit being generated.

If this is on a 3M SelfCheck unit, I'd be interested in the state of the following settings:

For the legacy "Phoenix" interface, software version around 4.72.5.0:

Under "Workflow":
 - Support undo checkout

On the newer QuickConnect / QCI software, software version around 1.30.4:

Under Workflow -> Check-Out:
 - Support Undo Check-out

In an Evergreen environment, I recommend disabling "undo checkout" or "cancel checkout" (and their checkin equivalents, if present/applicable) on any SIP clients.

There are few other less likely possibilities, related to the earlier software's support for an "Automatic Checkin" option, especially how it can react with renewals and an environment where patrons have multiple active cards.

If the above suggestion doesn't seem to apply, please provide any other specifics that you can related to SIP client vendor and version, as well as renewal or automatic checkin settings.

At a minimum, the result of this bug might be that we ensure that the undo/cancel checkin/checkout configuration recommendations are well documented.

Thanks for any additional info you can provide!

-jeff

[Tina Ji (tji)]

Thanks for all the input. I finally got some information from our library. I attach its 3M settings here.

After the undo check-out was turned off, I still find some circs checked in within seconds in the database. I did not notice any difference in the amount of circs checked in within seconds. It looks like the checkout could be 'undone' as checkin or renew. The interval between checkout and checkin time seems bigger in RENEW.

 target_copy | xact_start | checkin_scan_time | stop_fines
-------------+-------------------------------+-------------------------------+------------
     8349158 | 2015-11-25 12:12:12.419795-08 | |
     8349158 | 2015-11-25 12:11:06-08 | 2015-11-25 12:12:12.419795-08 | RENEW
     8349158 | 2015-11-25 12:10:26-08 | 2015-11-25 12:11:06.372691-08 | RENEW
     8349158 | 2015-11-25 12:10:18-08 | 2015-11-25 12:10:20.571156-08 | CHECKIN

Tina
BC Libraries Co-op