Staff Slips (UXPROD-19)

[UXPROD-1280] Paging Requests Individual Staff Slip Created: 05/Nov/18  Updated: 16/Sep/20  Resolved: 10/Dec/19

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: Q4 2019
Parent: Staff Slips

Type: New Feature Priority: P2
Reporter: Cate Boerema (Inactive) Assignee: Darcy Branchini
Resolution: Done Votes: 0
Labels: cap-mvp, po-mvp, printslips, q4-2019-at-risk, requests
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Defines
is defined by CIRC-494 BE: Print pick slips for service poin... Closed
is defined by CIRC-504 View/edit/preview pick slip (aka call... Closed
is defined by UIREQ-382 FE: Print pick slips for service poin... Closed
Relates
relates to UXPROD-272 Requests: Paging requests (Basic) Closed
relates to UXPROD-1138 Requests Pick List: CSV Export Closed
relates to UXPROD-923 Requests in-app report: Requests Pick... Draft
Potential Workaround: Darcy
- UXPROD-923 Requests in-app report: Requests Pick List, but that feature also tags this feature as a possible work-around. I'm ranking it higher assuming this one will be implemented and UXPROD-923 will not.
Epic Link: Staff Slips
Front End Estimate: Large < 10 days
Front End Estimator: Kostyantyn Khodarev
Back End Estimate: Large < 10 days
Back End Estimator: Kostyantyn Khodarev
Development Team: Vega
PO Rank: 91
Rank: Chalmers (Impl Aut 2019): R5
Rank: Chicago (MVP Sum 2020): R4
Rank: Cornell (Full Sum 2021): R2
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R1
Rank: FLO (MVP Sum 2020): R1
Rank: GBV (MVP Sum 2020): R2
Rank: hbz (TBD): R1
Rank: Hungary (MVP End 2020): R1
Rank: Lehigh (MVP Summer 2020): R2
Rank: Leipzig (Full TBD): R1
Rank: MO State (MVP June 2020): R2
Rank: TAMU (MVP Jan 2021): R1
Rank: U of AL (MVP Oct 2020): R1

 Description   

Purpose/Problem:
Paging requests are requests on items that are available in the library. To fulfill these types of requests, library staff need to print the list of open paging requests and go get the items off the shelf. Many institutions print a single report for this purpose (see UXPROD-1138 Closed and UXPROD-923 Draft ) but some want the option to print individual slips instead. NOTE: The report might be an acceptable work-around temporarily until this feature can be developed.

  1. Some libraries use an individual pick slip for retrieving an item from (closed) stacks and then place the same slip in the item on the collection shelf. The top printed line on the slip could provide a (pseudonymous) identification of the patron, that could stick out at the top for easy collection. The pick slip also serves as a paging slip in this case.
  2. Large closed stack libraries (Magazinbibliotheken) might want to aggregate pick slips for a certain period of time, sort them by call number and print them in a batch. This would provide one way of optimizing collection routes for staff.
  3. Other libraries want to have these slips print as a request comes in.
  4. Closed stack libraries might leave a copy of the loaned item call slip in the stack until the item is returned. This would require the system to print each call slip twice.

Implementation Thoughts:

  • Setting to enable this option
  • Ability to CRUD the paging slip template, specifically the content and format (like hold slips)
  • Ability to print individual paging slips on demand and/or on a schedule
  • Ability to print only slips relevant to your location
  • Individual slips are properly sorted and collated (by location, call number, maybe even custom field - sort order should be configurable)

Further use cases: (from Uschi Klute in comments below)
In our larger libraries there are several closed stacks, each with its own printer. The slips automatically printed there belong to exactly this closed stacks area. In most libraries the books are picked "on demand" and not with a certain provision time.
If an unexpectedly large amount of slips has been produced on a printer, it can easily be divided between two employees.
For media which were not found in the shelf, a corresponding text can be noted on the slip. Those slips are collected at the service point and checked again at a later time.
If the books are then transported to the service point, it is important that the request slip is in the book, as this is the only way for everyone involved to recognize that it is an ordered and already picked book.
With a list, the status of the book (already picked or not found etc.) would have to be noted on the (paper) list.
A list is very impractical and would cause much more work.



 Comments   
Comment by Cate Boerema (Inactive) [ 05/Nov/18 ]

Schwill, Carsten, can you please take a look at this feature and add any additions/changes?

Comment by Schwill, Carsten [ 08/Nov/18 ]
  1. Some libraries use an individual pick slip for retrieving an item from (closed) stacks and then place the same slip in the item on the collection shelf. The top printed line on the slip could provide a (pseudonymous) identification of the patron, that could stick out at the top for easy collection. The pick slip also serves as a paging slip in this case.
  2. Large closed stack libraries (Magazinbibliotheken) might want to aggregate pick slips for a certain period of time, sort them by call number and print them in a batch. This would provide one way of optimizing collection routes for staff.
  3. Closed stack libraries might leave a copy of the loaned item call slip in the stack until the item is returned. This would require the system to print each call slip twice.
Comment by Cate Boerema (Inactive) [ 15/May/19 ]

Kostyantyn Khodarev could you please provide the t-shirt size estimates for this feature? I feel like Vega would be best positioned to estimate this since it's a kind of staff slip (like hold and transit). These estimates are intended to be rough - please don't spend too much time thinking about it. That said, if you have questions, please let me know.

+ Darcy Branchini because this one actually falls between our areas. Not sure if this should be considered part of Requests or Staff slips... Anyway, we need it estimated regardless

Comment by Darcy Branchini [ 16/May/19 ]

Cate Boerema - My understanding is that from a user perspective, this is closely related to UXPROD-923 Draft . It supports the same workflow function – staff retrieving requested items off of shelves. And it's a matter of preference by institution and/or maybe library or service point, some prefer to have one list with all outstanding picks and others prefer to have individual items printed on separate sheets/slips. I do wonder if both are necessary in FOLIO. Since items will be scanned at the service point after they are retrieved and hold slips can (or will) be printed, then do they need individual pick slips? Also, perhaps their current systems didn't allow them to do one consolidated list by location so that is why they do this? Also, I know some were using pick slips as hold slips, so they didn't have to print another slip. These are all good questions to get clarification on from the SIG.

Comment by Uschi Klute [ 11/Jun/19 ]

Cate Boerema, Darcy Branchini - It is absolutely necessary that individual slips are created for page requests.
In our larger libraries there are several closed stacks, each with its own printer. The slips automatically printed there belong to exactly this closed stacks area. In most libraries the books are picked "on demand" and not with a certain provision time.
If an unexpectedly large amount of slips has been produced on a printer, it can easily be divided between two employees.
For media which were not found in the shelf, a corresponding text can be noted on the slip. Those slips are collected at the service point and checked again at a later time.
If the books are then transported to the service point, it is important that the request slip is in the book, as this is the only way for everyone involved to recognize that it is an ordered and already picked book.
With a list, the status of the book (already picked or not found etc.) would have to be noted on the (paper) list.
A list is very impractical and would cause much more work.

Comment by Anya [ 11/Jun/19 ]

Hi Cate Boerema the capacity plan has this as a planned release as q2 2020 and this is q4 2019 - which one is correct?

Comment by Cate Boerema (Inactive) [ 12/Jun/19 ]

Hi Anya target releases beyond Q2 should be ignored. We haven't completed planning for Q3 and beyond. The dates you see are just POs' best guesses and many of them are very stale

Comment by Darcy Branchini [ 12/Jun/19 ]

Cate Boerema, I was planning to handle this as the PO for "staff or print slips," but are you planning to instead?

Comment by Cate Boerema (Inactive) [ 13/Jun/19 ]

Hi Darcy Branchini this one could go either way as it's definitely a staff slip and definitely request-related. As I mentioned earlier, now that the basic staff slip feature is in place, I feel that other POs should be able to extend on it, as long as they keep you in the loop. That said, I'm time-starved and more than happy to let you take this one.

Comment by Darcy Branchini [ 13/Jun/19 ]

Cate Boerema, since I was already planning to, I'll continue with that plan.

Comment by Cate Boerema (Inactive) [ 28/Jun/19 ]

Tentatively reassigning to Vega, since that's the team Darcy works with most and they "own" staff slips

Comment by Darcy Branchini [ 02/Jul/19 ]

This feature was reviewed at the RA SIG meeting on 7/1/2019 and consensus was that this was still a go-live feature. However, many institutions felt the workaround proposed above (using the report instead of individual slips) might be an acceptable work-around temporarily.

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