[OPEN-ILS-GENERAL] In-Process items, centralized cataloging, filling random holds, not in Best Hold Selection order

[Hardy, Elaine]

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
ehardy at georgialibraries.org
www.georgialibraries.org
www.georgialibraries.org/pines

 

From: Open-ils-general
[mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of
Josh Stompro
Sent: Wednesday, November 04, 2015 3:15 PM
To: Evergreen Discussion Group
(open-ils-general at 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  

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20151105/f1945ccf/attachment.html>