[OPEN-ILS-GENERAL] Hold Stalling at Cataloging/Delivery

[Hardy, Elaine]

In our investigation of holds a few years ago we determined several things
about stalling. We confirmed it halts opportunistic capture of copies from
outside a library branch/system to allow a local copy to fill the hold
first. In other words, it limits opportunistic capture to copies held by
the patron pick-up library for a set interval. (In PINES this is five
days.) Stalling does not take into consideration whether or not the
pick-up library owns a copy or not, it still stalls opportunistic pickup
if there is no copy attached to the pickup library. Opportunistic capture
on non-pickup library copies will not occur during the stall interval.
Stalling does not affect the targeter.
(http://pines.georgialibraries.org/sites/default/files/files/Holds%20White
%20Paper.pdf )

 

So I would expect a copy where circ lib = hold pickup lib to fill the
hold. And I can see where, if the copy has no circ lib since your
collection is floating, where stalling could prevent capture of any hold.

 

Stalling isn't just to reduce transit times. It is also to solve a problem
caused by slow transit times - a patron places a hold on a title.
Opportunistic capture grabs a copy at another library and it is placed in
transit. In the meantime, the pickup library's copy is returned and is
shelved. Then the patron comes in and finds it before the item captured
for their hold has time to get to the pickup library. Patron is confused
and not happy that they have been waiting, maybe for a long time, when a
copy was seemingly available. Staff is confused and not happy,
particularly when they notice their copy was returned within days of the
other copy being placed in transit. They check the item out to the patron
and then have to return the other library's copy when it finally arrives.
To solve this very specific set of problems, PINES libraries requested the
stall on opportunistic captures to give time for any copy owned by the
pickup library to be returned and fill the hold.

 

We also had a problem at one time where the software didn't automatically
recognize a new copy as available for a hold - it was invisible to the
hold process for about 24 hours. By new copy here, I mean where a library
has items attached to a bib record, holds are placed, more copies are
subsequently added --any copy added after the holds are placed would not
be captured until the next day when the targeter "found" them. I believe
we did solve this but I am not positive. Chris might have more
information. 

 

 

J. Elaine Hardy

 

PINES & Collaborative Projects Manager 
Georgia Public Library Service 
1800 Century Place, Ste 150 
Atlanta, Ga. 30345-4304 

 

404.235.7128 Office 
404.548.4241 Cell 
404.235.7201, fax 
ehardy at georgialibraries.org 
www.georgialibraries.org/pines 

 

From: Open-ils-general
[mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of
Josh Stompro
Sent: Friday, March 18, 2016 11:38 AM
To: Evergreen Discussion Group
<open-ils-general at list.georgialibraries.org>
Subject: [OPEN-ILS-GENERAL] Hold Stalling at Cataloging/Delivery

 

Hello All, I just figured out that a bunch of our strange holds behavior
can be blamed on having hold stalling enabled for our Cataloging/Delivery
org unit.  We just enabled the stalling at the consortium level to start
with, didn't realize the issues it would cause for certain locations.

 

The hold stalling was preventing newly cataloged items from filling holds
at checkin that were less than 3 days old(Our stalling interval), with a
twist of allowing the hold if the copy circ lib = hold pickup lib  if the
hold happened to have been retargeted between the time the copy circ lib
was changed, because the action.hold_copy_map is consulted.  This doesn't
make sense for us since we don't use a Best Hold Selection Sort Order that
uses action.hold_copy_map.priority.  I should just mention that we do the
initial check in of in-process items in cataloging so we get a routing
slip to send the item where it needs to go.  Our items don't have any
location specific info on them since we float everything.

 

So a bunch of new holds in our system would be skipped, and the holds for
another system were targeted first because they were older than our
stalling interval.  And then occasionally a hold would be picked up if it
was retargeted between the time the copy circ lib was changed and it was
checked in.  This didn't happen all that often, but when it did it was
very confusing.

 

We only use p.prox (copy checkin library to hold pickup library) in our
opportunistic hold sort.  We don't want the hold copy map proximity
consulted because we use proximity adjustments to modify it for hold
targeting, so certain locations always get targeted first.  But we don't
want certain locations prioritized in the same way for opportunistic
capture.

 

The fact that both the proximity between the checking location and hold
pickup location, and the proximity between the copy circ lib and pickup
location is looked at for determining which holds are effected by stalling
was unknown to me.  I still haven't wrapped my mind around that yet.  It
seems like it might cause odd results when items are being checked in at
locations other that their circ lib.  If the point of stalling is to
reduce transits, then why not only consult the checkin lib to pickup lib
proximity?  Maybe it is because the copy will be sent back to the circ lib
if it isn't captured, so might as well target holds there also to save a
step?

 

I believe that setting the stalling to zero for our cataloging location
will bypass the retarget time dependent issues.

 

Lake Agassiz Regional Library - Moorhead MN larl.org

Josh Stompro     | Office 218.233.3757 EXT-139

LARL IT Director | Cell 218.790.2110  

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20160318/8453d83f/attachment.html>