ILL Actions
2 types of Actions are now defined within VDX:
Protocol Actions (Type 1)
Use
Protocol actions are generally used to change the status of a request.
This usually results in an ILL protocol message being sent from the borrower
(requester) to lender (responder), or lender (responder) to borrower (requester).
However, there are some protocol actions that do not result in a message
being sent e.g. Add Private Note, Change Local Request Details, Complete.
Availability
Protocol actions are provided as a standard part of a VDX system. The
availability of an action for a particular request will depend on the
requesting protocol in use and the current status of the request. However,
it is possible to 'hide' an action from all staff users. The actions and
the order in which they are displayed can be locally defined and will
be dependent on the ILL status. Any local configuration can be done through
the windows admin client.
Note: the pull-down
list of actions may include both protocol and locally defined actions.
Protocol Actions available to Borrower (Requester)
Request Send the ILL request to the next location on the rota.
Cancel Cancel the current transaction for this request.
NOTE: This only cancels the current transaction with the current supplier,
it does not cancel the request as a whole, and may lead to the request
being automatically sent to the next supplier on the rota.
Conditional-Reply
Yes If the current supplier has responded by sending an ILL Answer-Conditional,
this action is performed in order to confirm the borrower (requester)’s
acceptance of the conditions. Both parties revert to their original statuses
of Borrower (Requester) being Pending
and Lender (Responder) being In Process.
Conditional-Reply
No If the current supplier has responded by sending an ILL Answer-Conditional,
this action is performed in order to confirm the borrower (requester)’s
rejection of the conditions. This automatically terminates the current
transaction for both parties. The Lender (Responder) goes to Not
Supplied 'and the borrower (requester) goes to Pending
with the next supplier on the rota.
Received This action acknowledges receipt of the delivered item by the Borrower
(Requester). In the case of electronic documents
received by the Document Receiver programs - this action will be triggered
automatically by VDX. In a Copy request, this action completes the transaction
as far as the Borrower (Requester) is concerned.
Unreceive For LASER and IFM
transactions only.
This action allows the Borrower (Requester) to undo an accidental Received action. This action will also
"undo" any inappropriate IFM transaction that may have been
triggered by the incorrect "Received" action.
The ISO ILL protocol has no equivalent action or message.
Cost
Adjustment This action allows the borrower (requester) to adjust the cost-to-borrower
(requester) field of the request after receiving the Shipped or sending
the Received message. This covers the case where
the Shipped cost and the cost on the eventual invoice are different, and
the Borrower (Requester) wishes to make the cost in the Request record
match the cost in the Invoice. This is a’ local’ action in that it does
not affect the other party in the current transaction.
Renew This action allows the Requesting institution to ask the Supplier whether
they are willing to renew the current inter-library loan.
The request will go into a state of Renew-Pending until the supplier responds
by sending a Renew-Response=Yes or a Renew-Response = No.
If the Renew-Response = Yes, then the due date of the request should automatically
update to the new due date contained in the response.
This action is only available if the shipped-service-type is’ Loan’
Returned This action allows the Borrower (Requester) to notify the Lender (Responder)
that the borrowed item has been returned to the supplier.
This action is only available if the shipped-service-type is Loan.
This action completes the transaction, as far as the Borrower (Requester)
is concerned.
Informed Shipped If the request has gone to a Location using an email
protocol or the Generic Script
protocol, then the requesting location can enter this response 'manually'
on behalf of the lender (responder), to indicate the item has been shipped.
This is useful when the responding location is unable to send a response
via the VDX system. By using this action the VDX database is still updated
and the request moves from Pending
to Shipped. Suitable fields are
made available for you to record relevant information.
Informed
Not Supplied If the request has gone to a Location using an email
protocol or the Generic Script
protocol, then the requesting location can enter this response 'manually'
on behalf of the lender (responder), to indicate the item is not supplied.
This is useful when the responding location is unable to send a response
via the VDX system. By using this action the VDX database is still updated
and the request moves from Pending
to Not Supplied. Suitable fields
are made available for you to record relevant information.
Informed Renewed If the request has gone to a Location using an email
protocol, then the requesting location can enter this response 'manually'
on behalf of the lender (responder), to indicate the item has been renewed.
This is useful when the responding location is unable to send a response
via the VDX system. By using this action the VDX database is still updated
and the request moves on to the next stage.
By using this action the VDX database is still updated and the
request moves from Received or Renew/Pending
to Received. Suitable fields
are made available for you to record relevant information.
Terminate Request Terminate Request cancels the entire request. It prevents the request
being sent to further locations on the rota.
Send User Alert Allows the borrowing location to send an 'ad-hoc' message to the end
user. An email with a patron note can be sent. A private note for library
staff can be entered with the action.
Actions available to Borrower (Requester) and Lender (Responder)
Local Change Request Details This action allows both the Lender (Responder) or more usually, the
Borrower (Requester) to update the bibliographic or service details of
the request without this information passing to the other party in the
current transaction. Any such changes will be reflected
in any subsequent transactions for this request.
Add
Private Note A private note can be added which will not be sent out with the request.
Send
Public Note A public note can be added that will be sent to the Lender (Responder)
or Requester.
Resend Last Message If a message failed to transmit properly, or if it failed to be received
by the other party, this action allows either party to re-transmit the
last valid outgoing message.
The message to be resent must still be valid for the current status of
the transaction. The details in the message are
not allowed to be changed from the initial transmission except for the
Note which can be specific to each re-transmission. VDX
will not re-transmit the ’last message’ if it is no longer valid to do
so.
NOTE: This is not strictly speaking a chasing mechanism. It
is a fail safe to cope with those occasions where a message has got lost
between sender and receiver.
Lost This action allows either party to report that the item either never
arrived or that they lost it once it came into their possession. Both
parties requests will go to the LOST status.
Damaged This action allows either party to report that
the item they have received has been damaged.
This action does not affect the status of either party.
Complete Use to complete request and remove from work queue
This action does not send any message to the other ILL participant.
It sets the date-completed of the request to the current date and time.
This causes the request to not display in most work-queues or request searches.
Completed searches can always be retrieved by searching specifically for
a given request number, or by ticking the "Display completed requests"
in the Advanced Search screen, as part of a search.
Actions available to Lender (Responder)
Answer Conditional This action allows the supplier to reply that the item is available
under certain additional conditions.
The borrower (requester) must reply to these conditions with a simple Yes
or No response.
The request goes into a state of conditional
for both parties.
Answer Will Supply This action allows the supplier to indicate that they will be supplying
the requested item shortly.
This message has the added benefit (to the supplier) of turning off the
Expiry timers at both ends of the transaction.
This action does not otherwise change the state of the request at either
party.
Answer Hold This actions allows the supplier to say that the requested item is not
immediately available, but that when it comes back it will be trapped
in order to satisfy this request.
Answer hold should never be actioned if the borrower (requester) explicitly
set the Can Hold flag to No in
the request.
This action does not change the status of the request at either party.
Answer Nonsupply This action allows the supplier to state that the requested item cannot
be supplied.
This action completes the transaction as far as the Lender (Responder)
is concerned.
The Borrower (Requester) may well move on to another potential supplier
on the rota on receipt of this message from the current supplier.
Answer Locations-Provided This action allows the supplier to state that the requested item cannot
be supplied.
This action completes the transaction as far as the Lender (Responder)
is concerned. The Borrower (Requester) may well move on to another potential
supplier on the rota on receipt of this message from the current supplier.
Cancel Reply-Yes This action allows the supplier to confirm that they agree to cancel
the current transaction.
This is the end of the transaction as far as the Lender (Responder) is
concerned. The transaction terminates in a state
of’ Cancelled' The borrower (requester) is free to start a fresh transaction
with another supplier.
Cancel Reply-No This action allows the lender (responder) to confirm that they do not
agree to cancel the current transaction (because they have already transmitted
the document the borrower (requester) for instance).
The Borrower (Requester) and Lender (Responder) will go back to their original
statuses of Pending and In-Process respectively.
Change Current Service Type Available to the Lender (Responder) when the request status is In Process. This enables the current
Service Type on the Request to
be changed to one other of the requested service types. It allows you
to perform a subsequent Action on the request, that would not otherwise
be possible for the current service type.
Shipped This action allows the Lender (Responder) to state that the item has
been sent to the borrower (requester).
In a copy transaction, this message terminates the transaction for the
Responder.
In a loan transaction, this status of SHIPPED remains the same until the
lender (responder) admits to having lost the item or item is checked back
in to the responding ill department.
Unshipped Only available for LASER protocol and IFM.
This enables a Lender to "unship" an incorrectly shipped item.
This action also "undoes" any inappropriate IFM transaction that
may have occurred as a result of the wrongly applied "Shipped"
action.
Overdue This action notifies the borrower (requester) that the inter-loaned
item is now overdue at the Responder’s system.
Recall This action notifies the borrower (requester) that the inter-loaned
item is needed urgently, and that the item should be returned to the supplier
immediately.
Renew Reply-Yes This action allows the lender (responder) to agree to a renewal of the
loaned item. The due-date for the loan is
updated to the new due-date stated in the action screen.
The request status reverts to Shipped
for the supplier and Received
for the borrower (requester)
Renew Reply-No This action allows the lender (responder) to refuse to renew a loaned
item.
The request status reverts to Shipped
for the supplier and Received
for the borrower (requester).
Checked
In This action allows the lender (responder) to notify the borrower (requester)
that the returned item has been successfully checked back into the supplying
library’s collection.
Informed Cancelled If your Location uses the Generic
Script protocol and you want to respond to a request 'manually' to
indicate the borrower (requester) wishes to cancel, then you can use this
action on the borrower (requester)'s behalf. This is useful when the requesting
location is unable to send an ILL message via the VDX system. This still
updates the VDX database and moves the request from In
Process to Not Supplied.
The Note field is available for
you to record relevant information.
Informed Received If your Location uses the Generic
Script protocol and you want to respond to a request 'manually' to
indicate the borrower (requester) has received the item, then you can
use this action on the borrower (requester)'s behalf. This is useful when
the requesting location is unable to send an ILL message via the VDX system.
This still updates the VDX database and moves the request from In
Process to Shipped (unless
the item was already at Shipped).
Suitable fields are made available for you to record relevant information.
Informed
Returned If your Location uses the Generic
Script protocol and you want to respond to a request 'manually' to
indicate the borrower (requester) has said they have returned the item,
then you can use this action on the borrower (requester)'s behalf. This
is useful when the requesting location is unable to send an ILL message
via the VDX system. This still updates the VDX database and moves the
request from In Process to Shipped (unless the item was already
at Shipped). Suitable fields
are made available for you to record relevant information.
Locally-defined Actions (Type 2)
Use
Locally defined actions can be defined for a particular VDX system,,
location or user. They are typically used
to trigger user alerts not covered by the usual Protocol Actions.
Locally defined actions do not change the status of a request, nor do
they send a message to the other participating location.
Availability
Locally-defined actions are independent of any specific protocol. They
are only available to a staff user if access has been granted to them
via resource group permissions..Locally defined actions can be configured
to only appear when a request is at a partiuclar ILL-Statuses.
Locally Defined Actions are a more flexible way
of driving User Alerts than the existing Process Status method.
Note: the pull down
list may include both protocol and locally defined actions.
Actions available
Locally defined actions are created locally to meet local needs.
