Hi Tasha, the classification source from $2 is used together with the callnumber from $o to create a machine sortable form of your callnumber that is stored in items.cn_sort and is used for example by the inventory tool. If you haven't set it and cn_sort should be empty in your items, it can also be fixed later by setting the classification source and running a script. Hope that helps, Katrin On 06.01.22 22:11, Bales (US), Tasha R wrote:

Thanks Katrin. I do have other rules that insert homebranch and holdingbranch. I never insert a classification source, and I hope that doesn't matter. It would be very sensible to just try importing one of the problem records on its own w/ and w/o modification template. I will give that a try.

Tasha Bales Enterprise Services http://isesi.web.boeing.com/

-----Original Message----- From: Koha [mailto:koha-bounces@lists.katipo.co.nz] On Behalf Of Katrin Fischer Sent: Thursday, January 6, 2022 03:38 To: koha@lists.katipo.co.nz Subject: [EXTERNAL] Re: [Koha] Item fields transposed during import?

EXT email: be mindful of links/attachments.

Hi Tasha,

I have never seen that, but wonder if you have other rules for rewriting the 952? Like homebranch and holdingbranch ($a and $b) appear to be missing as is $2 for the classification source.

I wonder if another rule might be causing the issue, as we can't see the end result of the modifications in the case of item data.

Maybe you could try if it works correctly creating the 952 for these 3 manually and importing them without the modification templates.

Hope this helps

Katrin

On 05.01.22 23:40, Bales (US), Tasha R wrote:

...

Good afternoon,

Has anyone ever experienced item fields getting transposed during MARC import when multiple items are attached to a bib? It seems like there is no way this could happen except for human error, but I've seen it before and can't figure out the error.

Today I noticed that some items have the wrong "Not for loan" status. I've provided details below. I don't expect anyone to solve this, but if you've seen this before and are able to share what the root cause was in your case, that would be very helpful. I'm sorry if I've asked this before. I distinctly remember typing up a similar question months ago, but I think I abandoned the draft. --Thank you.

I loaded this data: =952 \\$a1F-15E-25-10$t0$pTUST23257507$cTOSTO$4a$f-$1-$y2$d10-03-31<file:// /\\$a1F-15E-25-10$t0$pTUST23257507$cTOSTO$4a$f-$1-$y2$d10-03-31> (this record should NOT have a Not for Loan) =952 \\$a1F-15E-25-10$t3$pTOSTH23247507$cTOST$4a$fn$1-$y2$d14-08-05<file:// /\\$a1F-15E-25-10$t3$pTOSTH23247507$cTOST$4a$fn$1-$y2$d14-08-05> (this record should have Not for Loan "8") =952 \\$a1F-15E-25-10$t1$pTOSTH23257506$cTOST$4b$fn$1-$y55$d17-07-10<file:/ //\\$a1F-15E-25-10$t1$pTOSTH23257506$cTOST$4b$fn$1-$y55$d17-07-10> (this record should have Not for Loan "8")

I have these lines in my modification template: -- "Move field 952$f to 952$7 if 952$f matches RegEx m/[cdnw]/" -- "Update existing or add new field 952$7 with value 8 if 952$7 matches n"

In other words, I move 952$f to $7 and if its value is "n", I change "n" to "8".

My record modification log matches the records and shows that two records have their Not for Loan values "swapped". I've included only the problem records below:

item $VAR1 = { 'withdrawn' => 0, 'biblioitemnumber' => '878655', 'restricted' => undef, 'coded_location_qualifier' => undef, 'itemlost_on' => undef, 'notforloan' => '8', 'replacementpricedate' => '2021-12-11', 'itemnumber' => '2309607', 'ccode' => undef, 'itemnotes' => undef, 'location' => 'TOSTO', 'itemcallnumber' => '1F-15E-25-10', 'stack' => undef, 'itemlost' => 0, 'barcode' => 'TUST23257507'...

item $VAR1 = { 'withdrawn' => 0, 'biblioitemnumber' => '878655', 'restricted' => undef, 'coded_location_qualifier' => undef, 'itemlost_on' => undef, 'notforloan' => 0, 'replacementpricedate' => '2021-12-11', 'itemnumber' => '2309609', 'ccode' => undef, 'itemnotes' => undef, 'location' => 'TOST', 'itemcallnumber' => '1F-15E-25-10', 'stack' => undef, 'itemlost' => 0, 'barcode' => 'TOSTH23257506'...

FYI, the source data is from Millennium. I've verified that I'm not loading any subfields or authorized values that aren't defined in Koha. I did notice that the first record has a copy number of "0", and this gets loaded as a blank in Koha.

Tasha Bales Enterprise Services http://isesi.web.boeing.com/

_______________________________________________

Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

---

Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha