[Koha-bugs] [Bug 13937] Add a 'primary status' field for items

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13937

--- Comment #7 from Heather Braum <hbraum at nekls.org> ---
I'm not quite following the comments being made here -- forgive my ignorance on
how MARC works with the Koha items table. 

TLDR version: Regardless of how this is developed and coded, will the final
data field result be mappable to a MARC 952 subfield within Koha? It also is a
status that needs to be constantly updated, in order for it to be used
successfully by an external system.

Long version: 

Background: Right now the not for loan, the lost, the damaged, and the
withdrawn fields are separate items table subfields and mapped to the 952 field
within MARC. Additionally, the in transit/on hold, waiting for pickup status of
an item is stored elsewhere. 

NEKLS, SEKLS, and CKLS would like to develop an additional Koha field that is
then possible to be mapped to a MARC 952 subfield so external systems are able
to tell if an item is TRULY available for ILL (in our specific case); I'm sure
there are other uses we haven't thought about. This new field would be able to
aggregate the separate onloan, notforloan, withdrawn, lost, and damaged item
fields, as well as pull in the separate data from the branchtransfers and
reserves tables that indicate if an item is in transit and/or on hold waiting
for pickup; it would need to be updated automatically -- not only on exports or
when scripts are run.

When we first looked into this last fall, we discovered that other ILSes
typically have one MARC subfield where availability data is stored. Koha
currently has the data that determines an item's availability stored all over
the place. Right now, this external system profiles our systems using the 952$q
field (items.onloan). That field isn't enough, obviously, to determine true
availability; items that are on hold, in transit, lost, damaged, regularly
appear on ILL request lists. Years ago, we asked about how to fix this problem,
but were told a major rewrite of Koha would have to happen. Obviously, we've
lived with the situation since. But Jason Robb at SEKLS started asking
questions last fall, and we were told that this problem is possible to be fixed
now.  

It was originally explained to us that this development could have greater
impact on Koha in other places, too, but Kyle can explain that part much
better. 

As long as we can map the outcome of where ever this data combining all of
these statuses is stored to a MARC 952 item field, I don't care how it's
developed :) But if the end result is that this new field is not going to be
constantly updated and it can't be mapped to a MARC subfield, we may have to
abandon this development.

-- 
You are receiving this mail because:
You are watching all bug changes.