Recall overdue block not removed after recall is cleared

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

Description:
We are having an issue with recall overdue blocks. When a patron is blocked because of a recall overdue and then the recall is cleared for some reason - expired, deleted, canceled or status of item changes to something like "Patron Claims Returned"--, the recall overdue block is *not* removed. Any idea why this is happening and is there any way to change it so the recall block is removed when the recall is cleared for whatever reason?

Resolution:
Are you waiting until p_cir_13 has been run to check the due date? You need to.

Looking at the p_cir_13 job log in $alephe_scratch, I see that you are setting p_reset_loan ("Reset Due Date of Cancelled Requests") to "Y". The effect of this *should* be to change the z36_due_date back to what it was before the recall -- and to change the z36_recall_due_date to 00000000 -- when p_cir_13 is run.

Please check some z36 records for cases where the recall has been eliminated to see if you see these changes.

Note: I'm assuming that no *explicit* block (Z303-DELINQ-n or Z305-DELINQ-n) is being created in these cases. If it were, it would, of course, need to be removed manually.

Note: If the status of the z36 loan record is L (Lost) or C (Claims returned), then the elimination of the recall will *not* cause p_cir_13 to reset the due date. p_cir_13 resets the due only for loans with status "A" (Active). It seems we're in a Catch-22: the only process which can change the due date from the current (recall) due date back to the original due date is p_cir_51,... but it doesn't work with Claims Returned items.

The following SQL could be used to locate the cases (which I think should be few) of z36's with status "C" where the z37 hold request no longer exists:

SQL> select z36_rec_key from z36 where z36_status = 'C' and z36_recall_due_date ^= '00000000' minus select substr (z37_rec_key,1,15) from z37;

and then you would do SQL to change the z36_recall_due_date back to 0 and (since you have tab100 RECALL-METHOD = 1) to move the z36_original_due_date to the z36_due_date. (With RECALL-METHOD's 2 or 3, you would *not* want or need to do this update of the z36_due_date.)

• Article last edited: 10/8/2013