Hello Chris, It looks like Traditional has a sort order of (in 2.8.4 at least):
1. approx 2. pprox 3. aprox 4. priority 5. cut 6. depth 7. rtime So the first 2 sorts are based on the proximity of the copy capture lib to the hold pickup lib proximity. approx uses the proximity adjustment feature and pprox does not. So the copy should fill the first hold on the list at the check-in location. Although that will depend on the priority, top of queue and depth values also. But it will try to first fill holds where the capture lib = the pickup lib. So I think this is what you mean by always filling holds at the owning location. But it is really just filling holds at the checking location. If you take that item to a different location, it wouldn’t try to fill the hold at the copy owning location, it would try to fill the holds at that checking location. The goal is to reduce transits. There are settings that specifically will try to fill holds at the copy owning location first(hprox), and some neat ones that will send the copy back home if it has been at a different branch for so long(htime, shtime). If you want to just fill the oldest hold, no matter where that is at, then you want a BHSSO that has rtime (request time) as the first value. If you still want to allow the use of top of queue/cut in line (I love that there are two different labels for that feature) then you could keep cut as 1, and rtime as 2. If you use the Permission Group hold priority feature, you could keep that in the mix also. FIFO should do it, since that is 1. Priority, 2. Cut and 3. Rtime. If you use FIFO then a checked in item will try to fill the oldest hold first (if there are no Priority or cut options in use). If you don’t want to change all your opportunistic captures to FIFO from Traditional you could create another org unit to own them. And then setup the FIFO BHSSO for that org unit. The downside is that if you just use one, then you lose the link to the owning lib. If you ever decided to stop floating, allocating the items back to the location that purchased them would be harder. You may want to add an item stat cat to hold the owning location for those items, so there is an easy way to get a report to put the items back. What do you want to happen to all your non floating materials… maybe you don’t allow requests from other libraries right now? If you don’t currently allow requests from other libraries on your non floating items, then changing from Traditional to FIFO wouldn’t be that big of a deal, since approx, pprox and aprox all have to do with holds going to other locations. If those don’t apply then it is basically the same as FIFO. Josh Stompro - LARL IT Director From: Open-ils-general [mailto:[email protected]] On Behalf Of Chris Owens Sent: Wednesday, March 09, 2016 12:45 PM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] Floating collections Josh: Looking over your documentation, I just had a couple of questions, if you have time. It looks like we are using what you call the "traditional" BHSSO, but if I understand you correctly, changing it to the FIFO method will not solve our problem because the new floating item we check in will still go first to the patron of that owning library even if that patron isn't first on the holds list? Does it seem to you that the only solution to this problem right now is to create another org unit for these items for the FIFO method (with Hold Priority at the top of the list) to truly work correctly? Thanks again for your help, Chris On 3/4/2016 10:29 AM, Josh Stompro wrote: Hello Chris, I believe you will need to adjust your Best-Hold Selection Sort Order (BHSSO) so that owning location doesn’t get priority. The official docs are at http://docs.evergreen-ils.org/2.8/_best_hold_selection_sort_order.html I’ve been working on some updates to the docs that may help. https://gist.github.com/stompro/42eb6cbe2c1db5f12324 You may be currently using hprox as one of your first sorts, which always fills holds at the Owning locations first. If you switch to pprox then you will fill holds at the checkin location first. If you only want to change the BHSSO for the floating items, then you could create a new org unit just to own those items. The BHSSO is applied based on the items owning location. Keep in mind also, that items don’t float until all holds are filled and the item goes to reshelving. So an item with many holds won’t change circ lib until all the holds are filled. This has caused problems for our staff since they like to see where items are filling holds, and it isn’t easy when working with floating items since the catalog view isn’t accurate until all the holds are filled and the circ location gets updated. You have to look at the last checkout location to see where an item is actually at. Let me know if you have more questions, I would like to update the docs if they don’t cover certain things. From: Open-ils-general [mailto:[email protected]] On Behalf Of Chris Owens Sent: Wednesday, March 2, 2016 2:02 PM To: 'Evergreen Discussion Group' Subject: [OPEN-ILS-GENERAL] Floating collections We have begun floating some popular items in our consortium and are running into a problem. We created a special shelving location for the items, but the library that purchases the item becomes the owning and circulating library for the item. The problem is that whenever we check in a new floating collection item that has requests, the item defaults to the owning library's patron rather than the next person on the request list. Does anyone know if we just need to change a setting or is it something more complex? Thanks, Chris -- Chris Owens Director Blanchester Public Library 110 N. Broadway Blanchester, OH 45107 937-783-3585 937-783-2910 (fax) [email protected]<mailto:[email protected]>
