The items table in 3.2 has a new field stocknumber (varchar 32).
In UNIMARC this field is mapped to 995$j called Inventory number:
('995', 'j', 'Inventory number', 'Inventory number', 0, 0, 'items.stocknumber ', 10, '', '', '', 0, 0, '', '', '', NULL),
In Germany we also use inventory numbers/accession numbers. Those are attached on item level, not on biblio level and very important to the library. In the past I have used a mapping from 952$i to more_subfields_xml.
This made it hard to query the inventory number and it was not displayed in a lot of places in staff and opac.
I would like to add a permanent mapping from 952$i to items.stocknumber in the bibliographic frameworks and add a search index for it to zebra.
This would also help to make sure the field is not used for another new feature.
Please tell, if you think this is a bad idea!
I favor your idea! We "misused" copynumber (952t) on item level for inventory number. This makes it show up in several opac/intranet places (detail view etc.)
To make the switch, we would like to see the new field show up there too as well as searching for it in zebra, etc.
thx for your comment! I think we should have a second bug for the display issues? Once we have a save place to store the information we can work from that.
I also had requests to make the inventory number show up on OPAC and make it easier to search for it.
Checking with some of our data I see that the items.stocknumber field is unique. This is good, because in theory inventory numbers should be unique. In practice you will often get old data with duplicate numbers.
Marcel: Do you think this is a problem?
(In reply to comment #3)
> Checking with some of our data I see that the items.stocknumber field is
> unique. This is good, because in theory inventory numbers should be unique. In
> practice you will often get old data with duplicate numbers.
> Marcel: Do you think this is a problem?
No, it should not be a problem for us. Would favor keeping it unique..
Yes, I favor that too. But already ran into data that needs to be cleaned before I can move it out of the xml and into the new field.
Is someone opposed to map 952$i to items.stocknumber in the frameworks by default? I would like to start working on this.
Created attachment 3512 [details] [review]
Patch adding 952$i and mapping to items.stocknumber to frameworks
Created attachment 3517 [details] [review]
Adding new index stocknumber on field 952$i
(In reply to comment #7)
> Created attachment 3512 [details] [review]
> Patch adding 952$i and mapping to items.stocknumber to frameworks
Tested (with install). Works OK. Signed off. Will test the other one too.
(In reply to comment #8)
> Created attachment 3517 [details] [review]
> Adding new index stocknumber on field 952$i
Katrin: Could you check on the following?
In bib1.att 1028 is already conform LOC standard: Stock-number.
Should we use that one instead of adding 1062? You could also add a line:
Note too that 1062 is in the reserved LOC range. You could better pick a number in the 8XXX range as has been done for item attributes already.
Furthermore, I already signed the first patch. But this second patch makes me wonder if we not better mention it: inventory number? That would also make the choice for a new number 8XXX more acceptable.
I will send a mail to the dev list for the name issue.
After that I would be happy to sign a revised patch.
I think we concluded that 1028 was reserved for the supplier's stock number, rather than the local number.
(In reply to comment #11)
> I think we concluded that 1028 was reserved for the supplier's stock number,
> rather than the local number.
OK. Zeno Tajoli was the only one responding to the mail and favored inventory number too. I would say: let's call it inventory number instead of stocknumber and pick a 8000 number for it in bib1.att. And Katrin?
I don't completely understand.
What do you want to rename? The index or the field description in the frameworks? I agree that inventory number has a better sound to me - the German word is Inventarnummer. I decided to name it after the field in items, because I thought a new name might cause confusion. Renaming in the frameworks in fine for me though.
But I don't understand your concerns about 1062
Document acquisition number assigned by the system.
Which is exactly what a inventory number is.
Why should we choose another attribute?
Created attachment 3600 [details] [review]
Added inv: as alias for index
Created attachment 3601 [details] [review]
Alternative to 0001: Description changed to 'Inventory number' instead of 'Stocknumber'
Tested: Added inv: as alias for index
Tested: Alternative to 0001: Description changed to 'Inventory number' instead of 'Stocknumber' (Tested sql files on English)
Signed off both patches.
Will add another comment about a related error, but not originating from these patches.
Stumbled while testing this patch on another error in C4/Items.
If I entered a duplicate inventory number, the item was not saved but the user is not warned. This error comes from an existing bug [read: not existing code] in C4/Items. Only the logfile tells you what happened.
Created bug 6041 for this.
[Mon Apr 04 10:05:12 2011] [error] [client 184.108.40.206] [Mon Apr 4 10:05:12 2011] additem.pl: DBD::mysql::st execute failed: Duplicate entry 'invtest' for key 3 at /usr/share/koha/testclone/C4/Items.pm line 2157., referer: http://libdevelop.rijksmuseum.nl:8009/cgi-bin/koha/cataloguing/additem.pl?op=edititem&biblionumber=144200&itemnumber=147307
[Mon Apr 04 10:05:12 2011] [error] [client 220.127.116.11] [Mon Apr 4 10:05:12 2011] additem.pl: ERROR in _koha_modify_item UPDATE items SET homebranch=?,replacementprice=?,restricted=?,items.cn_sort=?,wthdrawn=?,more_subfields_xml=?,booksellerid=?,holdingbranch=?,damaged=?,stocknumber=?,notforloan=?,replacementpricedate=?,itemnumber=?,ccode=?,itemnotes=?,location=?,itemcallnumber=?,stack=?,barcode=?,itemlost=?,uri=?,items.cn_source=?,materials=?,enumchron=?,dateaccessioned=?,copynumber=?,permanent_location=?,price=?,paidfor=?,itype=? WHERE itemnumber=?Duplicate entry 'invtest' for key 3 at /usr/share/koha/testclone/C4/Items.pm line 2160., referer: http://libdevelop.rijksmuseum.nl:8009/cgi-bin/koha/cataloguing/additem.pl?op=edititem&biblionumber=144200&itemnumber=147307
The first patch applied, the second one fails
error: patch failed: installer/data/mysql/pl-PL/marcflavour/marc21/optional/marc21_fastadd_framework.sql:118
error: installer/data/mysql/pl-PL/marcflavour/marc21/optional/marc21_fastadd_framework.sql: patch does not apply
error: patch failed: installer/data/mysql/pl-PL/marcflavour/marc21/optional/marc21_simple_bib_frameworks.sql:180
error: installer/data/mysql/pl-PL/marcflavour/marc21/optional/marc21_simple_bib_frameworks.sql: patch does not apply
Did you hand edit your patch?
It does not apply to blobs recorded in its index.
Cannot fall back to three-way merge.
Patch failed at 0001 Bug 5839: Add mapping for items.stocknumber to MARC21
[marcel@RKM004 testclone]$ git reset --hard
HEAD is now at e1a0b4a bug 4865: added dependency for using memcached for sessions
[marcel@RKM004 testclone]$ git am -3 ../5839a-sign.patch
Applying: Bug 5839: Add index stocknumber on 952$i
[marcel@RKM004 testclone]$ git am -3 ../5839b-sign.patch
Applying: Bug 5839: Add mapping for items.stocknumber to MARC21
The patch attached to this bug applies fine, the signed offone sent to the list doesn't. Applying the original one.
Pushed, please test
Comment on attachment 3512 [details] [review]
Patch adding 952$i and mapping to items.stocknumber to frameworks
Alternative was pushed.
Created attachment 3614 [details] [review]
Follow up patch for Norway file
Norwegian installer file updated
Resetting status to Signed for tiny follow up fix.
Follow up pushed
This doesn't seem to apply to upgrades, and it probably should.
You mean the updates to the framework? I am not sure there is a save to do this. A library might have used the field for local purposes. Adding an index and a mapping for newly installed libraries doesn't hurt them. But updating the framework and changing the mapping in the items table might cause trouble.
Fair enough. I'm going to close the bug, then, since it works on new installations.