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

[Josh Stompro]

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/20151104/b0a46fe2/attachment.html>