New Hold Type - Send To/Rotation - cancel when arrives

[Josh Stompro]

Hello, I've been looking at how some types of item rotation could be made easier, and one idea I've been toying with is having a separate hold type that acts like a forced hold, but the goal is just to get an item to the pickup location so it will go on the shelf there.

We currently use floating, so all we need to do is get an item to the correct location, and when it gets checked in, the circ lib changes to the current location. But the lists of what to send have to be sent to each location, and there is no tracking of the items when they are in delivery.

I think it would be ideal if the holds pull list could be used to notify staff about what they need to grab, and then the items could be pulled and tracked in transit like any other hold.

Once the item arrives at the pickup location and gets checked in, the hold would be canceled and the item would float to that location.

I can emulate this now by placing force holds and then canceling the hold as soon as the item goes in transit, saying no to canceling the transit. It would just be nice not to have to do the hold cancellation step.

This would make it possible to handle rotation and collection balancing entirely in Evergreen, without needing to send out separate lists via email, and having special procedures for handling those items.

This could be made to work for systems that don't use floating by forcing the circ_lib=pickup_lib at checkin also. For those that do rotate items, but don't use floating.

Josh

[Mike Rylander (mrylander)]

Josh,

This is interesting, but I wonder if it deserves a separate UI from holds that helps with tracking. For instance, we could (in a dedicated UI) simply fill a bucket (new type of "rotation"), force the circ_lib up front via the batch-copy-edit-in-bucket logic, and have the UI provide a "rotation pull list" that could be generated at any time, given a selected rotation bucket. Then, when pulled and scanned at checkin, the items would transit to their new home automatically, via the normal mechanism. This would also have the benefit of allowing circ between the "rotation selection" stage and the "check in for transit" stage, if a patron has the item in hand.

Thoughts?

[Josh Stompro (u-launchpad-stompro-org)]

Hello Mike, I really wouldn't want to see a new UI for this, at least for the pull list portion of it. One of my goals is for it to work without any new instructions/training being needed for staff. They already run their pull list on a regular basis so this could be rolled out easily.

I also don't like "hopeful" changes such as changing the circ_lib before the item has been actually pulled, transited and checked in at the new location. You hope the item is actually on the shelf (and that it gets marked missing if needed), hope that staff actually pull it, hope that it actually makes it through delivery, hope that staff actually check in their delivery tub before shelving it. I just hate making changes that place something out of sync with reality and dependent on human error not happening.

Probably the scope of the rotation matters also though. A method that works for moving 100 items at once probably isn't ideal for 3000 items at once. So I guess I can see the appeal of a UI for rotation, but I still think that one of the implementation methods of the rotation could be via a new kind of hold type. The Rotation UI could handle creating the lists, managing sets of rotation locations (Go to locations x, then y, then z). Setting limits to the number of items in flight at once, to spread out the load and only use available delivery space. Turning rotation from a scheduled blitz to a constant steady process. I don't know if that is really an improvement though.

Josh

[Galen Charlton (gmc)]

Josh, would I be correct in assuming that a rotation hold request would generally have the lowest priority? I.e., (not counting frozen holds) if literally anybody else has requested it, they get served first?

And do you envision that such a hold is always item-level? Rather than title-level semantics where the point would be about getting X copies over to a new branch, rather than specific ones?