Requests
(UXPROD-790)
|
|
| Status: | Closed |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | TBD | Parent: | Requests |
| Type: | New Feature | Priority: | P3 |
| Reporter: | Brooks Travis | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | front-end, requests, resourceaccess, ui-only, volaris-candidate | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||
| Issue links: |
|
||||||||||||||||
| Epic Link: | Requests | ||||||||||||||||
| Development Team: | Vega | ||||||||||||||||
| PO Rank: | 0 | ||||||||||||||||
| Rank: Cornell (Full Sum 2021): | R5 | ||||||||||||||||
| Description |
|
Current situation or problem: Under some circumstances, items in FOLIO inventory may share a barcode, but FOLIO requires all item barcodes to be unique. One potential remedy in these situations is to add a suffix to the barcodes to make them unique WITHOUT updating the physical barcodes on the item. Another situation may arise when handling items from outside the local FOLIO inventory (eg. ILL, INN-Reach integration, etc.). We need a mechanism to disambiguate items under these circumstances when presented with an unaltered barcode. In scope
Out of scope
Use case(s)
Proposed solution/stories To avoid inadvertently transacting with the incorrect item, it should be possible to perform a "fuzzy" or wildcard match on the entered barcode before populating item information in the request creation form. If more than one matching item record is returned, then a modal should be presented with a list of items (similar to the "move request" modal in ui-requests) to choose from. When an item is selected, that item's information should be used to populate the request transaction. Links to additional info Questions |