[OPEN-ILS-GENERAL] Hold targeting behavior - Always Try a new copy

[Thomas Berezansky]

For the situation you describe I wonder if the easiest solution is to  
simply disable the stalling period at your distribution hub. As far as  
I can tell the setting is based on the workstation ou checking the  
item in.

Beyond that, if you do want to implement a "don't skip the current  
targeted copy" setting I would make it an OU setting that can be set  
per location. Then you can set the setting for those org units that  
are highly likely to be the best choice of copy, without needing to  
have longer retarget times (may negatively impact opportunistic  
capture) or have the system ignore even better copies (pickup library  
copy that for some reason became an option after the last targeting).

If you want to cheat locally you could also just set up a DB trigger  
that bumps the check time into the future by an extra day when the  
current_copy is set to a copy in your distribution hub. Then the holds  
targeting those copies won't be found by the hold targeter for a  
retarget for an extra day.

Quoting Josh Stompro <stomproj at exchange.larl.org>:

> Thanks Thomas,
>
> I made a big miss-statement in my message.  I wrote that "none of  
> the copies that they pulled would capture".  My intended meaning was  
> that "none of those 20 items that had been re-targeted would  
> capture".  Other copies that were for local holds or that were still  
> targeted to that branches copies captured just fine.
>
> The copies that didn't capture would have all been going into  
> transit.  The branch that I mentioned that had the 20 copies,  is  
> also our delivery hub.  So any copies that they pull to fill holds  
> will only take 1-2 days to get to the destination location, vs any  
> other branch which will require that the item first transit back to  
> that hub location, then be sent to the hold pickup location.  So  
> even if the Hub location doesn't fill the hold in the first 24  
> hours, it is still quicker for them to fill it than going on to any  
> other branch.
>
> The goal of us using stalling was to hopefully always give the  
> optimal location time to fill the hold before an opportunistic  
> capture took effect.  But I wasn't taking into account this bouncing  
> behavior when we decided to try that.
>
> As for your last paragraph, do you mean that you don't see that as  
> overly beneficial for our situation, or in general?  What you  
> described is exactly what I was hoping for.  Don't retarget unless  
> something has happened to the currently targeted copy to make it  
> unholdable/unavailable.
>
> Josh Stompro - LARL IT Director
>
>
> -----Original Message-----
> From: Open-ils-general  
> [mailto:open-ils-general-bounces at list.georgialibraries.org] On  
> Behalf Of Thomas Berezansky
> Sent: Tuesday, March 01, 2016 10:39 AM
> To: Evergreen Discussion Group
> Subject: Re: [OPEN-ILS-GENERAL] Hold targeting behavior - Always Try  
> a new copy
>
> As far as I know, stalling should never apply if the copy is for
> *local* pickup. That is, if the library is pulling copies (or  
> checking in returned copies) that match holds for pickup at that  
> library the stalling code says "oh, that is local" and skips the  
> stalling period entirely. Based on that your collection of "would  
> not capture" were either all going into transit or had been captured  
> elsewhere before they captured the local copies.
>
> As for the "option to not exclude the current copy" I don't see that  
> as overly beneficial. At that point running the hold targeter would  
> only really update the opportunistic capture list or find another  
> copy when the previously selected one became ineligible (checked  
> out, marked missing, etc).
>
> Quoting Josh Stompro <stomproj at exchange.larl.org>:
>
>> Hello all, I was recently working on a reported problem with the hold
>> targeting.  Our largest branch didn't run their evening pull list
>> because of low staffing one day, and the next morning between the time
>> when they ran their hold list and tried to capture the item, 20 copies
>> has been re-targeted to other branches.  Since we are currently using
>> hold stalling, none of the copies that they pulled would capture.
>>
>> This caused me to figure out that the hold targeter always excludes
>> the current copy when re-targeting if other copies exist.  I wasn't
>> aware of this fact, and I don't remember seeing it mentioned in any of
>> the docs or presentations on holds design.
>>
>> This is not optimal in our situation because our targeting priority is
>> very specific.  All our branches are ranked according to number of
>> open hours, staffing and delivery proximity.  We have a wide variety
>> of locations, those that are open 6 days a week to those that are open
>> 1 day a week.  We also share materials between two regional system, so
>> we always want to get the copies local to the system if possible.  So
>> it doesn't work very well to have holds bouncing back and forth
>> between the two lowest proximity locations, since the optimal one is
>> always targeted first.  The hold may bounce between a location that is
>> open 80 hours a week, that is only 24 hours delivery time away, to a
>> location that is open 8 hours a week that may take 10 days for
>> delivery.  It would be somewhat based on luck if the customer got
>> their hold filled in 1 day vs 10 days in this admittedly worse case
>> scenario.
>>
>> The options that I think we have are.
>>
>> 1.       Design change so that the hold targeter optionally doesn't
>> exclude the current copy.
>>
>> 2.       Change the re-targeting interval to something longer, 72
>> hours, to give the first location 3 days to pull the item.  I think
>> this may have other negative impacts though.
>>
>> 3.       Stop using hold stalling, this would help in the situation
>> where the holds get retargeted after the pull list is run.
>>
>> Does anyone have any other suggestions?  Would anyone else be
>> interested in having the targeter not exclude the currently targeted
>> copy?
>>
>> Thanks
>> Josh
>>
>> Lake Agassiz Regional Library - Moorhead MN larl.org
>> Josh Stompro     | Office 218.233.3757 EXT-139
>> LARL IT Director | Cell 218.790.2110
>
>
> --
> Thomas Berezansky
> Assistant Network Administrator
> Merrimack Valley Library Consortium
> 4 High ST, Suite 175
> North Andover, MA 01845
> Phone: 978-557-8161


-- 
Thomas Berezansky
Assistant Network Administrator
Merrimack Valley Library Consortium
4 High ST, Suite 175
North Andover, MA 01845
Phone: 978-557-8161