Loans (UXPROD-788)

[UXPROD-527] Loans: Recently returned Created: 23/Apr/18  Updated: 04/Jan/24

Status: Draft
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Loans

Type: New Feature Priority: TBD
Reporter: Emma Boettcher Assignee: Cheryl Malmborg
Resolution: Unresolved Votes: 0
Labels: loans, po-mvp, resourceaccess, round_iv
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Defines
is defined by UICHKIN-94 Change status to recently returned at... Open
is defined by UICHKOUT-651 Check out items with the item status ... Open
is defined by UICHKIN-96 Handle multiple check-ins during Rece... Draft
is defined by UIREQ-517 Recently returned: Allow requests Draft
Gantt End to Start
has to be done after FOLIO-1953 SPIKE: propose an approach for schedu... Closed
has to be done after UXPROD-3652 Item Status: Recently Returned Draft
Relates
relates to UICHKIN-39 Status change upon check in: recently... Closed
relates to UXPROD-3652 Item Status: Recently Returned Draft
Potential Workaround: No workaround, but unlike other item states, Recently returned items only stay that way for a short time (shelving lag time).
Epic Link: Loans
Analysis Estimator: Emma Boettcher
Front End Estimator: Aditya matukumalli
Back End Estimator: Marc Johnson
Estimation Notes and Assumptions: Scheduler feature is in place to trigger updates from "Recently returned" to "Available" (increased estimate due to scheduling feature not being in place)
Item status updating mechanism is in place (if this is derived, then need to determine what information this is based up - is it a loan closed recently)
When a loan was closed is already stored
When an item status changed is already stored (and can be queried)
Dedicated Check In API is in place (rather than just updating a loan, as currently is now)
Development Team: Vega
Kiwi Planning Points (DO NOT CHANGE): 1
PO Rank: 65
PO Ranking Note: Not replaceable by custom item status (since recently returned needs to automatically change to Available, based on shelving lag time), but not necessarily high-priority.
Rank: Chalmers (Impl Aut 2019): R5
Rank: Chicago (MVP Sum 2020): R4
Rank: Cornell (Full Sum 2021): R4
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R4
Rank: FLO (MVP Sum 2020): R4
Rank: GBV (MVP Sum 2020): R2
Rank: Grand Valley (Full Sum 2021): R1
Rank: hbz (TBD): R1
Rank: Hungary (MVP End 2020): R1
Rank: Lehigh (MVP Summer 2020): R2
Rank: Leipzig (Full TBD): R1
Rank: Mainz (Full TBD): R3
Rank: MO State (MVP June 2020): R4
Rank: TAMU (MVP Jan 2021): R2
Rank: U of AL (MVP Oct 2020): R4

 Description   

Current situation or problem:
When an item is checked in at a service point assigned to its effective location, its status changes to Available. This can confuse patrons, who might assume that the item is already on the shelf.

In scope

  • Creation and handling of Recently returned item status
  • When an item is checked in at a service point assigned to its effective location, its status changes to Recently returned
    • if checked in again while its status is Recently returned, this restarts the clock
  • When the shelving lag time for the service point has passed, it becomes Available

Out of scope

Use case(s)

Proposed solution/stories

Links to additional info

Questions

  • Is the change from Recently returned --> Available done on a live/rolling basis or as a batch job?


 Comments   
Comment by Uschi Klute [ 21/Aug/18 ]

The Shelving Lag Time can be set per Service Point. In my experience it should be configurable per location. Some of our libraries have 0 or 30 or 60 minutes in their settings, others have 1 or 2 days, as they have closed stacks, sometimes far away with daily car transport.
There are two Service Points which handle items from this closed stack and also items from within the central library.

Comment by Emma Boettcher [ 05/Oct/18 ]

The RA SIG discussed this again yesterday, and they decided to prioritize easier setup (shelving lag time on service point) over granularity (shelving lag time on location), even with the remote storage example in mind.

One comment from the group supporting this decision was that they could also set up a service point for the remote storage/closed stacks, sending items in that location in transit to that service point, and checking in items at the remote location/closed stacks when they arrived there.

Comment by Emma Boettcher [ 30/May/19 ]

Changing from Blocked to Open since scheduler is no longer blocking development.

Comment by Erin Nettifee [ 08/Feb/21 ]

Cheryl Malmborg Charlotte Whitt any sense of whether this might make it to Juniper?

Comment by Cheryl Malmborg [ 08/Feb/21 ]

Erin Nettifee Given the relatively low ranking and the backend estimate of XXL, I doubt it will make Juniper. However, I don't have a sense of the rankings in other modules.

Comment by Molly Driscoll [ 10/Nov/21 ]

I've had a few libraries ask me about the possibility of developing shelving lag time at the location level rather than the service point level. I see this was downvoted in favor of service point level configuration in 2018, but I wonder if the conversation should be revisited now to gain the perspective of libraries newer to the community and those that have been around for awhile who may have differing opinions after working with FOLIO in intervening years. cc: Jana Freytag for possible RA SIG consideration.

Comment by Erin Nettifee [ 10/Nov/21 ]

Hey Molly Driscoll - do they have use cases for different lag times for different locations that all go to the same service point? Can you give an example?

Conceptually, it still really makes sense to have it at the service point level - if the hope is that it might be developed faster at the location level, I don't think that will make a difference, because it depends on a PO and development resources to make the item status piece work - the transition from Available to Recently Returned, managing the circ processes that touch that status, things like that.

Comment by Gang Zhou [ 11/Nov/21 ]

Hi, Erin Nettifee, Molly Driscoll

For a large library, one service point may corresponds to multiple locations, so it is better to set the shelving time in the location.

The library may have a service point which all items are returned, then items are sent to a specific location before being placed on shelves. This is a two-stage process, and shelving times may vary from location to location.

Comment by Molly Driscoll [ 11/Nov/21 ]

To add to Gang Zhou's point, the library I was speaking to most recently circulates all materials from their circulation desk. However, they want reserve items and circulating technology to have a shorter "recently returned" time frame than all other materials whose locations are "owned" by that service point since they are given re-shelving priority when returned. They do not like the idea of having to transit materials to a secondary service point to achieve the shorter recently returned time frame as this makes the workflow bulkier for their circulation staff. 

Comment by Erin Nettifee [ 11/Nov/21 ]

Thanks for the feedback Gang Zhou and Molly Driscoll. This has not been considered super high priority so I don't know when it might be able to come back up for discussion, but I will move the status on this from "Analysis Complete" to "Draft" to indicate that there is a desire to go back through the requirements before development might start, when we get to that point.

Comment by Erin Nettifee [ 11/Nov/21 ]

One thing that will need to be discussed is considering whether there are cases where you would want the shelving time to NOT be associated with the effective location of the item, but rather with another one of the location values. If there are scenarios where that would be the case, that would significantly increase the complexity of implementation. That's why gathering specific use cases and desired behavior would be helpful.

Comment by Erin Nettifee [ 03/May/22 ]

Moving this to a "Blocked" status as part of Vega board review - this cannot progress until the item status of "Recently Returned" is created. It looks like Emma had consolidated that into this feature, but that really should be a separate feature.

Generated at Fri Feb 09 00:08:36 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.