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 without first confirming that either 1.) there are no existing holdings records at the destination location for that bibliographic record, or 2.) your holdings records do not contain important data (see below). 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.
[UPDATE June 2021: recent Alma monthly releases have included some changes to record behavior. This article has been updated after testing these changes.]
When an item’s location is changed from within the Physical Item Editor, Scan In Items, or the Change Physical Items job AND the destination location does not have an existing holdings record for attached bibiliographic record, Alma retains the existing holdings record and all of its field data. Depending on the process used, the View Versions (holdings record in the MD Editor) and History tab (in the Physical Item Editor) may not contain previous versions of the holdings record or reflect the previous locations used. Also, during testing, the History tabs of test records occasionally displayed change information that related to a different item/holding under the same bibliographic record.
If the same processes are used for items moving to a location with an existing holdings record (for example, when relocating a second copy or moving issues of a serial with older items stored off-site), the items are added to the destination holdings record if the base call number and copy ID are the same as a holdings record at the destination location. In most cases (see table below), this will occur even if one of the holdings has a (different) call number prefix in the 852 $k. 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.
|Scan In Items||Physical Item Editor||Change Physical Items job|
|No holdings at destination||Retains original holdings record fields||Same as Scan In Items||Same as Scan In Items|
|Holdings exist at destination||Item(s) moved under destination holdings record; record does NOT retain unique fields from previous location's holdings record UNLESS 852 $t is present||Same as Scan In Items||Same as Scan In Items, but also creates second holdings record when 852 $k is present|
|Record history data||Location change shown as "item changes" or "holdings changes" in Item Editor history, depending on whether user and item are in the same Alma library; no new holdings record version appears in MDE if starting library is outside of user's department at time of scanning||Location change shown as "holdings change" in Phys Item Editor History tab and a "there have been Holdings changes in the past 6 months" indicator appears; previous holdings record available in View Versions in MDE (same fields, but with the old library/location subfields)||Same as Physical Item Editor|
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:
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):
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”