Re: [OPEN-ILS-GENERAL] In-Process items, centralized cataloging, filling random holds, not in Best Hold Selection order
Elaine, Thanks for all the feedback. It has helped me work though the options. We do have a test system that we can try things out on, once I get it updated with a more recent copy of our production system. Here is a summary of what I think our options are. 1. Manually route in-progress items to the assigned locations. Poses problems for us because we use floating and don't have a physical indication on the copy of where it initially needs to go. If we did have a custom barcode label that specifies which location it goes to, or something similar this would work ok. There is a chance that an item would get to its home location and immediately get sent back to fill a hold at another location. Watching for those situations would again take more manual checking. We would rather have the system take care of it. 2. Use top of queue/cut in line to force the new copies to fill the holds at the locations that we want the initial copies to go to. a. Pro: Items get to the initial locations they need to be at. b. Pro: Items wouldn't go somewhere just to be checked in and go back in transit to another location. c. Cons: Extra work to change the holds. d. Cons: Depending on how long of a time period passes between setting the Cut-in line for the holds and the copies getting processed e. Cons: Depending on the order that the copies are checked in, the item owning/circ lib won't match up with which hold they are going to fill. This would make the catalog display confusing until all the holds are filled and items start floating at reshelving time. I can think of a couple enhancements that would make this process smoother for us. If anyone else is interested in something along these lines let me know so we can coordinate. New Development/New Features * A new checkin modifier that would force the use of the workstations org unit best hold selection sort order. This would allow our cataloging stations to force a home proximity based sort, so the copies would automatically start filling holds at their assigned home libraries first. If there are no holds at the home location then the oldest hold based on the normal proximity would take effect. I can see this feature helping out other organizations. It seems like a way to override the best hold selection sort based on physical location could be useful in other situations. I don't know how feasible this would be to create. Maybe it would be easy to just modify the copy object higher in the stack to change the owning lib for that copy just for the checkin. * A new checkin modifier that would suppress holds but allow transits, so items would be routed to their home locations to start with and would start filling holds once they get there. This would potentially send copies out to a location that has no local holds, so the item would immediately go back into transit, wasting time in transit. So I think this option is less desirable than the first one. But since there is already a suppress holds and transits checkin mod feature, there is more of a chance that I could figure out how to create this. Josh Stompro - LARL IT Director From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Hardy, Elaine Sent: Friday, November 06, 2015 9:13 AM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] In-Process items, centralized cataloging, filling random holds, not in Best Hold Selection order Josh, A floating collection would certainly change how you would handle items. No PINES library has a floating collections at this point, so I am not sure I can answer your questions since we don't have experience with it. I can tell you that, with PINES holds configuration, there is no guarantee after the 6 months hold protection is over that a location's item will fill a location's holds. It isn't unusual for Org Unit A's item to fill holds at OU B while OU B's item is filling holds at another OU. It is one of those things that annoys PINES staff but it does prevent an item from criss-crissing the state and spending too much time in transit as a result. One downside to having all copies owned by one OU would be sorting copies amongst locations if you did ever stop floating your collection. Consider, if you have a test server to set up holds testing/tracking and see what happens under different scenarios that you know you encounter. If you don't have a test server, I suggest you monitor and track how holds are functioning for a specific period of time. Whichever method you use, evaluate your workflow and settings based on your findings. It may take time and cause for headaches along the way; but, in the end you will have a practical understanding of how holds are functioning under your policies and workflows and will be better able to make any adjustments to either you need. Elaine J. Elaine Hardy PINES
Re: [OPEN-ILS-GENERAL] In-Process items, centralized cataloging, filling random holds, not in Best Hold Selection order
Josh, If you are a consortium with a floating collection, and no property designation on the item, does it matter which copy fills which hold as long as the hold gets filled? Elaine J. Elaine Hardy PINES & Collaborative Projects Manager Georgia Public Library Service 1800 Century Place, Ste 150 Atlanta, Ga. 30345-4304 404.235.7128 404.235.7201, fax eha...@georgialibraries.org www.georgialibraries.org www.georgialibraries.org/pines From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Josh Stompro Sent: Friday, November 6, 2015 3:03 PM To: Evergreen Discussion Group <open-ils-general@list.georgialibraries.org> Subject: Re: [OPEN-ILS-GENERAL] In-Process items, centralized cataloging, filling random holds, not in Best Hold Selection order Elaine, Thanks for all the feedback. It has helped me work though the options. We do have a test system that we can try things out on, once I get it updated with a more recent copy of our production system. Here is a summary of what I think our options are. 1. Manually route in-progress items to the assigned locations. Poses problems for us because we use floating and don't have a physical indication on the copy of where it initially needs to go. If we did have a custom barcode label that specifies which location it goes to, or something similar this would work ok. There is a chance that an item would get to its home location and immediately get sent back to fill a hold at another location. Watching for those situations would again take more manual checking. We would rather have the system take care of it. 2. Use top of queue/cut in line to force the new copies to fill the holds at the locations that we want the initial copies to go to. a. Pro: Items get to the initial locations they need to be at. b. Pro: Items wouldn't go somewhere just to be checked in and go back in transit to another location. c. Cons: Extra work to change the holds. d. Cons: Depending on how long of a time period passes between setting the Cut-in line for the holds and the copies getting processed e. Cons: Depending on the order that the copies are checked in, the item owning/circ lib won't match up with which hold they are going to fill. This would make the catalog display confusing until all the holds are filled and items start floating at reshelving time. I can think of a couple enhancements that would make this process smoother for us. If anyone else is interested in something along these lines let me know so we can coordinate. New Development/New Features * A new checkin modifier that would force the use of the workstations org unit best hold selection sort order. This would allow our cataloging stations to force a home proximity based sort, so the copies would automatically start filling holds at their assigned home libraries first. If there are no holds at the home location then the oldest hold based on the normal proximity would take effect. I can see this feature helping out other organizations. It seems like a way to override the best hold selection sort based on physical location could be useful in other situations. I don't know how feasible this would be to create. Maybe it would be easy to just modify the copy object higher in the stack to change the owning lib for that copy just for the checkin. * A new checkin modifier that would suppress holds but allow transits, so items would be routed to their home locations to start with and would start filling holds once they get there. This would potentially send copies out to a location that has no local holds, so the item would immediately go back into transit, wasting time in transit. So I think this option is less desirable than the first one. But since there is already a suppress holds and transits checkin mod feature, there is more of a chance that I could figure out how to create this. Josh Stompro - LARL IT Director From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Hardy, Elaine Sent: Friday, November 06, 2015 9:13 AM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] In-Process items, centralized cataloging, filling random holds, not in Best Hold Selection order Josh, A floating collection would certainly change how you would handle items. No PINES library has a floating collections at this point, so I am not sure I can answer your questions since we don't have experience with it. I can tell you that, with PINES holds configuration, there is no guarantee after the 6 months hold protection is over that a location's item will fill a location's holds. It isn't unusual for Org Unit A's item to fill holds at OU B while OU B's item is filling holds at another OU. It is one of those things that annoys PINES staff but it does prevent an item from criss-crissing the state and spending too
Re: [OPEN-ILS-GENERAL] In-Process items, centralized cataloging, filling random holds, not in Best Hold Selection order
Josh, A floating collection would certainly change how you would handle items. No PINES library has a floating collections at this point, so I am not sure I can answer your questions since we don't have experience with it. I can tell you that, with PINES holds configuration, there is no guarantee after the 6 months hold protection is over that a location's item will fill a location's holds. It isn't unusual for Org Unit A's item to fill holds at OU B while OU B's item is filling holds at another OU. It is one of those things that annoys PINES staff but it does prevent an item from criss-crissing the state and spending too much time in transit as a result. One downside to having all copies owned by one OU would be sorting copies amongst locations if you did ever stop floating your collection. Consider, if you have a test server to set up holds testing/tracking and see what happens under different scenarios that you know you encounter. If you don't have a test server, I suggest you monitor and track how holds are functioning for a specific period of time. Whichever method you use, evaluate your workflow and settings based on your findings. It may take time and cause for headaches along the way; but, in the end you will have a practical understanding of how holds are functioning under your policies and workflows and will be better able to make any adjustments to either you need. Elaine J. Elaine Hardy PINES & Collaborative Projects Manager Georgia Public Library Service 1800 Century Place, Ste 150 Atlanta, Ga. 30345-4304 404.235.7128 404.235.7201, fax eha...@georgialibraries.org www.georgialibraries.org www.georgialibraries.org/pines From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Josh Stompro Sent: Thursday, November 5, 2015 4:44 PM To: Evergreen Discussion Group <open-ils-general@list.georgialibraries.org> Subject: Re: [OPEN-ILS-GENERAL] In-Process items, centralized cataloging, filling random holds, not in Best Hold Selection order Elaine, We just tried to work though how it would work to send items out without checking them in and I don't think we can make it work. There is nothing on the items themselves that say which branch they go to, so we cannot simple look at the item to know where to send it. We float everything so we don't need that info on the item. So someone would need to look up the info on each item and manually add/create a routing slip at that point, which is quite a bit more work than just checking stuff in and printing a slip. What I think might work for us is that when our Collections Dev librarian decides where the copies are initially allocated based on the holds, she can select the first X number of holds (where X = number of copies) for the locations where the items are going to be assigned, and use top of queue/cut in line to set those holds to be filled first. Then when the items are checked in , they will fill those holds first and go to the correct locations. It might make the catalog look a little strange, since there is no guarantee that location A's item will be filling location A's holds, unless we are really good about checking in the items in the right order. Now I'm wondering if we can use floating to skip the volume creation step for each owning location? Is there a downside to having all the items at one owning location with all the copies having different circulation library locations? Josh Stompro - LARL IT Director From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Josh Stompro Sent: Thursday, November 05, 2015 2:03 PM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] In-Process items, centralized cataloging, filling random holds, not in Best Hold Selection order Thanks Elaine, I found out that the issue I was having with the specific title that seemed to fill the wrong hold was because our migrated holds all had a selection_depth of 1, and holds placed post migration have a selection depth of 0. We had the selection depth included in our Best Hold Selection Sort order, which was sorting the holds based on that, which was prioritizing the holds with a depth of 0. So the system was working exactly like it should, it just took me a while to figure it why. I think the problem with checking in as a workstation for each location is that then the items would immediately fill holds and go onto the holdshelf. Notifying the patron that the item is ready, when it is really in transit. Maybe the capture local holds as transits checking mod would help with that. I wish there was a checkin mod like the Suppress Holds and Transit that was just suppresses holds, which would just place the items in transit back to their circ lib. We will try just sending the items without a transit, and see how that works out. Thanks for the info. Josh Stompro - LARL IT Director From: Open-i
Re: [OPEN-ILS-GENERAL] In-Process items, centralized cataloging, filling random holds, not in Best Hold Selection order
Hi Josh, One thing you could try is to add the new items with a non-holdable status. Then you can check them in and they will be set in transit to their circ library rather than being captured for any holds. I'm not sure exactly what will happen when they're received at their circ library. It might take two checkins with the Retarget checkin modifiers turned on to capture the holds at that point. Another thing you could try is, after adding the copies centrally, view the holds on the bib, and select and manually retarget the oldest (or all) of the holds on the bib from there. If you do this prior to checking the items in, they should be properly targeted. Then you can check them in and send them on their way to fill their holds. As far as development, some is definitely needed to address this type of situation. I'd like to see the hold targeting for newly added items moved to a background process rather than forcing a retarget at checkin. Not sure how this could be accomplished, but if, for example, creating a new item could initiate a retarget of holds that item could possibly fill, it could eliminate a lot of problems like this. Hope this is helpful, Michele -- Michele M. Morgan, Technical Assistant North of Boston Library Exchange, Danvers Massachusetts mmor...@noblenet.org On Fri, Nov 6, 2015 at 3:39 PM, Hardy, Elaine <eha...@georgialibraries.org> wrote: > Josh, > > > > If you are a consortium with a floating collection, and no property > designation on the item, does it matter which copy fills which hold as long > as the hold gets filled? > > > > > > > > Elaine > > > > J. Elaine Hardy > PINES & Collaborative Projects Manager > Georgia Public Library Service > 1800 Century Place, Ste 150 > Atlanta, Ga. 30345-4304 > > > > 404.235.7128 > 404.235.7201, fax > eha...@georgialibraries.org > www.georgialibraries.org > www.georgialibraries.org/pines > > > > From: Open-ils-general > [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of > Josh Stompro > Sent: Friday, November 6, 2015 3:03 PM > > > To: Evergreen Discussion Group <open-ils-general@list.georgialibraries.org> > Subject: Re: [OPEN-ILS-GENERAL] In-Process items, centralized cataloging, > filling random holds, not in Best Hold Selection order > > > > Elaine, > > > > Thanks for all the feedback. It has helped me work though the options. We > do have a test system that we can try things out on, once I get it updated > with a more recent copy of our production system. > > > > Here is a summary of what I think our options are. > > > > 1. Manually route in-progress items to the assigned locations. Poses > problems for us because we use floating and don’t have a physical indication > on the copy of where it initially needs to go. If we did have a custom > barcode label that specifies which location it goes to, or something similar > this would work ok. There is a chance that an item would get to its home > location and immediately get sent back to fill a hold at another location. > Watching for those situations would again take more manual checking. We > would rather have the system take care of it. > > 2. Use top of queue/cut in line to force the new copies to fill the > holds at the locations that we want the initial copies to go to. > > a. Pro: Items get to the initial locations they need to be at. > > b. Pro: Items wouldn’t go somewhere just to be checked in and go back > in transit to another location. > > c. Cons: Extra work to change the holds. > > d. Cons: Depending on how long of a time period passes between setting > the Cut-in line for the holds and the copies getting processed > > e. Cons: Depending on the order that the copies are checked in, the > item owning/circ lib won’t match up with which hold they are going to fill. > This would make the catalog display confusing until all the holds are filled > and items start floating at reshelving time. > > > > I can think of a couple enhancements that would make this process smoother > for us. If anyone else is interested in something along these lines let me > know so we can coordinate. > > > > New Development/New Features > > · A new checkin modifier that would force the use of the workstations > org unit best hold selection sort order. This would allow our cataloging > stations to force a home proximity based sort, so the copies would > automatically start filling holds at their assigned home libraries first. > If there are no holds at the home location then the oldest hold based on the > normal proximity would take effect. I can see this feature helping out > other organizations. It seems l
Re: [OPEN-ILS-GENERAL] In-Process items, centralized cataloging, filling random holds, not in Best Hold Selection order
Josh, While we don't do centralized cataloging for the entire consortium, individual systems catalog at their headquarters and then send the items to owning branches. The items are in process until they are received by circulation at each branch. That is how in process was designed to function originally. Some libraries run reports for items in process longer than the expected transit time to see if material has gone astray . Some libraries include an "invoice", based on a report,of the items included in a delivery for branches to acknowledge receipt. So you can send items still in process to locations and keep track of them; but you would need to use reports to assist. PINES libraries find that items rarely go astray - occasionally they might not make it into the delivery or are sent to the wrong branch. The most common problem is that they make it to the shelf at the correct location without being checked in. Running reports and shelf checking for items still in process should find most of the strayed items. If you do want to continue checking the items in at central cataloging, it may be best to set up workstations for the separate locations and check each location in using that workstation login. Elaine J. Elaine Hardy PINES & Collaborative Projects Manager Georgia Public Library Service 1800 Century Place, Ste 150 Atlanta, Ga. 30345-4304 404.235.7128 404.235.7201, fax eha...@georgialibraries.org www.georgialibraries.org www.georgialibraries.org/pines From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Josh Stompro Sent: Wednesday, November 04, 2015 3:15 PM To: Evergreen Discussion Group (open-ils-general@list.georgialibraries.org) Subject: [OPEN-ILS-GENERAL] In-Process items, centralized cataloging, filling random holds, not in Best Hold Selection order Hello, I know I've heard mention of this issue, but I'm now trying to figure out how to deal with it and I cannot find a good explanation. We are a consolidated system and do centralized cataloging, and assign initial owning and circ locations when the items are received based on number of holds for each pickup location. So our normal process is to assign those locations for the items and then check in the items (at our Cataloging OU/workstation) so they will grab the holds and fill them. So the items are in "in processing" status and then get checked in. But the holds that are being grabbed seem to be somewhat random. In the latest test case, it is the hold with the largest hold ID number that is getting assigned to a copy, which is the last hold that was placed. So our Best Hold Selection sort order for opportunistic holds is being ignored, in many different ways. It should be filling the oldest hold first when all the proximities are the same, but it isn't. I've tried the retarget local holds, but the holds are not local, so that doesn't seem to do anything for us. I've tried setting a new Best Hold Selection sort order based on hprox (Home proximity) on the cataloging OU so that the holds would be evaluated based on owning location -> pickup location proximity, but that doesn't change the behavior at all. The first hold that gets selected is based on it having the highest hold ID. It seems like it would work to just send the items to the correct owning location, without checking them in, but that seems wrong, there would be no record of the transit which would make it harder to find items that get lost on the way. Can someone point me to the correct way to deal with this, or where the issue is discussed? Thanks Lake Agassiz Regional Library - Moorhead MN larl.org Josh Stompro | Office 218.233.3757 EXT-139 LARL IT Director | Cell 218.790.2110
Re: [OPEN-ILS-GENERAL] In-Process items, centralized cataloging, filling random holds, not in Best Hold Selection order
Thanks Elaine, I found out that the issue I was having with the specific title that seemed to fill the wrong hold was because our migrated holds all had a selection_depth of 1, and holds placed post migration have a selection depth of 0. We had the selection depth included in our Best Hold Selection Sort order, which was sorting the holds based on that, which was prioritizing the holds with a depth of 0. So the system was working exactly like it should, it just took me a while to figure it why. I think the problem with checking in as a workstation for each location is that then the items would immediately fill holds and go onto the holdshelf. Notifying the patron that the item is ready, when it is really in transit. Maybe the capture local holds as transits checking mod would help with that. I wish there was a checkin mod like the Suppress Holds and Transit that was just suppresses holds, which would just place the items in transit back to their circ lib. We will try just sending the items without a transit, and see how that works out. Thanks for the info. Josh Stompro - LARL IT Director From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Hardy, Elaine Sent: Thursday, November 05, 2015 10:37 AM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] In-Process items, centralized cataloging, filling random holds, not in Best Hold Selection order Josh, While we don't do centralized cataloging for the entire consortium, individual systems catalog at their headquarters and then send the items to owning branches. The items are in process until they are received by circulation at each branch. That is how in process was designed to function originally. Some libraries run reports for items in process longer than the expected transit time to see if material has gone astray . Some libraries include an "invoice", based on a report,of the items included in a delivery for branches to acknowledge receipt. So you can send items still in process to locations and keep track of them; but you would need to use reports to assist. PINES libraries find that items rarely go astray - occasionally they might not make it into the delivery or are sent to the wrong branch. The most common problem is that they make it to the shelf at the correct location without being checked in. Running reports and shelf checking for items still in process should find most of the strayed items. If you do want to continue checking the items in at central cataloging, it may be best to set up workstations for the separate locations and check each location in using that workstation login. Elaine J. Elaine Hardy PINES & Collaborative Projects Manager Georgia Public Library Service 1800 Century Place, Ste 150 Atlanta, Ga. 30345-4304 404.235.7128 404.235.7201, fax eha...@georgialibraries.org<mailto:eha...@georgialibraries.org> www.georgialibraries.org<http://www.georgialibraries.org> www.georgialibraries.org/pines<http://www.georgialibraries.org/pines> From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Josh Stompro Sent: Wednesday, November 04, 2015 3:15 PM To: Evergreen Discussion Group (open-ils-general@list.georgialibraries.org<mailto:open-ils-general@list.georgialibraries.org>) Subject: [OPEN-ILS-GENERAL] In-Process items, centralized cataloging, filling random holds, not in Best Hold Selection order Hello, I know I've heard mention of this issue, but I'm now trying to figure out how to deal with it and I cannot find a good explanation. We are a consolidated system and do centralized cataloging, and assign initial owning and circ locations when the items are received based on number of holds for each pickup location. So our normal process is to assign those locations for the items and then check in the items (at our Cataloging OU/workstation) so they will grab the holds and fill them. So the items are in "in processing" status and then get checked in. But the holds that are being grabbed seem to be somewhat random. In the latest test case, it is the hold with the largest hold ID number that is getting assigned to a copy, which is the last hold that was placed. So our Best Hold Selection sort order for opportunistic holds is being ignored, in many different ways. It should be filling the oldest hold first when all the proximities are the same, but it isn't. I've tried the retarget local holds, but the holds are not local, so that doesn't seem to do anything for us. I've tried setting a new Best Hold Selection sort order based on hprox (Home proximity) on the cataloging OU so that the holds would be evaluated based on owning location -> pickup location proximity, but that doesn't change the behavior at all. The first hold that gets selected is based on it having the highest hold ID. It seems like it would work to just send the item
Re: [OPEN-ILS-GENERAL] In-Process items, centralized cataloging, filling random holds, not in Best Hold Selection order
Elaine, We just tried to work though how it would work to send items out without checking them in and I don't think we can make it work. There is nothing on the items themselves that say which branch they go to, so we cannot simple look at the item to know where to send it. We float everything so we don't need that info on the item. So someone would need to look up the info on each item and manually add/create a routing slip at that point, which is quite a bit more work than just checking stuff in and printing a slip. What I think might work for us is that when our Collections Dev librarian decides where the copies are initially allocated based on the holds, she can select the first X number of holds (where X = number of copies) for the locations where the items are going to be assigned, and use top of queue/cut in line to set those holds to be filled first. Then when the items are checked in , they will fill those holds first and go to the correct locations. It might make the catalog look a little strange, since there is no guarantee that location A's item will be filling location A's holds, unless we are really good about checking in the items in the right order. Now I'm wondering if we can use floating to skip the volume creation step for each owning location? Is there a downside to having all the items at one owning location with all the copies having different circulation library locations? Josh Stompro - LARL IT Director From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Josh Stompro Sent: Thursday, November 05, 2015 2:03 PM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] In-Process items, centralized cataloging, filling random holds, not in Best Hold Selection order Thanks Elaine, I found out that the issue I was having with the specific title that seemed to fill the wrong hold was because our migrated holds all had a selection_depth of 1, and holds placed post migration have a selection depth of 0. We had the selection depth included in our Best Hold Selection Sort order, which was sorting the holds based on that, which was prioritizing the holds with a depth of 0. So the system was working exactly like it should, it just took me a while to figure it why. I think the problem with checking in as a workstation for each location is that then the items would immediately fill holds and go onto the holdshelf. Notifying the patron that the item is ready, when it is really in transit. Maybe the capture local holds as transits checking mod would help with that. I wish there was a checkin mod like the Suppress Holds and Transit that was just suppresses holds, which would just place the items in transit back to their circ lib. We will try just sending the items without a transit, and see how that works out. Thanks for the info. Josh Stompro - LARL IT Director From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Hardy, Elaine Sent: Thursday, November 05, 2015 10:37 AM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] In-Process items, centralized cataloging, filling random holds, not in Best Hold Selection order Josh, While we don't do centralized cataloging for the entire consortium, individual systems catalog at their headquarters and then send the items to owning branches. The items are in process until they are received by circulation at each branch. That is how in process was designed to function originally. Some libraries run reports for items in process longer than the expected transit time to see if material has gone astray . Some libraries include an "invoice", based on a report,of the items included in a delivery for branches to acknowledge receipt. So you can send items still in process to locations and keep track of them; but you would need to use reports to assist. PINES libraries find that items rarely go astray - occasionally they might not make it into the delivery or are sent to the wrong branch. The most common problem is that they make it to the shelf at the correct location without being checked in. Running reports and shelf checking for items still in process should find most of the strayed items. If you do want to continue checking the items in at central cataloging, it may be best to set up workstations for the separate locations and check each location in using that workstation login. Elaine J. Elaine Hardy PINES & Collaborative Projects Manager Georgia Public Library Service 1800 Century Place, Ste 150 Atlanta, Ga. 30345-4304 404.235.7128 404.235.7201, fax eha...@georgialibraries.org<mailto:eha...@georgialibraries.org> www.georgialibraries.org<http://www.georgialibraries.org> www.georgialibraries.org/pines<http://www.georgialibraries.org/pines> From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Josh Stompro Sent: W
[OPEN-ILS-GENERAL] In-Process items, centralized cataloging, filling random holds, not in Best Hold Selection order
Hello, I know I've heard mention of this issue, but I'm now trying to figure out how to deal with it and I cannot find a good explanation. We are a consolidated system and do centralized cataloging, and assign initial owning and circ locations when the items are received based on number of holds for each pickup location. So our normal process is to assign those locations for the items and then check in the items (at our Cataloging OU/workstation) so they will grab the holds and fill them. So the items are in "in processing" status and then get checked in. But the holds that are being grabbed seem to be somewhat random. In the latest test case, it is the hold with the largest hold ID number that is getting assigned to a copy, which is the last hold that was placed. So our Best Hold Selection sort order for opportunistic holds is being ignored, in many different ways. It should be filling the oldest hold first when all the proximities are the same, but it isn't. I've tried the retarget local holds, but the holds are not local, so that doesn't seem to do anything for us. I've tried setting a new Best Hold Selection sort order based on hprox (Home proximity) on the cataloging OU so that the holds would be evaluated based on owning location -> pickup location proximity, but that doesn't change the behavior at all. The first hold that gets selected is based on it having the highest hold ID. It seems like it would work to just send the items to the correct owning location, without checking them in, but that seems wrong, there would be no record of the transit which would make it harder to find items that get lost on the way. Can someone point me to the correct way to deal with this, or where the issue is discussed? Thanks Lake Agassiz Regional Library - Moorhead MN larl.org Josh Stompro | Office 218.233.3757 EXT-139 LARL IT Director | Cell 218.790.2110
