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:

key	summary	type	created	updated	due	assignee	reporter	priority	status	resolution

Loading...

Refresh