Items are overdue at checkout
- Article Type: General
- Product: Aleph
- Product Version: 20
Description:
We are experiencing problems loaning items which have a 6-hour loan period. When a patron checks out an item, the due date is stuck at 1/24/12 (even though today is 1/26/12) and the due time is the time of checkout. Thus the item is immediately 2 days overdue and has incurred a $50 fine before it even leaves the desk. We are not having this problem with the 1-hour or 2-hour loans, only the 6-hour items. Our Tab15 shows that the settings are identical for these statuses (you'll need to paste this into Notepad to see it properly):
:
ABC15 31 ## L Pdcl 1 hr loan Y Y N N Y N N N N 00 N
ABC15 32 ## L Pdcl 2 hr loan Y Y N N Y N N N N 00 N
ABC15 36 ## L Pdcl 6 hr loan Y Y N N Y N N N N 00 N
Our Tab16 also shows identical settings:
! Item Status 31 - Periodicals - 1 hour loan (Display Issues)
ABC16 31 ## 01 + 00000000 00 + 0100 0030 02400 002 000 3 007 000 06 0000 0000100.00 000 0 01
ABC16 31 ## 02 + 00000000 00 + 0100 0030 02400 002 000 3 007 000 06 0000 0000100.00 000 0 01
ABC16 31 ## 10 + 00000000 00 + 0100 0030 02400 002 000 3 007 000 06 0000 0000100.00 000 0 01
ABC16 31 ## 20 + 00000000 00 + 0100 0030 02400 002 000 3 007 000 06 0000 0000100.00 000 0 01
ABC16 31 ## 21 + 00000000 00 + 0100 0030 02400 002 000 3 007 000 06 0000 0000100.00 000 0 01
ABC16 31 ## 57 + 00000000 00 + 0100 0030 02400 002 000 3 007 000 06 0000 0000100.00 000 0 01
ABC16 31 ## 80 + 00000000 00 + 0100 0030 02400 002 000 3 007 000 06 0000 0000100.00 000 0 01
ABC16 31 ## 81 + 00000000 00 + 0100 0030 02400 002 000 3 007 000 06 0000 0000100.00 000 0 01
ABC16 31 ## 30 + 00000000 00 + 0100 0030 00000 002 000 0 007 000 06 0000 000 0 01
ABC16 31 ## 31 + 00000000 00 + 0100 0030 00000 002 000 0 007 000 06 0000 000 0 01
ABC16 31 ## 40 + 00000000 00 + 0100 0030 00000 002 000 0 007 000 06 0000 000 0 01
ABC16 31 ## 41 + 00000000 00 + 0100 0030 00000 002 000 0 007 000 06 0000 000 0 01
ABC16 31 ## 82 + 00000000 00 + 0100 0030 00000 002 000 0 007 000 06 0000 000 0 01
! Item Status 32 - Periodicals - 2 hour loan (Forecasts)
ABC16 32 ## 01 + 00000000 00 + 0200 0100 02400 002 000 3 007 000 02 0000 0000100.00 000 0 01
ABC16 32 ## 02 + 00000000 00 + 0200 0100 02400 002 000 3 007 000 02 0000 0000100.00 000 0 01
ABC16 32 ## 10 + 00000000 00 + 0200 0100 02400 002 000 3 007 000 02 0000 0000100.00 000 0 01
ABC16 32 ## 20 + 00000000 00 + 0200 0100 02400 002 000 3 007 000 02 0000 0000100.00 000 0 01
ABC16 32 ## 21 + 00000000 00 + 0200 0100 02400 002 000 3 007 000 02 0000 0000100.00 000 0 01
ABC16 32 ## 30 + 00000000 00 + 0200 0100 00000 002 000 0 007 000 02 0000 000 0 01
ABC16 32 ## 31 + 00000000 00 + 0200 0100 00000 002 000 0 007 000 02 0000 000 0 01
ABC16 32 ## 40 + 00000000 00 + 0200 0100 00000 002 000 0 007 000 02 0000 000 0 01
ABC16 32 ## 41 + 00000000 00 + 0200 0100 00000 002 000 0 007 000 02 0000 000 0 01
ABC16 32 ## 57 + 00000000 00 + 0200 0100 00000 002 000 0 007 000 02 0000 000 0 01
! Item Status 36 - Periodicals - 6 hour loan
ABC16 36 ## 01 + 00000000 00 + 0600 0100 02400 010 000 3 007 000 02 0000 0000100.00 000 1 01
ABC16 36 ## 02 + 00000000 00 + 0600 0100 02400 010 000 3 007 000 02 0000 0000100.00 000 1 01
ABC16 36 ## 10 + 00000000 00 + 0600 0100 02400 010 000 3 007 000 02 0000 0000100.00 000 1 01
ABC16 36 ## 20 + 00000000 00 + 0600 0100 02400 010 000 3 007 000 02 0000 0000100.00 000 1 01
ABC16 36 ## 21 + 00000000 00 + 0600 0100 02400 010 000 3 007 000 02 0000 0000100.00 000 1 01
ABC16 36 ## 57 + 00000000 00 + 0600 0100 02400 010 000 3 007 000 02 0000 0000100.00 000 1 01
ABC16 36 ## 80 + 00000000 00 + 0600 0100 02400 010 000 3 007 000 02 0000 0000100.00 000 1 01
ABC1
Resolution:
The analysis of due-date problems is described in KB 16384-14305. In this case, when I looked at the abc50 z301 for sublibrary ABCMN with util f/4, I saw this for item status 36:
02 z301_line[000000242]..3601+0000000020120124+06000000+0000000020120124+06000000
02 z301_line[000000243]..3602+0000000020120124+06000000+0000000020120124+06000000
<etc.>
that is, a due-date of 20120124. (I would think that the GUI - Loan - Active Due Dates would have shown the same...)
I noticed that your tab16 had "1" in column 27 for item status 36 (you'll need to paste this into Notepad to see it properly):
! 1 2 3 4 5 6 7 8 9 10 11 12 13 4 5 16 7 18 19 20 21 22 23 24 25 26 2728
!!!!!-!!-!!-!!-!-!!!!!!!!-!!-!-!!!!-!!!!-!!!!!-!!!-!!!-!-!-!!!!!!!!-!-!!!!-!!!-!!!-!!-!!!!-!!!!!!!!!!-!!!!!!!!!!-!!!!!!!!!!-!!!-!-!!
ABC16 36 ## 01 + 00000000 00 + 0600 0100 02400 010 000 3 007 000 02 0000 0000100.00 000 1 01
ABC16 36 ## 02 + 00000000 00 + 0600 0100 02400 010 000 3 007 000 02 0000 0000100.00 000 1 01
<etc.>
Here's the description of column 27:
! When calculating the due date:
! 0 - Adjust a due hour which is after closing time to the closing
! time (if the due date is an open day), or to the closing time
! of the NEXT open day (if the due date is a closed day).
! 1 - Adjust a due hour which is after closing time to the closing
! time (if the due date is an open day), or to the closing time
! of the PREVIOUS open day (if the due date is a closed day).
! Note! When choosing '0' or '1', if the due hour is after
! closing and before 23:59:59, the due hour will change to the
! closing time of the same day. If the due hour is in the next day
! (after 00:00:01), the due hour will change to the opening
! time of the following day.
It wouldn't seem that this should be throwing the date back to Jan. 24, but since these are the only lines with "1" in column 27, I suspected that it was. I updated the "1"s to "0"s.
As described in KB 150, to force the z301 to be recreated, you need to either run p_cir_01 for the xxx50 or do util a/17/1 for the xxx50 z301. (With the former, the recreation of the z301 occurs only upon the first loan transaction; the latter recreates the z301 as part of its processing.)
Note: the above worked.
- Article last edited: 10/8/2013