Ordering functionality that FOLIO needs to stay competitive
(UXPROD-3440)
|
|
| Status: | Analysis Complete |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None | Parent: | Ordering functionality that FOLIO needs to stay competitive |
| Type: | New Feature | Priority: | P4 |
| Reporter: | Ann-Marie Breaux (Inactive) | Assignee: | Dennis Bridges |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | acq-orchid-candidate, acquisitions, needs-ranking, needs-rmsigreview, orders | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Epic Link: | Ordering functionality that FOLIO needs to stay competitive |
| Development Team: | Thunderjet |
| Kiwi Planning Points (DO NOT CHANGE): | 4 |
| PO Rank: | 89 |
| PO Ranking Note: | This can be done manually by navigating to the item record immediately after the order is placed. The ranking reflects that this allows room for error and a less than ideal workflow. |
| Rank: Chalmers (Impl Aut 2019): | R3 |
| Rank: Chicago (MVP Sum 2020): | R2 |
| Rank: Cornell (Full Sum 2021): | R2 |
| Rank: Duke (Full Sum 2021): | R2 |
| Rank: 5Colleges (Full Jul 2021): | R2 |
| Rank: 5Colleges (ERM Jun 2020): | R2 |
| Rank: GBV (MVP Sum 2020): | R3 |
| Rank: Grand Valley (Full Sum 2021): | R3 |
| Rank: MO State (MVP June 2020): | R2 |
| Rank: TAMU (MVP Jan 2021): | R2 |
| Rank: U of AL (MVP Oct 2020): | R3 |
| Description |
Overview:Allow users to add enough request information to the order to generate a request on the item being ordered when the order is opened. This way patrons can be notified that the item they requested has been ordered and follow it's progress. Note: proposed by Duke (Julie Brannon, Erin Nettifee) Use cases:In scope
Questions
LinksSee proposed mockups: https://drive.google.com/drive/folders/1SpOvkcoQLuI0P0tpf_Le-924gKtTYzPM?usp=sharing |
| Comments |
| Comment by Ann-Marie Breaux (Inactive) [ 25/Sep/19 ] |
|
Dennis Bridges This came up in a Slack convo with Duke - see details in the description above. Could we consider adding a "create request" button, or automating some functionality based on the requestor field being filled in on the POL? I think the safer path would be a button, since the requestor field may or may not actually want to have a hold for the ordered book. Plus anything we can do to minimize having User info in the order record (especially user barcode number or other ID) in the POL will be more acceptable to the Europeans. Added Erin Nettifee and Julie Brannon as watchers |
| Comment by Erin Nettifee [ 25/Sep/19 ] |
|
Cate Boerema and Andrea Loigman - FYI - this is an Orders feature request that will intersect with Requests. |
| Comment by Dennis Bridges [ 25/Sep/19 ] |
|
Ann-Marie Breaux cc Erin Nettifee would it make sense for the request to result in an order being created? If not, is the user creating an order and creating a request at the same time or are they creating the order and linking it to an existing request? Happy to discuss this and get started on a wireframe. |
| Comment by Erin Nettifee [ 25/Sep/19 ] |
|
Basic process is like this.
So it depends on when creating an order results in the creation of an item, which I don't know enough about to tell you. Does that help? |
| Comment by Dennis Bridges [ 25/Sep/19 ] |
|
Erin Nettifee Yes, it does thanks for the additional detail. We currently have a requester field (as noted above) in the order record that is simply a text field. My thinking is that this could be a "Requester lookup" (as mentioned in description). Thus allowing Librarian B to pull the necessary requester information for Patron A. From that point the system knows the requester and the title. Thus, when mod-orders creates the item(s) in theory we could also place a request for the requester on the first item. However, this would be complicated if the order is for "New York Times", for example, and the request is for issue 4. In this case something would need to be done during receiving in order to identify the specific "Item" that the requester was looking for. Would you say this is a common occurrence? |
| Comment by Ann-Marie Breaux (Inactive) [ 26/Sep/19 ] |
|
Dennis Bridges We may need to have a less-controlled and more-controlled way of dealing with the requestor. For some libraries, it's just informational - which department or faculty member wants the thing, but it doesn't always necessarily lead to creating a hold. In any event, the sequence that I'm hearing is Thanks, |
| Comment by Julie Brannon [ 26/Sep/19 ] |
|
Ann-Marie Breaux The sequence you've outlined above sounds accurate, though we'd like to see the requestor ID changed to a dynamic user lookup rather than text (as it was probably planned from the beginning and mentioned by Dennis above). European users could choose to leave that field blank, as needed. To Dennis Bridges's question above, I'll need to dig around to find out whether requests might be at the volume level within a serial or set; though the alert described by Ann-Marie could address that scenario when needed. Thanks! |
| Comment by Ann-Marie Breaux (Inactive) [ 30/Jun/20 ] |
|
Hi Dennis Bridges Added a couple comments at the bottom of the description based on a mtg just now with 5 Colleges. Anya is asking how this could get ranked. It's not linked to a particular UXPROD feature. Do we have one for automating some of the interactions between requestors and orders? Or maybe we could create one and link this to it? |
| Comment by Dennis Bridges [ 30/Jun/20 ] |
|
Ann-Marie Breaux Yes no problem, I think given the detail here and the interest from other parties it should probably be written as a feature and prioritized accordingly. I can pick it up from here, convert it and discuss it with the RM group? |
| Comment by Dennis Bridges [ 06/Jul/20 ] |
|
Moving this discussion from the description to the comments: For example, at Duke when a patron requests that we order a title, we would flag it as a rush order and capture the patron ID on the order record. Upon arrival a hold is put on the item so that it can't be loaned to anyone else. In this morning's demo you set up a patron request - there was no automation to create the request automatically. Just looking for any JIRAs related to features that might come in future releases. Ann-Marie Breaux: Erin Nettifee: Ann-Marie Breaux: Julie Brannon: I definitely agree that the hold action needs to happen immediately at the time of order creation to preserve the "first dibs" priority of the original requestor so that they don't get bumped if a request sneaks in as soon as the item is created. Putting a "create hold" button is friendlier than asking them to toggle over to the item to create the hold. It seems like they would need a slightly modified request builder pop-up window because they wouldn't have the item identifier at the point of PO line creation - the item isn't created in inventory until the order is opened, right? So if all they have to do is remember to click “create hold” and enter the patron information that wouldn’t be much different than what they do now. Just thinking out loud. This is a high volume process at Duke and will cause grumbles if we don't have a smooth process in place. What is the next step for addressing this - would this be a new JIRA or is there one floating out there already? June 2020: Adding a comment that this is of interest to 5 Colleges too. Also being able to send automatic e-mails for notifies (not holds) when material is received.?? |
| Comment by Ann-Marie Breaux (Inactive) [ 25/Sep/20 ] |
|
Hi Dennis Bridges Just adding a comment that if the requester field becomes one that has a user ID/number in it, we still may need an uncontrolled text field for requester, in situations where a library wants to record a requester, but not their ID. If the same field can be used for both, that's great. Otherwise, maybe we create a new field for Requester ID and leave the existing Requester field uncontrolled. |
| Comment by Erin Nettifee [ 25/Sep/20 ] |
|
Want to point out a few things: For requests, there are five required fields (at least as far as I've understood it) - itemId, requesterId, requestType, requestDate, and fulfillment preference. Some places may want to do holds but I could also see some libraries wanting them to be recalls (to trigger faster action by staff, maybe) so that may not be able to be hard-coded. Then fulfillment preference is meant to be "hold shelf" or "delivery" and likely will actually need to be pulled from the user record, rather than set by staff. If you haven't talked to Cate already about this, that would be my recommendation. There's some active work happening around improving item delivery workflows on the RA side that could impact the description of this feature as well. |
| Comment by Dennis Bridges [ 25/Sep/20 ] |
|
Erin Nettifee Is the request date something you see the user wanting to set through this process? If so, is it safe to allow them to give us a date? Otherwise we would be using the date the order was opened. |
| Comment by Erin Nettifee [ 25/Sep/20 ] |
|
No - it's mainly used for ordering in the app itself, and for decisions to expire requests that haven't been filled. Using the date the order is opened would be the date the request is created, so that makes sense to me. |
| Comment by Dennis Bridges [ 28/Sep/20 ] |
|
Additional comments form Cate:
Dennis: It seems we may need to add an option for the Fulfillment preference after all? |
| Comment by Erin Nettifee [ 18/Mar/21 ] |
|
Brooks Travis this feature came up in conversation at Duke today - not sure if you've seen it or not. |
| Comment by Ann-Marie Breaux (Inactive) [ 18/Mar/21 ] |
|
Erin Nettifee and Brooks Travis One significant architectural issue for this feature (at least in my mind) - currently the requestor field in the POL is uncontrolled. In earlier conversations, Duke talked about changing the requestor into a controlled field with FOLIO User info. If that ends up being a requirement, I think we should consider added a separate field for a controlled version of the requestor, rather than changing the existing uncontrolled field and forcing that requirement on all the FOLIO libraries |
| Comment by Ann-Marie Breaux (Inactive) [ 30/Mar/21 ] |
|
Another use case that came up in Acq Group mtg today: alerting users to a newly-available, ordered eBook. If there's no item record, how could a request be handled? Added as an open question in the description. Might need to be split to a separate feature. |
| Comment by Erin Nettifee [ 30/Mar/21 ] |
|
Requests is not architected for using non-item records, so it would likely need to be some sort of notice feature to the patron rather than using the Requests app and associated features. |
| Comment by Ann-Marie Breaux (Inactive) [ 30/Mar/21 ] |
|
Thanks Erin Nettifee To me, in that case, that definitely sounds like a separate feature . |