On Wed, Jan 12, 2011 at 5:37 PM, Kathy Lussier <[email protected]> wrote: > Thank you for the response Jason. I knew that stalling only impacted > opportunistic holds captures, but the fact that it stalls one process and > not the other confuses me about what the ultimate intent of the setting is.
Kathy, So I've mentioned 2 libraries in my scenario, the pickup lib and the "pull" lib. Now imagine if opportunistic capture was enabled and you have 270+ libraries in your consortium. Staff at the pull lib may very well go to the trouble of pulling a targeted item, only to find that the hold it was being pulled for has already opportunistically captured another eligible item that was checked in at one of the other 269+ libraries. This is okay if it's the pickup lib doing the capturing (yay for the patron getting it sooner), but staff at the pull lib could feel slighted, and staff at other libs that happen to process their check-ins earlier in the morning could also get slammed with the lions' share of hold captures. That's what hold stalling was trying to address. You got picked to fulfill a hold, so we're giving you a chance to do it, except in the case where the pickup comes across the desired item sooner (saving ourselves a transit). Does that make sense? -- Jason Etheridge | VP, Tactical Development | Equinox Software, Inc. / Your Library's Guide to Open Source | phone: 1-877-OPEN-ILS (673-6457) | email: [email protected] | web: http://www.esilibrary.com
