« May 2006 | Main | July 2006 »

June 26, 2006

Returned requests not Checked In

We have a patron who has about 14 items returned quite a while ago in MNLINK. The system won't allow him to place anymore requests because it thinks he is above our 20 item limit. Is there any way that his MNLINK record could be manually cleared?

This is a good question about what is the proper way to clean up those requests that have been returned awhile ago, but were never Checked In. We will always have these items slip through the cracks because the paperwork was missing or just not noticed in the Returned request.

Here’s what I suggest, first choose the Action of Message on a request that has been returned. When the new screen opens you can leave the New Note Type as is and add a note to the New Note box. Your note should say something like "we returned this item on 6/29, would you please check your shelves to confirm this item has been returned and then Check In on VDX". This will put a message in their Lender Queue Message file.

It is important to be monitoring the Message file in both the Lender and the Borrower Work Queue. When there is a request in this file someone is likely awaiting a specific response, much like if a request was Conditional or Renewal.

There is also the option to call or email each library about the requests in question. You can find detailed contact information in the MINITEX ILL Policy Database. You can find the search page here: http://www.minitex.umn.edu/illpolicy/search.asp

If anyone has any questions or some other ideas about how these requests should be handled, please let me know.

Thanks for asking Steve, this was a great question!

June 21, 2006

Terminate request/Cancel request

This is just a reminder about the Terminate Request/Cancel Request functions.

The Terminate Request function is initiated when a user chooses the Cancel option in their ZPORTAL account. It is also a possible Action in VDX. When this occurs while the request is Pending in the Borrower Work Queue the request will move to the Cancel Pending file with the addition of a line of text in the body of the bibliographic information which says “Request No Longer Required”. This note appears in a red font and is hard to miss. When the user chooses the Cancel option in their ZPORTAL account after the request is shipped the request will stay in the Shipped file. The Lender will have the request appear in their Cancel Pending file. The Lender will have the responsibility of responding Cancel Reply-Yes or Cancel Reply-No.

  • If the Lender chooses Cancel Reply-Yes, this will cause the request to be automatically Completed on their end. On the Borrower end the request moves from their Cancel Pending file to their Cancelled file. The Borrower will then need to manually Complete the request. This request will continue to count against the user’s Request Limit until the request has been Completed.

  • If the Lender chooses Cancel Reply-No, the request remains active and goes back to the Lender file it was in at the time that the Action was initiated. The Borrower will also have the request restored to its previous Status file, and the note “Request No Longer Required” will continue to appear.

The Terminate Request function is essentially a combination of the multiple steps that were required with the earlier versions of VDX to Cancel a request. It Cancels the request to the entire Rota. Previously we would have to clear out the Rota if we wanted to Cancel a request. If we did not clear the Rota the request was only cancelled to the current Lender and the request would move on to the next Lender when the response Cancel Reply-Yes was given.

If the user chooses to Cancel a request that is still in the New file, you should just Complete the request. The request will appear with the note “Request No Longer Required” in the New file, but it has not gone out to any Lender. Because no lender has been contacted you should Complete the request.

The Cancel option in VDX will respond the way it did before the upgrade.

If anything doesn’t seem clear or if you have more questions, don’t hesitate to ask.

June 20, 2006

Handling Conditional requests

It is very important to follow up on requests in the Conditional file. Often someone is willing to fill the request, but they just need some more information.

When a request appears in the Conditional file of your Borrower Work Queue you will need to look at the Details to read the note explaining what information is needed. The most important thing to remember about responding to a Conditional request in your Borrower Queue is to use the Conditional Reply-Yes or Conditional Reply-No options in the Action drop-down when responding. Do not use the Message option. The Lender will be unable to update the request if you use the Message option to respond. Sometimes you will need to contact your patron to comply with the request for information. If you use the Conditional Reply-Yes the request will move back to the Lender’s In Process file. Make sure to supply the requested information. There will be no need to change the New Note Type unless you would want all possible Lenders to see the message. The Lender can then take the appropriate Action to fill the request. If the Borrower responds Conditional Reply-No the request will move from the current Lender to the next Lender in the Rota.

When you are the Lender and you need to ask for more information to fill a request you should use the Answer Conditional option. When you choose this option, enter a clear note in the New Note field so the Borrower will be able to understand what is needed. There is no need to change the New Note Type from ToCurrntLndr. Make sure to watch your Work Queue for the request to move back to the Lender In Process Waiting file.

Responding to Conditional requests promptly will enable out users to get the appropriate material in a timely manner.

June 7, 2006

Overriding request limits

Things seem to be coming along nicely since the changeover this weekend. We’ve been getting many questions every day related to the new request limits. This one just came in moments ago.

How do you override the request limit?

There is no function which turns the limiter on and off for a single patron. We can only turn it on and off by library system. They will be blocked from requesting beyond their system’s limit on ZPORTAL. You should not have any problems requesting beyond the limit on VDX. So if you choose to request beyond the limit for a single patron, the ILL staff will need to place the requests.