2020-09-03 (Item retrieval request)

Meeting details

Agenda

• Retrieval request process start
• Circulation stops to FOLIO service points mapping
• Response from Remote Storage processing
  • Hold shelf vs Delivery request
• Item States and Flags in CaiaSoft
• Outstanding questions from previous meetings
  • Locations mapping
  • Item state after de-accession
  • Update item's metadata during circulation

Notes

•  Start of the retrieval request process 
  • Not only library staff via ILS, but patrons via Discovery systems as well, can request an item from remote storage. This integration has already been implemented in FOLIO, at least for EDS (EBSCO Discovery Service).
  • Errors (server types) and rejections (logical) from remote storage in response to the retrieval request should be distinguished by the FOLIO flow. In case of error, the request should be sent again and in case of rejection, manual intervene is required, so it should be reported and request creator should be notified.
  • The system shouldn't overwrite the item's or request status, as in the meantime the item could have been put in transit or loaned, so the system doesn't know the correct final status.
  • Possible rejection reasons (more relevant for ILS though): there is already a hold (request) on the item, the item is already checked out, the item isn't available for circulation, the limit on the number of holds per user is exceeded, user's library card is blocked, item or patron isn't found 
  • Folio pings the remote storage for retrieval requests automatically, so that remote storage staff shouldn't do this manually.
  • Another possible rejection reasons (from Dematic): the crane is down, the item isn't here physically (GVSU); item isn't found, item is checked out of container, item in locked location, timed out waiting for a response or other communication errors (UChicago).
  • At Duke remote storage can't automatically say that the item isn't physically present, as somebody from the staff should go, look at it and then they would go and generate the message back. 
  • The crane can be shut down every night, and it shouldn't cause a request being cancelled. The only way it could be cancelled is when the staff member looks for the item in the box and can not find it, so they mark the item missing - that updates the item status to missing in ILS. Not sure if it cancels the request, but hopefully it does. 
• Action items: get API documentation from UChicago (Tod) and more documentation from Duke (Jacquie) regarding remote storage integration
• Circulation stops to FOLIO service points mapping
  • When patrons request resources they choose where they would like to have the resource delivered. The stops in Caiasoft would be the (pick-up) service points in FOLIO.
  • Almost all of them are usually a one-to-one mapping, same with locations
  • However, sometimes stop correlates to one place, sometimes to a building. There is one location per stop, but it is not necessarily a "service desk to service desk" mapping.   
  • For delivery requests, the new functionality with delivery service points is expected. See details here.
• Response from Remote Storage processing
  • For delivery request the behaviour of setting "Awaiting delivery" status whenever user checks in a requested item is going to be fixed in a way of having an option to transit this item to the service point from where it is going to be mailed.
  • At Duke, all of the resources go to "In transit"
  • Retrieval request process in Caiasoft: they get a file of requests from the ILS, they process everything by barcodes, then they go to the shelves and retrieve items, then they check it out of the module in Caiasoft (item is marked as out) and send it physically to the stop.
  • Retrieval request process in EMS: when something is successfully retrieved from FOLIO, we just check it in in our ILS to trigger the next state, so there is no integration here and it doesn't need to be, as it could probably cause problems. Dematic responds by bringing a bin up, but a human has to look at this bin and find the item, they have to then scan it into the EMS. It updates ILS with the status of retrieving and we walk it to another computer with ILS to check it in.
  • Without having item checked in manually you can't get printed a hold/transit slip. Having automatic check-in seems like a lot of work for little gain and with a lot of potential for error.
  • GVSU Dematic: when the request is made, the box automatically moves, the crane brings the box to the work station. When the item is retrieved (by the staff), we have a little receipt that it gets printed and then it goes to the circulation desk. So nothing happens on the Dematic side except to say "I processed this" and ILS gets the chance to decide what it wants to do with that note. ILS can say that it is "In transit". But the patron won't know the item is ready until it is checked in in Sierra. 
  • For Caiasoft the flows from Dematic are pretty the same.
• Item States and Flags in CaiaSoft
  • The items are deaccessioned often because we transferring them to different holding location. They are not necessarily missing or lost. 
  • There is a distinction between deaccessioning an item in the FOLIO system (withdrawing an item) and deaccessioning something from a storage system. For the first variant, we shouldn't change the location and it would include deaccessioning it from a remote storage system. For the second variant, you move the item to the different shelving location and item state wouldn't change.
  • When something is pulled and scanned for electronic delivery, it is temporarily not available. Someone else could request it, but it is processed at the moment. Status "In process" should be the closest equivalent for e-retrieval. 
  • Theoretically, item flags are present in Caiasoft to prevent item's circulation, so the additional communication is not needed throughout the circulation process in ILS (item's following check-ins and check-outs). Double-check with Erin. 

Artefacts

Attendees