Prepared By Katipo Communications
This feature has been developed and is in final testing by a client. It will be part of Koha 3.0
The purpose of this document is to outline features and functionality required for a Koha Serials Module for the CLIENT Information Centre and to then put in place a Project Plan for the development of these features.
The Client currently has a DOS based version of Dynix and wish to move to an ILS that is web-enabled and resides on a Linux platform as all their applications are Linux based. This document does not outline all the functionality required by the Client. It is purely an outline of the features and functionality required to handle serials. Koha needs to manage serials in the same way, or better, than their current ILS. Specifically it must have these features:
The Client is a Corporate Library that differs from other types of libraries such as an Academic Library or Public Library in that one of the main requirements of a Serials Module is that it automates a “routing” procedure whereby specific journals are flagged to be circulated to specific staff in a specific order. In the case of the Client the Routing list has a priority order dependent upon the seniority of the staff member.
Another important difference between a Corporate Library and a Public Library would be the Circulation Module and the OPAC. Whilst a Corporate Library may have patrons who borrow items from the library there is most likely not a need to issue fines or track issues in the same complex way a Public Library would.
A Public Library OPAC is an integral part of their ILS. It must be set up to cope with a substantial client-base and a range of user types, from children to professional researchers. The OPAC in a Corporate Library would be set up for one type of user: staff members (=adult, professionals). In fact, it may be that there is not an OPAC and that library staff are the only ones who search the Catalogue, on behalf of fellow staff. Having said that, the Serials Module for a Corporate Library would have most of the features required by a Public Library.
The main point of difference is the Corporate Library's requirement to “route” specific journals to specific staff.
Some libraries (can be any type) also require a Bindery component whereby issues are sent to another location for binding and their status is tracked. Additionally, many Serials modules allow for electronic ordering (EDI) so that staff can search a book vendor such as Blackwells, place an order, and receive an electronic invoice. The Client does not, at this stage, require either of these last two features.
In the case of the Client it will not be necessary to ensure that their Koha ILS is fully MARC compliant as they do not use MARC for cataloguing items.
(More Info: Following on from this, a Corporate Library would probably not require their Holdings Display on their Catalogue to conform to a specific MARC display. Public libraries and Academic libraries however require all Holdings to be presented in a standard format in order for their data to be displayed on a national bibliographic database. This is because they generally want to publicise their holdings in order to generate revenue from Inter-Library Loans. Libraries that make use of a national (or consortium) Inter-Library Loans network must have their holdings adhere to MARC standards so that they display in a uniform and easy to read format.
Additionally it would be essential that the Holdings are accurate and as up-to-date as possible. This means that when an issue is “Checked In” it automatically updates the Holdings details for that particular journal and displays this in the OPAC.
Term: MARC Format for Holdings Data (MFHD).)
Serials are first managed within the Acquisitions Module and the process begins with an order form. For the Client this is a Purchase Order Form where the number assigned is a unique running order number inserted automatically at the beginning of the Acquisitions process. Staff are able to search the system by Purchase Order number.
It is important that the workflow between the Acquisitions and Serials Modules be streamlined and that these two modules are fully integrated so that orders can be tracked and followed up with claims. Additionally all vendor details should be accessible and editable in either module. There should also be a single “master” catalogue entry (bibliographic record) for the one item that is accessible from any of the modules.
It is important that “pick lists” or “drop-down” menus are used, where appropriate, to maintain uniformity in spelling and formatting. For example the supplier name Baker & Taylor could be entered in a number of ways:
Baker & Taylor
Baker & Taylor, Inc (this is the correct format)
Baker and Taylor, Ltd.
With so many different names for the same company in a database, the accuracy of search functions can be greatly reduced therefore it is important to choose from an Authority list.
Sitting behind the Acquisitions and Serials modules are various Codes, Types and Lists. These would be part of the System Administration module or Parameters. Listed below are examples of the types of lists that are linked in to the various forms in these two modules. Note this list is not definitive:
Annual
Annual (with Volume number)
Biennial (every 2 years)
Biennial (every 2 yrs - with Vol. #)
Bimonthly
Biweekly (every 2 weeks)
Daily
Monthly
Monthly (except July and August)
Quarterly (with Months)
Quarterly (with Season)
Quarterly (Winter = first season)
Semiannual
Semimonthly (1st & 15th)
Semimonthly (15th & Last day of month)
Three times a year (every 4 months)
Triennial (every 3 yrs)
Every Four years
Every Five Years
Weekly
All items within the Information Centre are given a Loan Period which is set within the Parameters. The default is 3 - 4 week loan period.
This refers to an automated alert when an issue is late. If the issue has not arrived the staff will be alerted so that they can place a claim for the issue with the supplier. The default Claim cycle is 30 days.
1 DAY
1 MONTH
14 DAYS
2 MONTHS
3 MONTHS
4 DAYS
Irregular
No Claims
The Routing List gives the details of all staff who wish to receive a particular journal, as well as listing all journals that are currently available. Staff details include:
In order for the Client to have a Serials module that fits their needs Koha should have the following features:
As mentioned above, the Acquisitions module should be integrated with the Serials module and both modules are expected to utilise the system's bibliographic database and not require the creation or maintenance of a separate file of bibliographic records.
Monitor purchase details for all material types, not just serials
Search on ISBN/ISSN and make use of existing bibliographic record - automatically fills in some details, if appropriate. (It would be good to make use of an existing bibliographic record so that the system automatically fills in some details, if appropriate. At the ISBN/ISSN field you have the opportunity to go to a designated bibliographic database and pull over a bibliographic record using Z39.50).
Form to include the following fields, but not limited to:
The Acquisitions module should also allow for electronic ordering (EDI), if required. Some libraries place orders with book vendors using an electronic Order Form and all associated tasks are handled electronically including payment. (The Client does not require this facility at this stage but may do so in the future).
One of the most important features in this module is that it be able to set up the “Publication Pattern” so that it can predict when the next issue is expected, including allowing for irregular patterns. And setting the pattern up must be user-friendly and intuitive to use.
It would also be good to link in with the Order Form from the Acquisitions module so that if you go to this step following the creation of an Order the details are already populated in the “Serial Holdings Record”.
Elicits a “Serial Holdings Record” Form. System should allow staff to search on standard search fields such as Title as well as other details such as ISSN. Once the item is identified this will then automatically fill out all details including but not limited to Title, Supplier, ISSN etc.
materials so that its place on the shelf is known. (This could also be called “Shelf location”).
Form)
Months etc)
February etc)
Serial has an issue per month but skips every January
starts again each year, or is Continuous (need a more descriptive field title than “R/C”)
(More details about Publication Pattern below)
It should also be possible to copy from an existing Serial Holdings Record in the system so that multiple serial records can be created, if required.
When issue arrives it must be “Checked In” or received
Details will then be displayed:
If this journal is circulated to specific staff it would be good to have that presented on the same page as a reminder and an opportunity to print out a “Routing Slip”. (See below for more detail).
Standard Search: Title, Keyword, Corporate Author, ISBN, ISSN etc
PO number (Also, not essential but good to have, by staff member who ordered item, by vendor etc)
Takes you into Acquisitions module: Supplier maintenance
Set up Routing lists and customize look of Routing Slip
(See Appendix One for Rachel's response to handling this in Koha)
System has templates for sending Claim Letters to suppliers. Should be able to pull information over from the “Serial Holdings Record” into the Letter.
The Publication Pattern refers to:
And once this is coded into the system it will “know” when each issue should arrive. The system should handle at least 3 levels of hierarchical enumeration (e.g. Volume, Number, and Issue).
Users of the system should only need to input the Pattern, with all relevant data about the serial, and the system should then apply some sort of predictive algorithm to work out not only when the next issue is expected but also automatically assign the correct Volume number, Issue number etc at the time of “Check In”. If there is an irregularity (e.g. it skips a January issue every year - typical of New Zealand journals) then the system should compensate for this.
Koha currently has a “Numbering calculation” formula as part of the serials management module. While it does achieve the correct outcome in that it establishes the Publication Pattern for a serial it is extremely complicated to use. We need to develop a more user-friendly interface. See illustration below:
Our Use Case example is designed to help illustrate how the system would be used and the logic going on behind the scenes. We've created a fictional event at the Client Information Centre.
A new journal has been requested by a staff member and needs to be ordered. It is called “Architecture New Zealand”. The order will only cover a trial period of 12 months as it is not clear whether it will be of interest in the long term.
Its Publication Pattern is Volume then Issue Number and is currently up to Volume 5. The journal is produced 11 times a year and each Volume begins in February of each year. There is never an issue for January (standard practice for New Zealand journals).
Arrange for the subscription. This is done through the Acquisitions module in the Ordering component. The system will first force you to do a Search of the catalogue in order to ensure that this particular journal has not already been ordered or is already part of the collection.
If not, it will bring up an Order Form as per standard acquisitions procedure (whether a monograph, serial or another type of material). A Purchase Order number will automatically be assigned to the form. If the Order is not placed, for whatever reason, then this number can be reassigned to the next Order. (Some libraries will require that this component link in with their company's financial system. The Client does not require this).
Search Bibliographic Utility
It would be good to make use of an existing bibliographic record so that the system automatically fills in some details, if appropriate. At the ISBN/ISSN field you have the opportunity to go to a designated bibliographic database and pull over a bibliographic record using Z39.50. If not found then you must type in the details.
The supplier of this journal is also new and therefore the supplier's details will need to be filled out in the Administration > Supplier Maintenance component before completion of the Order.
The Order Form would have two sections and the following fields:
Item details
Order Number: Purchase Order number - this will automatically be assigned (Could be “Payment Method” for other ways of purchasing)
ISBN/ISSN: SEARCH > Bibliographic Utility
Title: “Architecture New Zealand” (free text but could be pulled down from a bibliographic database at the ISBN/ISSN field)
Supplier: Pick list. If new it will take you to the Supplier Form so that this Supplier is now in the system
Author/Corporate Author: If not automatically populated then you should be able to SEARCH an Authority List so that you choose the correct display of that author's name. E.g. J.K. Rowling not Rowling, Jo K. Same for a Corporate Author - It is essential that the correct spelling and format is used.
Publisher: Pick list. If not already in the system then “Add” to Pick List
Barcode: If applicable (not sure if this is better done in the Add A Subscription form?)
Branch: drop down or pick list
Order Type: drop down list. (E.g. subscription, purchase, gift etc)
Format: drop down list. (E.g. journal, monograph, CD etc)
Accounting details
Quantity ordered: how many will be purchased?
Fund: Serials - Wellington Branch
Pricing: Various fields (need to discuss with the Client) E.g.:
Replacement cost
Actual cost
Discount price
Notes: Only ordering for 1 year - on trial
Once the Form is completed this should then display the next task in the workflow. In the case of an order for a serial this would be Serials > Serials Processing component as the next logical step in the procedure. There should always be the opportunity to modify the Order (delete, add, copy etc).
Once the Order has been completed and the supplier's details are in the system the serial can be “catalogued” in the Serials Processing - Add Subscription component. As mentioned above, it would be good if the item ordered is a serial then a prompt to go to Serials > Serials Processing > Add a Subscription comes up and the details from the Order Form can be re-used in this next step in the workflow.
A “Serial Holdings Record” Form will come up. There are two sections to this Form:
Catalogue Details
If the system has not already populated the Form then the system should allow staff to search on standard search fields such as Title and ISSN. Once the item is identified this will then automatically fill out all details including but not limited to Title, Supplier, ISSN etc.
Publication Pattern
This should be as straight forward as possible. (See details about Publication Pattern).
Once the journal arrives it must be “Checked In”. This is so that the system knows which issues have arrived, are late, missing or pending. The Publication Pattern set up in the Serial Holdings Record will automatically translate the correct Volume, Number and Issue and display that in the appropriate box. Either:
Received Issues
Missing Issues
It should update the Catalogue entry so that if someone was to search the Catalogue for that journal they would see which issues are held (provide full holdings details on the OPAC).
A new Manager has requested that the following journals be circulated to her:
Library staff would set up this person's details in the system as they are new to the organisation. This could be done in the Circulation Module and exist as the Master record for that staff member. These details can then be picked up and re-used in the Serials module (Serials > Administration > Routing Lists).
If a Routing list already exists for the two journals simply add her name to the list (Serials > Administration > Routing Lists) - her details should already be in the system (Circulation).
If the journal is not already circulated then set this up in the Routing Lists. This should then be automatically linked in to that particular journal's Check In screen. At the bottom of the Check In screen there would be a section that displays the list of staff who receive this journal. (This field could be called “Circulated to:”).
It would be nice to have the Routing list for that journal set up so that it can be printed in a format customised by the customer - known as a Routing Slip. This print out would then be attached to the issue and then circulated accordingly.
It would have the following information on it - from fields in both the Routing list and Check In form:
Routing Slip
| Journal Title: | Business New Zealand | Volume & Issue:\\ | Vol. 3, No. 4 | Date circulated: | 1 Sept 05 |
| Name: | Judith Thompson | Location: | Christchurch Office Accounts Department Level 2 | Date forwarded: | (staff member writes this in) |
| Initials: | (staff member initials then forwards to next person on the list) |
Margaret, the Serials Librarian has noticed that issues for the journal, Building Economist, are very late and appear to be missing.
Margaret runs a report in the Serials > Administration > Status Reports component that lists all issues tagged as “missing” and confirms the exact details for this particular journal. The default Claim cycle is 30 days.
She then goes about placing a claim for those issues from the supplier. To do this she goes to the Serials > Administration > Claims component. This should be able to link in with the “Serial Holdings Record” that has all the details for that journal as well as the Report that was run that identified which specific issues were missing.
She selects a Claim Letter template to work from and has the choice whether to print this Letter or email it to the supplier.
The date the Letter was issued should be noted in the system so that if there is no response in a set amount of time (to be determined by the Client) then an alert is set up to notify Margaret that the supplier has still not responded. Of course if the issues arrive then the alert is removed.
Margaret runs a report called “Serial Claims Review” (not sure how frequently?) to view a list of all outstanding claims. This is another way of making sure claims are followed up.
Once issues arrive then they are Checked In as “Received”. Both reports will now be updated to reflect this situation.
Appendix One:
Rachel's response to how Koha would handle routing:
“Scenario: this journal needs to go to Bob the CEO, then Jane in Accounts, then Max in Marketing, then Joan then back to the library? You would set this up as a set of reserves - ie you'd reserve it for Bob, Jane, Max and Joan, and set the issue time for a week say, so that it goes down the line.
If you always do the same list for each journal, weekly/monthly then I'm sure we could do an easy template for that”.