Incorrect item data in loan/return/cash records; incorrect last-loan-number

Last updated
Save as PDF
Share
1. Share
2. Tweet
3. Share

Article Type: General
Product: Aleph
Product Version: 20

Description:
We are seeing strange results in Circulation for some returned items where a Cash record for items with overdue fines show information for the returned item in some parts of the display but a completely different item record in other parts. Loan History records also appear to be missing. An example is item 001515035-000310.

• The [O] History, Loan tab in Circulation does not show any loans for this item after 12/15/2010. This also corresponds to what we see running a query against the ABC50.Z36H table for the item key in the Z36H_REC_KEY field.

• Our /abc50/tab/tab100 table has CREATE-Z36H=Y specified, but we don’t seem to be getting loan history records for the item, which has circulated several times since 12/15/2010.

• However, [Z] Circulation Log does show the recent transactions for the item. The information in the Date/Time and Description fields appears to be correct, but the Due Date column shows due dates far in the past of when the loan was made – for example the entry for a Regular Return on 1/19/2011 at 11:47 pm shows a due date of 8/24/2010.

• There is a late return for this item on 1/19/2011 6:51am for the patron with ID ABC-13513. The late return fine was cancelled by our staff. When we look up that borrower’s record in Circulation and go to [C] Cash, Cancelled Transactions tab / Cash Details pane:
o The Cash Transactions and Bib Info tab appear to have the correct information.
o The Item tab however has information about a completely different item record (000777010-00010). The Loan tab appears to have the correct Loan and Due Dates, but the Original Due Date says 8/25/2010. The Patron Status says “Community Borrower” but patron ABC-13513 has a Patron Status of “10”, which translates as “ABC Undergraduate” in our setup.

Resolution:
The cash programs use the "loan number" in the z31_key to connect to the appropriate z36h record. In this case we see that the z31_key loan number is 000669623:

02 z31_rec_key \
03 id .........................ABC-13513
03 sequence ...................201101192189860
02 z31_date_x \
03 date .......................20110119
02 z31_status ...................W
...
02 z31_description ..............Late return <0000 0700 C 24.00> - 1st o
02 z31_key ......................001515035000310 000669623 <----------- loan number
02 z31_key_type .................Z36
02 z31_transfer_department ......
02 z31_transfer_date ............00000000
02 z31_transfer_number ..........
02 z31_recall_transfer_status ...
02 z31_recall_transfer_date .....00000000
02 z31_recall_transfer_number ...
02 z31_related_z31_key ..........
02 z31_related_z31_key_type .....
<etc.>

But this SQL shows that the z36h record with 000669623 as its loan number is not 001515035-31, but rather 000777010-10:

abc50@ALEPH20> select z36h_rec_key from z36h where z36h_number = '000669623';

Z36H_REC_KEY
---------------
000777010000010

This problem is occurring because the abc50 util g/2 last-loan-number got set to low at some point (during the the upgrade or your disk problem?):

While the abc50 util g/2 last-loan-number is set to 670314:

22. last-loan-number 670314

SQL shows that much higher loan numbers exist:

abc50@ALEPH20> select max (z36_number) from z36;

MAX(Z36_N
---------
000719720

abc50@ALEPH20> select max (z36h_number) from z36h;

MAX(Z36H_
---------
000719744

To correct this for future loans, you need to set the last-loan-number in util g/2 to a higher number.... "000720000" should be fine.

Article last edited: 10/8/2013