The Requests database is designed to support various workflows associated with pulling physical materials/tracking their return to the shelves and for fulfilling requests associated with digital resources.  A framework for the design of the module is represented in this illustrative classification of request types:

1)	Requests for Physical Materials (described in the Catalog)   PULL/ONSITE RESEARCH   PULL/PHOTOCOPY   PULL/DIGITIZE
2)	Requests for Physical Materials (not described in the Catalog)   PULL/ONSITE RESEARCH   PULL/PHOTOCOPY   PULL/DIGITIZE
3)	Requests for Digital Resources (associated with cataloged items)   DIGITAL/SEND (e.g., the high resolution file)   DIGITAL/PRINT
4)	Requests for Information:  INFORMATION/REFERENCE

The module can also be used to track pulls associated with internal processing and digitization projects, as well as pulls associated with exhibits and the loan of original materials.

A number of special reports have been designed for the module:

•   A Pull Report with configurable page/form elements to facilitate management of your retrieval and return procedures
•   Several statistical reports to help you track and analyze the services that are being provided to your user constituencies

The tasks in the two groups of this new module are displayed below and described in the next several sections.

Tasks:  Create new records... and Complete unfinished requests. The first two tasks in this group are used to log (and complete) a request record (in the .AREQUESTS transaction database). A record represents the following: a single researcher, one or more requested items, and a single delivery location for the requested items (e.g., Reading Room). More than one researcher can be associated with a request record but only one can be designated the primary requester.

The Create... logging task uses a multi-part transaction form designed to facilitate working with requests for which multiple items are identified to fulfill the research interest (e.g., requests that involve the pull of multiple containers). The form provides for filling in general request data and information on up to 10 items. If a request involves more than 10 pulls/items, you can create additional records, copying the general request data and cross-referencing the records. When a record is created and you have entered (or selected) the primary Researcher/Requester, the system automatically constructs a Group Request Number. The three-part number illustrated below in the Assigned Number field (protected) is constructed as follows: up to 15 characters from the name – today’s date, in YYYYMMDD format – a unique 5-digit number.

Until you have completed your research to identify the containers/items to be specified in the record, leave the record in a HOLD state and use the Complete unfinished records. task to recall it over time as you gather the information needed to finish the record. When you have completed a record that involves pulling physical materials, you have the option of immediately generating the Pull Report after setting the Explode Status field to EXPLODE and clicking the Done button. The EXPLODE setting triggers one or two actions:

Separate records are automatically created in the Requests database (.ASERVICES) for each item, along with its general request data, so that you can more easily track returns/reshelving and fulfillment. If you marked in the multi-part form that an item was to be pulled from its assigned location and that item is linked to a Catalog record, its Catalog record will be updated to populate several fields: the Request/Pulled Date, Last Retrieval Date (set to “today’s” date), and Retrieval Count (which is incremented). This means that, when working in the Catalog, you can easily determine whether an item is no longer in its assigned location (or will not be shortly).

In the schematic that follows on the next page, we depict the concept of your creating a transaction record, using the multi-part form illustrated in the Log a request section on the left. When the record is complete and you have triggered the EXPLODE, the set of records that will be constructed automatically are illustrated on the right, in the Track requested items section. The fields shown in the schematic are illustrative only; all fields are described in the Help pages associated with the input form tasks.

The EXPLODE operation that is triggered from the multi-part transaction form works as follows:

• if you fill out only the “general requests” data, e.g., for an “information/reference” request type that does not involve a pull, a single exploded record is created
• if you fill out only one part of 10 for requested items, a single record is created that represents the “general request” data and data for that one requested item
• if you fill in all 10 item sections, 10 separate records are created, where each includes the item-specific data and the “general request” data

As already noted, this separate requested-item data structure (i.e., the database with the exploded set of records) allows for more efficiency in tracking those items through to completion of the process. For example:

• a given request might involve multiple request types (e.g., for pulls of physical materials and requests for digital files), so that each would require its own fulfillment path
• multiple pulled items may be returned at different times for reshelving/re-filing

In the EXPLODE operation, an Item Request Number is constructed for each item from its Group Request Number, with the addition of a 2-digit number at the end of the string. For example, the first requested item for Group Request Number EVANSCHARLESL-20111204-00347 would be: EVANSCHARLESL-20111204-00347-01.

Task: Edit Request Records/Generate Reports & Statistics. In this task, you are searching the exploded records (in the .ASERVICES database), representing one or more records for any given request. Use this task to:

• Generate the Pull Report (on any set of records, whether marked Pulled or not)
• Track requests still to be fulfilled (i.e., not yet Closed)
• Modify General Request data (which automatically updates all of the item records associated with the request) and/or specific item data (e.g., to flag reshelved and by whom)
• Generate any of several management and statistical reports

Tasks: Batch Updates. The three tasks in the group provide for performing selected operations on a batch of records (instead of using the Edit Request Records... task to make the changes one record at a time). The global Action operations are summarized below and in more detail in Attachment 6. Batch Updates.

Mark items pulled/update catalog pulled data. When you first create a record, you can mark it “pulled,” even though procedurally the pull will be done later. Alternatively, if you forget to mark some items pulled and/or prefer to update the records after the pull is done, you can use this task to retrieve the set of records and have them updated at one time. Optionally, you can also have the system update the Catalog records to populate the several request-related Catalog fields.

Mark items returned/reshelved (by me). This task provides several options, to mark records returned, both returned and reshelved, or returned/reshelved and closed. The (by me) in the task name indicates that the “who reshelved/who re-filed” field will be populated with the ID of the staff member performing the global Action. If a different person did the reshelving/re-filing, edit records individually (until another batch update task is added to the application in a future release that allows you to specify the ID to be assigned).

Mark CLOSED/Clear Catalog Pulled Data. This task lets you close out a request at any point in your fulfillment process that fits your definition of “done.” If a requested item record is associated with a Catalog item, the Pulled Data field will be emptied automatically on the assumption that the item has been (or will be) returned to its original or new assigned location.