Request was completed as indicated.
If there additional ideas you are welcome to post them separately

New with Alma December 2018 release :-)
- Alternative call number (and type)
- Temporary call number (and type)
Also needed:
- Description
- Inventory number
- etc.

Another use case pertains to migrated item records. We migrated from Millennium, where we had bib records, item records, and for serials, check-in records--no holdings records. If a call number between two item records or between item and check-in records varied in any way--including different spacing or the presence/absence of 090 $b (equivalent to 852 $i)--alternative call number data was inserted into Alma item records. We're in the middle of a project to confirm call numbers on materials, and found that at least two-thirds of them call for merely deleting the Alt Call Number field and Alt Call Number Location from item records. We're stuck doing this process today item record by item record; gathering an item record set and deleting the fields via a job would make things much simpler.

We have serials/sets that that had two call numbers in the same location in our legacy system; we added alternative call numbers during migration so that we would know which holding the items belonged on. We moved the items to the correct holding, but if there were a lot of items, we didn’t take the time to remove the alternative call number. We want to be able to clean these fields up!

As others have noted, we also need to be able to batch update the Alternative Call Number Type field, so that we can also change that to blank if there is no alternative call number. We have 73,000 items with LC in the Alternative Call # Type field, but nothing in the Alternative Call number. (It is populated when new items are created through an Acq process).

Thanks for helping us gain much needed functionality.

I second the suggestion for updating from a spreadsheet. Being able to have a spreadsheet with a column of identifiers (MMS id, Holding id, Item id), a corresponding column of new values, and a job to read that spreadsheet and update the records with those new values would be enormously useful. We have call numbers, enumeration and chronology fields, etc. that would all be relatively easy to tidy up using such a method.

We would like to use this functionality to update serial items with the SuDoc number. We have hundreds of items attached to some US Government Document serials that that have been classed LC in our main collections. Right now the SuDoc indexing is lost. We'd like to make the SuDocs accessible, but it isn't cost effective to do this retrospectively one by one.

I would also like to make the case for alternatively providing functionality that would allow the update of item records by spread sheet upload. We could really use that for movind our migrated free text description in items to the proper enumeration and chronology fields. It's relatively easy to write formulas in Excel to convert the data.

I’ve entered that as an idea on the exchange as well. Find it as:
Enable bulk updating of items from spreadsheet based on barcode
https://ideas.exlibrisgroup.com/forums/308173-alma/suggestions/34562269-enable-bulk-updating-of-items-from-spreadsheet-bas

Our specific use case, which prompted me to add the Idea, was that we are receiving call numbers in this field from a vendor as part of EDI order responses (fulfilment) and we don't want them there but there is no way to remove them all in bulk.

An example:
In our Law Library there are several "Reference Library" collections which should be displayed in Primo with the name of the director of the institute. Instead of defining different locations (which would be displayed in Primo as separate Holdings!) we have defined one location (called "Reference Library") and the name of the director of the institute is stored in the field "Alternative Call Number".
In case of a change, we have to update the field "Alternative Call Number" with the name of the new director of the institute, because usally she/he takes over all or most of the books. In each of these "Reference Library" collections there are a few hundred book, but sometimes more than 1000.

What is the use case in which you need to update the alternative call number in bulk? Our assumption is that you update all the items with the same call number.

How many items will you usually update in this use case?

It would be extremely beneficial to be able to update the alt call number in this way. I strongly support this suggestion.

Why treat alternative call numbers different than other call numbers? Let them also be updated in batch in a job! This slicing and dicing of data elements (you can update only some in batch, but not others; you can search for some, but not others) is crazy. If it is data, at some point you will need to update it, delete it, search it, display it, whatever. If the data element is important enough to include in the database, it is important enough to be able to manipulate it in all the ways possible, surely? I have never understood why Alma is like this.

I strongly approve this suggestion.
The lack of this functionality is very prejudicial. Several of our colleagues would wish update the alternativ call number of their items (and specially of their serial issues) : they're still dependent on us and more exactly on updates by API that we execute.

This is very important. My problem ist to change Alternative Call Numbers of many Items that will be transfered for one Library to another which has a different Call Number System.

Strong agree. And if we have "Alternative Call Number", please also add "Alternative Call Number Type".

We have received following reply to our Salesforce Case regarding additional fields for the "Change physical items" job:
# "Alternative Call Number" and "Alternative Call Number Type"(!)
--> "the enhancement of the "Change physical items" job is on the roadmap but without schedule so far."
# "Inventory number"
--> "The existing enhancement for changing the "Change physical items" job includes only the temporary fields where "Inventory number" is unfortunately not included."
# "Description" field is also missing and several other fields. Ex Libris should include *all* item fields.
Yes, there is an API ("Update item information"), but changing item fields using an Alma job is the prefered procedure ;-)

This is very needed!

Very important!!

We also have many call numbers that migrated into this field we would like to delete in bulk.

We have many call numbers that erroneously migrated to this field that we'd like to delete in bulk.