Allow User to generate requests from Order line

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 type created updated due assignee reporter priority status resolution
Loading...
Refresh