Implement data consistency approach for Piece<>Item interaction
UXPROD-3342 - Getting issue details... STATUS
Problem(s):
- Users will update inventory record details and this does not updated order details
Use Cases & Requirements:
| Legend |
| Scope may require separate feature |
Requirement | Status | Use cases |
|---|---|---|
| When enumeration, chronology or copy number are edited in item record the linked piece is updated | VERIFIED | Users may need to edit input errors in the enumeration, chronology, copy number fields after the item has been received |
VERIFIED | Data import may need to update enumeration, chronology, copy number fields after the item has been created | |
VERIFIED | Catalogers editing item details after the point of receipt would always be thinking of inventory. Could be two different sets of enumeration and this needs to be changed to a different one. These users may not have received permissions | |
VERIFIED | Smaller operations may have a single user that has all permissions but after point of receipt this user would also focus on the inventory interface when correcting or updating these fields. | |
VERIFIED | For standing orders and periodicals in particular it is important to keep this data in these records in sync. Eg. if the item enumeration is changed to 3-4 but the piece is still 3, a user looking at receiving history may mistakenly think that issue 4 was never received. | |
VERIFIED | Receiving data is not necessarily describing "what was ordered" so much as what was received. This is in many ways dependent on how information is captured and how it evolves in inventory as the representations of this material become more specific. For this reason it also makes sense that the data be kept in sync. | |
User is able to change the instance connection of POL and move all related items See UXPROD-3619 - Getting issue details... STATUS | DEFERRED | Serials title change can be major and require a new instance be created. This is rarely caught at point of receipt meaning that once the new instance is created the library would move one or more items to the new record |
DEFERRED | One scenario we encounter often is a firm ordered monograph gets ordered on its own bib record but later it needs to get moved to a different mono continuation record--so this would involve moving the item to another holding on a different Instance record. Generally this would mean getting rid of the bib after as it is no longer needed. | |
DEFERRED | Often times materials that need to be moved would already be received. However it is possible that we discover the material while it is On order and want to correct it immediately | |
DEFERRED | I would say it is very common for us to do. maybe a few in one month, more than 5-10 some months We have a project right now with more than 100,000 items that need to be collapsed into a single holdings on the instance. Well, it happen every day for me, and when it does it's very time consuming, but it's way less than the number of things I process "normally" |
Proposed workflow:
https://miro.com/app/board/uXjVPPrQbuE=/?share_link_id=870031371969
Questions:
Question | Status | Conclusion | Comments |
|---|---|---|---|
OPEN |
Functionality Potentially Impacted by Changes:
Functional area | Records | Potential impact | Suggested Regression Testing |
|---|---|---|---|
Work Breakdown Structure: