Page Comparison

...

• David - a new member of the group, from UChicago, head of collection management and circulation, and so of a high-density storage facility. Dematic ASRS is onsite and connected to the main library. 
• Erin - at Duke we have items from special collections that are managed in AEON. But AEON talks to CaiaSoft, so it isn't a remote storage provider.
• David - new remote storage probably will be a separate physical location, but unnecessarily we will use Dematic for that, it might be CaiaSoft.
• Patty - Libraries in consortia which stay in one tenant, but use different remote storage provider - that's definitely a use case.   
• Tod - UChicago and Northwestern decided to use a shared storage facility.
• Patty - 5Colleges have two remote storage systems. One storage in a bunker and one they've just built. Remote storage systems aren't automated, just shelving style.
• All agreed that it will be good to have somebody from 5Colleges to join the group
• Jacquie - we add item records in Caiasoft as the first style. The pack comes back to Aleph now and says to either update the holdings on the remote storage holding record or if one doesn't exist to create that remote storage holding the record and move the items to it. Right now, I don't need to mark anything as remote, I just want the holding location and the locations of the associate item to change. 
• Erin - marking locations as remote would probably be at the shelving location level, rather than library location level to drive all this staff.
• David - UChicago needs to re-visit this question of item status because for Dematic it's relatively important. Otherwise, requests can get stuck. Basically, the item gets checked-in and it's available doesn't mean it's been stored in Dematic, so if you send a request to the Dematic system because the item is available is opposed to what we have (which is a unique item status), Dematic will return and say "I can't fulfil this request, it's done" and it will kill the request without feedback or anything else because somebody requested it and we didn't store the item the second it was checked in - that's a problem that needs to be solved.
• Mary - when we had that problem during our re-designs we asked to add an expected store, so that patron could still make their request and an item even though it hadn't been put away in the system as soon as it arrives at the work station and we try to put it away it would come up and say "hey, there is an order on this, do you want to process it?" and it comes right back out and doesn't even go in.
• Jacquie - I don't think that in CaiaSoft our items are available immediately after they are re-shelved through CaiaSoft version of circulation.  
• Erin - items can be requested while they are in transit or if there is a hold on it when it gets to circ desk it fills the hold and sends it back. People can put a hold on it when it's already checked out.
• Mary and David - we need/rely on accession being on-demand.
• Tod - when it comes to implementation, accession goes into a work queue (just like requests) and Dematic polls the ILS on a schedule about every 2 minutes, so the effect is "on-demand".  We can decide to change that like pollen once an hour, pollen once a day. The advantages, aside from a user doesn't have to wait for all the work to be done before they can move on, you also get the dial that you can control.
• David - remote storage accession every hour/day etc should include minutes.
• Mary - schedule like that would work.
• Jacquie - I think accession is scheduled, but not so frequently. Erin - I was pretty sure that accessions happen nightly. Jacquie - I think that they accession all day, and nightly we get exception reports. Erin - our discovery layer updates every half hour, so we'd like having lesser than an hour to put an item into the system.
• Jacquie - we normally don't have the holding changed, we create a new holding for the remote storage and move whatever items need to go to that storage and then delete the old one.
• David - if you add a new item record to a holding, that already exists and is already in remote storage then it needs to push that new item into the remote storage system.
• Jacquie - we don't add items to remote storage holding locations ever. If we add a new holding it's usually in one of the libraries, not the remote storage. We send the items out to remote storage location, they accession them in and then send information back to the ILS.  
• Tod - every save of holding or item level with remote location sends that information to the accession queue. It not only adds the metadata to the remote system, it also updates it (changing the title or anything else, which is propagated). 
• Mary - for us the storage location is set in our item record, not in our holding record, so it should be an "either...or" - for those who do use the holding location and for those who don't.
• David - if item is rejected the number of times beyond X times, there should be some kind of error log or something that let people know that the error happened.
• Jacquie - it's always permanent location, that needs to be changed for holding and item.
• David - I'd be hesitant to require staff, who are working with inventory, to make a change and do a separate action for accession. That will result in an error.  
• Mary - not having to push an extra button would be helpful.
• Tod - this goes in an accession workflow whenever such a record with remote location is saved. That does let us get the updated metadata into the storage system. If there is no metadata change, it's a static update. 
• Mary - changing one remote location to another through the update would be fine.
• David - those saving should happen even if you update the instance level because some of the metadata reside on the instance level.
• Tod - barcode is a unique key in the remote storage database. David - I think it's correct, that changing barcode in ILS would create a new item record in remote storage.  

Artefacts

...