Skip to main content
ExLibris
  • Subscribe by RSS
  • Ex Libris Knowledge Center

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

    • 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