Shouldn't this include a new database revision in updatedatabase.pl? Also, there is a stray conflict marker in kohastructure.sql.

This code came from Ian Wall's via PTFS/LL. He suggested it is flawed in its design and I am looking for input on fixing it up and getting it into Koha proper.

Origin:

I believe this code came from PTFS/LL; two ByWater partners who jumped ship brought with them as a requirement for continued operations.  The maintenance of this code fell to me when I was with ByWater, and I've subsequently rebased, enhanced and rewired it to keep it more or less functional for those partners.


Purpose of this development:

To allow multiple libraries with conflicting barcodes to come together into the same Koha install without having to rebarcode their materials.  Typically, in the US, most libraries with conflicting barcodes have too short a number (5-8 digits), where the most common standard is 14 digits, typically following this form:

{2|3}{prefix}{zero-padded number}{check digit}

This development just glues on the prefix values (first two there, 2 is for patron barcodes and 3 is for items) to the existing number, and zero-pads out to a specified length.  This is a cludge at this particular format, but it does make barcodes unique in the Koha database.


Fundamental problem:

Right now, barcode lookup is a unique process.   That is, looking for a barcode is a 0 or 1 result affair.  If you're scanning a short barcode in an environment where multiple libraries have that number, there is NO WAY TO KNOW which item you mean.  You need to return multiple results, and let the user choose.

Example:  two libraries, A (with prefix 1111) and B (with prefix 2222), have an item barcoded '12345'. That's the number on the book itself, and that's what comes out of the barcode scanner when scanned.  In the Koha database, however, the two barcodes are:

31111000012345 and
32222000012345

Library A sends it's book over to Library B to fill a hold.  Library B now has two books at the desk that scan to the exact same barcode value.  Which is which?


Why this code is insufficient:

This development makes the assumption that the correct prefix to affix to short barcodes is that of the CURRENTLY LOGGED IN BRANCH.  That works for libraries that don't share back and forth, but if the above described situation ever arose, this development would fail to properly recognize the material.


Ameliorations:

To be fair, this IS running in production on two large consortia in the US.  These library networks have had plenty of problems with this code, most of which are now fixed and integrated in the attached patch.  But their use case is just one of many possible.

I see, so would adding the ability to temporarily switch 'branches' for only the barcode prefix being used help? That way, if LibraryA recieves an item from LibraryB, the librarian can say 'run this book though the system as a LibraryB item with LibraryB's prefixing rules'?

Having this toggle between branches would be a huge pain, since so many different workflows and contexts involve barcode scanning.  It would also place the burden on the librarian to know a) this book is from another library and b) there could be a conflict.

What needs to happen, I think, is a kind of "did you mean" screen for when barcode scans come back with more than one result (or perhaps even in no results cases...).  This would include the full barcode, with the scanned value highlighted some how (to explain why this is in the list), the branch, and the title/author/callnumber (some kind of distinguishing feature).  Chances are, the two conflicting barcodes are not going to belong to the same title, unless we're in an even more convoluted situation than originally imagined.

What I'd like to see, though, is more than just item and patron barcode prefixes and lengths, a full Barcode Namespace setup, where multiple parts can be identified.  This way, whatever barcoding schema is in use, be it prefixed, length controlled, check digited, or otherwise delineated, Koha could handle it.

Ian,
Is this one of those things that can be improved once it's in, or will it have to be redone before inclusion?

That is, do you feel that this feature is "good enough" even though it has some shortcomings, or are the shortcomings extremely dire?

I personally feel that it is "good enough" as long as there are caveats noted for this feature noted in the manual. It seems like this feature won't be used by many libraries, but is critical for those who need it. It would also be great for libraries that have been running separate ILSs and are attempting to unify their catalogs. It would allow those libraries to get up and running right away while giving them a chance to re-barcode over time.

As Ian mentioned, this feature is being used by multiple consortia right now without any problems, because they know the limitations of the feature.

I agree with Ian that it would be great to add and extend this feature, but I don't see it as a requirement to its inclusion in the code base.

This patch has been tested in the field for several consortia, yes, and is more or less functional for their use case.  My concern is that the way this code implements the changes, it will seriously break things for anyone NOT using it.  Database tables are altered; core circulation functions are modified.

I'd like at least two sign-offs that non-prefixing library systems can continue to operated unaffected by the addition of this code.  Tests should include all 8 combinations of the following factors:

1 branch or multiple
Single Branch Mode on/off
IndepedentBranches on/off

Testing with the existing barcode filters should also be done; for example, can a Katipo-style check digit still work with this feature added?  What about Follett-style T-prefixes?

Created attachment 10720 [details] [review]
Barcode Prefixes

Allows for specification, on a per branch basis, of barcode prefixes for both items and patrons.
Barcodes must come to a specific length (as set in system preferences), and barcodes shorter than
this length will be auto-prefixed with the currently-logged-in branch's prefix.

Currently supports:
Circulation (checkout, return)
Patron lookup
Item creation
Patron creation
Bulk patron import
Inventory
Offline Circ
ILSDI

Created attachment 10721 [details] [review]
Barcode Prefixes - Followup - Add ability to use barcode prefixes with batch item modification/deletion tool

Created attachment 13249 [details] [review]
Barcode Prefixes [ version for 3.8.x ]

Allows for specification, on a per branch basis, of barcode prefixes for both items and patrons.
Barcodes must come to a specific length (as set in system preferences), and barcodes shorter than
this length will be auto-prefixed with the currently-logged-in branch's prefix.

Currently supports:
Circulation (checkout, return)
Patron lookup
Item creation
Patron creation
Bulk patron import
Inventory
Offline Circ
ILSDI
batch item modification/deletion tool