[Koha-devel] itemBarcodeInputFilter or Client side JS?

[Mike Hafen]

On Tue, Nov 2, 2010 at 10:18 PM, Koustubha Kale <kmkale at 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 at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20101103/3a5d4988/attachment.htm>