[OPEN-ILS-GENERAL] holds not picking up

[Ben Shum]

Hi Alexey,

I'm not an expert on holds functionality, but I think it's assumed that 
the process for calculating targets can be extremely taxing and applying 
the circulation checkin modifiers is staff's way of showing that they 
intend to be checking in new items.  Otherwise, you'd be constantly 
doing checks on each item coming in to determine if they're really "new" 
and slowing down normal circulation doing the retarget actions.

Just guessing,

-- Ben

On 08/08/2012 10:08 AM, Lazar, Alexey Vladimirovich wrote:
> Thanks, Ben.
>
> We have run into this problem with 2.0.x as well, and were indeed a bit perplexed. Thanks for this information, it is very helpful.
>
> Would it be possible and/or reasonable/useful for the system to bypass the previous hold time for brand new items automatically, so that the holds can be triggered as you describe, but without any special steps?
>
> On Aug 8, 2012, at 06:43 , Anne Murray wrote:
>
>> We're using 2.1.0 - I think it may well be the statuses - I will look in to this. Thanks for the info on the check-in modifier too - all very useful!
>>   
>>   
>> Anne
>>
>> On 8 August 2012 12:38, Ben Shum <bshum at biblio.org> wrote:
>> Oops, hit send too fast.  The reason I suggest using the check-in modifier for retargeting holds is that it bypasses the previous check time I mention and resets holds associated with the material so that the check occurs immediately, often resulting in a hold being triggered.  This does have the added effect of slowing down the check-in event (since you take more time to process all the holds, etc.) but one would only be using the option during the cataloging of brand new items.
>>
>> -- Ben
>>
>>
>> On 08/08/2012 07:36 AM, Ben Shum wrote:
>> Hi Anne,
>>
>> Which version of Evergreen are you using?  In more recent versions (since 2.1.0 and upwards, I think), it's possible to use a special "check-in modifier" (lower right corner of the check-in screen) to enable the re-targeting of holds upon check-in of items.  This special modifier is used when handling brand new material that gets added to an Evergreen system.
>>
>> Presently, holds are only targeted once every 24 hours based on the time that the hold was initially placed first.  There's a field on the hold table called "prev_check_time" (previous check time) that tells the targeter to skip said hold until it passes that point.  So depending on when the patron or staff created the hold, and then based on the regularity of your hold targeter script, the availability of materials that can fulfill a hold will vary greatly.  In our consortium, we run our hold targeter every 15 minutes, but because of the 24 hour wait time built into each hold, it still doesn't match brand new items to some existing holds till the following day.  For example, a hold could be created at 1 pm on Monday, a new item created to fill that hold on 2 pm on Monday, but that hold won't target that new item till 1 pm on Tuesday after the previous check time elapses and the hold targeter actually does another check.
>>
>> Another possibility is that whichever copy status that is being used when processing books ordered and scanned in your first mentioned approach is one that does not allow holds to be placed/processed on the material.  You may want to double check that the copy status options are all in order on your system as well and that holds are allowed on the statuses you expect.
>>
>> Hope this helps somewhat, please feel free to ask more questions. Holds can be a little perplexing...
>>
>> -- Ben
>>
>> On 08/08/2012 07:05 AM, Anne Murray wrote:
>> Can anyone help with this as we can't find the problem. If we order more copies of a very popular book, when they are scanned through check in, the holds aren't triggered. The holds targetter is running ok. Also, if we buy a book from Amazon (say) and catalogue it ourselves, the hold goes on ok, but again when it reaches the library the hold isn't picked up and the status goes to 'reshelving'.
>> Anne Murray
>> Service Support Officer
>> East Dunbartonshire Libraries
>> Kirkintilloch
>> Scotland
>>
>>
>> -- 
>> Benjamin Shum
>> Open Source Software Coordinator
>> Bibliomation, Inc.
>> 32 Crest Road
>> Middlebury, CT 06762
>> 203-577-4070, ext. 113
>>
>>
>
> Alexey Lazar
> PALS
> Information System Developer and Integrator
> 507-389-2907
> http://www.mnpals.org/
>
>

-- 
Benjamin Shum
Open Source Software Coordinator
Bibliomation, Inc.
32 Crest Road
Middlebury, CT 06762
203-577-4070, ext. 113