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 <[email protected]> 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 > >
