[Koha] [EXTERNAL] Re: Item fields transposed during import?

[Katrin Fischer]

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 at lists.katipo.co.nz] On Behalf Of Katrin Fischer
> Sent: Thursday, January 6, 2022 03:38
> To: koha at 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 at lists.katipo.co.nz
>> Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
> _______________________________________________
>
> Koha mailing list  http://koha-community.org Koha at lists.katipo.co.nz
> Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha