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 <bs...@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
