Receiving functionality that FOLIO needs to stay competitive (UXPROD-3438)

[UXPROD-4670] Make receiving data available through RTAC for Unbound issues Created: 23/Jan/24  Updated: 23/Jan/24

Status: Open
Project: UX Product
Components: None
Affects versions: None
Fix versions: Ramsons (R2 2024)
Parent: Receiving functionality that FOLIO needs to stay competitive

Type: New Feature Priority: P2
Reporter: Dennis Bridges Assignee: Dennis Bridges
Resolution: Unresolved Votes: 0
Labels: IC_review, LC-priority1, SolutionArchitecture, acquisitions, crossapp, loc, patron-ux, rtac
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Continues
continues UXPROD-3525 Extend Piece "Receiving history" info... In Refinement
Release: Ramsons (R2 2024)
Epic Link: Receiving functionality that FOLIO needs to stay competitive
Development Team: Dreamliner
PO Rank: 148
Rank: Chicago (MVP Sum 2020): R2
Rank: Cornell (Full Sum 2021): R2
Rank: Duke (Full Sum 2021): R4
Rank: MI State-Lib of MI (Sum 2021): R2

 Description   

Current situation or problem:

Pieces received with no item record in inventory can now be represented on Holdings records. In this case there is STILL no indication in the public interface that these materials have been received. This information is important for patron workflows.

In scope

Retrieve all pieces for a given Holdings that are flagged as "Display on holdings" and NOT "Suppress from discovery" OR "Bound". Follow on feature for Locate to display them in public interface

Out of scope

Use case(s)

Use cases:

  1. Print Journals (Only Physical Pieces) are checked-in for a periodical and the system is not set to create items to represent them. The librarian might be waiting to bind those things until they have enough pieces to bind and creating items may require them to be deleted once bound. The librarian wants these pieces to show in discovery as expected and ultimately as received until 1 item is created to represent them. These items would live on the self and be available for use even though there is no item record. These many be for circulation or for internal use.
    • When the librarian receives these pieces they might add a public note when they indicate they want them piece to display publicly
  2. Patron comes to reference desk because they can't find something. Librarian wants to confirm it has been received, identify what bound volume it is included (If it has been bound yet) in and find out where that bound volume or loose issue is in the library. These librarian often will not be accessing the ILS system and Acquisitions data as they may not have creds/perms/training.
  3. Patron wants to confirm a material has been received, identify what bound volume it is included (If it has been bound yet) in and find out where that bound volume or loose issue is in the library.
  4. For some legal materials (Integrated materials) there will never be an item representing the piece being received. It may be a pocket part etc. and librarians will still need to be able to identify whether it has been received or not. This information is also displayed in discovery
  5. Librarian my reference the receipt date as a means of troubleshooting why nothing has been received recently.
  6. Patron wants to see info for a particular title. Item may have been created for piece but holding with provide additional information about what makes up that item. Eg. Current years version of chapter two has been received and added to it.

Proposed solution/stories

Call pieces API for a given Holdings UUID and retrieve all pieces that are "Display on holdings" = true AND "Suppress from discovery" = false AND "Bound" = false

Store needed detail in Holding record so system get all info in 1 call - Then manage data synchronization via messaging service between orders and inventory

Links to additional info

https://folio-org.atlassian.net/wiki/x/VCQV

Updated MIRO design analysis https://miro.com/app/board/uXjVMkjOlnc=/?share_link_id=843393418514 

Questions

What public facing services are these use cases relevant for? VuFind, EDS, Locate, Blacklight etc.



 Comments   
Comment by Dennis Bridges [ 23/Jan/24 ]

Khalilah Gambrell I have created this feature to encompass the changes needed to edge-rtac for an OPAC to be able to display the desired receiving data. I have also assigned this work to Dreamliner for now. Please update the PO assignment as needed. Note this will also require a feature for the Locate team to actually display the data. The MIRO analysis linked in the description focuses on the acq portion but also contains examples of how other OPACs display this information etc.

Comment by Khalilah Gambrell [ 23/Jan/24 ]

Thanks Dennis. Radhakrishnan Gopalakrishnan 

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