Invalid item barcodes
- Article Type: General
- Product: Aleph
- Product Version: 19.01
Description:
We have a report that sometimes when using a barcode scanner the barcode number is not written completely to the barcode field in the Item record in Aleph. The Item with the partial barcode is often updated before the mistake is detected. Eventually, however, the barcode is corrected to the complete 14 digit barcode. Staff have subsequently noted entries, which they believe to be erroneous, in the Item History and Circulation Log of some of these Items with "corrected" barcode numbers.
Accepting that the initial problem of the scanner not communicating the complete number to Aleph might be a problem with the scanner, is it possible that such a situation as the partial number being updated in the item and subsequently correct and thus moved to the z30h could cause users that may have been working with other items and not the particular item to be listed in the Item History?
Our item barcodes all begin "312620", so over time, at different workstations duplicative number strings may end up on Item history of different items. The Items would however be associated with different ADM records so we don't see how that would explain the problem.
Here is an example: staff say some of the "Cataloger"s listed don't make sense for the particular item:
From Item History of barcode 31262084869881. Note the partial numbers until the last entry.
H.Date H. Hour Cataloger Cause Seq. Barcode
02/04/2010 10:29 AM TMAJONES Other 70 31262
02/04/2010 10:30 AM TMAJONES Other 70 31262
02/04/2010 11:05 AM JOHSMITH Other 70 31262
02/04/2010 11:06 AM JOHSMITH Other 70 31262
02/04/2010 02:18 PM SCCBLEEK Other 70 31262
02/04/2010 02:18 PM SCCBLEEK Other 70 31262
02/04/2010 03:14 PM CINDYBL Barcode 70 31262
03/04/2010 03:49 PM HANGSB Other 70 31262084869881
Staff explained to me that different catalogers listed work at different branches such as Arts and Archicteture Library and the Storage facility, etc... and that it is highly unlikely that they were truly working with the same item.
I'm pretty puzzled about the situation and claim that the listed "catalogers" could not be working with the same item, so any insights on the problem described?
Resolution:
Though this SQL query gets no results:
SQL> select z30_rec_key from z30 where z30_barcode = '312620';
This query:
SQL> select z30h_rec_key from z30h where z30h_barcode = '312620';
retrieves 425 z30h records.
There are two situations. One is where a barcode is being assigned and the second is where an item is being searched for by barcode.
When "312620" is defectively assigned as the barcode, if the staff realize the problem, then we will see only one z30h
transaction with barcode = 312620 for that item. The following SQL shows that there are 22 such cases:
SQL> select substr (z30h_rec_key,1,15) from z30h where z30h_barcode = '312620' group by substr (z30h_rec_key,1,15) having count(*) = 1;
In the case where the barcode for the item remains as "312620", then staff can (defectively) search by barcode "312620" and perform an update to this item, resulting in additional z30h's for the item. The following SQL shows there are three such items:
SQL> select substr (z30h_rec_key,1,15), count(*) from z30h where z30h_barcode = '312620' group by substr (z30h_rec_key,1,15) having count(*) > 1;
SUBSTR(Z30H_REC_KEY,1,15) COUNT(*)
--------------------------------------------- ----------
000050361000020 51
001145931000820 324
001922775000360 38
Though you have some checksum_create ... lines in the ufu50 tab_checksum, those have to do only with *system-generated* item barcodes, which, of course, would never happen.
The entries which you would need to validate the item barcode are:
CSV-LOAN-ITEM-BARCODE checksum_valid_codabar
CSV-Z30-BARCODE checksum_valid_codabar
And, if you wanted validate patron barcodes:
CSV-LOAN-BOR-ID checksum_valid_codabar
I suggest that you try this on your test server and, if OK, put it on Prod. This should prevent the cases you have been seeing.
KB 8192-4664 discusses the fact that z30_barcode is not defined as unique and how to deal with that, but I'm thinking that the checksum check is a better approach -- since it prevents an invalid barcode from being entered to begin with.
Problem with "CSV-Z30-BARCODE checksum_valid_codabar" corrected by v20 rep_change 2578 so that CSV-Z30-BARCODE prevents update when barcode is invalid.
- Article last edited: 10/8/2013