The following user information displays at the top of wizard window. The Reply tab displays below the user information, along with the Basic and Request tabs.
| • | Profile Name |
| • | Request ID |
| • | Request Type |
| • | User ID |
If the request is linked to an item in the catalog, title, author, call number, and item information will display on a platform button. Click the button to display detailed volume/copy information.
The Name and User ID glossaries display more information about the user.
The Reply tab for the Request wizards may contain the following information. Information will vary based on the request type.
| • | Date Replied or Reply Date |
| • | Reply Text (Entries will vary based on the request type) |
| • | Service Library |
| • | Status |
From the Reply tab, you have the option to modify this request, return to the request list, move to the next or previous request, look up another request, or exit the wizard.
The following fields are defined for the Reply tab.
Date Replied or Reply Date
This is the date entered by the user who answers the request.
Note: When a request record is created or duplicated, this date is automatically set to NEVER. As long as the request does not yet have a reply, or the reply is not ready to be seen by the library user, this date should remain NEVER. As long as the reply date is set to NEVER, the user cannot view the reply.
Use the drop-down list to select TODAY when the request has been answered. The system will supply the actual date of the reply when the library user views his or her request record.
This field contains a User Profile policy name. This is a required field when creating a user. Example Profile names could be STUDENT, ADULT, Faculty, Guest or LOST CARD. The User Profile policy name determines the user’s privileges, loan period and fine rate.
Reply Text (Entries will vary based on the request type)
In WorkFlows, reply text is entered into the Reply Tab. The template that displays consists of entries that are defined by the library in the Reply Format policy. When replying to a request, the Status Field and the Reply Date Field should also be updated.
This field contains the unique number, up to 20 characters, by which requests are identified.
Note: Selecting AUTO from the list automatically generates a unique request ID patterned after an established scheme. The SirsiDynix Symphony administrator may create a pattern that has a prefix, an incrementing numeral, and a suffix, such as REQ/1000-93. In a multilibrary system, each library may have a different pattern, such as REQ/MAIN-1000, REQ/WEST-1000, and REQ/;MURREY-1000.
The request type identifies what the request is to be used for and the format of the display. Request Type and Request Format are separate policies, but they may use the same policy name.
| • | Request Type is a policy which establishes the behavior of the request, such as whether user or item information is required. |
| • | Request Format is a policy that determines what text entry fields are available when a request or reply is displayed. |
In the Request module, the Service Library displays the library whose staff should respond to a request. Service Library defaults to the same library as the originating library, but this field may be changed to any library listed in the policies. Service Library allows staff at one library to direct or redirect a request for response by another library.
You may use the Service Library alone or combine it with Status to produce a list of requests. By specifying a library only, a list of all requests created in, awaiting a response from, or answered by that library, will appear. By specifying a library and a status, a list of all requests in that library with the specified status displays.
Note: The Library field does not display in a single library system.
Status for Requests
This field contains the status for a request record. The status name is based on a defined policy. All request records may be displayed for a particular service library that has the same status.
Note: Each request type must have a default Status policy defined that will be assigned to a new request during the Create Request process.
For example, all ILL requests would default to a status of NEWILL. While a default status exists for each policy type, the Status drop-down list allows the operator to change to another Status policy for the request being created.
If the Request Type policy defines user identification as necessary to the processing of the request, and the library has specified that a user should enter his or her user ID, then this field displays when a request is placed. If it displays, it may be optional or required. This field may contain up to 20 characters of the ID of the user for whom the request is being placed, or the operator’s user ID.
Note: You can enter a user ID using the User Search Helper or the User Search Gadget
© 2006, 2014 SirsiDynix