Circulation
Renaming of In Transit Transaction Types
To add clarity to the meaning of the In-Transit transactions, the names of these transactions have changed.
The Return in Transit transaction has been renamed In Transit Receipt.
In conjunction with this, the Issue In Transit transaction type has been renamed In Transit Issue.
The functionality of these transactions remains the same.
Configurable Transaction Types List on the I/R/R Screen
It is now possible to configure the content and order of the entries in the Transaction Type drop- down list on the I/R/R screen. This can be defined at user category level, location level and system level.
If the Transaction Types list has been defined at user category level (currently logged in user), it will be used in preference to any definitions that have been defined at location or system level. If it has been defined at location level (PC Location), it will be used in preference to the list that is defined at system level.
A default system level Transaction Types list is delivered with Service Pack 11. This can be viewed on the OLIB Defaults layout, on the User/Circ sheet.
In modify mode, the list can be configured as follows:
Changing the order of the transaction types
Select the transaction type you wish to move and use standard Up and Down re-sequencing facilities to change the order of the entries in the list.
Adding a transaction type
To add a transaction type to the list, select it from the drop-down list immediately above the list.
Click the Add to list button.
This adds the new transaction type to the end of the list.
To insert a transaction type in a specific position in the list, enter the position number in the sequence field to the left of the drop-down list, then select the transaction type and click the Add to list button.
The items at and below that position will be shuffled down to accommodate the new transaction type.
Removing a transaction type
To remove an item from the list altogether, select it and click the Delete option.
Subsequent entries in the list will be shuffled up so that the gap in the sequence numbering is filled.
The Transaction Types to be created at location level are configurable on the Location layout, on the User/Circ sheet.
The Transaction Types to be created at User Category level are configurable on the User Categories layout on the Details sheet.
New Reservation Refinements
The reservations filters have been enhanced so that you have the option of filtering by copy location or by user location when searching for reservations from the Reservations domain.
Refine by User Location
To refine a reservation search by user location, use the Users refinement listed under the
Linked Domains heading on the Refine Search dialogue box:
Select the Location refinement.
Select the location of the user as required.
Here the results are for reservations placed by users who are at the Bristol location.
Refine by Copy Location
To refine a reservation by copy location, use the Reserved Copies (for filtering) refinement listed under the Linked Domains heading on the Refine Search dialogue box:
Select the At Location refinement.
Select the location of the copy as required.
Here the results are for reservations placed on copies belonging to the Bristol location.
Date and Time Recorded for Copies Lost
OLIB now records the date and time on which a copy was flagged as Lost.
A new field has been included in the Copies domain, Recorded as Missing on.
This field has been added to the bottom of the standard Copies layout’s Main Details sheet, under the Miscellaneous Copy Settings heading. If you use locally-defined layouts for your copy records and you want to use the Recorded As Missing On field, you will need to add it manually using the Layout Manager tool.
This field is set to the current date and time whenever a copy’s status is changed to a status that has its Lost Status field set to Yes.
Here the copy status Lost presumed missing has it Lost Status set to Yes.
The Lost Status is a new Yes/No field in the Copy Statuses domain.
By default the Lost Status field is set to Yes for the Claims Lost (Key ID CLOST) and Lost presumed missing (Key ID WRDW) copy statuses when SP11 is installed.
If your OLIB system includes other copy statuses that represent a Lost or Missing status, their Lost Status field should be set to Yes manually.
If the item is recovered and you want to re-activate the copy record, you should clear the Recorded as Missing on field manually once you have changed the copy status.
Return Dates when Closed for Expired Users
It is now possible for libraries to specify how return dates are calculated when the return date falls after the user's expiry date but during a closed calendar period.
A new field has been added to the Calendar record, Allow Issue To Exp. Date?.
When an item is issued to a user and the user’s membership expiry date falls before the return date, if the expiry date falls during a location or global closed calendar period, Allow Issue To Exp. Date? is examined to determine what to set the return date to.
If Allow Issue To Exp. Date? is set to Yes in the location’s calendar record, the return date is set to the user’s membership expiry date (or, if this falls on a day on which the library is closed, the first open day before then).
If Allow Issue To Exp. Date? is set to No, the return date is set to the first open day before the user’s expiry date (i.e. the first open day before the calendar start date).
If Allow Issue To Exp. Date? is null in the location’s Calendar record, the Allow Issue To Exp. Date? field in the global calendar record is examined in the same way if such a record has been defined. If the Allow Issue To Exp. Date? field has not been set in the global calendar record (i.e. if it is null), it will be treated as if it were set to No, i.e. the return date will be set to the first open day before the user’s expiry date (i.e. the first open day before the calendar start date).