Filling holds: How the Koha holds queue works

by Kyle Hall on Jun 2, 2013

There are two methods for dealing with the process and pulling and filling holds with on-shelf items using Koha. The first and simplest is the Holds to pull report. This report will list all the holds that need filled at all libraries. It essentially works on a first-come-first-served basis. This report works best for Koha installations with a single library, or a library system where there is little to no cost to transfer items between libraries.

The second method, is theHolds queue which attempts to fill holds in a more intelligent manner. This method attempts to match particular items to particular holds, and also attempts to minimize transit costs for filling holds. The underlying logic for this system is far more complicated, but when used successfully, will minimize the cost and transit time involved with filling on-shelf holds.

The first step to using to the holds queue is to ensure thebuild_holds_queue.pl cronjob is enabled and set to run on a periodic basis. The most common setting seems to be to have it run every 15 minutes, but it may be run more or less frequently depending on the specific needs of your library. This script is the actual ‘brains’ behind the system, and selects the items to fill particular holds. This data is then stored in the Koha database for the holds queue report to then display on demand.

The holds queue is governed by a number of settings. The first setting of note, is UseTransportCostMatrix. The transport cost matrix is a new feature for the holds queue. If the cost of transferring an item between libraries varies greatly depending on which two sites are involved in the transfer, the transport cost matrix may allow your system to lessen the total cost of transferring items. To use it, you must first enable theUseTransportCostMatrix system preference. Then, you can populate the transport cost matrix from the link in Koha’s administration section. This matrix is a grid of your libraries, where you can enter a ‘weight’ for the cost of transporting a item between each pair of libraries. The number you enter here is simply a decimal number between 1 and 100. It may be easier to think of it in terms of dollar amounts. If the cost of transporting an item between Library A and Library B is $1.25, you can literally enter 1.25 in the cell for those two libraries. For a system with many sites, fully populating this table can take some time, but thankfully it only needs to be done once.

If you opt to not use the transport cost matrix, the branches to use for filling holds aredeterminedby the preferencesStaticHoldsQueueWeight andRandomizeHoldsQueueWeight. You can enter a list of branchcodes inStaticHoldsQueueWeight to be used in the order listed, or in a random order ( if you choose to enable RandomizeHoldsQueueWeight ). This is useful if you have libraries that need to opt-out of filling holds, or you would like to have particular libraries take the weight of filling holds instead of other libraries.

When the holds queue is generated, it first attempts to fill item-level requests first, then local holds with local items. That is, if there is a hold placed for pickup at Library A, and there is an available item at Library A to fill that hold, it will attempt to use that item in preference over items from other libraries, Thiseliminatesthe needs to transfer items between librariesunnecessarily, both improving the speed of filling the hold and keeping shipping costs down.

After filling all possible local holds, the system will then attempt to fill non-local holds in a fashion governed by the system preferences you have chosen.

I hope this explanation of the holds queue system has been both illuminating and helpful!