Requests (UXPROD-790)

[UXPROD-3803] Remote storage: Dematic StagingDirector Deaccessioning Created: 15/Sep/22  Updated: 06/Apr/23

Status: Blocked
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Requests

Type: New Feature Priority: P2
Reporter: Stephanie Buck Assignee: Stephanie Buck
Resolution: Unresolved Votes: 0
Labels: consortia-ebsco, remote_storage
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Cloners
clones UXPROD-2882 Remote storage: Deaccessioning Draft
Defines
is defined by UIRS-84 StagingDirector deaccessioning: mark ... Open
is defined by UIRS-85 StagingDirector deaccessioning: chang... Open
is defined by UIRS-86 StagingDirector deaccessioning: dele... Open
is defined by UIRS-87 StagingDirector deaccessioning: movin... Open
Relates
relates to FOLIO-3621 Remote storage knowledge transfer Closed
relates to MODRS-162 [Spike] RS - Investigate technical ap... Open
relates to MODRS-151 SPIKE: Investigate deaccession soluti... Closed
relates to MODRS-149 Spike for UXPROD-3803 Closed
Epic Link: Requests
Development Team: Volaris
Rank: Cornell (Full Sum 2021): R5

 Description   

Current situation or problem: Initial iterations of remote storage work did not include Deaccessioning

In scope: Deaccessioning items (removing an item barcode from the remote storage database) for Dematic StagingDirector

Use case(s): Permanently removing items from a collection is a regular part of library workflows. Moving an item to a temporary location is a regular workflow. 

Workflows: 

  • Marking an item as withdrawn (item status) should remove the item barcode from remote storage database, deaccessioning the item
  • Changing an item's remote storage location to a non-remote location would remove the item barcode from remote storage database, deaccessioning the item
  • Deleting an item record with a permanent remote storage location in FOLIO would remove the item barcode from remote storage database, deaccessioning the item
  • Moving a holding or item from an instance or holding with a remote location to an instance or holding with a non remote location should remove the item barcode from remote storage database, deaccessioning the item

Proposed solution/stories

  • Dematic (StagingDirector): has Inventory Delete message, which is sent by ILS when an item is changed from a status of "in storage" to “on shelf”. It indicates that the item is no longer in storage and is the means by which a SKU is removed from the StagingDirector database.
  • For the first step it might be enough to handle items removal manually. Deaccession flow also can be treated the same as FOLIO-initiated accession flow with the next differences:
    • Triggered only by changing permanent item’s location from remote to non-remote.
    • Checks that item is out of the storage before deaccession. Removing an item from the database before it was physically retrieved makes it impossible to pull out an item in future.

Links to additional info
https://folio-org.atlassian.net/wiki/display/AppInt/Dematic+StagingDirector+deaccessioning 



 Comments   
Comment by Mikhail Fokanov [ 26/Oct/22 ]

Stephanie Buck

Moving a holding or item from an instance or holding with a remote location to an instance or holding with a non remote location should remove the item barcode from remote storage database, deaccessioning the item

Should we change holding or instance location, when the item location is changed to non-remote?

Comment by Mikhail Fokanov [ 26/Oct/22 ]

Right now for accession if there is an error with accession, the Folio will just log exception to Folio logging and don't try to do it again. Should it be the same for the deaccession?

Comment by Mikhail Fokanov [ 26/Oct/22 ]

How the "Checks that item is out of the storage before deaccession" should be performed? What should Folio check? Item status?

Comment by Mikhail Fokanov [ 26/Oct/22 ]

"Triggered only by changing permanent item’s location from remote to non-remote." Why the permanent location and not the effective location is considered? Effective location is changed when the location of the parent holding is changed, that is why we used it for accession. Can we use the same field effective location ?

Comment by Stephanie Buck [ 28/Oct/22 ]

Right now for accession if there is an error with accession, the Folio will just log exception to Folio logging and don't try to do it again. Should it be the same for the deaccession?

Yes. 

Comment by Stephanie Buck [ 28/Oct/22 ]

How the "Checks that item is out of the storage before deaccession" should be performed? What should Folio check? Item status?

This is a human action. There are warning messages in the UI designs to ask FOLIO users to ensure they've pulled the item from the shelf before deaccessioning. 

Comment by Stephanie Buck [ 28/Oct/22 ]

"Triggered only by changing permanent item’s location from remote to non-remote." Why the permanent location and not the effective location is considered? Effective location is changed when the location of the parent holding is changed, that is why we used it for accession. Can we use the same field effective location ?

Please see UIRS-85 Open for location details. Effective location AND one other location type will be needed. 

Comment by Buddy Pennington Jr [ 28/Oct/22 ]

Stephanie Buck - I just wanted to chime in with a couple of quick comments, based on the documentation I have from GVSU as well as our own Dematic documentation.

  • ILS sends an ID (Inventory Delete) message to ASRS. ASRS will then send a DC (Delete Confirmed) message back to the ILS.
    • ID message includes ID, transaction number, timestamp, barcode/SKU.
    • DC message includes DC, transaction number, timestamp, barcode/SKU and reject code.
      • 006 = invalid code
      • 003 = barcode/SKU not in database
      • 009 = barcode/SKU has inventory (In UMKC documentation this is "barcode/SKU is stored in ASRS rack")
      • 000 = barcode/SKU successfully deleted 

It appears to me that our Dematic EMS setup messaging for deaccessioning follows what GVSU has. So hopefully, there is no need for additional accommodation for UMKC for deaccessioning functionality. We'd be happy to be included in testing once you all are ready for that. Thanks!

 

Comment by Tim Auger [ 23/Feb/23 ]

We just received a notification that Dematic may be decommissioning it's Staging Director product in October of 2023. As a result, we may not be spending any development resources to this product (and may be devoting resources to a different product).

Comment by Buddy Pennington Jr [ 23/Feb/23 ]

Ah, interesting, Tim Auger. Our situation at UMKC is a little odd regarding these FOLIO integrations in that we do not use Staging Director software. We use EMS (by Dematic) software but our connection is TCP/IP so we are relying on the Staging Director configuration for Remote Storage as that connection method is not supported by the Dematic configuration. 

Does this mean that deaccessioning functionality will not be developed for the Staging Director configuration?

Comment by Stephanie Buck [ 23/Feb/23 ]

Hi Buddy Pennington Jr. We're pausing on development until we have more information. We'll make sure you're kept in the loop. 

Comment by Buddy Pennington Jr [ 23/Feb/23 ]

Stephanie Buck - Sounds good. Thanks!

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