Autodocs: A Federal Documents Check-in System

A Detailed Explanation

by H. Vernon Leighton

Summary

Autodocs is an electronic check-in and shelflist system designed to be used with Microsoft Access 97. (It has been tested and can be converted to Access 2002.) It allows one to download an electronic shipping list to check-in and shelflist receipts without keying in shipping list data. There is a method of handling items that regularly arrive without a shipping list. Labels are generated only at the end of the session, not at the end of each shipping list, thereby reducing the number of wasted blank labels.

The zipped version of the Autodocs system and documentation is located at:
http://www.winona.edu/library/gov/autodocs.htm

The User's Guide and FAQ to the Autodocs system is located at:
http://www.winona.edu/library/gov/autoFAQ.htm

Within the zipped packageare files entitled:

autodocs readme first.txt - this introduction file
autodocs14.mdb - the autodocs system itself, in Access 97 format
autofaq.htm - likely questions and general information about Autodocs answered about Autodocs in html
autotutorial.rtf - an detailed walk through of the features with the preinstalled demo data tables.
procedures14.rtf - the detailed procedures for checking in materials
procedures14.doc - the same file in Word 2002 format.
ship.dbf - a shipping list of paper items that can be used to test the check-in. (They are not yet in the database.)

Detailed Description

The Types of Items Checked-in

I have created four classes of items that get received: the first three are paper, maps, microfiche and electronic items. All formats allow you to manually key data into a blank shipping list. All formats except maps also allow the user to import shipping lists in dBase format as downloaded from the FedBBS web site. The paper format also allows users to customize a list of direct mail items. There are many fewer of these than there were in 1999 when Autodocs was first released.

I have created functions to allow the list of items selected and the other lists (e.g., superceded items) to be printed out so that the items can at least be checked in and processed manually if necessary.

The Check-in Process (briefly)

For shipping lists where there is an electronic copy in dBase format on the FedBBS, the first step is to and download the shipping list to your hard drive, and then prepare to import it into Autodocs.

The shipping list that was downloaded from the FBB server is automatically run through the institution's selection profile, so that person checking the material in (the checker) only sees those items that matched the profile. (There is the obvious drawback that these lists aren't perfect, but there is a function to edit and add to the shipping list if the items fail to be processed due to typos on the shipping list.)

After the shipping list is filtered against your selection profile, the system checks helper tables for a match to the item. I have customized these tables for our operation at Winona State, so I apologize to anyone who has a different setup and wants to use this system without having to customize it.

I have three helper tables. The first tries to match the new item to the 1996 list of items that are superseded. The second matches the item against a local list of items that get special treatment (for example, the series gets cataloged in Library of Congress and is in a different location with a different call number). The third table changes the label information if the series gets a special label (for example, slip laws in our depository all get a quick label with an LC number, though they are not individually barcoded and cataloged).

I call the shipping list that has been enhanced with local details the "check-in list". It is stored in a table called the Intermediate Ship Table. Step three in the check-in process is to display this enhanced check-in list for review. The checker then compares the displayed records to the actual items received and to the paper shipping list. If an item is not received, the person can delete the item from the check-in list. If an item is on the superseded list, the person can automatically search the shelflist for all items that have the same class stem, to easily delete the superseded edition. The check-in list record will indicate special handling of a class gathered from the helper tables. Labels can be suppressed at the individual item level. What the label says can be changed on the fly by the person processing.

Once that list is finished, the checker may add the label items to the label job. Then the checker may in step 4 add the items to the shelflist, and delete the just finished shipping list in preparation for a new one. At the point of adding to the shelflist, a field is created that allows items to be sorted by SuDoc number. (The algorithm for this sorter is adapted with permission from SuDS by Stanley Price at USC Aiken.) When check-in is finished, the checker runs another macro that prints labels and deletes the temporary label table.

Searching

The final shelflist can then be searched by Sudoc number, by date, by title keyword or phrase (but not Boolean syntax), by item number, and by format, or any intersection (Boolean AND) of those searches. The searches are automatically truncated, so you can search for all items from the Geological Survey (I 19) that have the phrase "Mississippi River" sent on a shipping list from a given year, etc. The searching is not world class (fully SQL), but it works. Skilled Access users can create their own queries.

What is Missing

I have not yet developed a weeding module that creates candidate weeding lists from the shelflist. At Winona State, we have only been using the system for four years, so there are no older records yet to weed. When I looked at Kendra Swope's system, she had a table for storing information about the shipping list, which I decided not to include. (Too much keyboarding.)

One major structural problem is that there are no serial records. Every piece is treated as a unique item. The reason for this is that the shipping list treats each item as unique. My goal in this system is to reduce the amount of keyboarding that the checker needs to do. Adding a serial record would, I believe, add to the keyboarding and the time that check-in requires. I do not think that serial records are absolutely necessary, especially since you can search the shelflist by class number and pull up all items in the series. So I have stressed the convenience of the checker over the cleanness and friendliness of the database.


Features that have been added to Autodocs in version 1.4

  1. Added a map format. With ingenuity, you could have processed maps through Autodocs 1.3, but this will make the process easier.
  2. Added blank shipping list forms for each of the other formats. This will make adding items whose shipping lists are not on the FedBBS (such as contractor microfiche) easier.
  3. Cleaned up some poor internal names and designs that the user does not see.


Features that have been added to Autodocs in version 1.3

  1. Ability to sort by Sudoc number: I have borrowed with permission Stan Price's SuDS algorithm for creating a field from the Sudoc number that can be sorted by MS Access's standard sort function. It has it's limitations, see the AutoFAQ for an explanation of how it works.

  2. Support for weeding: A new field to be stored in the Main Shelflist will signal someone working on a weeding list that this item should not be considered for weeding. Version 1.3 still does not have a function to create a candidate weeding list automatically, but this field is a first step. By eliminating from consideration all series that are permanently retained, It will make the weeding process smoother when I finally add a weeding function.

  3. Add to labels: I have added a feature to add items from the Main Shelflist to the temporary labels files. You can search by either shipping list number or through the general search form, find an item, correct its Sudoc and label number, and then get the corrected number sent to the label table to be printed.

  4. Previewing print jobs: I have changed all of the report printing functions so that instead of printing directly out, they preview first. Then the person printing the report can see the results before they are sent to the printer.

  5. Printout of search results: I have added a feature so that from the General (and the Public) search forms, you can have the search sent to a report to be printed.

  6. When updating the EXCEPTIONS table, I have changed the initial search from a search by Sudoc number to a search by Item number. I did this because the Item number is required but the Sudoc number can be left blank (and at Winona State, now it usually is).

  7. Exception Note to Shelflist note: At one user's request, the note in the Exception field (field DOCSORLC) gets transferred to the Note in the Shelflist during step 2 of check-in. On the Check-in form, you can always change that note, edit or delete, but it is a way to get notes automatically loaded.

  8. More lateral moving among the screens. All of the check-in screens now allow you to jump to shelflist searching or other operations. All of the staff shelflist search results now allow you to create a label file as well as append to it when you are fixing sudoc numbers. So if you go in and forget to start the labels, try to add an updated call number to the label file, and it complains that you don't have a label file, just start one.

  9. Both the Public searches and the staff searches now can be output to a generic report. So for a quick bibliography of all Foreign Labor Trends, or all documents with the phrase "really cool" in the title, you can print them out.

Disappointments:

I wanted the form to automatically rebuild the sorting field when you change the sudoc number in a Main Shelflist record. I fought Visual Basic, and Visual Basic won. You have to rebuild all of the sorting fields of all of the records in order to fix the ones that you had edited. If anyone is a VBA hacker and can fix it, please contact me. I will give you credit if you succeed.

revised hvl 9/12/2007
H. Vernon Leighton
vleighton@winona.edu