[Koha] Barcodes - various thoughts and questions

Archives and Collections Society paul.a at aandc.org
Thu Mar 17 06:09:17 NZDT 2011

Hi Chris,

Many thanks... comments inserted into [snipped for relevency] text below"

At 12:50 PM 3/16/2011 -0400, Chris Nighswonger wrote:
> > [snip] is either "not to be used", "deprecated" (e.g  hbyymmincr.pm which
> > looked promising but "This format is deprecated and SHOULD NOT BE USED") or
> > has been relegated to "dead files" e.g.
>I am the one who is responsible for the hbyymmincr format. In
>hindsight it was a bit redundant as the homebranch can be included on
>the label without having to include it in the barcode. But at the
>time, it seemed a good thought. A critical limitation to this format
>is that it is only good for 9999 barcodes per month. While in
>production this might be ok, if one was doing a initial load of > 9999
>items it would present a serious limitation on this format's

Yes, but we would modify it along the following lines (Note: we are not 
necessarily following the "standard" CLSI 14 digit format[1], although I 
think we would want to tend that way):

<branch> replaced by 4 digit category (think sub-branch as in "navy", 
"merchant marine", "oceanography"); then yymm; then increment based on 
*separate* increment per sub-branch. No initial load or subsequent batch 
would be > 9999.

Q: we would prefer to use alpha for "sub-branch, but fear this breaks 
industry standards. Yes? No? and can Code128 checksums be implemented?

>I'm sure we could fix up the code to raise the limit, but it probably
>is not worth the effort, imho.

If you wrote the original .pm, could we possibly prevail upon you to draft 
a mod|fix as described above? We'd do testing and fine tuning and give the 
results back to the community :)

>Have you had a look at the POD for C4::Barcodes?
>This includes some brief direction for adding other formats.

Yes, as you say - brief. We're also somewhat confused on the background and 
Koha use of $types hashref. Is there a more complete doc somewhere? (I 
can't find it.)

>The daemon has memory leak problems. You are well advised to run away
>from it as fast as possible.
>There should be no reason to totally reindex afaik. You can run
>rebuild_zebra.pl -b -a -z and just catch the new/modified records.

Yes - we implemented that very early in our process; set to every minute, 
overhead on incrementals seems very low. However, for batch jobs this has 
to be done for *every* write to koha.db, hence our 12,000 records taking 10 

Best regards - Paul

[1] 14 digits: 
1:ItemType  2-5:[Sub]Branch|Category  6-9:YYMM  10-13:Increment  14:Checksum

Archives and Collections (ACS) Society
205, Main Street, Picton, Ontario, K0K 2T0, Canada
Canadian Charitable Organization 88721 9921 RR0001
Dedicated to maritime conservation and education. 

More information about the Koha mailing list