Bug 20070 - autoBarcode broken for hbyymmincr if branchcode is numeric
Summary: autoBarcode broken for hbyymmincr if branchcode is numeric
Status: CLOSED WONTFIX
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: 17.05
Hardware: All All
: P3 normal (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-23 09:36 UTC by mustaqeem
Modified: 2018-12-03 20:04 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mustaqeem 2018-01-23 09:36:04 UTC
Hi Bugzilla,

Today I just found an error when enabling autoBarcode (generate in the form <branchcode>yymm0001.) in System Preferences. the problem is the barcode number is not auto increase for the next item added. I realize the problem because our branchcode is numeric (e.g 0001, 0002, 0003, LIB1). The barcode number is increase if code used is alphabet only (e.g LIB, LIBI, LIBII, LIBIII). Please help regarding this matter.

Our Koha version 17.05.

Step to regenerate the problem:

1) Enable autoBarcode (generate in the form <branchcode>yymm0001.) in Cataloging Preferences.

2) Add New Item (Appear great for the first item)

3) Add another New Item (this is where barcode number not auto increase).

Thank you!!
Comment 1 Liz Rea 2018-01-26 01:24:12 UTC
Hi, 

I'm not able to reproduce this problem in current Master. 

Cheers,
Liz
Comment 2 mustaqeem 2018-01-26 01:51:20 UTC
I try use Koha demo(https://koha-community.org/demo/) by ByWater Solution also happen like that.

If the code is numeric or alphanumeric, it will not increase. (e.g the first barcode is 000118010001 or LIB118010001, the number will be same for other items.)

The other thing we found is if we have few branches (e.g ABC, DEF), barcode number will be like ABC18010001, ABC18010002, DEF18010003, DEF18010004, ABC18010005 (is it ok for DEF branch to start the barcode like that or it is suppose to start at 0001 for each branch?)

Thank you.
Comment 3 Jonathan Druart 2018-01-30 19:57:52 UTC
Confirmed, it certainly comes from that line:

108     $head =~ s/\d{4}$//; # else strip the old yymm
in C4::Barcodes::hbyymmincr::process_head

This value of autoBarcode is deprecated and should not be used.

Take a look at the notice in the bottom of the file:

"""
This format is deprecated and SHOULD NOT BE USED.

It is fairly clear the originator of the format did not intend to accommodate
multiple branch libraries, given that the format caps the available namespace to
10,000 barcodes per year TOTAL...

Also, the question of what to do with an item that changes branch is unsettled...
Nothing prevents the barcode from working fine, but it will look out of place
with the old branchcode in it.  Rebarcoding a single item is trivial, but if you
consider the scenario of branches being consolidated, it is an unnecessary.
burden to force the rebarcoding of thousands of items, especially when the format
will limit you to under 10,000 on the year!

The main purpose of the format seems to be to get the branch code into the barcode.
This is wholly unnecessary, since the barcodes can be printed with the branchcode
directly on it, without it being part of the barcode itself...

The API for this module should exist almost exclusively through C4::Barcodes...
One novel aspect of this format is the fact that the barcode is tied to a branch...
"""