2024-09-04 Meeting notes: Move holding/item data in Inventory should update POL-Instance connection accordingly

 Date

Aug 12, 2024

Homework

Please try to do the homework, but you are still more than welcome to attend even if you don’t have time!

Housekeeping

Convener and notes: @Martina Schildt

Recording:

  • @Martina Schildt, @Kristin Martin, @Dennis Bridges, @Ryan Taylor, @Felix Hemme @Dung-Lan Chen @Owen Stephens @Maura Byrne @Ryan Taylor @Heather McMillan @Lloyd Chittenden @Peter Sbrzesny @Jean Pajerek @Charlotte Whitt@Laura Daniels @Kimberly Smith PLEASE ADD YOURSELF

 Goals

  •  

 Discussion topics

Time

Item

Presenter

Notes

Time

Item

Presenter

Notes

5 min

Announcements

 

  • Upcoming meetings (Tara)

55 min

Holdings/Item → POL relationship

@Kristin Martin

@Felix Hemme & @Martina Schildt

  • Move holding/item data in Inventory should update POL-Instance connection accordingly

 

Minutes

Time

Item

Presenter

Notes

Time

Item

Presenter

Notes

0:02

Announcements

 

  • Meeting on Sep 9th on Actual Cost field

18:06

Holdings/Item → POL relationship

Chicago workflow

@Kristin Martin

Kristin demos a spreadsheet where Chicago lists use cases to transfer holdings/items

  • duplicate bibliographic records

  • item attached to wrong record

  • moving records is happening from bibliographic standpoint - not from acquisitions

Kristin demos workflow in FOLIO

  • actions menu indicates that moving to another instance is possible

  • no error messages from the system that instance and holdings references will be independant from now on

  • reason for independant linking: link from item leads to the ‘former’ title instead of the new one, whereas it should point to the new instance

    • holding and instance are both linked to the correct order, though

  • the solution Chicago has come up with:

    • in the beginning: acquisitions team do the change,

    • meanwhile metadata staff have permission to do the change from the POL (Orders app)

  • it stays a cumbersome process > it is a workaround

  • more and more inaccurate linking will happen over time, the longer libraries are in FOLIO

  • at the moment: a dozen per month

  • Dennis: receiving will try to fix the connection and will move the holdings back to the former instance

  • solution: make Inventory aware of all connection > have Inventory message acquisitions what is happening and then produce a message that asks the user what is supposed to happen

    • e.g. move holding AND instance to new

  • Dung-Lan in chat: No warning about a PO/POL existed for the item you are trying to move to a different instance and if you'd like to continue and have the POL title switched out to the new instance as well or if you want to stop.  It would be nice to have such warning for awareness purposes, I feel.

18:26

Holdings/Item → POL relationship

GBV workflow

@Felix Hemme

Felix presents slides to describe GBV workflow

  • workflow starts in Union Catalogue

  • reason to move holdings

    • wrong edition or duplicative record has been used

  • GBV uses a statistical code to tag all ‘wrong’ records where holdings have been moved but POL is still connected

  • with the code all instances can be listed and staff can act on list

  • change instance connection in orders > what should happen with holding > find or create new

    • although we only want to find but not create new, but there is no other option

    • ‘None’ would be appropriate, but will lead to an error message

  • Charlotte in chat: In MIU (mod-inventory-update) we are fixing the issue with moved holdings and items to be aligned with data in Orders (and avoid data corruption) - will be addressed in MODINVUP-110

  • Martina in chat: we would like to link POLs to existing items

  • Dennis: why is the solution using ‘find and create’ instead of move

    • find or create: there will still be a holding on the old instance

    • ‘move’ should be used > information should be added to documentation

18:40

Discussion

 

  • Laura in chat: Often we need to move holdings/items after something has been received; the person who knows it needs to be moved is not the person receiving it... or did I miss something about what Dennis just said?

  • Charlotte: The FOLIO system should clean up across apps - that would be the right way to do it. > agreed

  • Laura in chat: It seems like we need an in-between place (app?) to store relationships between apps > agreed

  • Laura in chat: it is awkward when users have to keep track of where the data actually resides

  • Charlotte: Orders app should listen to events in Inventory that refer to orders and then fix it in orders

  • Dennis: it seems to be the responsibility of orders to listen to changes

    • orders would follow one workflow (not individual workflows)

  • there is a feature for syncronizing item data with piece data

  • we need independance on how things should be organised

Outcomes

  • need knowledge about where data lives

  • bring topic to Workflow SIG because workflow engine could possibly solve this issue

    • workflow triggers one change based on another change

  • if no workflow case: bring back to ACQ SIG

    • Dennis sees the responsibility in orders app to listen to these changes

 Action items