Analyse and implement container object in Inventory

Description

Analyse and possible implement the container object described in The Codex Metadata Model - https://folio-org.atlassian.net/wiki/pages/viewpage.action?pageId=5854462

Local package is part of the initial model - which consists of 5 objects: package, instance, item/holding/coverage, and location. Vince's model is inspired by BIBFRAME2, but the Package object in this model is new, and does not originate from BIBFRAME.

At MM-SIG meeting on 4/5/2018:
The role of a package structure in inventory. Some options:

  • Instance records could represent packages in inventory

  • There could be a package structure in inventory, instead of a package becoming an instance. This could be a new entity within inventory.

UX-mock up - reviewed by the Container Small Group on 8/8/2019:

Documents:

Priority

Fix versions

None

Development Team

None

Assignee

Solution Architect

Parent Field Value

None

Parent Status

None

Attachments

3

has to be done before

Checklist

hide

TestRail: Results

Activity

Show:

Jacquie SamplesSeptember 23, 2020 at 8:32 PM

I agree with Dennis that creating dummy records as a work-around is not sustainable and will cause problems later when the needed features listed here are developed. It appears that the high ranking supports Dennis's 2 cents.

Dennis BridgesJanuary 13, 2020 at 4:59 PM

I think should not be the issue that sets the priority for the Inventory feature. If the folks working on the inventory app decide that is a priority it should be implemented accordingly. Once it has been implemented we can worry about . My logic here is that creating the record from an order should be secondary to what the inventory app decides is best for the usability and functionality of inventory app. If and when things change in inventory acquisitions folks will revisit the question of how best to leverage the inventory app to enhance the workflow of acquiring material. Know what I mean?Just my two cents

Charlotte WhittJanuary 13, 2020 at 3:44 PM

Hi - I noticed that now has fix version as Q4 2020. Do that imply that we then set , and if not doing the full data set, then the minimized data set (UIIN-695) as Q3 2020, so Inventory work is ready for Orders to build upon?

CC:

Felix HemmeSeptember 27, 2019 at 8:53 AM

Dennis BridgesJuly 19, 2019 at 4:26 PM

From the acquisitions perspective the container is essentially step 3. First we need to be able to use the POL to order a package of titles and Receive those titles (AKA check-in multiple titles against a POL). Step 2 is the connection with inventory and we have already built the ability to generate instances holdings and items based on a POL and its 'physical', 'electronic' or 'other' piece records (We need to build in how a POL generates multiple instances but the design is already complete). Step 3 would be allowing the user to choose to have the POL represented directly in inventory by a container, generating that container and associating it with the titles the POL has been connected to.

By the end of step 2 you will be able to accomplish all of three of the bullets listed above. The container may enhance visibility and provide additional functionality but the relationship between POL and multiple titles is the immediate priority for orders and receiving.

Details

Reporter

Potential Workaround

CW: Do dummy records!

PO Rank

104

PO Ranking Note

CW: The feature for the Order app creating container records (UXPROD-1105) has the calculated institutional ranking: 110, PO ranking: 76). The Order feature is dependent on having the container in Inventory. DB: Just clarifying here. UXPROD-1105 is for the creation of the container based on a POL. Which of course, relies on the container being possible to create. However, this is currently related to receiving packages (UXPROD-1547) but not required. Someone could receive packages of material through checkin using instances as a workaround.

Analysis Estimate

Medium < 5 days

Analysis Estimator

Front End Estimate

XL < 15 days

Front End Estimator

Front-End Confidence factor

Medium

Back End Estimate

Large < 10 days

Back End Estimator

Rank: FLO (MVP Sum 2020)

R2

Rank: 5Colleges (Full Jul 2021)

R1

Rank: Cornell (Full Sum 2021)

R4

Rank: Chalmers (Impl Aut 2019)

R5

Rank: GBV (MVP Sum 2020)

R2

Rank: hbz (TBD)

R1

Rank: Hungary (MVP End 2020)

R1

Rank: TAMU (MVP Jan 2021)

R1

Rank: Chicago (MVP Sum 2020)

R1

Rank: Leipzig (ERM Aut 2019)

R1

Rank: U of AL (MVP Oct 2020)

R5

Rank: Leipzig (Full TBD)

R1

Rank: Lehigh (MVP Summer 2020)

R4

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs

Created April 6, 2018 at 6:51 PM
Updated December 6, 2023 at 6:52 PM
TestRail: Cases
TestRail: Runs