ALEPH 500 Versions 17 and 18 Major New

ALEPH 500 Versions 17 and 18 Major New Features Judy Levi Senior Product Analyst Ex Libris North American 2006 Technical Seminar Knoxville, TN

Session Outline Authority control enhancements Cross reference sorting Author + Title break Patron Direct Queue Booking Printing Circulation logger Inventory control SDI ALEPH 500 Version 17 and 18 Highlights 2

Authority Control in V. 18 ALEPH 500 Version 17 and 18 Highlights 3

Authority Related Developments in V. 18 Solution for “Conflicting Headings” Problem The second and third positions of the tag are taken into account to create “groups”, and matching is done only within group Correction of Field Tag and Indicators If a BIB field is corrected through cross-reference, the field tag is also corrected Sorting of Ambiguous Headings Copy/Break Author + Title heading ALEPH 500 Version 17 and 18 Highlights 4

What is the “Conflicting Headings” Problem? Lets start with an example (taken from a presentation given by Sandy Card from Binghamton. ALEPH 500 Version 17 and 18 Highlights 5

This is a haddock – it’s a fish ALEPH 500 Version 17 and 18 Highlights 6

This is a spy – Jules Salvador Moch was a spy (we think) and had a code name of Haddock – but he is not a fish! ALEPH 500 Version 17 and 18 Highlights 7

Until version 18 Aleph did not know the difference between them (Personal subject vs. Topical subject). A library loaded records, started ue_08 – and got: ALEPH 500 Version 17 and 18 Highlights 8

ALEPH 500 Version 17 and 18 Highlights 9

instead of what they expected to get: ALEPH 500 Version 17 and 18 Highlights 10

This happened because of the “conflicting headings problem” ALEPH 500 Version 17 and 18 Highlights 11

Haddock as a Topical Heading, is tagged 150 in the Authority Record ALEPH 500 Version 17 and 18 Highlights 12

Haddock as a Personal Name Cross Reference, is tagged 400 in the Authority Record ALEPH 500 Version 17 and 18 Highlights 13

Why did the problem occur? In the BIB and AUT libraries a new heading is created when the text of the field is unique – the nature of the field is not taken into account. When BIB and AUT headings are matched, using the “GEN” headings file, the match is on the content of the field – the nature of the field is not taken into account. ALEPH 500 Version 17 and 18 Highlights 14

What are “Conflicting Headings? ” Conflicting headings are similar to ambiguous headings. In both cases a single heading is linked to more than one Authority record. Ambiguous headings are headings created from identical non-preferred terms within the same category or family of headings. For example: A. L. A is a non-preferred term of the following corporate authors: American Library Association American Lung Association of Legal Administrators ALEPH 500 Version 17 and 18 Highlights 15

What are “Conflicting Headings” ALEPH solves the problem of ambiguous headings by adding the preferred term to the non-preferred term (using fix_doc_aut_duplicate). For example: A. L. A (American Library Association) A. L. A (American Lung Association) A. L. A (Association of Legal Administrators) In this manner ambiguous headings become unique (until v. 18 there was a problem filing such headings…more on this later). ALEPH 500 Version 17 and 18 Highlights 16

What are “Conflicting Headings” Conflicting headings are created by identical headings from different heading categories. While ambiguous headings are legitimate because they are created by the authority records themselves, conflicting headings are not because in principle headings from different categories should never match. ALEPH 500 Version 17 and 18 Highlights 17

The Haddock Problem Scenario 1: the AUT library has only “Haddock the spy” (Haddock is 400. ( The subject “Haddock” from the BIB matches the personal heading “Haddock” in the AUT “GEN” headings and the AUT record. The BIB record is updated from the AUT record – the record in which “Moch, Jules Salvador” is the preferred heading of Haddock. … ALEPH 500 Version 17 and 18 Highlights 18

The Haddock Problem Scenario 2: the AUT library (from v. 17) uses fix_doc_aut_duplicate, which prevents two AUT records being linked to a single AUT heading When two AUT records share the same text for 4 XX or 1 XX, the text of the 1 XX is added to the 4 XX. 400 |a Haddock becomes 400 |a Haddock |7 Moch, Jules Salvador 1893 ALEPH 500 Version 17 and 18 Highlights 19

The Haddock Problem fix_doc_aut_duplicate prevents incorrect flipping if there are multiple AUT records with the same x-ref (e. g. A. L. A(. But fix_doc_aut_duplicate does not solve the problem of mismatch subject and name. The categories mechanism solves this problem. ALEPH 500 Version 17 and 18 Highlights 20

The “Categories Mechanism” Version 18 introduces the “categories mechanism” to solve the problem of conflicting headings. The categories mechanism takes the category of the heading into account. It does this by using the last two positions of the tag. ALEPH 500 Version 17 and 18 Highlights 21

How does the tag relate to the category? 100 field = authorized personal name heading 150 field = authorized topical subject heading 400 field = “see from” personal name (meaning don’t use this form, use the 100 form) 450 field = “see from” topical subject heading (again meaning don’t use this form, use the 150 form) ALEPH 500 Version 17 and 18 Highlights 22

How does the tag relate to the category? 1 st digit tells you whether the term you have is currently used or not. 1 XX represents the authorized (currently used) version of a heading 4 XX represents an unused version of the heading While the other 2 digits represent the type of heading you are dealing with: X 00 = a personal name X 50 = a topical subject heading ALEPH 500 Version 17 and 18 Highlights 23

Bibliographic Record Tags In most cases (but not all – more on this later) the last two digits of the tag in the bibliographic record matches the last two digits of the tag in the authority record: 00 = personal name 10 = corporate author 11 = meeting 50 = topical subject 51 = geographic subject ALEPH 500 Version 17 and 18 Highlights 24

The Categories Mechanism The “Category Mechanism” is not mandatory, but it is recommended, especially if your records adhere to MARC 21 cataloging standards. A new field – Z 01 -CATEGORY – has been added to the headings record. It is part of the record key, and is used to differentiate two headings that have the same text. ALEPH 500 Version 17 and 18 Highlights 25

The Categories Mechanism The Z 01 -CATEGORY field is three characters in length. The first two characters are the second and third positions of the AUT or BIB field tag. The third position is not in use – it may be used in future to enable an additional level of categorization (e. g. subject headings for children’s literature( If the categories mechanism is not used – the content of the field is ZZZ. ALEPH 500 Version 17 and 18 Highlights 26

The Categories Mechanism: COR field When a heading field in the authority library is updated, the system generates a “COR” field. This field contains the original term. The COR field needs to contain the category of the original field. This is now added in $0. For example: COR $a Trees INC. $0 01 If the categories mechanism is not used the $0 will contain ZZZ. ALEPH 500 Version 17 and 18 Highlights 27

How does this work? AUT Library Haddock - 00 100 $a Moch, Jules Salvador 400 $A Haddock - 50 150 $a Haddock BIB Library B I B Haddock - 50 650 $a. Haddock $x. Habitat ALEPH 500 Version 17 and 18 Highlights 28

Categories Mechanism Setup A new table – tab_acc_category – has been added to the BIB and AUT tab directory. The table has two columns: Tag Indication whether the mechanism used: 0 – not used 1 – used 2 – for future use ALEPH 500 Version 17 and 18 Highlights 29

Recommended Setup: AUT library: 100## 1 111## 1 148## 1 130## 0 150## 1 151## 1 155## 1 400## 1 411## 1 430## 1 451## 1 455## 1 BIB library: 100## 1 111## 1 130## 0 245## 1 246## 1 247## 1 440## 0 600## 1 611## 1 630## 1 648## 1 650## 1 651## 1 655## 1 ALEPH 500 Version 17 and 18 Highlights 700## 1 711## 1 730## 0 740## 1 800## 1 811## 1 830## 0 30

Explanation of the Setup As noted, in MARC the bibliographic and authority tags do not always match. The categories mechanism will prevent mismatches but will not always enable a match. Title tags do not match – 130 in the AUT and 130, 240, 440, 730 and 830 in the BIB. The solution was to avoid adding the category for these fields – since other fields will have the category, mismatches should not occur while a 240 in the BIB can match a 130 in the AUT. ALEPH 500 Version 17 and 18 Highlights 31

Explanation of the Setup Note that uncontrolled titles – 245, 246, 247 and 740 have been defined to include the category. This was defined in order to prevent a match with identical titles – and possible authority control of these titles – from the authority database. These uncontrolled titles should not be updated from the authority records. ALEPH 500 Version 17 and 18 Highlights 32

Explanation of the Setup While the setup above enables matches between varying title tags, it does not provide a solution for possible geographic names, where a 151 authority field can match the bibliographic 110 and 710 fields (“ 51” will not match “ 10. (” ALEPH 500 Version 17 and 18 Highlights 33

Implementation of Categories Mechanism Implementation will require re-building of the headings in the AUT and BIB libraries and then re-creating the links between the AUT and BIB libraries. Run: P_manage_02 in all AUT libraries P_manage_102 in BIB for all AUT libraries (first time with delete=Y) P_manage_02 in BIB ALEPH 500 Version 17 and 18 Highlights 34

Correction of Tag and Indicators Authority control has been enhanced in version 18 so that when a bibliographic record field is updated, in addition to updating the content of the field the system will also correct the field tag and indicators if they are different than those of the authority record. ALEPH 500 Version 17 and 18 Highlights 35

Example: For example: Authority record: Original bibliographic record: Corrected bibliographic record: ALEPH 500 Version 17 and 18 Highlights 36

Sorting of Ambiguous Headings Ambiguous headings are non-unique or undifferentiated 4 XX headings (same 4 XX for different 1 XX). ALEPH solves ambiguous headings by adding the preferred term (1 XX) to the non-preferred term (4 XX). This can be done automatically using the fix_doc_aut_duplicate program. For example: 410 2 $$a. ALA $$7 African Literature Association Such headings were not sorted correctly in the headings list. ALEPH 500 Version 17 and 18 Highlights 37

Sorting of Ambiguous Headings For example: 410 2 $$a. ALA $$7 African Literature Association 410 2 $$a. ALA $$7 American Library Association 110 2 $$a. ALA Auto & Travel Club. 410 2 $$a. ALA $$7 Stiftelsen Anpassning till liv och arbete ALEPH 500 Version 17 and 18 Highlights 38

New Filing routine: add_prefix_hash This routine adds a hash (#) sign to the subfield specified in the parameters column of the tab_filing table. The hash (#) sign is added immediately after the subfield code. For example: $$a [original heading]$$7#[text of added by fix_doc_aut_duplicate]. ALEPH 500 Version 17 and 18 Highlights 39

Correct sorting : For example: 410 2 $$a. ALA $$7#African Literature Association 410 2 $$a. ALA $$7#American Library Association 410 2 $$a. ALA $$7#Stiftelsen Anpassning till liv och arbete 110 2 $$a. ALA Auto & Travel Club. Note that the addition of the hash sign is only for filing purposes, both the record and the display of the heading are not altered ALEPH 500 Version 17 and 18 Highlights 40

Implementation Add the process to the filing routine in tab_filing: 01 N add_prefix_hash 7 Re-sort headings – run p_manage_16 and p_manage_17 ALEPH 500 Version 17 and 18 Highlights 41

Copy and Break “Author + Title” heading o fix_doc_1 xx_240 and fix_doc_1 xx_243 o subfield t and all subsequent subfields are copied from field 1 XX, to field 240 or 243. The $$t subfield is copied to $$a subfield in the new tag 240/243, all subsequent subfields are copied as they are, and deleted from the original 1 XX field. o AUT o 100 10 $$a Shakespeare, William, $$d 1564 -1616. $$t King Richard II o BIB o 100 10 $$a Shakespeare, William, $$d 1564 -1616. o 240 10 $$a. King Richard II ALEPH 500 Version 17 and 18 Highlights 42

Patron Direct Queue ALEPH 500 Version 17 and 18 Highlights 43

Functionality Objectives To allow patrons to loan and return in any library, without having to register in each library. To allow patrons to request any pickup location, regardless of which library fulfills the request. To consider the pool of all copies of all libraries when fulfilling a patron’s request. To manage the potential suppliers according to a pre-defined roster. To enable reporting cross library activity. Note that this functionality is applicable in Multior Single ADM sites. ALEPH 500 Version 17 and 18 Highlights 44

Requirements Single or Multi-ADM environment, sharing a single library catalog, which is either Union View, or shared Bibliographic records. Cross-institution agreements on patron statuses that are used in common. For Multi-ADM: Participating libraries define their patrons as shared. Patron ID is unique across the participating institutions. Barcodes are unique across all participating libraries. ALEPH 500 Version 17 and 18 Highlights 45

GUI Limitations in Multi-ADM Circulation GUI is limited to loan (check out) and return (check in) actions for items that belong to a different ADM library. The items cannot be renewed, recalled, declared lost or claimed returned, nor can their information be displayed. These actions are possible only at the owning institution. ALEPH 500 Version 17 and 18 Highlights 46

“ALEPH” Local Patron record The “ALEPH” Z 305 Local Patron Record was originally intended as the “default” record for patrons that do not have a Local Patron record that matches the item record. The “ALEPH” Z 305 record is relevant (and present) only in Multi-ADM environments. It is located in the usr_library environment, where it is shared by all ADM libraries. ALEPH 500 Version 17 and 18 Highlights 47

“ALEPH” Local Patron record tab 31 (col. 22) determines whether or not to generate an ALEPH record. tab_map_privileges defines the patron status that is assigned in the patron’s ALEPH record (per sublibrary + status). ALEPH 500 Version 17 and 18 Highlights 48

“ALEPH” Local Patron record - Conversion Upgrade processes handles the change: Convert existing Z 305 records. If patron has both ADM and "ALEPH“ Local Records, the "ALEPH" record is deleted. If patron has "ALEPH" Local Record, and no ADM Local Record, it will be changed from "ALEPH" to ADM (e. g. change "ALEPH" to "USM 50"). Update cols. 9, 10, 11 in tab_sub_library table If cols 9, 10, 11 contain both "ALEPH" and ADM library code, delete "ALEPH". If cols 9, 10, 11 contain "ALEPH" but not the ADM code, replace "ALEPH" with ADM code. ALEPH 500 Version 17 and 18 Highlights 49

“ALEPH” Local Patron record - Conversion Multi-ADM PDQ requires Manually setting up tab 31 col. 22 flag Manually setting up tab_map_privileges and the tab_sub_library hierarchy. Running a utility that will create required ALEPH patron records. ALEPH 500 Version 17 and 18 Highlights 50

ALEPH and ADM Patron records - Summary When a new patron registration occurs: 1. A local Z 305 record is created in the ADM library. 2. An ADM level Z 305 record is created in the ADM library. 3. An “ALEPH” Z 305 record might be created in the usr_library, depending on tab 31 policy. ALEPH 500 Version 17 and 18 Highlights 51

Loan and Return Anywhere Multi-ADM The general ALEPH record will be used whenever the patron is active in an institution in which he is not explicitly registered. Since the ALEPH statuses are agreed on, each institution can use its configuration tables (tab 16) to enforce local policies regarding loan and request privileges for ‘external’ patrons. ALEPH 500 Version 17 and 18 Highlights 52

The Title Request – Patron and OPAC “Request” button on FULL record display; if the title has items of more than a single material type, or differing enumeration/chronology, a list displays for the patron to choose from. The Request Form displays libraries that have available copies displays list of possible pickup locations, filtered to include relevant locations only ALEPH 500 Version 17 and 18 Highlights 53

The Title Request – Pickup Locations The default pickup location (first location in the list) is patron dispatch library; if blank then, patron home library; if blank then, item sublibrary or first library in tab 37 If there is only a single possible pickup location, naturally it is the default. ALEPH 500 Version 17 and 18 Highlights 54

The Title Request – Patron and OPAC A global limit of active title requests is set on the patron’s Global Record. The patron views his title requests in the Web OPAC “My Library Card ”. The title requests are displayed on a separate line, below the patron activity table, similar to ILL requests display. ALEPH 500 Version 17 and 18 Highlights 55

The Title Request – The Roster tab_roster sets which libraries are potential suppliers for each pickup location. The potential suppliers are arranged in groups, each with an internal order that is either pre-set or random. ALEPH 500 Version 17 and 18 Highlights 56

The Title Request – The Request Records The Title Request creates a queue (Z 370), using representative items, one per Supplier. A hold request (Z 37) is placed on the single potential supplier that is currently active. ALEPH 500 Version 17 and 18 Highlights 57

The Title Request – The Roster Batch A batch process moves the active request (Z 37) to the next stop in the roster (Z 370). The batch’s duty is: Determine whether the request should be moved on. Determine who the next potential supplier is. The next potential supplier will be: The next potential supplier in the roster that has an available item, or, If no available item is found, the next potential supplier, regardless of item availability. ALEPH 500 Version 17 and 18 Highlights 58

The Title Request – Pickup Locations The patron’s selection of a pickup location might narrow the list of potential suppliers for the request. Title Pickup Locations : A B C D E ADM Record Item Item ALEPH 500 Version 17 and 18 Highlights 59

The Title Request – Pickup Locations Each institution can define (by item status) which of its items can be transferred to pickup locations that are outside the institution. Each institution can define which patron statuses can request a pickup location that is outside the institution. ALEPH 500 Version 17 and 18 Highlights 60

The Title Request – Pickup Locations Each institution can define which of its sublibraries may serve as pickup locations for items of other institutions. Each institution can define paging rules – i. e. sublibraries which will not be allowed pickup locations if there is a loanable on-the-shelf item in the sublibrary. ALEPH 500 Version 17 and 18 Highlights 61

The Title Request – Life Cycle OPAC Request is placed GUI Roster Return to Owning Library Request Management Patron CIRC policy Patron Return Owning Inst. Fulfillment Pickup Inst. Fulfillment Patron Loan ALEPH 500 Version 17 and 18 Highlights 62

The Title Request – Owning Inst. Fulfillment If the request if fulfilled (item is returned or call slip was printed for an available item) and the pickup location is not the owning library, then the item will be placed ‘In Transit’ to the pickup location. A configurable option enables notifying the patron at this stage. ALEPH 500 Version 17 and 18 Highlights 63

The Title Request – Pickup Inst. Fulfillment When the item arrives at the pickup location: The ‘In Transit’ status is cancelled. The item is put ‘On Hold’. A configurable option enables notifying the patron at this stage. ALEPH 500 Version 17 and 18 Highlights 64

The Title Request – Patron Loan When the patron checks out the item, and the checkout is not at the owning institution: Staff must have ‘Cross Institution’ privileges. The ‘On Hold’ status is cancelled. The loan procedures (loan checks, due date, cash transactions, patron local privileges) are performed at the owning institution, using the owning institution’s values. The Loan Session will be updated with the item’s and the loan’s values, but will not include the option to change the due date. Loan Receipt will be printed (subject to station configuration). ALEPH 500 Version 17 and 18 Highlights 65

The Title Request – Patron Return When the check-in is not performed at the owning institution: The performing staff must have special ‘Cross Inst. ’ privileges. The patron is discharged The item is put ‘In Transit’ ALEPH 500 Version 17 and 18 Highlights 66

The Title Request – Staff Management The CIRC GUI Patron tree has a ‘Title Request’ node. Staff members in all of the institutions that manage the patron are able to : Delete the title request (notifying the patron). Change the request’s expiry date. ALEPH 500 Version 17 and 18 Highlights 67

The Title Request – Staff Management The Item tree lists the requests that are currently active for a library of the institution. Request fields can be updated, but apart from the expiry date, changes are relevant only for the current supplying institution. Deletion of the request at the active institution will cause deletion of the title request, subject to staff approval. ALEPH 500 Version 17 and 18 Highlights 68

The Title Request – Staff Management Call slips printing (cir-12 and ue_06) is handled in the active institution. Expired request deletion (cir-17) is handled in the active institution. The title request will also be deleted. Item recall (cir-13) is activated only in the active institution. ALEPH 500 Version 17 and 18 Highlights 69

Reports Title Request Report (cir-81) reports how many requests were handled by partners. How many times the library fulfilled requests of patrons from other libraries (based on home library); based on the ‘Other Inst. Fulfillment’ event. How many times a library served as a pickup location for items of other libraries; based on the ‘Pickup for Another Inst. ’ event. How many times the library’s items were transferred to another library. ALEPH 500 Version 17 and 18 Highlights 70

Reports Institute Time Report (cir-82) reports the average time duration for different stages in the fulfillment of the title request. How long (average) it took for an institution’s patrons’ requests to be fulfilled, from the time the request was placed. How long (average) it took for a fulfilling institution to put the item on the hold shelf or send it to the pickup location. How long (average) it took for a pickup location to loan the item after it arrived at the pickup location. ALEPH 500 Version 17 and 18 Highlights 71

Booking ALEPH 500 Version 17 and 18 Highlights 72

What is Item Booking? A booking request is a request on a specific item for a specific patron at a specific time. Booking requests differ from standard ALEPH hold requests in two ways: Booking requests have specific start and end dates. Booking requests have priority over all other requests. Booking is suitable for “Reserves” and for “Equipment”. ALEPH 500 Version 17 and 18 Highlights 73

Item Booking Concepts Effective request time span is made up of three parts: Delivery Head Time Request Time Tail Time Delivery Time Request can be fulfilled by any “like” item. Request can not be longer than the loan period. ALEPH 500 Version 17 and 18 Highlights 74

Item Booking Concepts Requested item must be available, meaning: Not on loan Not on hold shelf Not booked by other patrons Not being reshelved Preview Time Release Time Re-allocate ALEPH 500 Version 17 and 18 Highlights 75

OPAC Booking Request Booking on Full view Booking on Items view ALEPH 500 Version 17 and 18 Highlights 76

OPAC Booking Request Booking on free form ALEPH 500 Version 17 and 18 Highlights 77

OPAC Booking Request Booking on pre-set schedule ALEPH 500 Version 17 and 18 Highlights 78

GUI Booking Request Booking on pre-set schedule ALEPH 500 Version 17 and 18 Highlights 79

OPAC Booking Request Patron’s booking requests ALEPH 500 Version 17 and 18 Highlights 80

GUI Booking Request Patron’s booking requests ALEPH 500 Version 17 and 18 Highlights 81

Handling – Staff Workflow Fetch the requested material Services : cir-12 (ue_06) CIRC GUI: Administration tab Deliver a requested item Loan a requested item ALEPH 500 Version 17 and 18 Highlights 82

Handling – Staff Workflow CIRC GUI: Administration tab Filter list by locations, dates, patron, start time, end time, … ALEPH 500 Version 17 and 18 Highlights 83

Handling – Staff Workflow CIRC GUI: Administration tab F 11 – Print ALEPH 500 Version 17 and 18 Highlights 84

Booking Request handling in the Circulation Module Loan tab Shortening a loan Merging and extending a loan Renewals Slot restricted advance bookings Risk Analysis Report ALEPH 500 Version 17 and 18 Highlights 85

Booking Configuration Local Patron (tab 31) – booking permission; release period ignored (item always held) tab 15 – re-loaning / re-booking time wait; booking for closed / open / both tab 16 – limit of number of bookings tab 100 – like items tab_hold_request – BK section tab_booking – times for head, tail, release, patron delete, how far into future ALEPH 500 Version 17 and 18 Highlights 86

Booking Configuration tab 37_booking_delivery – non-library locations for delivery/pickup (per item location, item status, patron status( tab 37_booking_pickup – sublibrary locations for delivery/pickup tab 27 – loan to patron, or to pickup location tab 18 – booking charges tab 43 – advance booking slots ALEPH 500 Version 17 and 18 Highlights 87

Booking Services Call slips – cir-12 Reminders – cir-33 Risk analysis – cir-35 Report/Delete expired – cir-34 ALEPH 500 Version 17 and 18 Highlights 88

Printing ALEPH 500 Version 17 and 18 Highlights 89

PC Client Printing Control Optional in v 16 and v 17, default in v 18 Printing now runs under third party software, instead of directly under MS Windows. The software has been added to the PC client. It is placed under alephcombin, and is called Html. Print. This software was added in order to solve problems of re-direction for printing. However, it also provides some additional features, such as the ability to set margins, and to add header and/or footer. Some entries in the configuration file should NOT be changed, such as a registration number and settings which are automatically updated when you configure your client. ALEPH 500 Version 17 and 18 Highlights 90

PC Client Printing Control ALEPH 500 Version 17 and 18 Highlights 91

PC Client Printing Control ALEPH 500 Version 17 and 18 Highlights 92

Circulation Logger ALEPH 500 Version 17 and 18 Highlights 93

Circulation Logger The objective of this functionality is to achieve patron oriented tracking of circulation actions such as loans, renewals, recalls and cash transactions. The logger gives the staff user concentrated information on patron circulation activities, to enable providing better service to the patron, and information when handling disputes. ALEPH 500 Version 17 and 18 Highlights 94

Circulation Logger Configuration ADM table (tab_circ_log. eng) defines which actions create a log entry, whether systemgenerated or manual, and the name of the action 00 Y Y LLog loan note 01 Y N LRegular loan 09 Y N LSelf check loan 02 Y N LOffline circulation loan Display can be filtered by action ALEPH 500 Version 17 and 18 Highlights 95

Log Display ALEPH 500 Version 17 and 18 Highlights 96

Log clean-up Circulation Logger Clean Up (cir-78) – deletes log entries when The transaction type fits the input parameter (cash or loan) The action date is not later than the input parameter The transaction is closed (returned or paid) Patron Scrubbing and deleting removes log records ALEPH 500 Version 17 and 18 Highlights 97

Inventory – Shelf Reading ALEPH 500 Version 17 and 18 Highlights 98

Inventory Step 1: define the range – item-01 boundaries of the inventory range are defined; items can be included/excluded depending on sublibrary, collection, item status, item processing status, material type Step 2: input barcode of items on shelf – online or item-08 Barcode of the shelved item is input using GUI Items client; immediate warning for mistakenly shelved and lost-but-now-found items; or File of barcodes is submitted batch (item-08); optional update to “no longer lost”. ALEPH 500 Version 17 and 18 Highlights 99

Inventory ALEPH 500 Version 17 and 18 Highlights 100

Inventory Step 3: reports – item-09 Creates file of barcodes for items that were not found and not accounted for (can be used to delete items from the database) Creates report (author, title, call number, etc. ) of unaccounted-for items optional update process status to lost Step 4 (optional): reports – item-10 Output of item-01; i. e. the shelf range Step 5 (optional): delete items – item-11 First, change barcode to item key using manage-70 ALEPH 500 Version 17 and 18 Highlights 101

SDI ALEPH 500 Version 17 and 18 Highlights 102

Enhanced SDI Functionality SDI is now based on an “SDI ready” mechanism, that builds or does not build an SDI record. This mechanism allows : Sending SDI notification only when an item has no item process status, i. e. is available for the patron. Allowing patron to define his SDI profile for a specific campus/sublibrary. ALEPH 500 Version 17 and 18 Highlights 103

SDI Ready – Technical aspects Configuration /xxx 50/tab_z 105 UPDATE-SDI 8 USM 01 Z 324 stored in the BIB library Processes running xxx 01: ue-01 usr_lib: ue-11 Record creation depends on: Item process status check (must be blank) Sublibrary/location check (must be new) Enumeration check (must be new) ALEPH 500 Version 17 and 18 Highlights 104

SDI Ready – Technical aspects First-time record is created for ALL ADM library Sublibrary Each sublibrary triggers additional records, and possibly an ADM library record A record is not created/deleted when Item is moved from one sublibrary to another Item without item process status is assigned one ALEPH 500 Version 17 and 18 Highlights 105

SDI Profile – New Options Additional fields in profile (Z 325): Patron can set an expiry date for his profile. Alternative e-mail address. Patron can define request to receive (or not receive) SDI search that retrieves zero results. Patron can suspend SDI searches for a certain period (for example, vacations). Additional options for profile: Patron can select the character set encoding of the SDI results list. Patron can receive SDI as an RSS alert [v 18]. ALEPH 500 Version 17 and 18 Highlights 106

Enhanced SDI Functionality ALEPH 500 Version 17 and 18 Highlights 107