2020-08-20 (Accession / de-accession discussion)

Meeting details

Agenda

• Summary from the previous meeting about accession

• Restrictions for item accession: any possible reasons, why an item can’t be sent to remote storage, that are known to the ILS.

• Locations synchronization between FOLIO and remote storage system

• Bulk accession:

  • how is it happening now

  • what are the desired improvements

  • proposal

• Send updates of item’s metadata to remote storages 

• Deaccessioning flow(s)

• Remote storages configuration in FOLIO

• Working with remote storage locations in FOLIO

Notes

• Rob O'Connell - joined the group. Director of discovery access in digital engagement for Smith Colledge (part of the 5Colleges). Smith Colledge is a primary user of the 5Colleges high-density storage system. Wrote the software for the facility (interface for Aleph installation) and it does a lot of the staff that a standard remote storage system does.
• Rob O'Connell - we are using one remote storage system and Smith Colledge is the only user of the facility (about 60%) right now. UMass has their own system, but there will be a transition to our software very soon.
• Rob O'Connell - older facility (the bunker) has no own software and is managed by the Aleph.
• David - the other issue with a purely location-based approach is that as of now if somebody stores something without having updated it to the correct location we can still get it back out because the status will let us request things. But it is more of an outlier because we could fix it by running a report. 
• David - restrict items from being accessioned in statuses others than "Available" would cause problems for us. I am thinking about things like accessioning an entire serial run if five volumes are currently loaned to patrons. We still need those records to go into the database, so that when they come back they can be stored. It feels like an unnecessary restriction
• Tod - implement this restriction would be more development work. We should probably implement them is these restrictions actually protect us from something we want to be protected from.
• Jacquie - currently we get accession reports on this kind of data from Aleph, so for CaiaSoft and GFA these kinds of restrictions could be set up as a report to come back to tech services, but never prevent the actual accession of the item. The ones that are circulating could not be accesioned until they come back, because the Caiasoft needs to scan the barcode.
• Mary - in our case our current ILS requires available and it frustrated us often because it is a requirement of ILS, not the Dematic, so getting rid of that requirement would be helpful
• Jacquie - I just like the idea of tech services having a report or review to track down those things.
• David - prevent locations from being marked as remote if they are assigned to holdings or items might cause migration issues. All of our locations will have records already associated with remote storage.
• Tod - this would be a part of setting up and configuring locations, so that could also be controlled by permissions for updating the locations. 
• David - the chance of an accident with configuring locations would be pretty low. And in case of an accident - you picked a location and a big number of records are sent to remote storage, then you would simply find a way to do a batch delete of those records.
• Jacquie - it is unlikely that we will change our locations in that way, but I agree if the location has got any holdings or items, it shouldn't be changed to the remote. But the likelihood of someone attempting to do that is low - it would be a tech service or remote storage manager.
• David - as long as it didn't affect the migration I can't imagine the scenario in which we would wholesale take a location and make it remote. The example of that is we have a shelving location, and we move the entire collection wholescale into our facility, but we did that by transferring it from existing shelving location to a new one. I can't image too many scenarios where having this restriction could be a problem.
• Jacquie - I can imaging moving a whole collection to remote storage, but I can't image taking the location code and making it remote. We would create a new shelving location and transfer them.
• Erin - my concern is about hiding the Caiasoft location in records editing as I don't know if there is any place in FOLIO that does that and it feels like something that could be really buggy and difficult to test. I would rather show it and, in case I put it and I didn't have the permissions to do that, then get the message that says about that.
• David - or you can, again, have a report that looks for things that have their remote locations, but they don't actually exist in Caiasoft for cleanup purposes. Erin - that would be my second preference. I would want something in that workflow that would stop me if I didn't have the permission to accession an item.
• Jacquie - because errors will happen because of humans and because our accession process starts from CaiaSoft and the data flows back to Aleph there are situations where the location can't be changed by the script right now - the item is checked out or it has got the wrong item state or there is an error - communication hiccup. Something just didn't go the way it was supposed to, our staff go in and update the data. So we have to be able to update the data.
• Tod - location codes in Caiasoft and in FOLIO might be not exactly the same and probably mapping should be provided
• Jacquie - I think the map is necessary, I need to double-check, so this is my tentative answer - the coding is not exactly the same because it can't be for some reason in CaiaSoft the same locations in ILS. The synchronization by cron job would be preferred. 
• Erin - CaiaSoft has the concept of delivery locations. Jacquie - yes, but they locate the book by a completely different system (container, shelf, area, the building of the storage). Erin - so CaiaSoft call them circulation stops and that's probably the closest to FOLIO locations. Same with GFA.
• Jacquie - CaiaSoft sends back a list of barcodes, the ILS looks and identifies those items, refers to an accession table that says "when you find an item that has this location and is on this accession list - flip it to this other location". CaiaSoft sends barcodes and owning library.
• Erin - ILS looks at the text file that sits on the server to map the locations. Tod - the mapping file would have to be represented into Caiasoft edge module.
• Tod, David - we do bulk accession on the back (changing locations). Tod - we might do those updates in SQL
• Mary - we change location codes to one bogus location, then it goes through a maintenance process that bulk changes the location to whatever ASRS was sending it to, whereas this new process we are looking at is as the item's location gets changed in the record, it would be sending the information to Dematic.
• David - we need the ability to do the bulk occasionally. The bulk accession should use the same process as triggering it in the UI one by one would do. Not a "day one" requirement.
• David - forming a batch of accessioning items might be via the SQL query, using a combination of factors (locations, number of times item circulated, call number ranges etc.). I don't think this would be done through the Inventory, through the UI at all, likely somewhere on the back end.  

Artefacts

Attendees