JIRA issue:  UXPROD-2373 - Getting issue details... STATUS

Problem:

Some pieces are received with no items in inventory to represent them. In this case there is no indication that those materials have been received in any other application. This information may be important for discovery, managing inventory and other workflows.

Note: this feature will include an update to the interaction logic between orders and inventory regarding Holdings. Receiving pieces to a new location can in some cases result in unwanted Holdings being created. When the permanent location of a Holdings is changed, it may need to update expected pieces such that they can be received to the correct location.

Use cases:

1. Print Journals (Only Physical Pieces) are checked-in for a periodical and the system is not set to create items to represent them. The librarian might be waiting to bind those things until they have enough pieces to bind and creating items may require them to be deleted once bound. The librarian wants these pieces to show in discovery as expected and ultimately as received until 1 item is created to represent them. These items would live on the self and be available for use even though there is no item record. These many be for circulation or for internal use.
   • When the librarian receives these pieces they might add a public note when they indicate they want them piece to display publicly
2. Patron comes to reference desk because they can't find something. Librarian wants to confirm it has been received, identify what bound volume it is included (If it has been bound yet) in and find out where that bound volume or loose issue is in the library. These librarian often will not be accessing the ILS system and Acquisitions data as they may not have creds/perms/training.
3. Patron wants to confirm a material has been received, identify what bound volume it is included (If it has been bound yet) in and find out where that bound volume or loose issue is in the library.
4. For some legal materials (Integrated materials) there will never be an item representing the piece being received. It may be a pocket part etc. and librarians will still need to be able to identify whether it has been received or not. This information is also displayed in discovery
5. Librarian my reference the receipt date as a means of troubleshooting why nothing has been received recently.
6. Patron wants to see info for a particular title. Item may have been created for piece but holdings will provide additional information about what makes up that item. Eg. Current years version of chapter two has been received and added to it.

Workflow

Step 1

User creates piece(s) for receiving

User may add enumeration and chronology or they may not (Not required)

Step 2

IF Piece format is associated with "Create inventory" setting that includes Holdings (If NOT then user can select location)

User can Select Holdings with which the piece should be associated

Any item record created for the piece would also be associated with this Holdings

Existing holdings are populated in select list based on Title/instance connection.

User can choose to create new holding for a location by clicking the Hyperlink and choosing a location.

A new holding will be created when the user saves the piece

Step 3

User will choose if they want piece information to appear on the related holdings using the toggle (Checked by default for POLs that are "Manually add pieces for receiving")

Step 4

User will choose if they want the piece information from the holdings to appear in discovery using the toggle (By default not checked)

User can save piece information. No matter what is selected pieces with a status = expected DO NOT display on holdings. Pieces must have status = Received to display on holdings.

Ie. for piece information to appear on Holdings. Display on holdings is checked AND Piece status = received

Step 5 (TBD)

When piece is received, Holdings "Receiving history" is updated. to display data from the field analysis below.

All workflows below will now be implemented as part of the work being done to link POL and Holdings

UXPROD-1925 - Getting issue details... STATUS

Update to Order record Location assignment

Given the update being made in receiving for selecting holdings and storing the holding UUID. It could make sense to adjust POL location selection at the same time. The changes would be as follows:

Given user has created a "Title" POL AND connected the POL to an instance

User can select a Holdings rather than a location

If desired Holdings does not exist then user can click the "Create new holdings for location" link to add a location to the field. When order is opened a new holding will be created for this location.

Possible Update to Order record Edit quantity of open order

Scenario 1

For order lines with "Manually add pieces for receiving" = true

Quantity and location can be edited without affecting the expected pieces in receiving. In this scenario order quantity and receiving quantity ARE NOT kept in sync.

Scenario 2

For order lines with "Manually add pieces for receiving" = false

Quantity and location of POL would be inactive (Disabled) in the EDIT form, once PO status = Open or Closed

In receiving user would be able to add or remove pieces as needed AND this will update the POL quantities, location and estimated price information. Meaning this would also affect encumbered value.

Add piece button:

(Clearly display to user that adding and removing pieces will change the quantity and price of POL)

Delete piece button:

APENDIX

Analysis of piece data to be displayed in holdings

Receipt date? No Yes

• General consensus would be only to display what has been received - making this data redundant
  • UPDATE: if someone is looking for a serial issue that was checked in just yesterday, having the receipt date display allows one to surmise that it has not made it to the shelf yet, but is somewhere awaiting shelving and could be fetched.

Piece status? No

• General consensus would be only to display what has been received - making this data redundant

Caption? Yes

• Must be split into Enumeration and Chronology
• For migration the current "Caption" field should become "Enumeration"
• This information needs to display in order to identify what exactly has been received

Format? No

• Could be confusing as it primarily serves as an indication to the system how to treat this piece when interacting with inventory

POL #? NO!

Location? Yes

DB: This may not make sense, still need clarification. The holdings should represent the location if there is no Item. This would be valuable for pieces that have an unbound location which is different from the permanent location.

• Holdings record would need to allow you to hide location information about the piece. 

Comments? Yes

• At least makes sense to provided them for display and these may or may not be shown to public etc.

Expected date? No

• We are not expecting to show 'expected' issues. There is a possibility that it would be valuable to show the next upcoming piece but that would be out of scope for this feature.

Additional data needed in piece

Display on holdings

• Must have toggle that controls whether piece information displays on holdings or not.

Public display

• Must have toggle that controls whether piece information displays to public or not. There is already a corresponding data point in Holdings record

Create/update piece flow diagram

Use cases : manual create piece (from UI or direct API call)

Feature: Create piece with holding reference for the open order, where POL "manually add pieces" is false and "create inventory" is "Instance, Holding, Item" or "Instance, Holding"

Background
Given Open order with Non package POL
And "Manually add pieces" is false
And "Create inventory" is "Instance, Holding, Item" or "Instance, Holding"

@Case1
Scenario: An open order has POL with the same link to the holding as Piece
Given An open order  with one physical POL
And POL has link to the Holding_Ref_1 link for the Location1 with 1 physical item

When From Receiving App → Manual piece creation started (UI or direct API call)
And Physical piece has link to the Holding_Ref_1

Then Location1 has 2 physical item with link to the Holding_Ref_1
And POL has 2 pieces with Holding_Ref_1
And Cost amount updated has 2 physical items
And Encumbrances updated

@Case2
Scenario: An open order contains a POL in which the link to the holding differs from the link to the holding in the Piece
Given An open order with one physical POL
And POL has link to the Holding_Ref_1 link for the Location1 with 1 physical item

When From Receiving App → Manual piece creation started (UI or direct API call)
And Physical piece has link to the Holding_Ref_2

Then Location1 has 1 physical item with link to the Holding_Ref_1
And The new location was created (Location_2) for the line with a link to the Holding_Ref_2
And Location_2 has 1 physical item
And POL has 1 piece with referenced Holding_Ref_1
And POL has 1 piece with referenced Holding_Ref_2
And Cost amount updated and has 2 physical items
And Encumbrances updated

Feature: Create piece with location reference for the open order. POL has "manually add pieces" is false and "create inventory" is "Instance, Holding, Item" or "Instance, Holding"

Background
Given Open order with Non package POL
And "Manually add pieces" is false
And "Create inventory" is "Instance, Holding, Item" or "Instance, Holding"

@Case3
Scenario: An open order has POL with link to the holding. Piece has link with same location to the holding's permanent location in the line.
Given An open order with one physical POL
And POL has link to the Holding_Ref_1 link for the Location_1 with 1 physical item
And Holding_Ref_1 has permanent location Location_Ref_1

When  From Receiving App → Manual piece creation started (UI or direct API call)
And Physical piece has link to the Location_Ref_1

Then Location_1 linked to the Holding_Ref_1 with 1 physical item
And New holding was created (Piece_Holding_Ref) with permanent Location_Ref_1
And The new POL location was created (Location_2) for the line with a link to the Piece_Holding_Ref
And Location_2 has 1 physical item
And POL has 1 Piece linked to the new created holding (Piece_Holding_Ref)
And POL has 1 Piece linked to the Holding_Ref_1
And Cost amount updated has 2 physical items
And Encumbrances updated

@Case4
Scenario: An open order has POL with link to the holding. Piece contains a link to a location that is different from the holding's permanent location in the line.
Given An open order with one physical POL
And POL has link to the Holding_Ref_1 link for the Location_1 with 1 physical item
And Holding_Ref_1 has permanent location Location_Ref_1

When  From Receiving App → Manual piece creation started (UI or direct API call)
And Physical piece has link to the Location_Ref_2

Then Location_1 linked to the Holding_Ref_1 with 1 physical item
And New holding was created (Piece_Holding_Ref) with permanent Location_Ref_2
And The new POL location was created (Location_2) for the line with a link to the Piece_Holding_Ref
And Location_2 has 1 physical item
And POL has 1 Piece has linked to the new created holding (Piece_Holding_Ref)
And POL has 1 Piece has link to the Holding_Ref_1
And Cost amount updated has 2 physical items
And Encumbrances updated

Receive piece flow diagram

Updating POL cost, location and related inventory records diagram

Receiving pieces with Holdings ID stored in piece and POL

POL receipt status is "Receipt not required"

Ticket to cover : MODORDERS-574 - Getting issue details... STATUS