Ability to delete items by scanning-in
At present items can be withdrawn/deleted in two ways:
1. Manually, an item at a time (or multiple items only if in same holding)
2. In bulk, from a set created either directly from search results or from a spreadsheet.
There is no way to rapidly delete items-in-hand.
A feature in Alma to quickly delete items-in-hand, in quick succession, with the same safeguards as when using existing deletion methods.
The attached document gives more details and a mock-up of such a feature - it would be a big bonus to those of us with a lot of weeding to do!
Cathy Chapman commented
Thanks Josh-- when I searched for this before posting, I totally forgot to use the search term "delete." Whoops. Glad to hear this is already under review!
Josh Hutchinson commented
I believe this is the same as "Ability to delete items by scanning-in" https://ideas.exlibrisgroup.com/forums/308173-alma/suggestions/15745660-ability-to-delete-items-by-scanning-in
which is under review.
Linda Crook commented
This process would also need to somehow generate a list of OCLC numbers so that holdings can be removed, for libraries that do not have their holdings synchronized.
Cathy Chapman commented
It would be nice to add the ability to simply scan in the barcodes of items that are to be withdrawn, in addition to the current , more time-intensive methods-- creating set of items then running a job, or withdrawing items title by title on the Items List page. This functionality should be available for both acquisitions and circulation.
David Morgan commented
As an addendum, it would be useful if if the safeguards could be expanded by warning if an item is a last copy, and by allowing checking against sets of records.
For example, if we could create sets of items that are on reading lists, of special research interest, are held in fewer than x institutions, are agreed to be retained, etc., then set these as 'watch lists' that Alma would check against when deleting an item, we would be able to withdraw stock with greater confidence, and greater efficiency, whilst ensuring that we are acting responsibly.
This would be terrific, with, as you say, the necessary safe-guards.
Another approach for safeguarding against accidental deletion would be to add a process type of "withdrawn."
Items for withdrawal/deletion could be moved into this process either manually, by scan-in, or in batch, rather than being instantly deleted. Items with the "Withdrawn" process type could then either be suppressed from public display or displayed as "not in place", per local preference and configuration. The appropriate staff (cataloging, collection development, automation) at the library could then run a single batch at calendar intervals to complete the deletion (i.e. move the item into lifecycle of inactive, delete empty holdings, delete empty bibs) of all items which have been in the withdrawn status for more than "x" number of days/weeks/months.
In this way, the very repetitive parts of the physical removal of the items is separated from the more technical aspect of determining the action to take on the database records and running those jobs.
It also preserves the bib records, by default, for a given (locally-decided) length of time, so that, for example, if among your withdrawals you have an AV item or kit for which your library did original cataloging within Alma, you have time to order and receive a replacement before the bib record is purged from the system and your work is lost. We already avoid this by doing original cataloging in OCLC, but this is not a viable workflow for all.
This is similar to the way withdrawals were handled in my 70+ member mullti-type consortia at a previous job, and it was both efficient and provided good safeguarding of the database. In fact, as a group, the member libraries made a decision to never delete bib records for AV media which was still currently held by any of the libraries, specifically because of the amount of institutional time put into creating and enhancing thorough records with generous access points. When the monthly delete job was run, those media types were run separately and only item and holding records were deleted. Title reports were also generated 2 weeks (I think, it’s been a few years) beforehand of every item slated for deletion and sent to the head cataloger at each library. This allowed them to review the list, if they felt it was a good use of their time, and take action to “un-withdraw” or otherwise preserve a given item record before the final purge took place. Again, I chose not to review, as the time taken was far greater than the time needed to recatalog the very few items that ever wound up getting deleted in error, but for other libraries, it was an essential part of their procedures.