Skip to main content
ExLibris

Knowledge Assistant

BETA
 
  • Subscribe by RSS
  • Back
    Voyager

     

    Ex Libris Knowledge Center
    1. Search site
      Go back to previous article
      1. Sign in
        • Sign in
        • Forgot password
    1. Home
    2. Voyager
    3. Knowledge Articles
    4. Message that call number is being saved as type "Other" in Voyager cataloging

    Message that call number is being saved as type "Other" in Voyager cataloging

    1. Last updated
    2. Save as PDF
    3. Share
      1. Share
      2. Tweet
      3. Share
    1. Question
    2. Answer
    • 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.

     

    call number indexing error.jpg

     

    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
    View article in the Exlibris Knowledge Center
    1. Back to top
      • Message "Upload of FILENAME to /incoming/ failed. Error writing to file." when upload file via WebAdmin
      • MFHD data displayed in Older Issues?
    • Was this article helpful?

    Recommended articles

    1. Article type
      Topic
      Language
      English
      Product
      Voyager
    2. Tags
      This page has no tags.
    1. © Copyright 2025 Ex Libris Knowledge Center
    2. Powered by CXone Expert ®
    • Term of Use
    • Privacy Policy
    • Contact Us
    2025 Ex Libris. All rights reserved