Cornell University Library Staff Web Page

Back to LMS Committee Page | StaffWeb Index

Library Management System Evaluation Committee

Acquisitions

Scott Wicks

Bill Kara, Julie Stiles, Jim Cassaro, Ed Zieba, Mary Wesche, Elizabeth Perenyi, Nancy Heliseva

3.1 Current data

The next system must allow for the transfer of current acquisitions data into appropriate fields of the next system (assuming the next system has corresponding fields.) Such data include:

• Order numbers on file with our vendors and publishers (NOTIS order numbers)
• Order dates
• Fund codes
• Selector IDs
• Action intervals
• Action dates
• Internal notes
• Vendor codes
• Non-coded vendor data (NOTIS Vendor code = 'd')
• MARC holdings
• Receipts history (including current receipts) ['R' statements]
• Payment history (most recent annual payment for serials) ['P' statements]

3.2 Order records

• Ability to use existing bibliographic records which are part of the catalog. Ability to import MARC (and UNIMARC in the future) bibliographic records from national utilities (RLIN, OCLC, WLN) as well as materials vendors including Yankee Book Peddler, Academic Book Center, B. H. Blackwells, Casalini Libri, Otto Harrassowitz, and Aux Amateurs de Livres using Z39.50 retrieval protocol.
• Ability to create, at point of order entry, MARC tagged bibliographic records in any MARC format. Default format should be determined by operator sign-on.
• The system must allow for the inclusion of the following bibliographic record data elements for any order or memoranda output:
  • MARC tag: 020 ISBN (default to subfield a)
  • MARC tag: 022 ISSN (default to subfield a)
  • MARC tag: 024:^2: ISMN (default to subfield a) Int'l Standard Music Number
  • MARC tag: 028 Music publisher number
  • One of the following 1xx MARC tags:
    • MARC tag: 100 author (all subfields)
    • MARC tag: 110 corporate author (all subfields)
    • MARC tag: 111 conference (all subfields)
  • MARC tag: 245 Title (all subfields)
  • MARC tag: 250 Edition statement
  • MARC tag: 255 Scale for maps
  • MARC tag: 260 Imprint (all subfields)
  • MARC tag: 440 or 490 Series statement (all subfields)
• Unique purchase order number will be derived from associated unique bibliographic record number.
• Ability to transmit bibliographic and special order information using full ALA character set which includes all diacritics.
• Effective ability to communicate to vendor/publisher orders for multi-part items, multivolume set, multivolume continuation, serials continuation, multimedia packages (book + accompanying material)
• Effective ability to communicate special order notes to vendor/publisher. These special order notes must be available as predefined standard, abbreviated codes which expand to full messages when order is output. The operator must have the ability to compose case-specific special order notes at point-of-order which will be output as an identifiable part of the purchase order.
• Templates with default values which can be used repeatedly as needed either during an order session or saved for retrieval at a later date for that day's order session.
• Ability to update order records or put on hold before final submission for printing or electronic transmission to our vendors.
• Ability to regenerate purchase orders by individuals with appropriate level of security, individually, in groups, by vendor, and by date.
• Ability to identify and copy order records when transferring accounts from one vendor to another--either as a global update or by individual records.
• Variable length note fields adequate to relay a complete message to staff which are in a clear location immediately apparent to staff.
• Ability to produce memos which allow for individual, free text messages in addition to precoded standard messages. Adequate space to express our needs to our vendors.
• Ability to print from the desktop, batch for remote printing, import into word processing at desktop, and/or transmit over the Internet.
• Ability to hold for review prior to output.
• Ability to encumber single or multiple fund codes at point-of-order. If multiple fund codes, ability to encumber based on percentages of total cost as well as by different whole numbers. The sum of multi-funded encumbrances or expenditures must equal total cost of encumbrance or expenditure.
• Ability to retain indexed selector identifier within order record
• Ability to system-validate selector identifier
• Ability to system-validate fund
• Ability to system-validate vendor code
• Ability to perform global update of selector identifier (find or find and replace all)
• Ability to retain operator identifier (retain information on who placed the order, who modified the order and when that modification was made.)
• Functional alerts--a flashing note or special "hot" colored text to alert staff to specific tasks which are not part of the routine receipt procedures. (Highly Desirable)

3.3 Serials check-in records

• A flexible, predictive check-in system. It should allow us to track issue-specific information (including date of receipt) as well as consolidate receipts for public display. It should allow staff to override the predictive pattern as needed without permanent disruption to the pattern. For those instances where predictive patterns are inappropriate, the system must allow for all check-in activities without use of the predictive function.
• Ability to produce system-generated, automatic claim memoranda based on expiration of an action interval. System should automatically prompt missing issue claim at point-of-check-in when issue receipt causes a gap in holdings. All claim memoranda should allow for higher-level staff approval prior to output from the system.
• Ability to produce operator-initiated memos which allow for individual, free text messages in addition to precoded standard messages. Adequate space to express our needs to our vendors. Ability to print from the desktop, batch for remote printing, import into word processing at desktop, and/or transmit over the Internet. Ability to hold for online review prior to output.
• Ability to view call number, location, and sublocation, most recent payment history, and check-in correspondence history from check-in record.
• Ability to update MARC holdings directly from the check-in record. With serial volumes, those items received as a single, complete volume, receipt should not require both a check-in statement as well as be added to the MARC holdings record.
• Automatic labels with the location and call number should be printed as part of the check-in process.
• Ability to scan the barcode for check-in of the issue (SISAC)/(SICI)
• Ability to load electronic, vendor-supplied check-in information
• Ability to maintain binding information--when to gather issues for binding, how to mark bound volumes, allow for charging out of volume while in binding process.

3.4 Monographic check-in records

• Ability to reflect wide range of receipt activity, for instance:
  • Received, no payment required, order closed
  • Received, paid, order closed
  • Received, not paid, order open
  • Not received, paid, order open (prepay)
  • Partially received, paid, order open
  • Partially received, unpaid, order open
  • Received in imperfect condition, unpaid, order open
  • Returned to vendor awaiting credit, order open
  • Returned to vendor awaiting shipment of correct title, unpaid, order open,
• Ability to check in by scanning barcode (shelf-ready material may be delivered to library with barcoded check-in and/or invoice data)
• Ability to disencumber single or multiple fund codes without payment transaction
• Ability to reencumber single or multiple fund codes after payment transaction
• Fund code charges should disencumber whenever an order record is closed, with or without transacting a payment (this should be the default value when an order is closed.)
• Memos which allow for individual, free text messages in addition to precoded standard messages. Adequate space to express our needs to our vendors. Ability to print from the desktop, batch for remote printing, import into word processing at desktop, and/or transmit over the Internet. Ability to hold for review prior to output.

3.5 Invoices

• No size limitations. The invoice record should accommodate one-line invoices as well as two thousand-line invoices.
• Currency conversion: Check-in staff should be able to record payments in foreign currency while the system converts final amount to US currency as of date of final invoice approval. Alternatively, the system converts final amount to US currency matching the date of the invoice to the currency rate for that date.
• Discounts: Invoice records should allow for discounts applied to specific line items or against the total invoice. Example: we should be able to record shipping costs as a separate line item (non discounted) while applying a discount to other payments recorded on the same invoice record.
• In addition to discounts, the system should allow us to distribute shipping and handling applied to the whole invoice amongst all items listed on the invoice. A portion of the shipping cost is charged against each item shipped.
• The invoice record should close/be saved if the line is dropped, the computer freezes, or any other factor causes the operator to lose the connection to the invoice record.
• Vendor invoice numbers, in addition to the system invoice record numbers, should be dynamically indexed and retrievable from individual desktops.
• Vendor invoice numbers should be verified automatically against the file at point of initial invoice record set-up to alert the operator of any duplication. Operator should be allowed to override the warning.
• Vendor code input in invoice record should match the vendor code in the order records. If the codes do not match, the operator should be alerted and offered the opportunity to override the conflict.
• Operator should be allowed to edit and update pay lines for invoice records not having received final payment approval.
• Operator should be able to enter pay statements with $0.00 amounts to account for titles billed on the vendor's invoice but not retained by the Library (items lined off the invoice.)
• After payment, the Cornell check number should be loaded in the invoice record for reporting back to vendors upon inquiry. This process would require they system to allow for automatic loading of voucher information from the university's central accounting office.

3.6 Funds

• We should be able to continue using the existing fund codes developed for NOTIS.
• The funds should allow for various sub categories to accommodate all fund reporting needed by selectors whether tracking by format, subject, or geographic indicator.
• When deactivating a fund, the system should be able to check all open order records which make use of the fund (both those order records with or without encumbrances) and update with a replacement fund globally. We should not be able to deactivate a fund which is used in open order records.

3.7 Vendor records

• With appropriate operator authorization, ability to create and maintain a file of library supplier (vendor) records. These records are coded for use within order and invoice records and are indexed by vendor code, vendor name, country, and account number.
• The vendor record must allow for a minimum of four separate addresses to accommodate orders, claims, payments, and returns. The records must include the following fields:
  • Vendor code (system must validate vendor code input into order or payment record against those codes in the vendor file.)
  • At least six lines for full address with four distinct fields for address:
    • Name
    • Country
    • Library's account number with vendor
    • Library's L-number used by Cornell Accounting Office
  • Vendor standard address number (SAN)
  • Vendor telephone and fax numbers
  • Vendor electronic mail and other domain addresses (web, telnet, modem)
• Ability to designate default values for order and claim intervals
• Ability to designate default values for method of order output (print, e-mail, EDI,...)

3.8 Special Receipt Processing notes

• Somewhere in a record frequented by both the ordering and receivings staff there needs to be space for processing notes such as RESERVE (with course number), REQUESTOR (with name and address), and other "special handling on receipt" codes. This information should be in a field which can be set up for automatic printing as part of the receiving process similar to a distribution list.

3.9 Reporting

• The system must include a powerful report generator that will allow retrieval of data from any field, tagged or not, in any record. The system should be able to provide standard statistics such as totals, means, standard deviations, and correlation coefficients for any time period or periods.
• Staff should be able to draft reports at their desktop from various data in the records. Such reports include, but are not limited to:
  • Open order report. Reports listing all orders placed during a specified time frame, to a specific vendor, to all vendors, to domestic vendors, to foreign vendors, to monographs vendors, to serials vendors...
  • Statistical reporting. Reports counting the number of orders placed within a specified time period, the number of those orders fulfilled, outstanding, percentages of totals, domestic dealers, foreign dealers,...
  • Reports comparing the price of specific subscriptions through several fiscal years, sorted by selector, sorted by fund, sorted by price increases of over 15% from previous years...
  • Fund reporting. Reports of all open orders by selector, sorted by format, sorted by fund, sorted by country of origin.

3.10 Statistical measures

For any given time period:

• Ability to track method of acquisition--approval plan, firm order, subscription, monographic standing order, gift, exchange, government depository program, others methods as desired.
• Ability to track transaction statistics by operator identifier--claim transaction, order transaction, check-in...
• Ability to track vendor performance--time from point of order to receipt, number of orders placed compared to number of orders received (within specified periods of time.)

3.11 Electronic Data Interchange (EDI)

• Ability to exchange acquisitions information in electronic form according to the latest standards, ANSI X12 and UN/EDIFACT using industry implementation guides. This includes sending orders and claims to our vendors as well as having the capability to receive electronic acknowledgments of said transmissions from our vendors: invoices, claim responses, dispatch data and reports from our vendors and from publishers.
• Ability to load standard USMARC bibliographic records received from our vendors. From any desktop, operator should be able to download single and/or batches of bibliographic records for direct import into the production files from FTP or from data disks of USMARC ASCII bibliographic files supplied from the outside agents.

3.12 Searching in STAFF mode

Standard keyword searching must be supported in staff mode as well as public mode.

3.13 Security of data

Security should be password-specific to allow for the most flexible working conditions while ensuring our ability to prevent unauthorized staff from corrupting data.

3.14 Online help documentation

Staff should be able to refer to help information on any of the functional modules of the system directly from their desktop.

Back to LMS Committee Page | StaffWeb Index

3/31/97 sbw

rev. 7/24/97 dih