[Koha] Barcodes - various thoughts and questions

[Archives and Collections Society]

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
>usefulness.

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 :)

>[snip]
>Have you had a look at the POD for C4::Barcodes?
>
>http://perldoc.koha-community.org/v3.02.05/C4/Barcodes.html
>
>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.)

>[snip]
>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 
hours.

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
http://www.AandC.org
Canadian Charitable Organization 88721 9921 RR0001
Dedicated to maritime conservation and education.