VDX FAQ for ILL Staff
1. How to update campus calendars
2. How to set up Calendars for Holiday closures
- a. If all campus libraries have the same holiday closure hours.
Setting up your Calendar for holiday closures ensures that new requests will come into your "In Process" queue from UC requesters with a delayed expiration date according to your calendar settings.
For example, if your library is closing from 21-DEC-2010 to 01-JAN-2011, the expiration date would be 9 Jan 2011.
This avoids the unwelcome condition where requests would be automatically routing out to OCLC rather than waiting for a UC location to be open. Editing the "Local Holidays" on the bureau level Calendar causes the same edits to be made to all lower level Calendars. This is all you need to do; you do not need to update the calendar for each unit.
- b. If some campus library units have different holiday hours
First update the bureau calendar. Next go to the Calendar for the unit that has different holiday hours and update that Calendar with the unit specific hours.
3. How to set a VDX suspension date:
A requesting library will always be able to add your location to the Rota of a new request, even when it is suspended. The system will automatically skip your location if it is suspended and it will be moved to the end of the Rota. Your location will automatically be re-tried if your suspension finishes before the request reaches the end of its life.
If DocFind-Requester is on for your location, and the only location in the rota is suspended or not available, then the request will go to status Check Manual. There is also an error message on the audit page:
Location XXX rejected: Location is suspended
4. How dates and times are handled by ISO. (Why does the request have tomorrow’s date?)
ISO ILL requires Greenwich Mean Time (GMT) for all date–time fields. VDX uses Eastern Time time internally and does not do any date-time conversion for the items it receives in ISO messages.
VDX ISO messages sent outside of UC’s VDX group follow the ISO rules and the date-time data is converted to GMT. This means that any requests going out from VDX after 4pm California time will be dated the following day!
For example, a request sent at 4:30pm on July 28, would show up as being received by OCLC on July 29, and a response could be received in VDX on July 28 with a date of July 29.
5. Actions that set the expiry date
Items that are processed within VDX: the expiry date is set by the responder
Items that come into VDX from WCRS: the expiry date is set by OCLC
- a. Outgoing actions that set expiry date:
- conditional response
- b. Incoming action that sets expiry date:
- conditional response
- c. Most common reason for short expiry date
- Items that come in over the weekend may not have the full five days, e.g. expiry is five days but two are weekend days.
6. VDX scripts for patron privacy, auto-completion, date correction and archiving
Patron Privacy scripts Patron privacy scripts selects items completed 60 days before the current date and then breaks the link between the patron record and the ILL record. Completed items appear in My ILL Request (Zportal) only for 60 days.
Copynon-returnable auto-complete script This script automatically completes ILL transactions for non-returnable items received 30 days before the current date.
Expired user record deletion script The expired user script checks for patron records that have an expiry date before the calendar date the script runs and that have no active ILL items associated with the user record. Expired patron records with no active requests attached are deleted. This script runs the first Sunday of every month. .
Reset bad shipped and received dates script This script resets the incorrect dates created during a batch process to the correct dates. It runs every night, after 10pm.
Archiving scripts Transactions for the current year, plus two preceding years are kept in the active database. For example in 2010, we have all the records for 2008, 2009 and 2010. The archiving scripts move the completed records for previous years out of the active VDX database to an archive based on the completion date in the record. Active records from earlier years, if any, are not archived, they remain in the active database. The archiving scripts are run manually. Archived records are available for reporting in the data warehouse via Report Runner
7. How Request builds the VDX rota
- A non-lending location does not lend items. (Request has a list of the non-lending and special collections locations.)
- UC campus Special Collections units may lend to a Special Collections unit on another campus.
- Net borrowing campuses:
UCD, UCI, UCM, UCR, UCSB, UCSC, UCSF, UCSD
- Net lending campuses:
- Northern campuses (closest to NRLF):
UCB, UCD, UCM, UCSC, UCSF
- Southern campuses (closest to SRLF):
UCI, UCLA, UCR, UCSB, UCSD
Building the VDX ROTA
The Request resolution service keeps track of the lenders used within a calendar day in a table. This table is used for load balancing.
- SRLF & NRLF, (the closest to the requestor's campus is put first)
- The non-special collections UC locations at net borrowing campuses
- The non-special collections UC locations at net lending campuses (B, D, LA)
- The special collections locations at net borrowing campuses
- The special collections locations at net lending campuses
- The CRL location, if it occurs.
If there are non-special collections locations, only the RLFs, the non-special locations and CRL are used. Locations that are Special Collections are not added.
- These are used in the order they appear above. The non-special UC locations at net borrowing campus and the non-special UC locations at net lending campuses are each load balanced so that the most requested location is moved to the bottom of those lists.
If all the holdings are from Special Collections locations,
- If all the holdings are from special locations, only the RLFs, and the Special Collections locations are used in the order they appear above.
- Note: in the Request interface the patron is prompted and asked to confirm they want to continue or want to skip the request. If they continue it is set to idle in the home campus VDX review queue.
8. What circumstances send items to the home campus review queue
- Campus allows users to override the “available on home campus” message and ask for ILL and the user’s home campus has Request send these to VDX for home campus review instead of direct to lender.
- Item is not owned by any UC campus
- Some campuses VDX configurations do not automatically add OCLC to the rota.
- PIR set the "Material Type" to OTHER which sets the VDX status to IDLE preventing items from auto-authorizing if:
- The Request has insufficient information to determine holdings, thus the citation is marked incomplete and/or
- The ROTA is empty, there is no ISBN/ISSN, and the item lacks an OCLC number or has multiple OCLC numbers and/or
- All UC copies are non-circulating or all UC locations are Special Collections.
- Reminder: In VDX 4.1 the bibliographic data you see depends on the VDX "Item Format" & "Service Type", thus you won't see article details if the "Material Type" is OTHER. You must set the "Item Format", "Service 1", "Service 2", and "Item Details" to match what is being requested.
9. What do the different notes types in VDX do?
|VDX Note Type||Meaning|
|Client Instuction.||This is a note from the end user made at the time of request creation.|
|Item Note||Send this note on the first action to each responder the request is sent to.|
|Public Note||This message is a local note. It is never sent to the other party in the transaction|
|Private note||Transmit this note with every message for this request from the requester..|
|Patron note||This note is created by IL:L staff to send directly to the patron making the request.|
10. How to create or delete VDX User accounts for ILL staff or patrons; how to validate users when entering a new request in VDX web
11. Reasons that Requests get locked in VDX
a. The request is in an authorized auth state
b. The current rota location doesn't have a protocol record setup with a sequence number of 1
c. The driver associated with the protocol for the current rota location is slowly processing requests
12. Can I get a list of all ISO statuses and see how they are used?
13. What is the difference between Request; PIR and PIRAuth?
- Request is the program that controls the interface that the patrons see. (more info)
- PIR is the program that controls the processing for the requested item. (more info)
- PIRAuth is the program that handles patron authentication.(more info)
- a. Request functions
- Request is the patron interface, it handles all human interactions
- Request form collects user’s patron data (form is campus specific)
- Barcode/PIN; home campus, pickup location, etc.
- Collects Copyright acknowledgement
- Displays situation specific messages to user
- Error messages (many are campus specific)
- Asks user to choose specific actions, e.g., use DDS or skip an item when necessary
- Confirmation screen
- Request can handle multiple items in a single transaction
- Request receives all bibliographic data from services such as Melvyl; UC-eLinks and Citation Linker (SFX); and UC’s multi-item service from PubMed (via “Order” button) and captures bibliographic data from direct user input within the Request session for Requests initiated from a Melvyl journal record.
- Interacts with the Melvyl User Profile to obtain user’s profiled data, e.g., barcode
- Uses SFX API to look for systemwide licensed online journals when Request is initiated from a journal record in Melvyl and provides a link to the electronic version if available.
- Passes data to PIR and receives data from PIR
- b. PIR functions
- Handles all ILL and DDS processing (one item at a time)
- Interacts with Request patron interface
- Interacts with PIRAuth to authenticate patrons
- Validates data
- Returns error/success codes to Request
- For Requests originating outside of Melvyl checks Melvyl via Z39.50 for holdings/circulation data
- Interprets location and circulation status messages to determine the availability of an item.
- Passes data to VDX, OCLC ILL service, and campus DDS systems
- Creates III bridge records for UCSF and UCI
- Creates and load balances the rota for VDX/lender strong for OCLC
- c. PIRAuth functions
- Authenticates patrons against campus library circulation or LDAP system
- Interacts with PIR
14. What happens when I de-ISO an ILL request in OCLC WCRS?
If you choose to de-ISO a Request in WCRS then the link to the item in VDX will be broken. All future actions must be done in WCRS. Because the link to VDX will be broken, you will need to manually update the VDX record to keep it in sync with the WCRS record.
The de-ISO feature is not available in WSILL; you will need to use the Report a Problem procedure if you feel the need to de-ISO a request. Be sure to include the reason you need to de-ISO the request.
15. How can I find out who authorized a Request?
The authorization signature displays in the right column of the History in the 'Details display'.
16. Why did an item come in from WCL via UC-eLinks without UC holdings, when I see UC holdings for that item.
When a Request is initiated in WorldCat Local, the information passed to UC-eLinks in the OpenURL is from the specific record the user is viewing, and the holdings are based on OCLC number. It does not include any holdings for other items in OCLC with that title but with a different OCLC number. If the OpenURL does not include an ISBN or ISSN Request cannot attach holdings. When you do a title search, you may retrieve more than one matching record.
WCL uses the OCLC number as the key for matching. Only a single record will match on this number.
In current Melvyl we use ISBN or ISSN for matching. There may be multiple records that match. CDL and OCLC are working on ways to get better holdings as part of the WCL Request project.
17. How can I add locations to the rota using the OCLC symbol?
Enter "OCLC:" followed by the OCLC symbol. For example:OCLC:B2Q
18. For OCLC WCRS locations we list the location multiple times to allow them more time to fill the request. Should I list the location for one of UC’s ISO partners multiple times?
Multiple listing of OCLC locations is no longer necessary; the respond by time is set in the lenders OCLC Policy Directory record.
19. When I sent a Conditional-Reply-No to OCLC WCRS, why did the WCRS request get canceled?
The ISO-ILL protocol requires VDX to cancel the WCRS request when you send a conditional-no. From the ISO protocol: (ISO 10161 section 8.3.2)
- A Conditional-Reply with the Answer 'NO' is to be mapped onto the subtransaction (ED: ie must be relayed to the supplier). Note that in this case the intermediary may not initiate a new sub-transaction with another responder.
This means that if a brokered-to supplier sends an answer:conditional to the broker, the Broker is mandated to relay the answer conditional to the requester. The Broker is also mandated to relay any response to this conditional to the current supplier. If the requester responds NO – then the broker must relay this to the current supplier, thus in one go both the sub-transaction and the requester/broker transaction have to go to Not-Supplied. AND the broker is explicitly forbidden from starting a new sub-transaction.
When OCLC are brokering as part of an ISO transaction they should NOT continue through their lending string if one of their suppliers gets a NO in response to an Answer:Conditional.
20. How are OCLC locations handled in VDX?
Currently, there are two ways that OCLC locations are handled in VDX:
- option a: only one lender in the WCRS request
- option b: 'stacking' multiple lenders into one WCRS request, for example, items that are sent to OCLC as "direct to profile"
21. Why is there no payment type on this OCLC WCRS request?
According to the WCRS instructions for Lending charges the payment type is supposed to be left blank if they enter the word "free", which is why there is no payment type in the parent VDX request. Any time a payment type is blank on the picklist or in the request, the max cost (if any) should be ignored and assumed to be $0.
22. Why isn’t the item brokering?
If you tried brokering it over to another location but the Request won’t move, check to see if you changed the "Auth status" on the item to "Authorized" when you did the brokering action. If you did not, then try again but changing the Auth Status.
23. We received a Conditional because we forgot to pick CCL/CCG, can we fix this?
For VDX/OCLC borrowing requests you can't directly change the CCL/CCG, maxcost, or shipping address fields once has gone out to OCLC WCRS. Doing a local change does not modify the current request.
Once a Borrowing request has gone out to OCLC WCRS just about every field on the OCLC request is "frozen" as it was originally transmitted for the life of that request string.
24. How are the Work queue dates set?
Borrower Pending > 2 weeks The time span is calculated from Entry date to Current date
Borrower Shipped > 2 weeks The time span is calculated from Date Shipped to Current date
Lender Overdue sent > 4 weeks Actual service date
25. How are the entry dates set? WCRS entry dates and VDX dates seem different
For a UC to UC Lending request the Entry Date is the date the request entered the Borrower's queue.
For an incoming OCLC request the Entry Date is the date the request entered the Lender's queue.
Questions? Contact Discovery & Delivery Team (firstname.lastname@example.org)