Hi Dave,

DefaultClassificationSource to lcc, as well as the itemcallnumber to map to 050a. And I'm using the default framework in Koha 3.20.02.

Do you mean the system preference itemcallnumber? That would explain what you see: The pref will not change the mapping, but will help you when cataloguing by making a suggestion. So every time you edit the item and it notices that the callnumber field is empty, it pulls a suggestion from 050a for you - so when you save, 952$o gets filled and then it works as it should. I wonder why putting your callnumber in 952$o during import didn't work - maybe you can retest that or share an example with us to see what was going wrong there. Hope this helps, Katrin Am 01.10.2015 um 19:55 schrieb dc12345:

Hi everyone,

I've recently set up a web server running Koha for a small library at a research institute, and I'm having issues with the OPAC in displaying the itemcallnumber field. I originally converted my holdings from an Excel file to .mrc format with MarcEdit and everything else imported perfectly. I am using LCC for my call numbers rather than Dewey, and I changed the DefaultClassificationSource to lcc, as well as the itemcallnumber to map to 050a. And I'm using the default framework in Koha 3.20.02.

The weird thing is, when I go to edit an individual record as an admin, the full call number is there in the 952o subfield, just as it should be. It just comes out blank in the OPAC. If I then save the entry without editing it, it fixes the issue. I would just edit each book then, but I have 5144 total books to edit, so there's got to be another way to fix it. Here's an example of a MARC record as I originally imported it:

=LDR 00303nam a2200109Ia 45e0 =008 150928s9999\\\\xx\\\\\\\\\\\\000\0\und\d =050 \\$aF1435.1 .C46 =100 \\$aRobin, Cynthia =245 \\$aEveryday Life Matters: Maya Farmers at Chan =260 \\$bUniversity Press of Florida =260 \\$c2013 =952 \\$aMARI$bMARI$p03403$yBKS

I've also tried adding the 952$o subfield before I import it, but I get the same result. By the way, I know my 050 field should be split as 050$aF1435.1$b.C46, but I'm an archaeologist and not a librarian (dammit Jim!) and didn't realize this when I started this process. But I've also imported single books this way and played around with formatting a lot, with the same results.

Any help would be greatly appreciated! Other than this hiccup, which is surely my fault, I've been very impressed with Koha!

Thanks! Dave

-- View this message in context: http://koha.1045719.n5.nabble.com/952-o-subfield-not-displayed-in-OPAC-tp585... Sent from the Koha-general mailing list archive at Nabble.com. _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha

Hi Dave, We manually add 952 tag and necessary sub-fields in the MARC records and copy the call number from the relevant tags of MARC into 952$o field. 952 tag contains holdings information and OPAC displays the holdings information from 952 tags, not from the MARC tags. So, add 5144 952 tags into your MARC records and copy the call number from 050 to 952$o field using MarcEdit. I hope this helps! On 10/1/15, dc12345 <davidchat815@gmail.com> wrote:

Hi everyone,

I've recently set up a web server running Koha for a small library at a research institute, and I'm having issues with the OPAC in displaying the itemcallnumber field. I originally converted my holdings from an Excel file to .mrc format with MarcEdit and everything else imported perfectly. I am using LCC for my call numbers rather than Dewey, and I changed the DefaultClassificationSource to lcc, as well as the itemcallnumber to map to 050a. And I'm using the default framework in Koha 3.20.02.

The weird thing is, when I go to edit an individual record as an admin, the full call number is there in the 952o subfield, just as it should be. It just comes out blank in the OPAC. If I then save the entry without editing it, it fixes the issue. I would just edit each book then, but I have 5144 total books to edit, so there's got to be another way to fix it. Here's an example of a MARC record as I originally imported it:

=LDR 00303nam a2200109Ia 45e0 =008 150928s9999\\\\xx\\\\\\\\\\\\000\0\und\d =050 \\$aF1435.1 .C46 =100 \\$aRobin, Cynthia =245 \\$aEveryday Life Matters: Maya Farmers at Chan =260 \\$bUniversity Press of Florida =260 \\$c2013 =952 \\$aMARI$bMARI$p03403$yBKS

I've also tried adding the 952$o subfield before I import it, but I get the same result. By the way, I know my 050 field should be split as 050$aF1435.1$b.C46, but I'm an archaeologist and not a librarian (dammit Jim!) and didn't realize this when I started this process. But I've also imported single books this way and played around with formatting a lot, with the same results.

Any help would be greatly appreciated! Other than this hiccup, which is surely my fault, I've been very impressed with Koha!

Thanks! Dave

-- View this message in context: http://koha.1045719.n5.nabble.com/952-o-subfield-not-displayed-in-OPAC-tp585... Sent from the Koha-general mailing list archive at Nabble.com. _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha

-- Dibyendra Hyoju