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 Contact Details : Address : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), Maharashtra, India, Pin : 400601. TeleFax : +91-22-21720108, +91-22-21720109 Mobile : +919820715876 Website : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2
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@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
Contact Details : Address : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), Maharashtra, India, Pin : 400601. TeleFax : +91-22-21720108, +91-22-21720109 Mobile : +919820715876 Website : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
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@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@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
2010/11/2 Mike Hafen <mdhafen@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?
I think they are asking for the proper way of modifying the script that generates barcodes in koha for NEW items, preserving the semantics of the current system they're using. To+
On Tue, Nov 2, 2010 at 7:31 AM, Koustubha Kale <kmkale@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
Contact Details : Address : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), Maharashtra, India, Pin : 400601. TeleFax : +91-22-21720108, +91-22-21720109 Mobile : +919820715876 Website : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Is it not possible to do one of these two?
I think they are asking for the proper way of modifying the script that generates barcodes in koha for NEW items, preserving the semantics of the current system they're using.
I don't think so, based on: Post migration we will generate & print barcodes from Koha; so we dont have
to emulate this logic in the barcode generation for Koha
Though I did mention they may want to seed a valid new max value for their intended barcode scheme once everything is loaded. I.E., their values are not numerical, so they can't use incremental, and they'll need to use something else.
just make the data loaded in Koha match the printed barcodes.
I would just love to be able to do that. But Its not possible to exactly match barcodes in Koha with printed barcodes because : 1) No report from the old software has barcodes in it. ( the barcode printing utility they have provided is a standalone application) 2) The accession number stored in the MS SQL db has no leading zeros. 3) The printed barcode length is arbitary so I cant predict the number of leading zeros.
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.
The old software has no notion of MARC.. Regards, Koustubha Kale Anant Corporation Contact Details : Address : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), Maharashtra, India, Pin : 400601. TeleFax : +91-22-21720108, +91-22-21720109 Mobile : +919820715876 Website : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2
On Tue, Nov 2, 2010 at 10:18 PM, Koustubha Kale <kmkale@anantcorp.com>wrote:
just make the data loaded in Koha match the printed barcodes.
I would just love to be able to do that.
But Its not possible to exactly match barcodes in Koha with printed barcodes because :
1) No report from the old software has barcodes in it. ( the barcode printing utility they have provided is a standalone application) 2) The accession number stored in the MS SQL db has no leading zeros. 3) The printed barcode length is arbitary so I cant predict the number of leading zeros.
So there is no way to predict what the printed barcode will be. That does complicate things.
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.
The old software has no notion of MARC..
That may be a good thing in this case. It will give you some time to play with barcodes before committing them to MARC in the database. I think the stand-alone barcode application must have some algorithm for generating the barcodes. Given sufficient time that algorithm could be understood and SQL created to match it. The question then is do you have enough time to understand the algorithm. Not having a barcode report complicates this too. It means you have no easy access to the barcodes. Without easy access to the result of the algorithm it will take much more time to figure out the algorithm. Unless there is someone with inside knowledge. Perhaps you can contact the vendor of the barcode printing application, or a librarian is familiar enough with the barcodes to help you quickly figure out the algorithm? If that fails then you have to do something else to fix the problem. At first glance I would say the way to go is to amend the barcodeInputFilter. It seems the variable of the barcode is the number of zeros, the rest of the information is present. Perhaps you could create barcodes during the migration to approximate the the printed barcode, using the most number of zeros. Then have the barcodeInputFilter take the scanned barcode and try to find it, adding zeros until it does. Once it's found the barcodeInputFilter can from there take some action: put the missed and found barcodes in a table for later reporting, email a dev or librarian to update the item's barcode to match the printed one, or even modify the item itself with the correct barcode. The drawback of this method is you will have to support that code for some time, because it will take a lot of time before every barcode in the library has been scanned. Either way it is a lot of work. Good luck.
Regards, Koustubha Kale Anant Corporation
Contact Details : Address : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), Maharashtra, India, Pin : 400601. TeleFax : +91-22-21720108, +91-22-21720109 Mobile : +919820715876 Website : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
participants (4)
-
Joe Atzberger -
Koustubha Kale -
Mike Hafen -
Tomas Cohen Arazi