Misadventures in Koha: Inventory

It’s nearly time to take up inventory again this year (exciting) and start picking at that old scab.  Our ILS is Koha, hosted by PTFS and it’s not without it’s issues when it comes to inventory.  We’re looking at a new inventory process this year that sort of circumvents some Koha functionality in order to hopefully solve some issues. But for now I wanted to share the regular issues we’ve faced when doing inventory in Koha using steps recommended by the Koha manual.

Below is an excerpt from an internal document I’ve been compiling as we’ve run into problems.  Many issues are due to limitations in Koha, while others are issues with our collection and/or past processes.  If nothing else, it illustrates how complicated a purportedly simple process can be.

Inventory Shortcomings & Issues:

Simple inventory

The Koha inventory works on a simple last-seen attribute – update the attribute and run a report based on it. This lets us know if an item is missing, but little else. The Koha inventory system doesn’t take into account shelving position so correcting misshelved books must be handled in a different process.

All or nothing

Also, because shelf position isn’t taken into account, a partial inventory cannot produce accurate information. If we inventory only some sections and those sections have books that are misshelved in other non-inventoried sections (not uncommon), those books will be mistakenly labeled as missing. We discovered this when we attempted an inventory of the new books section in the fall of 2012.

Withdrawn, missing, and lost items showing up

Running a report based on the last seen attribute doesn’t take into account unique statuses such as withdrawn that shouldn’t be included. This creates extra work in the reporting step from having to extract this information after running reports. A report excluding these types of records could potentially be created with some advanced SQL, but we haven’t been able to successfully create one.

These best-disregarded item types also affect shelf checking. Running the shelf checking report also includes withdrawn items. Checking the shelf for long missing items could potentially be fruitful, but checking for withdrawn items is a waste of time. Over time, as the amount of records that should be excluded grows, inventory reporting and shelf checking will become more lengthy and unwieldy. We may need to look into purging old records as a result.

Phantom Records

During the shelf checking process we discovered that many items had two copies in the catalog but only on the shelf. The two copies would not have copy indicators in the record or on the labels and often they would have sequential barcodes suggesting they were processed at the same time and that two copies were purchased at the same time. That seems unlikely. Also, the way the current cataloging workflow is in Koha, it would be easy to accidentally create two records for the same item. All this combined makes us suspect that in the past more than one item record was created for a single item. If so, the number of reported missing books is much higher than books actually missing. However, there is no way for us to verify that and we have to consider those items missing.

Auto Check-ins

Koha automatically checks in items whose barcodes are uploaded into the inventory module. This can be helpful for lost items, but otherwise is a problem. If items are checked out in-between scanning and uploading they are automatically checked in. This is a big problem that shouldn’t happen. We can feasibly re-check items out to their last person, but there is a possibility of mistakenly checking items out to the wrong person. Also, patrons are notified when they check items out so re-checking them out could confuse them.

We could limit inventory to just the summer, but we would lose the help of work studies and graduate assistants, who are very helpful in the process. We need to be sure that barcodes are uploaded a.s.a.p. after scanning so that the issue doesn’t happen again.

In the fall 2014 inventory we discovered that auto check-ins do not apply to books with a “lost” status. This happens despite the inventory upload report indicating that the book has been returned. This probably happens because the system initiates a checkin, but lost items require an override and fine decision to be checked in.

Old last seen not labeled missing

A few times in 2014 we encountered books that had a last seen date long before recent inventories but wasn’t labeled missing. This could be a problem if it is happening a substantial amount. We haven’t figured out why particular long-not-seen items aren’t labeled missing, but preliminarily it seems like it would be due to filtering missing items after initial reporting (e.g. removing ‘withdrawn’ and other items) and accidentally removing legitimate items mistakenly. We’ll need to take care during the next inventory reporting phase.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s