[OPEN-ILS-GENERAL] ***SPAM*** ***SPAM*** Re: ***SPAM*** ***SPAM*** Re: ***SPAM*** Re: Holds fulfillment enhancement

[Doug Kyle]

Hey Lori,

I submitted a patch to the dev list with the 'Holds go Home' code back 
in early May, should you care to try it out.

Bill Ott wrote:
> Here in Grand Rapids, we wrote something, which we affectionately call 
> "Holds go Home".  After a designated interval (e.g. 6 weeks), if an 
> item has not been checked in at it's shelving library, it checks back 
> to see if there are any holds waiting at that location.  If so, it 
> sends the item "home".  If not, it happily fills holds in the 
> traditional Evergreen manner.
>
> I've also talked about, but not implemented, a wild card pickup 
> location.  Here the library gas is saved, but the patron could get the 
> item as fast as possible, if they're willing to pick it up wherever it 
> shows up.  This works well if you're as geographically dense as we 
> are, but it's certainly not for everyone.
>
>
>
> On 6/9/10 5:09 PM, Lori Bowen Ayre wrote:
>> This is cool.  Thanks to Thompson-Nicola!  I'm wondering if anyone 
>> has ever considered a related situation that comes up with holds and 
>> that is the ability to promote someone to the top of the queue 
>> because of their pick-up location. 
>>
>> For example, let's say a patron has been waiting for PopularDVD for 5 
>> weeks and finally the patron has risen to position #10 on the wait 
>> list.  As soon as a copy is returned to that patron's pick-up 
>> location, I would like the system to behave opportunistically and 
>> allow that patron (now #10 on the wait list) to get that hold filled. 
>>  I would like the setting to be flexible, meaning each library could 
>> allow for queue jumping to fill opportunistic holds at 5 or 3 or 15, 
>> their choice.
>>
>> I think this would address both the need to reduce as much travel for 
>> the item as possible while respecting the wait lists.  We could even 
>> make the top five or ten positions (depending on your setting) be 
>> called something special like the Red Zone or something so that 
>> everyone knows that at any moment they could get the item.
>>
>> Any interest?
>>
>> Lori Ayre
>>
>> On Wed, Jun 9, 2010 at 1:41 PM, James Fournie 
>> <jfournie at sitka.bclibraries.ca 
>> <mailto:jfournie at sitka.bclibraries.ca>> wrote:
>>
>>     Hi everyone,
>>
>>     There was some discussion about problems with holds fulfillment
>>     at the
>>     holds roundtable at EG2010.  I am pleased to share this patch
>>     with the
>>     community which has been thoroughly tested by the folks at
>>     Thompson-Nicola Regional District Library.  (thanks guys!)
>>
>>     Background:
>>
>>     Evergreen's default out-of-the-box behaviour for holds fulfillment is
>>     a gas-saving method.  Holds are fulfilled by proximity.  In a
>>     multibranch library, holds are fulfilled at the local branch first.
>>     Many libraries, particularly single branch libraries may be ok with
>>     this, but it may be problematic for other libraries.
>>
>>     Imagine a scenario where you have a large central branch and a small
>>     rural branch of the same library system.  At the large branch, there
>>     are many copies of Popular New DVD with lots of holds.   There are no
>>     copies at the rural branch.  Patrons at the small rural branch who
>>     want to pick up Popular New DVD at their home branch may never get
>>     their hold fulfilled because the copies will stay at the large branch
>>     as long as there are holds for pickup there.
>>
>>     This patch adds an org unit setting that changes the opportunistic
>>     check-in so that items checked in will be assigned to holds by
>>     request
>>     date first, rather than proximity.   This setting can be applied to
>>     any level of the org tree, so in some situations you may even want to
>>     activate FIFO for large libraries, but leave the original setting for
>>     smaller libraries with less traffic who want to keep their copies
>>     more
>>     local.
>>
>>     Also credit to Jeff Godin who thought of the same patch and
>>     contributed the setting name "holds FIFO" for the setting
>>
>>     Patch is for rel_1_6_0
>>
>>     ~James Fournie
>>     BC SITKA
>>
>>