Bug 5839 - Add mapping for items.stocknumber to MARC21
Summary: Add mapping for items.stocknumber to MARC21
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: MARC Bibliographic data support (show other bugs)
Version: master
Hardware: All All
: PATCH-Sent (DO NOT USE) enhancement (vote)
Assignee: Katrin Fischer
QA Contact: Bugs List
URL:
Keywords:
Depends on: 5860
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-07 09:20 UTC by Katrin Fischer
Modified: 2012-10-25 23:10 UTC (History)
4 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Who signed the patch off:
Text to go in the release notes:
Version(s) released in:


Attachments
Patch adding 952$i and mapping to items.stocknumber to frameworks (57.34 KB, patch)
2011-03-29 21:53 UTC, Katrin Fischer
Details | Diff | Splinter Review
Adding new index stocknumber on field 952$i (2.45 KB, patch)
2011-03-30 06:38 UTC, Katrin Fischer
Details | Diff | Splinter Review
Added inv: as alias for index (2.51 KB, patch)
2011-04-01 05:29 UTC, Katrin Fischer
Details | Diff | Splinter Review
Alternative to 0001: Description changed to 'Inventory number' instead of 'Stocknumber' (57.76 KB, patch)
2011-04-01 05:45 UTC, Katrin Fischer
Details | Diff | Splinter Review
Follow up patch for Norway file (1.87 KB, patch)
2011-04-04 10:40 UTC, Marcel de Rooy
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Katrin Fischer 2011-03-07 09:20:51 UTC
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!
Comment 1 Marcel de Rooy 2011-03-07 09:49:11 UTC
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.
Comment 2 Katrin Fischer 2011-03-07 09:53:19 UTC
Hi Marcel, 

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.
Comment 3 Katrin Fischer 2011-03-07 11:17:22 UTC
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?
Comment 4 Marcel de Rooy 2011-03-07 11:20:26 UTC
(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..
Comment 5 Katrin Fischer 2011-03-07 11:27:30 UTC
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.
Comment 6 Katrin Fischer 2011-03-25 11:41:07 UTC
Is someone opposed to map 952$i to items.stocknumber in the frameworks by default? I would like to start working on this.
Comment 7 Katrin Fischer 2011-03-29 21:53:14 UTC Comment hidden (obsolete)
Comment 8 Katrin Fischer 2011-03-30 06:38:48 UTC Comment hidden (obsolete)
Comment 9 Marcel de Rooy 2011-03-30 13:04:07 UTC
(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.
Comment 10 Marcel de Rooy 2011-03-30 13:47:37 UTC
(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:
stocknumber Stock-number

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.
Comment 11 Jared Camins-Esakov 2011-03-30 15:22:58 UTC
I think we concluded that 1028 was reserved for the supplier's stock number, rather than the local number.
Comment 12 Marcel de Rooy 2011-03-31 06:58:08 UTC
(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?
Comment 13 Katrin Fischer 2011-03-31 07:49:45 UTC
Hi Marcel, 

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

http://www.loc.gov/z3950/agency/defns/bib1.html
Number-local-acquisition 	
1062 	
Document acquisition number assigned by the system.

Which is exactly what a inventory number is. 
Why should we choose another attribute?
Comment 14 Katrin Fischer 2011-04-01 05:29:11 UTC
Created attachment 3600 [details] [review]
Added inv: as alias for index
Comment 15 Katrin Fischer 2011-04-01 05:45:32 UTC
Created attachment 3601 [details] [review]
Alternative to 0001: Description changed to 'Inventory number' instead of 'Stocknumber'
Comment 16 Marcel de Rooy 2011-04-04 08:41:54 UTC
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.
Comment 17 Marcel de Rooy 2011-04-04 08:46:35 UTC
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 192.87.126.61] [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 192.87.126.61] [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
Comment 18 Chris Cormack 2011-04-04 08:55:00 UTC
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
Comment 19 Marcel de Rooy 2011-04-04 08:57:47 UTC
[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
Comment 20 Chris Cormack 2011-04-04 09:28:26 UTC
The patch attached to this bug applies fine, the signed offone sent to the list doesn't. Applying the original one.
Comment 21 Chris Cormack 2011-04-04 09:31:45 UTC
Pushed, please test
Comment 22 Marcel de Rooy 2011-04-04 10:39:28 UTC
Comment on attachment 3512 [details] [review]
Patch adding 952$i and mapping to items.stocknumber to frameworks

Alternative was pushed.
Comment 23 Marcel de Rooy 2011-04-04 10:40:32 UTC
Created attachment 3614 [details] [review]
Follow up patch for Norway file

Norwegian installer file updated
Comment 24 Marcel de Rooy 2011-04-04 11:02:15 UTC
Resetting status to Signed for tiny follow up fix.
Comment 25 Chris Cormack 2011-04-05 02:58:41 UTC
Follow up pushed
Comment 26 Jared Camins-Esakov 2011-07-14 15:35:17 UTC
This doesn't seem to apply to upgrades, and it probably should.
Comment 27 Katrin Fischer 2011-07-14 15:39:12 UTC
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.
Comment 28 Jared Camins-Esakov 2011-07-14 15:40:34 UTC
Fair enough. I'm going to close the bug, then, since it works on new installations.