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