Requests in-app report: Requests overdue/missing in transit list
Description
Priority
P3Fix versions
Development Team
Assignee
Solution Architect
Parent
Parent Field Value
Parent Status
duplicates
relates to
Checklist
hideTestRail: Results
Activity
Cate Boerema September 11, 2019 at 11:41 AM
Discussed this feature with the RA SIG on 2019-08-07. It turns out they really need a list of items in transit. There is a separate feature for this which Emma created (https://folio-org.atlassian.net/browse/UXPROD-944#icft=UXPROD-944) which is tagged cap-mvp. I will close this as a duplicate of that feature.
Cate Boerema July 30, 2019 at 8:52 AM
Thanks @(OLD ACCOUNT) Erin Nettifee. I have marked this po-mvp based on SME feedback on its importance
(OLD ACCOUNT) Erin Nettifee July 24, 2019 at 3:29 PM
I followed up on this with Duke's rep to the reporting SIG.
We can expect that request and in-transit fields would be available in the LDP once a report is spec'd for the LDP that is using those fields. There is an existing report in the requested reports list - "Items in transit for too long" - REP-172 - that would probably get close to what's here.
Because the Reporting SIG is in the middle of moving reports into UXPROD to be included in capacity planning, I don't know how we would know if this would be available for go-live. My sense is the thin-thread approach needs to move ahead, given the important of this for RA needs.
Anya March 29, 2019 at 11:05 PM
Comment from the March meeting : the ability to pull a CSV or get to the data is a must .
Tania Hewes March 27, 2019 at 3:21 PM
@Karen Newbery - https://folio-org.atlassian.net/browse/UXPROD-927#icft=UXPROD-927 was closed earlier this month as a duplicate of this one
Purpose: Institutions that allow items to transit between service points to fill requests will want to run a report periodically - probably daily - that lists items that are in transit to or from a particular service point that should have arrived by now, based on expected transit times. The report must contain bib information, item call #, item barcode, etc as well as the service point an item is coming from, where it is going to, and when it became in transit.
NOTE - The concept of "average travel time" between service points has been discussed in passing but not defined or analyzed. An expected transit time is probably needed for any time an item is travelling between service points, not just to fill a request.
Some thin thread implementation ideas:
Augment Requests csv to include "Date in transit" (the date the item went in transit), "From service point" and "To service point"
OR create specialized csv for this purpose with Requests that are in Transit, "From service point" and "To service point" and "Days in transit"
AND/OR modify the Requests app search results to add this data as additional columns (but the list of columns is already too long to fit on one page...)