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

[Bill Ott]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20100609/c2799a01/attachment-0001.htm