UXPROD-2565 - Getting issue details... STATUS

Problem(s):

  1. User must navigate to inventory to place a request on newly ordered items. This requires additional permissions and breaking up the acquisitions workflow or risking that items are requested before a hold can be place for the desired user.
  2. Title level requests will automatically pull an item that is created by the orders app.
  3. When creating multi-line POLs a library may be waiting on approval for the full PO. The requested item is associated with one POL and user must remember to go back and create request once orders is approved and Opened. Because Item is not generated until the order is opened.

Use Cases & Requirements:

RequirementStatusUse cases

Automatically create a request for the on-order material so that it can't be taken by someone else. Prevent Title level request queue from picking up this item.

VERIFIED

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

Allow requests to be created for a general user. Possibly system user or a specified generic user account (Requests require a user ID so we can not allow free text when generating request)

VERIFIED

  • The library does occasionally place holds at point of order without knowing the specific user id. In some cases the requester information could be in a separate system (Eg. Iliad) and a default user is used to identify that this item should be treaded a certain way in the workflow ultimately having a person update the request information so the item is put aside for the correct user.
  • Library is ordering at vendor site and vendor does not have user ID. Allowing requester to NOT be a "user" account would be valuable.


Proposed workflow:


Functionality Potentially Impacted by Changes:

Functional area

Records

Potential impact

Suggested Regression Testing




Questions:

Question

Status

Conclusion

Comments

  • It seems we may need to add an option for the Fulfillment preference after all?

OPEN

User must indicate the Fulfillment preference for Pickup service point to be required. So we must add this field as well. It will be a select list.

Re the step "User must select a pickup service point," we're using delivery requesting so there may not be a pickup service point. It seems like there's an extra step needed in there for fulfilment preference, then service point or delivery address selection.

  • Regarding Hold vs. Recall can an assumption actually be made here or would it need to be a setting?

OPEN

The only type of request needed here is a Hold request.There are patron that ask to be notified but not have a hold placed. This is potentially a note that would be added to the request or to the POL if a request was not being created.
  • Another use case: alerting a user to a newly-available, ordered eBook, which does not have an item record. Is there a way to create a patron request for that? Should that perhaps be a separate feature?
  • Should all requests be "title level requests"

OPEN


At 5C if the request comes from a prof from University A the library would not want to give a different item to that user. They would want the item they are buying to be given to the user. Ie. they want the item that their group is buying to be loaned to that user rather than taking something from another library.

For the most part it is not critical that a user is assigned to the specific item they are ordering. Just that the get the item as soon as possible.

  • Are there ever multiple requesters. Would the POL need to accommodate multiple requesters?

Only one requester should be possible. However, only require a user ID if the user actually wants a request created.Users could always add additional requests as needed. In current systems this is often handled in a note field.

Work Breakdown Structure:

Features:


UI Stories


MOD Stories

Key Summary T Created Updated Due Assignee Reporter P Status Resolution
Refresh

10 Comments

  1. Erin Nettifee

    Brooks Travis just FYI this is being worked on as a candidate for Morning Glory. 

  2. Erin Nettifee

    With regards to the proposed workflow, you don't necessarily have to choose a pickup service point, it depends on how the library is loading users. The user record has a field for "Default pickup service point" that the request app will use when a request is created for the user. But that field is optional, so if the library doesn't populate it, one would have to be chosen as indicated on the workflow.

  3. Erin Nettifee

    With regards to the question about TLR and requesting, this is my understanding:

    • TLR requires the existence of an item record
    • An item with a status of "on order" will not fulfill a title level request since it's assumed it's not actually at the library yet
    • Once the item is received, it can fulfill a TLR, but it requires that the item be checked in to trigger the workflow.

    Stephanie Buck does this sound right?

  4. Stephanie Buck

    Regarding TLR:

    • An instance and holding record are required to place a title level request
      • If a title level request results in a page or recall, and item record must be present

    Erin Nettifee, your second and third bullets above sound right. 

    Is this really a Morning Glory candidate? Platform core feature freeze has already passed, and platform complete feature freeze is June 10.

  5. Erin Nettifee

    Stephanie Buck the feature is labeled as such, but it may just not have been updated yet.

  6. Dennis Bridges

    Stephanie Buck no, UXPROD-2565 has not yet been given a fix version. These requirements will be ready during the Nolana release cycle but we will not have capacity to work on this for Nolana so it would be a following release. I don't know where you are seeing an association with Morning Glory but please let me know so I can remove it. Thanks!

  7. Erin Nettifee

    Dennis Bridges the Jira is labeled as acq-morningglory-candidate, does that have a particular meaning in your workflow?

  8. Dennis Bridges

    Oh thanks Erin Nettifee! Yes, this just indicates that I was trying to prepare it for Morning Glory. The labels just help me keep track of my priorities for defining requirements. Clearly I didn't meet that goal lol. I should have removed it when we locked in our morning glory features (smile)

  9. Tim Darlington

    Re the step "User must select a pickup service point," we're using delivery requesting so there may not be a pickup service point. It seems like there's an extra step needed in there for fulfilment preference, then service point or delivery address selection.

  10. Marie Widigson

    We're using page-and-recall-policy only. Currently in Morning Glory, still using Item level requests, On order-items are possible to recall. Even though that might not be philosophically correct, it is part of currently implemented status logic, and a vital part of our daily workflow.

    For Title level requests, the ticket CIRC-1684 (TLR: Unable to recall items with status In process, In transit, On order) is just filed.
    Just want to comment on that here, so we think through how recalls should be handled when the request is placed directly in Orders app as well.