Inventory (UXPROD-785)

[UXPROD-2284]  Inventory. Receive item data/update item record as part of receiving process Created: 26/Feb/20  Updated: 13/Sep/21  Resolved: 02/Mar/21

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Inventory

Type: New Feature Priority: P3
Reporter: Charlotte Whitt Assignee: Dennis Bridges
Resolution: Duplicate Votes: 0
Labels: acquisitions, receiving, round_iv
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Epic Link: Inventory
Front-End Confidence factor: Medium
Back End Estimator: Dennis Bridges
Development Team: Thunderjet
PO Rank: 71.3
PO Ranking Note: DB: Since I have taken responsibility for this feature I have adjusted ranking to fit with my other feature rankings. However, as noted in comments it is unclear what still needs to be implemented for this feature
Rank: Chicago (MVP Sum 2020): R1
Rank: Cornell (Full Sum 2021): R1
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R1
Rank: GBV (MVP Sum 2020): R1
Rank: hbz (TBD): R4
Rank: MO State (MVP June 2020): R1
Rank: TAMU (MVP Jan 2021): R1

 Description   

Automatically/manually add info such as barcode number, call number, item status, receipt status, receipt status date from the Order and Receiving app, or imported MARC record.

Requirements documented in slide deck: https://docs.google.com/presentation/d/1efvGfC3uot-E9iSuhHkWqJZ0oxV8n3OsZC7IwoDV0o8/edit#slide=id.p

Out of scope in initial phase: change status in bulk (e.g. in process moving to available)



 Comments   
Comment by Cate Boerema (Inactive) [ 29/Jun/20 ]

Marc Johnson and Michal Kuklis can you please add FE and BE estimates to this feature? If you need more info, please ask questions in the comments and Charlotte will answer.

Comment by Michal Kuklis [ 29/Jun/20 ]

Charlotte Whitt would you mind providing more details / mockups for this story? From reading the description this seems to be mostly a backend work but maybe I'm wrong.

Comment by Marc Johnson [ 02/Jul/20 ]

I'll echo Michal Kuklis request, there isn't enough information here for me to be able to estimate this feature.

I would need to understand a little bit about the process for receiving and how items are changed during it.

I don't have enough context to even start asking good questions.

Automatically/manually add info such as barcode number, call number, price from API, MARC record, order record, or invoice.

What does automatic mean in this sense?

The processes around MARC records and orders already create item records using APIs, they can also update if they so wish.

Comment by Cate Boerema (Inactive) [ 03/Jul/20 ]

Charlotte Whitt can you please add a more comprehensive description to this feature so the guys can estimate?

Comment by Cate Boerema (Inactive) [ 28/Oct/20 ]

Dennis Bridges and Charlotte Whitt, we recently discussed a similar issue (I can't remember which one) and decided it made more sense for Thunderjet to do the development because the process originates with their apps. Would the same hold for this one?

Comment by Charlotte Whitt [ 28/Oct/20 ]

Cate Boerema - the features we discussed were UXPROD-1925 Closed and UXPROD-1995 Closed - which already are assigned to Thunderjet.

If Thunderjet have the bandwidth and also can pick up this work on automatically populating data in holdings/item in Inventory when captured in the Receiving app that would be nice, especially if we can have it done for R1 2021. It's important for Round_iv libraries.

CC: Dennis Bridges

Comment by Dennis Bridges [ 28/Oct/20 ]

Actually most of the data points referenced in the description we have already implemented as part of the receiving workflow. Eg. you can already populate the barcode and call number into the item record from receiving. I would say it does make sense for use to pickup this feature. However, Thunderjet does not have any additional capacity for R1, so the remainder of this would be implemented in a future release. Thoughts?

cc: Cate Boerema Charlotte Whitt

Comment by Cate Boerema (Inactive) [ 29/Oct/20 ]

Actually most of the data points referenced in the description we have already implemented as part of the receiving workflow. Eg. you can already populate the barcode and call number into the item record from receiving.

Then I'll bet the rankings on this are higher than they should be. I think we should clean up the feature description to indicate that many of these are already being populated and clear out the rankings so people can re-rank the remaining work. I also think we can reassign to Thunderjet. If you guys have already done work exactly like this, it doesn't make sense to have another team pick up the remaining data elements (unless they turn out to be a super high priority for R1)

Comment by Dennis Bridges [ 19/Nov/20 ]

Charlotte Whitt I'm just circling back to this. I believe everything mentioned in the slide deck that is referenced in the description above as the requirements document, has now been implemented. We may also, be able to consider the other details noted in the description as having been covered by other features?

Ie. When user receives an Item using the receiving app. They can input a Barcode and Call number. When the user clicks receive these details are actually stored in the Item record in inventory (Not in the Orders/receiving app). The item status is also set to "In process" as desired.

The description also makes reference to the receipt status and receipt status date. Is it safe to say that UXPROD-1995 Closed will satisfy this requirement? That feature will see the Order information displays on the item record (Including the referenced fields). However it will not be stored in the item record. This way the system does not need to worry about syncing the data across apps. It can be edited in orders or receiving and the changes will appear on the appropriate item record.

The description also references an imported MARC record. Is it safe to say that if users could import orders through data import via MARC files, that this detail would ultimately end up in orders and UXPROD-1995 Closed would also satisfy this requirement. Meaning that the data coming in from a mark record would be added to orders would in turn connect to items records where the details would display?

That said do you think we could resolve this feature? If not what updates do you think we need to make here to address the original concerns? Thanks!

Generated at Fri Feb 09 00:22:41 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.