Automated Storage and Retrieval System Requests
Description
Priority
Fix versions
None
Development Team
Vega
Assignee
Unassigned
UnassignedSolution Architect
None
NoneParent
Parent Field Value
None
Parent Status
None
relates to
Checklist
hideTestRail: Results
Activity
Show:
Holly Mistlebauer March 7, 2022 at 7:32 PM
This feature is marked DRAFT until has a chance to review it for validity.

David Bottorff February 5, 2021 at 10:36 PM
That sounds right to me as well

Tod Olson February 5, 2021 at 10:30 PM
My view is that will let us work around the lack of an ASR Request, but I still see it as a work-around and the project eventually needs to have more flexibility in Requests.

David Bottorff February 5, 2021 at 8:48 PM
I believe that's the case, but I would like to confirm, as he's got a more detailed understanding of where we are with our edge module development.

Stephanie Buck February 5, 2021 at 8:44 PM
, I did not. and , does UXPROD2696 cover the needs of this feature?
Won't Do
Details
Details
Reporter

PO Rank
22
PO Ranking Note
2020-10-04 - CB: Making my PO rank same as the calculated total rank for now.
2019-07-12: Keeping PO rank same as calculated rank (with potential minor adjustments to avoid having two features with same rank)
Rank: FLO (MVP Sum 2020)
R5
Rank: 5Colleges (Full Jul 2021)
R4
Rank: Cornell (Full Sum 2021)
R5
Rank: Chalmers (Impl Aut 2019)
R5
Rank: GBV (MVP Sum 2020)
R5
Rank: hbz (TBD)
R5
Rank: Hungary (MVP End 2020)
R1
Rank: Grand Valley (Full Sum 2021)
R1
Rank: TAMU (MVP Jan 2021)
R5
Rank: Chicago (MVP Sum 2020)
R1
Rank: U of AL (MVP Oct 2020)
R5
Rank: Leipzig (Full TBD)
R5
Rank: Lehigh (MVP Summer 2020)
R4
TestRail: Cases
Open TestRail: Cases
TestRail: Runs
Open TestRail: Runs
Created February 4, 2019 at 1:37 PM
Updated January 31, 2025 at 8:43 PM
Resolved January 31, 2025 at 8:43 PM
TestRail: Cases
TestRail: Runs
Automated storage and retrieval systems like the one at University of Chicago come with a unique set of needs. When a request comes in for an item stored in the ASR, it must be flagged in such a way that the ASR system can detect the presence of a new request so it can be retrieved by robotic arm. For this purpose, we have designed a new request type called "ASR Request".
Current thinking on design:
Note: this feature was defined in collaboration with and of University of Chicago
New request type "ASR Request" is created in FOLIO
New item (availability) status "Available in ASR" is created in FOLIO
This item status can only be set in FOLIO by an integrated ASR system (if there is one)
This item status is pushed to FOLIO when an item is stored in ASR (it overrides whatever FOLIO status would have otherwise be set)
This status would only be applicable to institutions using ASRs and, therefore, wouldn't interfere with workflows for institutions not using this type of storage system
When a request is made for an item with item status "Available in ASR", the only possible request type is ASR (this is very analogous to how Page requests work for Available items)
ASR system polls FOLIO for new ASR requests
When a new request is identified, the ASR system begins to retrieve the item and pushes a new item availability status to FOLIO called "Retrieving from ASR"
The ASR delivers the book to a library staffed service point
The entire process from request creation to item delivery takes less than 3 minutes
Library staff scans the item in FOLIO check in app
Item goes into "Awaiting pickup" or "In transit" depending on the pickup service point specified in the ASR request (this part of the process is already working)
When an ASR item is returned, it goes into Recently returned status like all other returned items (assuming your institution uses the Recently returned status)
When the item re-stored in the ASR, the ASR again pushed the "Available in ASR" status into FOLIO
This new type of request has been added to the request whitelist document (you may have to unhide columns and rows to see it)
FAQs:
Why can't we just use Page requests for this?
If we used Page requests, we'd need some other mechanism for automatically identifying pages for ASR vs pages for non-ASR.
This could be done by item location, but there are a few issues with the location-based approach:
We'd need to develop the ability to flag certain locations as ASR locations
The system(s) would then need to traverse many tables to determine whether the request is an ASR request or not. Assumption is that this would be slower with more points of failure.
Also, there are some cases where something is stored in ASR and the item location isn't properly updated (this is an error, but it happens)
Alternatively, ASR requests could be identified as page requests where item status = Available in ASR
This might be less problematic than the location-based approach
Still, if we used Page requests, we'd need to make sure to exclude ASR requests from staff picklist reports for regular pages. Of course, picklist reports will need to be filtered by location, but there could be locations that contain ASR items and regular collections.
Leveraging Page requests would also make it more difficult to get statistics on numbers of ASR requests vs Pages
Overall, it feels like the distinct request type is simpler, requires less conditional logic and wouldn't be very difficult to implement
Why would we make this a general feature?
While it's relatively uncommon, there are institutions that use ASRs and our assumption is that this feature could work for many of them (there are only a few vendors for these kinds of systems so, chances are other institutions are using the exact system Chicago is using)
Final note: These types of systems are very expensive and very high-visibility in their institutions. It is extremely important that they work well and they work fast.