Message that call number is being saved as type "Other" in Voyager cataloging
- Product: Voyager
- Relevant for Installation Type: Multi-Tenant Direct, Dedicated-Direct, Local, TotalCare
Question
Receive "The Call number in this holding record could not be indexed using the Call Number Type specified." in Voyager cataloging.
Answer
When a MFHD is saved to the database, Voyager performs normalization on the call number. Normalization starts with the 852 field’s first indicator, which tells the system what type of call number is stored in the record. For example, an 852 indicator 1 value of 0 (zero) means the call number uses LC classification, and an 852 indicator 1 value of 8 means the call number uses an “Other” classification scheme.
When the MFHD being saved fails to normalize according to the rules for the call number type, the operator is presented with a message stating that the call number is being saved as an “Other” call number. When this message displays, the MFHD is saved to the database, the CALL_NUMBER_TYPE index in the underlying Voyager tables is set to Other, but the 852 indicator 1 value in the MFHD record is not changed from its original value. Because the MFHD is not edited under these circumstances, looking at the MFHD via the cataloging client at a later time offers no clue that the underlying call number type indexing is different from the 852 first indicator’s value.
Some common scenarios for this kind of failed call number normalization are listed below, in the order most often encountered in testing:
1) The call number is legitimately an “Other” number, but the indicator value is set as though the call number were from a standard classification scheme (e.g., LC or Dewey), often based on defaults set in the cataloger’s client preferences;
2) The call number prefix is incorrectly coded in $h instead of $k, which usually causes normalization to fail;
3) The call number is legitimately an LC, Dewey, or other standard classification number, but it contains typographical errors significant enough to cause normalization to fail.
Records that match the third scenario above may prevent the patron from finding the item on the library shelves, and therefore should be corrected, if possible.
- Article last edited: 03-Aug-2020