> Thinking about what you've said about stalling. We get the idea that op > capture is the least costly way to fill a hold, since the item is already in > the hands of a staff person, and may already be at the pickup location. If > you're trying to reduce transits around the system, wouldn't you want to > delay having the hold appear on a pull list to give the op capture a chance > to fill the hold?
I think a lot of folks have been looking for a balance, and then we have the FIFO folks who are looking for predictable fairness. There are also other settings that could be used to limit transits (such as soft boundaries and hold ranges). These settings might have problems of their own. For example, if you have a Soft Boundary configured for Branch, and the pickup has an eligible item that is currently circulating, the hold targeter will never look beyond the pickup lib (even if the item is later returned damaged, etc.) The soft boundary effectively turns the hold into a branch-ranged hold. I don't have empirical evidence handy, but I'd expect for op-capture to happen most often in the morning when folks are checking in items from their drop-boxes. So maybe an option that thins out pull lists during such times for titles that have many circulating and eligible items would be a nice thing to have. Folks who print their pull lists later could get an unabridged version for everything that didn't get caught that morning opportunistically. Or folks could just not use/print their pull lists until after such an op-capture-frenzy in the first place. -- Jason Etheridge | VP, Tactical Development | Equinox Software, Inc. / Your Library's Guide to Open Source | phone: 1-877-OPEN-ILS (673-6457) | email: ja...@esilibrary.com | web: http://www.esilibrary.com