Uploaded image for project: 'UX Product'
  1. UX Product
  2. UXPROD-928

Requests in-app report: Requests overdue/missing in transit list

    XMLWordPrintable

Details

    • New Feature
    • Status: Closed (View Workflow)
    • P3
    • Resolution: Duplicate
    • None
    • None
    • None
    • Hide
      Cate Boerema: There is no workaround for this report using the current Requests app or Requests csv. Most on SIG feel strongly that we need at least a thin thread implementation for mvp. Erin Nettifee investigating whether this info would be available in the LDP. If not, we probably need to add at least the following to the requests csv: Status update date, Service point to, Service point from.
      Show
      Cate Boerema: There is no workaround for this report using the current Requests app or Requests csv. Most on SIG feel strongly that we need at least a thin thread implementation for mvp. Erin Nettifee investigating whether this info would be available in the LDP. If not, we probably need to add at least the following to the requests csv: Status update date, Service point to, Service point from.
    • Medium < 5 days
    • Medium < 5 days
    • XL < 15 days
    • Low
    • estimates based on other appreport features
    • Prokopovych
    • 96
    • Hide
      2019-07-18: Bumping PO rank per discussion with SIG. This seems higher priority than default pickup service point for users
      2019-07-12: Keeping PO rank same as calculated rank (with potential minor adjustments to avoid having two features with same rank)
      Show
      2019-07-18: Bumping PO rank per discussion with SIG. This seems higher priority than default pickup service point for users 2019-07-12: Keeping PO rank same as calculated rank (with potential minor adjustments to avoid having two features with same rank)
    • R4
    • R1
    • R2
    • R1
    • R2
    • R2
    • R2
    • R2
    • R1
    • R2
    • R1
    • R1
    • R2

    Description

      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...)

      TestRail: Results

        Attachments

          Issue Links

            Activity

              People

                cboerema Cate Boerema
                cboerema Cate Boerema
                Tania Fersenheim Tania Fersenheim
                Tania Fersenheim Tania Fersenheim
                Tania Fersenheim Tania Fersenheim
                Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved:

                  TestRail: Runs

                    TestRail: Cases