Page Comparison

Moving requests from one item to another:

• Seen as valuable by German institutions (GBV, Leipzig) which purchase lots of copies of course books and allow them to be requested
• Seen as a nice-to-have rather than a must have by US institutions, as they don't have this feature today.  Some might not use it (much) as:
  • They typically only have one item per instance (Chicago and Lehigh) unless you are talking about eBooks
  • They don't do this often today (Cornell) BUT they do have title level requests (Voyager) so that might be why.  Joanne didn't really have the details on how that was working.
  • They aren't sure they are ever in this situation (Cornell).  The things people would like to request the most are reserve items and we don't allow requests on reserve items.
  • This is rare enough that people just cancel requests and create new ones (Chicago, Cornell)
  • Andrea thought she would happily use this at Duke if it were available especially if it came with reports regarding where there are queue imbalances
  • People thought this would be useful for public libraries
• People thought true title level requesting was really complicated and that moving requests would be a simpler thing to do to start
• Reviewed: https://docs.google.com/presentation/d/1E05xd9q8C8XJ6AReGr0WuiMneuZzEPkBmzLm0uL4R5o/edit#slide=id.p
  • Selecting destination item:
    • To start, you would need the ability to move to another copy in the same instance (moving to an item in another instance can be handled later if needed)
    • Should display Instance name in the popup
    • Should change the status column to item status for clarity (this is the availability status)
    • Would want to see call number and enumeration as columns
    • For journals or multi-volume sets, there could be hundreds of items
  • Patron notices - generally you don't want these to be sent.  In the cases where you would want to send a notice, you'd just email the patron (would be nice if there was an email patron feature that would capture a record that the notice was sent)
  • When all requests on a Paged item are cancelled or paged, the item state should return to previous state (which can only be available now but eventually that could also be recently returned).  A popup should tell you what state it will be changed to as a heads up.  Would be nice efficiency to give the choice of changing to available or missing, but it's not a must-have since you can pretty easily just mark it missing from item record
  • When a page at the top of the queue for a paged item is cancelled or moved, the requests behind it do not need to be converted to page requests.  They can stay as holds or recalls or whatever as long as they show up on the pick list report.  People agreed that, what you want to have happen in this scenario, is that the item is picked up off the shelf and scanned into Check in so that fulfillment can begin on the next request in the queue.