[Koha-devel] itemBarcodeInputFilter or Client side JS?

[Joe Atzberger]

I agree, neither itemBarcodeInputFilter nor javascript are necessary.  Just
make the data loaded in Koha match the printed barcodes.

If you are worried about further generation of barcodes, then you might have
to insert an artificial max barcode value under the scheme you intend to
use, in order to provide a valid base value to increment.

--Joe

2010/11/2 Mike Hafen <mdhafen at tech.washk12.org>

> Why can't you correct the barcodes during the migration?
>
> If you are going from MS-SQL to MySQL you should be able to add another
> step in the middle to populate the barcode from the available information in
> the database.
>
> If you are going from MARC into Koha you should be able to populate the
> barcode once the data is in Koha and update the MARC and Zebra from there.
>
> Is it not possible to do one of these two?
>
>
> On Tue, Nov 2, 2010 at 7:31 AM, Koustubha Kale <kmkale at anantcorp.com>wrote:
>
>> Hi All,
>> We are implementing Koha at a college. They have a existing software
>> for library. They have barcoded all their collection of about 150000
>> books with this software.
>> The peculiar thing about the software and the barcode it generates is this
>> :
>>
>> The barcode related data stored in the database of the software
>> backend ( MS SQL) is the item's accession number & item type. The
>> actual barcode is not stored anywhere.
>> The printed barcodes are like this B011364, B011436, AR011346,
>> AR011436,AR018100,AR018103,AR018104,AR018105. ( Note the duplicate
>> accession numbers)
>> The first alphabets correspond to the itemtype code stored in a table.
>> The remaining numbers are the accession number stored in a table
>> without the leading zeros. This causes a problem while migrating this
>> data to Koha due to the missing leading zeros and arbitrary length of
>> the string and the fact that accession numbers are same for different
>> item types.
>> While generating a barcode for a new item the software takes the
>> itemtype and the accession number and prints out a barcode label in
>> the required format.
>> When the barcode is read back in the softwares circulation module by a
>> barcode reader, a asp script on the server separates the item type and
>> the accession number, strips the leading zeros from the numeric part
>> and does a search on the database by means of a join on the two
>> tables.
>>
>> As the college has stuck these barcode labels on all items, we have to
>> figure out how to emulate this functionality in Koha. (Post migration
>> we will generate & print barcodes from Koha; so we dont have to
>> emulate this logic in the barcode generation for Koha). I was thinking
>> we could store the barcode in Koha as itemtype-accession_number  (
>> without the leading zeros e.g. AR-18100) retrieved from the old
>> softwares database and when reading it in circulation in Koha we
>> convert the barcode from for example AR018100 to AR-18100.
>>
>> I see two options to acchieve this..
>> options :
>> 1) Create another filter for itemBarcodeInputFilter and modify the sub
>> barcodedecode  in C4/Circulation.pm
>> 2) write a client side javascript to do it.
>>
>> I would like to know is
>> 1) What is the better way to acchive this?
>> 2) Is there way for us to avoid a patch to Koha which will probably be
>> useless to anybody not migrating from this particular software. By
>> using opacuserjs perhaps..
>>
>>
>> Regards,
>> Koustubha Kale
>> Anant Corporation
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20101102/3f8fd5ac/attachment-0001.htm>