Hi, On Thu, Feb 28, 2013 at 4:39 PM, BWS Johnson <abesottedphoenix@yahoo.com> wrote:
I think this should be unpacked as well ... when would one prefer to transit the item rather than fill a hold request?
In the case of an item that has been damaged and needs return to processing. (You don't like transmission fluid leaking from your Chilton's?)
But I find that imparts a special tang to the reading experience! Seriously, thanks for the example, and that does sound like a situation that could occur often enough to account for in the checkin and transit workflow.
In the case that the delivery driver is at the door right NAO and that hold could theoretically come back to you quite quickly v. sitting on your holds shelf mouldering away for quite a while.
These are related to requests, obviously. I realise a lot of this can be done with overrides. I <3 overrides for situational stuff. Being a slave to the LMS is no fun. Some of this stuff can be managed with clever Patron categories and is on the Librarian rather than the database designer.
In the case of a delinquent Patron, I'd rather forward the item on to someone that is more likely to return it than give it to someone proven to be a bit dodgy. In the case of a Patron what takes overly long to read in favour of one that I know takes a day or two to worm on through. (The former is me. Don't look at my reading records, they are not pretty on the renewal front.) In the case of at Patron who has a time sensitive request. (Dude, my kid needs this book for his school project what was due YESTERDAY. Doctor so and so needs this book for surgery NAO.) These are related to requests, obviously. In the case that the item has essentially been on world tour and really, the collection development people are getting torqued that their book isn't on *their* shelf. (This should be accomplished through itemtypes, but hey, sometimes folks are nice and it's not.)
I also think this is useful to think about in the reverse. When would I want to prefer that an item stay put rather than fill a transfer?
In the case of a Very Important Patron. (You tell that Major Sponsor they ain't getting Consent of the Networked right now or Jo that she's not getting Fifty Shades of Grey. Not me, I'm a coward!) In the case where geography makes it silly and a book would ping pong unnecessarily if behaving how it ought to under the transfer or reserves queue alone. (This happens with ILL proper way more than local transfers, but seriously, why would I send summat way far out only to come back again when I can just kill all non local holds in one fell swoop?{Clearly care needs to be taken in logic to avoid making someone wait for bloody ever for their stuff, but suppose someone is #5 on the list and you're working on #3. Skip #4 for now because it's a victimless crime like punching someone in the dark.}) In the case of a book club, town read, or other event that is time sensitive. (As in hey, I happen to need 10 copies of this, but just for tonight or 1 week from now, or whatever. [Yes you ought to have placed a group hold, but hey, let's not talk about who smells like what for not doing so.])
Thanks! This is all giving me the impression that many of these use cases could be handled with a good interface for cancelling transfer (requests). Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org