How to avoid losing data when changing locations.
Short answer: never change a permanent location from the Physical Item Editor, Scan In Items, or the Change Physical Items job. Because the user roles that enable some of these features cover just about anyone with an Alma login, this is more a dire warning than a how-to article.
When an item’s location is changed from within the Physical Item Editor, Scan In Items, or the Change Physical Items job, Alma deletes the old holdings record and creates a new (identical) one in the new location. While this usually preserves the holdings data, it erases all previous versions, making it impossible to investigate problems that were introduced before the location change. The version history is a valuable tool for catalog maintenance tasks.
Worse, if the base call number and copy ID are the same as a holdings record at the destination location, Alma will add the item to the existing holdings record instead of creating a second one. In most cases, this will occur even if one of the holdings has a (different) call number prefix. Even worse, all of the information from the old holdings record is lost: summary holdings fields, notes, method of acquisition (in the 008/07), call number prefix, everything.
In order to retain this data, it is recommended that all changes to permanent location be done from the holdings record via the MD Editor. For batch location changes, the Change Holdings Information job and some normalization rules can be used (when approached with caution).
This is not a problem when using these features to move an item to a temporary location, as that data is stored in the item record and does not modify the holdings record.
Scenario: The library has two holdings locations for PCs for dummies, a four-volume set. A complete set is located at Main (library) Repo (location), while a copy of volume 2 is located at the Science Library.
The Science Library volume is part of the Homer J. Simpson Collection, a generous gift from a wealthy donor. Because of its importance, the Simpson Collection has restrictions detailed in the action note field 583, as well as tags related to its status as a gift (541 field, 008/07 field). All items in this collection also have the call number prefix designation “Simpson Coll” to help them stand out on the shelf.
The 4-volume set at Main Repo was a normal acquisition, with no special notes or restrictions.
To cover the more serious case first, we want to move the volume at the Science Library to the Main Repo location with the other items.
Here's the holdings record for the gift item at SCIENCE:
In the above record, note the following:
008/07 = g (method of acquisition is “gift”)
541 Note (immediate source of acquisition)
583 Action note warning about withdrawals
852 Call number prefix
866 Summary holdings (the Simpson collection only has v. 2 of this set)
The destination location already has a holdings record with the same call number (852 $h, $i and $t) but without the $k prefix:
Using the drop-down menus in the Physical Item Editor to change the location:
Upon saving the item, the original holdings record is deleted, and the item is added to the existing holdings record at the destination location:
The history tab for the item that was moved shows the location change:
...but does NOT show any holdings changes (because it only shows holdings changes related to the current holdings record):
All of the unique data from the original holdings record has been deleted. Later, if someone discovered what happened, we could use Manage Deleted Repository to restore these individually, then attempt to link the items back to the original holdings record. Even if we’re lucky enough to catch the problem in time, it’s a very time-intensive recovery process.
Next, using Scan In Items, these location changes can be performed as fast as anyone with a circulation desk user role can scan:
Again, the location is changed and former holdings record is deleted, adding the item to the existing holdings record without any of the critical notes and other fields:
The Change Physical Items job can do this even faster:
In this case, Alma behaves a little differently. The 852 $k (call number prefix) stopped this job from merging the holdings, creating a second holdings record at that location:
But if the same record with all of the gift, action and summary notes but without a $k is run through the Change Physical Items job, it adds the item to the existing holding as usual, once again deleting all other data that existed in the holdings record.
Again, these can be restored one at a time in Manage Deleted Repository (this time searching by the Job ID, if you know it):
A less problematic situation occurs when changing an item’s permanent location where a holdings record does not exist at the destination. When this happens, the version history (access via View Versions in the MD Editor) is erased.
Here’s the version history for our Homer J. Simpson gift. Before it gets moved you can view and restore any previous iteration of the holdings record:
After the item is transferred to another location using the item record (or Scan In Items or the Change Physical Items job), the history is erased:
While the previous location can be found in the item record’s History tab, there is no way to see other historical changes to the holdings record. For example: a cataloger erased the donor information or made extensive changes to the summary holdings fields by mistake. In this situation, the deleted original record is NOT available to restore in Manage Deleted Repository. The data is permanently lost.
Recommended best practice for location changes.
The safest way to process a location change is by editing the holdings record in the MD Editor. Not only does this retain all the data and version history in the holdings record, the validation process will alert you to a call number conflict when saving. If you require two distinct holdings at this new location (for example, to distinguish between different gifts or other methods of acquisition), you can bypass the call number conflict by adding a copy number in the 852 $t. [Note: Ex Libris has advised against using multiple holdings records in a single location.]
To manage a bulk location transfer, the Change Holding Information job can be used to execute normalization rules on a Physical Items or Physical Titles set. You will want to run some analyses on your set first to pull out any records where a holdings record already exists at the destination location. Those will be run through a different set of normalization rules to add the necessary copy ID subfield.
Sample normalization rules for changing locations. This assumes you are working with a Physical Items set that has been filtered to the exact holdings you wish to change.
rule “location change to Main Stacks”
replaceContents “852.b.*” with “MAIN”
replaceContents “852.c.*” with “Stacks”