• Article Type: General
• Product: Aleph
• Product Version: 16.02

Description:
I'm going through the overdue file for old ones that never got prices. I found 80081 from NDJ. Everything looks correct until you get to circ. It isn't on our patron's loan record, but it is listed in the ILL. But the due date there is listed as blanks.
Is that because it got pushed into overdue? I see the same thing with 82474 on the same patron's record

Observations from another staff member:
when I do the item check - on ILL-80081 and ILL-82474, I can look at History and see that there is an entry and it has
SCR20080128 and SCR20080121

if I look at other overdue ILL's for patrons, there is no history entry
so either someone already did a circ return and nothing with ILL OR patron scrubbing is screwing up ILL's

Observations/portions of logs:
I was able to track some of the transactions from the logs (first shows 80081 going overdue)....

Info from job execution log for p_cir_32
start ABC50,abc-cir32-scrub-0100,030,Y,Y,Y,,Y,ABCMA,Y,Y,N,
procedure=p_cir_32
Fixed param: ABC50,nds-cir32-scrub-0100,030,Y,Y,Y,,Y,ABCMA,Y,Y,N,
setenv p_active_library "ABC50"
setenv p_report_file_name "abc-cir32-scrub-0100"
setenv p_number_of_days "030"
setenv p_update_z31 "Y"
setenv p_update_z36h "Y"
setenv p_item_status_yes_no "Y"
setenv p_item_status_filter ""
setenv p_sub_library_yes_no "Y"
setenv p_sub_library_filter "ABCMA"
setenv p_update_z37h "Y"
setenv p_update_z35 "Y"
setenv p_update_z40 "N"


Portion from /exlibris/aleph/u16_3/abc50/print/abc-cir32-scrub-0100-lmw:
<section-03>
<z36h-time>200712261401039</z36h-time>
<z36h-doc-number>002368727</z36h-doc-number>
<z36h-item-sequence>000010</z36h-item-sequence>
<z36h-id>SCR20080128</z36h-id>
<z36h-number>000088129</z36h-number>
<z36h-material>BOOK</z36h-material>
<z36h-sub-library>ABCMA</z36h-sub-library>
<z36h-status>A</z36h-status>
<z36h-loan-date>10/29/2007</z36h-loan-date>
<z36h-loan-hour>0000</z36h-loan-hour>
<z36h-due-date>11/13/2007</z36h-due-date>
<z36h-due-hour>2359</z36h-due-hour>
<z36h-returned-date></z36h-returned-date>
<z36h-returned-hour></z36h-returned-hour>
<z36h-item-status>76</z36h-item-status>
<z36h-bor-status>51</z36h-bor-status>
<z36h-letter-number>03</z36h-letter-number>
<z36h-letter-date>20071212</z36h-letter-date>
<z36h-no-renewal>0</z36h-no-renewal>
<z36h-note-1></z36h-note-1>
<z36h-note-2></z36h-note-2>
<z36h-loan-cataloger-name></z36h-loan-cataloger-name>
<z36h-return-cataloger-name></z36h-return-cataloger-name>
<z36h-renew-cataloger-name></z36h-renew-cataloger-name>
<z36h-renew-mode></z36h-renew-mode>
<z36h-bor-type>LO</z36h-bor-type>
<z36h-note-alpha>L</z36h-note-alpha>
<z36h-recall-date>00000000</z36h-recall-date>
<z36h-recall-due-date>00000000</z36h-recall-due-date>
<z36h-last-renew-date>00000000</z36h-last-renew-date>
<z36h-original-due-date>00000000</z36h-original-due-date>
<z36h-process-status>IL</z36h-process-status>
<z36h-loan-type></z36h-loan-type>
<z36h-proxy-id></z36h-proxy-id>
<z36h-recall-type></z36h-recall-type>
<update-error-code>Succeed</update-error-code>
</section-03>

Can you tell us what is causing the problem the user describes and how to fix?

Resolution:
In regard to p_cir_32: p_cir_32 operates on the following tables: z31, z35, z36h, z37h, z40, z68, z309.
It does not operate on the active loan (z36) table; only on the loan history (z36h) table.

p_cir_32 changed the z36h_id in this abc50 z36h record to "SCR20080128". That's what it's supposed to do.
If you need to be able to look at the patron id in the historical z36h records in order to diagnose situations like this,
then you should consider increasing the p_cir_32 "Number of Days to Retain" parameter to a value which will retain
the patron ID for the number of days you will need for this analysis.

• Article last edited: 10/8/2013