Skip to main content
ExLibris
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    Horizon to Alma Migration Guide

    Overview

    Horizon is an integrated library system produced by the Sirsi corporation. This document serves two purposes:
    • A step-by-step guide to filling out the Horizon Migration Form.
    • An explanation of the migration rules for Horizon to Alma that do not require any customer input.
    This document is divided into four areas:
    • Inventory
    • Fulfillment
    • Acquisitions
    • Physical to Electronic
    Each area has the following sections:
    • Questionnaire Tab – Instructions for individual questions asked on the Questionnaire tab of the Migration Form.
    • Individual Tabs – Instructions for how to fill in individual tabs on the migration form.
    • Further Explanation – Explanations of migration processes that need more explanation and/or do not need customer input.
    We recommend that you look at the Questionnaire tab section and the individual tabs in each area to assist in filling in the migration form.
    If you have further questions about any of the data input or about the migration in general, see the more detailed explanations in the Further Explanations sections.

    Related Documentation

    Ex Libris migrates your acquisitions and course data only if this service is purchased by your institution and is stipulated in your contract with Ex Libris.

    Inventory

    Alma uses bibliographic, holding, and item records. Horizon has bibliographic, item, and optional serial records. During Alma migration, MARC holding records are generated from information in the Horizon item record, serial holding record, serial issue record, and optionally from embedded information in the bibliographic record such as a serial holdings statement in an 866 tag.

    Customer Input

    Questionnaire Tab

    Institution Code, Customer Code, Institution Name, Customer Name, Time Zone

    Codes: INST_CODE, CUST_CODE – these are filled in by Ex Libris
    INST_NAME and CUST_NAME: fill these fields in with your institution’s name and your customer name (this is only different from the institution name if you are part of a consortium). These are mandatory and must be filled in.
    Default: N/A
    Time Zone: Select your time zone from the drop-down list. If your time zone is not listed, contact your Ex Libris project manager.

    MARC Organizational Code

    Code: MARC_OC
    Default: None; this is not mandatory
    Options: Enter your MARC Organizational code, which will be used to construct the former system number in Alma. Only one code is allowed.
    Further Information: The migration moves the value in the exported record’s 001 field (Horizon bibliographic system number) to the 035 $a field:
    (MOC)<Horizon record id>-<customer code>
    <(MOC)> is the MARC Organization code specified here. <customer code> is the customer code specified in the CUSTOMER_CODE question above.
    For example: (AbC)u12345-01abc_inst

    List Prefix for bibs from SFX or other management system

    Code: SFX_PREFIX
    Default: ‘(SFX)’
    Options: String. If not indicating a link resolver management system, leave blank.
    Further Information: If your Horizon catalog contains records imported from SFX or another electronic resource management system and you are also migrating bibliographic records directly from SFX or the other management system, this may result in duplicate bibliographic records in Alma. You can enter a prefix here so that the migration programs can identify these bibs and not migrate them to Alma to avoid creating duplicate SFX records in Alma. The migration programs do not make any attempt to physically merge the two records into one.
    The default response to this question is ’(SFX)’, but you can enter any prefix that represents the bibs that you want to exclude from loading into Alma. The migration programs search for the string in the 035 $a field of the MARC record. If you do not want to exclude any such records, leave this field blank.
    If the migration programs identify bib records containing the prefix in the 035 $a and the records in Horizon are connected to a purchase order line and/or physical items, these bib records are still migrated so that the purchase order and/or items can be migrated, but they are automatically suppressed in Alma to avoid end-user discovery duplication.

    Do you use internal system numbers in $w of Linked Entry fields?

    Indicate if you use internal system numbers in fields 76x-78x to link bibliographic records to each other.
    Code: LINKED_ENTRY_W
    Default: No
    Options: If you answered Yes to this question, the internal system numbers in the subfield w of the specified tags are converted from the Horizon system number to the Alma system number.

    Internal record designation for Linked Entry fields $w

    Code: LINKED_ENTRY_PREFIX
    Default: Blank
    Options: If you answered Yes to the previous question and the internal system numbers have a prefix, enter the value to be matched to identify the local system number. If the system numbers in $w do not have a prefix, or if you answered No to the previous question, leave this question blank. Further information on LINKED_ENTRY_W and LINKED_ENTRY_PREFIX: When bibliographic records are related to each other, such as a journal title that is superseded by a second journal title, Horizon may store the information in bibliographic fields 76x-78x. If the number in the $w of the linking tags is the internal Horizon system number, these numbers must be changed to the Alma representation of the system number. If your library does not use the internal system number to link and instead relies on more general identifiers such as the ISBN, ISSN, or shared cataloging DB (OCLC or DLC), these numbers are not modified. In Alma, the system numbers in the $w field (along with $z and $x) are used to link two related bibliographic records together using the related records process. Related records can be found by clicking the More Info link on the Alma Search Results page.

    Indicate which 852 subfields to use to determine unique holdings records

    Code: 852_SUBFIELDS_FOR_HOL
    Default: bc (library and location only, not call number)
    Options: To group all items on a single bibliographic record by location only, select bc here. If you have many items in the same bibliographic record in the same location but different call numbers WITHIN that location and you want each of them to have their own distinct holdings record, select from additional subfields h, i, j, k, m, p and indicate those subfields in the call number data with a semi-colon separator.
    Further Information: See  Bibliographic Records
    Bibliographic records are migrated as is. Each bibliographic record may be modified in the following way during migration:
    • Suppressed bibliographic records are marked as suppressed
    • Australian customers have ALL bibliographic records marked for Libraries of Australia Publish, if relevant.
    • OCLC records (records with an 035 |a with an OCLC-official prefix) are marked for OCLC publish, if relevant.
    • The LDR position 9 (character coding scheme) is set to a, indicating Unicode.

    Limit exported records by location

    Code: LIMIT_BY_LOCATIONS
    Default: No
    Options: If your export contains all of the data from a shared database, and you wish to only migrate a part of that export to Alma, then the migration programs can filter the data according to locations listed on the Location Tab. In this case, the ALMAME_VALUE_NOT_FOUND line on the location tab is not used. Inventory and Acquisitions are filtered by locations on the Location Tab, and Fulfillment is filtered based on campus codes in the Campus Code Tab. Use this option only if agreed upon with your Ex Libris project manager.

    Bib Key Prefix

    Code: BIB_KEY_PREFIX
    Default: empty
    Options: If you are combining data from two or more separate databases into a single combined institution in Alma, then indicate a prefix here that will be used to distinguish the former system numbers in Alma after migration. For example, the different systems likely had completely different bibs for system number 12345 and you want to be able to search for the specific bib from your own institution after go-live. The prefix does not include a hyphen so if you want a hyphen in the number (e.g. PQ-12345), then include it in the string. If you are not merging institutions, leave this question blank.
    See also the similar Fund Prefix in Acquisitions.

    Alma Library Tab

    Use this tab to create a list of Libraries in Alma. At least one library is mandatory.
    Alma Library Code: Maximum 10 characters. Mixed case is valid, but not recommended. Do not use special characters or spaces. Allowed: - and _ (hyphen and underscore). Not allowed: !@#$%^&*()+=/?><.,\|]}[{`~ or the space character.
    Alma Library name: Maximum 255 characters. This is visible to the public.
    Address lines: Alma allows you to specify address, phone, and e-mail information about each library. It is mandatory for a library to have a shipping/billing address in order to place orders in Alma. The migration process sets the designated address provided with all possible types in Alma (shipping, billing, claiming, etc.). At least one address line is mandatory.
    Email: An email address is mandatory. The migration process sets the email address provided with all possible email address types in Alma. Phone: The phone number must contain dashes (nnn-nnn-nnnn). A phone number with no dashes is not accepted by the migration program. Not mandatory.
    Default language: Indicate the language of patrons and/or staff members if it differs for each library. Use two-letter codes as defined in ISO 639-1. Consult the codes at https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes
    Further Explanation: The Horizon location, which is the higher level of location, and is comparable to the Alma library. Use the Alma Libraries tab in the Horizon Migration Form to indicate your list of Alma libraries. The actual mapping from the Horizon location to the Alma library is done in conjunction with the Horizon collection (lower level of location) in the Alma Location tab.
    If you use an error library (for example “EMPTY”) in the ALMAME_VALUE_NOT_FOUND line of the Location Mapping tab, be sure to list that library here on the Library Tab. It is not mandatory to use an error library; you may also choose to use one of your regular libraries plus a lower-level error location for the items that encounter errors during the mapping process.

    Alma Location Tab

    Use this tab to map your Horizon locations and collections to libraries and locations in Alma. Filling in this tab is mandatory.
    Include ALL locations of ALL types, including electronic types that may ultimately be deleted in Alma. They still need to be provided in the location tab mapping.
    Horizon Location: Value from the Location field in the item extract from Horizon.
    Horizon Collection: Value from the Collection field in the item extract from Horizon.
    Alma Library Code: The library that contains this library/location combination in Alma. This code must be present on the Alma Library Tab, column A. The match is case-sensitive.
    Alma Location Code: The new location code for this library/location combination in Alma. It can be a maximum of 10 characters. You can use the same location codes in Alma that you used in Horizon, but this is not required. You may also use this form to collapse locations if desired, for example refa and refb in Horizon both map to ref in Alma. Mixed case is valid, but not recommended. Do not use special characters or spaces. Allowed: - and _ (hyphen and underscore). Not allowed: !@#$%^&*()+=/?><.,\|]}[{`~ or the space character.
    Call Number Type: List the call number type for any newly created holdings records, based on the values for the 852 first indicators. (http://www.loc.gov/marc/holdings/hd852.html). If we cannot determine the call number type from the item or holdings record itself, we use this as a default for all items in the location.
    Alma Location Name: A description for this location as seen/used by library staff members. The same location name cannot be used for different locations in the same library, but the same location name can be used for different locations in different libraries. See the examples in the Further Information section below for what is acceptable and not acceptable. Maximum 255 characters.
    Alma External Location Name: A description for this location as seen/used by the public. The same name can be used for as many different locations as desired. For example, the location names may be Archives A and Archives B, but the external location names can both be Archives. Maximum 255 characters.
    Electronic Location? (Yes or No): Used by the P2E migration process to determine if a holding/item/order should be converted to electronic. See Physical to Electronic (P2E) Processing for more information.
    Suppress from Externalization? (Yes or No): Indicate if the location should be suppressed from being visible to the public. The items are not marked as suppressed, but no holdings or items with this location code are exported to Primo.
    Further Information: Do not leave the Alma location and library code fields blank. If you want to stop using a location code after migration, map the Horizon code to an easily identifiable code such as XXX or unused just in case any stray items are still in your Horizon database.

    ALMAME_VALUE_NOT_FOUND

    The ALMAME_VALUE_NOT_FOUND line must be included at the top of the list of locations, in case any location codes were overlooked when completing this map. For example, you may think that you do not have any items left in a certain collection, so you leave it off the location map. However, there may be one or two items left or a stray holdings record, etc.
    By default, the location code for the ALMAME_VALUE_NOT_FOUND line is UNASSIGNED, which is the default catch-all in Alma in production mode. Ex Libris recommends that you select your primary/largest library as the library code for the line, for example MAIN as in the example line below. In this case, the items inherit the configurations for the MAIN library.
     
    Horizon Location Code Horizon Collection Code Alma Library Code Alma Location Code Alma Location Desc Alma External Loc Desc Suppress from Externalization
    ALMAME_VALUE_NOT_FOUND ALMAME_VALUE_NOT_FOUND MAIN UNASSIGNED Problem location from Migration Problem: See Library Staff Yes
    Post-migration, search for items in the UNASSIGNED location and correct the records appropriately.

    Alma Location Name and Alma External Location Name

    The Alma Location Name column contains the names of the location codes that are displayed in the staff interface. The names cannot be repeated in the Location Name column when the location codes both belong to the same library, but you can use the same name for two different locations, if these locations belong to different libraries. The Alma External Location Name column contains the names of the location codes that are displayed to library patrons. These names can be repeated within the column without regard for libraries. For example:
    The following is acceptable:
     
    Library Alma Location Code Alma Location Name Alma External Location Name
    Library A stacks Main Stacks Main Stacks
    Library B stacks Main Stacks Main Stacks
    Library A archa Archives A Archives
    Library B archa Archives B Archives
    Library A archstk Archives Stacks Archives
    Library A archref Archives Reference Archives
    Library A stacks Main Stacks Main Stacks
     
    Library Alma Location Code Alma Location Name Alma External Location Name
    Library A archstk Archives Archives
    Library A archref Archives Archives
    The Alma library and Alma location are put in the following places in the migrated or newly created MARC holdings record:
    • The Alma library is placed in the 852‡b field.
    • The Alma location is placed in the 852‡c field.

    Collapsing Locations

    Collapsing location codes: This mapping table can be used to collapse location codes – that is, two or more location codes in Horizon can map to a single location code in Alma. The Alma location and library code fields may not be empty. If you want to stop using a location code on migration, map the Horizon code to an easily identifiable code such as XXX if any stray items are still in your Horizon database.
    If you collapse location codes, you may have lines in the table such as the following:
     
    Horizon Location Code Horizon Collection Code Alma Library Code Alma Location Code Alma Location Desc Alma External Loc Desc Suppress from Externalization
    MAIN reserves MAIN RESERVES Reserves Reserve No
    MAIN reservesElec MAIN RESERVES Reserves ReserveElec Yes
    MAIN reservesShort MAIN RESERVES Reserves Reserve No
    MAIN reservesPerm MAIN RESERVES Reserves Reserve No
    The two values in bold italic above (ReserveElec as the External Location name, and Yes for Electronic location) are not used in Alma. Since the locations are being collapsed, the first line for the RESERVES Alma location is used, and all subsequent lines below it use the values from the first line.

    Shelving Scheme Tab

    Alma will generate a first indicator for the 852 based on the Shelving Scheme tab.
    Horizon Call Number Type: The values in the Call Number Type field as delivered in the extract from Horizon.
    852 1st Indicator: List the value that should be used in the 852 first indicator field when generating a holdings record from the item. For a list of possible values and their description, see http://www.loc.gov/marc/holdings/hd852.html. Note that 7 is not supported on migration. Mandatory. Description: A description or note for this shelving scheme value, if you need to make a note while deciding the first indicator value. This column is not used in migration.
    Further Information: Do not use an ALMAME_VAL_NOT_FOUND line here, because if an item has a shelving scheme that is not listed or does not have a shelving scheme value, the shelving scheme is taken from the Call Number Type column on the Location tab of the Horizon Migration Form.

    Item Type Tab

    Use this tab to migrate the Horizon Item Type to the Alma Item Policy. This tab is optional. The item type in Alma is not required, so if you leave this tab blank, no item policies in Alma are created.
    Horizon Item Type: The value in the item type field of the Horizon item. The item type is a factor that may be used to differentiate between items when determining how items circulate.
    Horizon Description: The description of the Horizon item type, for information only. This column is not used during the mapping process.
    Alma itemPolicy: The Alma value for the item type. This sheet can be used to collapse item types if desired.
    Alma itemPolicy Description: This description is loaded into Alma as the display text for the item types. These values can be changed after migration. Maximum 255 characters.
    You can optionally include an ALMAME_VAL_NOT_FOUND line at the top of the map. If this line is included, any value not found or any blank value is assigned the value in the ALMAME_VAL_NOT_FOUND line. If the ALMAME_VAL_NOT_FOUND line is not included, any value not found, including blanks, is left as blank in Alma.

    Item Base Status Tab

    Use this tab to map your item status in Horizon to an item status in Alma.
    Horizon status: The item status in Horizon. List all statuses in this tab.
    Description: A short description of the status in Horizon, if desired, for note purposes while filling out this form. This column is not used for migration.
    Base Status: In Alma, the base status indicates whether or not the item is on the shelf. Indicate whether or not an item with this status is on the shelf. For example, NewBooks is on the shelf (1), but Withdrawn is not (0).
    Further Information: Alma has a process type that indicates the status of an item depending on the Alma workflow (item is on loan, item is sent to the bindery, etc.), but the process type is dependent on the corresponding Alma workflow. For migration, all item statuses that are indicated as not on the shelf (0) from Horizon are given the process type of TECHNICAL and the item status from Horizon (the Description column) is written to an Alma item note. This is placed in internal note 1.
    Include any status that may indicate no status, for example Available, but leave column B blank. This migrates the item to Alma with no status at all, which is how Alma indicates that an item has no status. If any status is in your data but is NOT included in column A, it is given a note of Unknown status.
    If you want the temporary locations (such as new book shelf or reserve) to be changed to actual temporary locations in Alma after migration, you can search for values in Internal Note 1 and then move the items to the appropriate location. Alternately, the search may be used to move an item to a specific department, or the list can be used as a configurable criterion for suppressing items from display in the GetIt services screens in discovery systems. See Appendix A – Post-Migration Process Statuses for more information.

    Further Explanation - Inventory

    Bibliographic Records

    Bibliographic records are migrated as is. Each bibliographic record may be modified in the following way during migration:
    • Suppressed bibliographic records are marked as suppressed
    • Australian customers have ALL bibliographic records marked for Libraries of Australia Publish, if relevant.
    • OCLC records (records with an 035 |a with an OCLC-official prefix) are marked for OCLC publish, if relevant.
    • The LDR position 9 (character coding scheme) is set to a, indicating Unicode.

    Determining Groups of Holding Records

    The permanent location and call number in Alma is only stored in the holding record. All items attached to the holding record have the same permanent location and call number. On migration, the call numbers for any new holding record created are generated from the first item found in the group of equivalent items. By default, a group of equivalent items is determined by the location of each item attached to the same bibliographic record. For example, if a bibliographic record has five items:
    • Item 1, 2 in Location A
    • Item 3, 4 in Location B
    • Item 5 in Location C
    The migration program generates three different MARC holdings records, one for each location A, B, or C. The items for each location are then attached to the newly created holdings record. If there are any call numbers that differ from the holdings record’s call number, the differing call number is stored in the item’s Alternative Call Number field.

    Changing the Holdings Record Grouping

    You can decide which 852 subfields are used to determine what makes items belong to the same group. The 852 subfields as mapped from Horizon are: $b Location $c Collection $h Call Number. By default, the migration programs compare $b and $c, but you may decide to change this based on items in your collection.
    When the holdings record group is based only on $b (library) and $c (location), some item call number information is not reflected in the holdings record call number if the call numbers differ from each other in the same library/location. However, the differing call number is stored in the item’s Alternative Call Number field, so the call number is not permanently lost.
    For example, if there are four items on the same bibliographic record with the following call numbers, all in location main:
    item 1 $b main $c stacks $h PN 567 $i .M4
    item 2 $b main $c stacks $h PN 567 $i .M457
    item 3 $b main $c stacks $h PN 567 $i .M457
    item 4 $b bio $c flr1 $h PN 567 $i .M457
    When only $b and $c are used to determine a holdings record group, two holdings records for the above items are created:
    Holdings record $b main $c stacks $h PN 567 $i .M4
    item 1
    item 2 (with PN 567 .M457 stored in AltCallNo)
    item 3 (with PN 567 .M457 stored in AltCallNo)
    Holdings record $b bio $c flr1 $h PN 567 $i .M457
    item 4
    When the holdings record group is based on more subfields, for example $b $c $h $i, three holdings records are created:
    Holdings record $b main $c stacks $h PN 567 $i .M4
    item 1
    Holdings record $b main $c stacks $h PN 567 $i .M457
    item 2
    item 3
    Holdings record $b bio $c flr1 $h PN 567 $i .M457
    item 4
    Decide which 852 subfields will be used to determine holdings record groups by answering the question in the Questionnaire tab of the Horizon Migration Form, “Indicate which 852 subfields to use to determine unique holdings records”.

    Item Barcodes

    While Horizon may allow item barcodes to be duplicated, Alma does not. The item barcode must be unique in Alma – though it may be left empty.
    The item barcode is migrated according to the following rules:
    • If the barcode is empty, leave it as is.
    • If the barcode exists but is not unique:
    • First item barcode encountered – migrate as is.
    • Second and subsequent item barcodes encountered – migrate as -.

    Material Type

    The material type in Alma is a description of the type of material the item is such as book, map, issue, DVD, compact disc, etc. It is controlled by a fixed list of physical resource material types in Alma. Each item in Alma must have a material type specified. The migration automatically assigns a material type based on bibliographic record LDR and 007 fields. There is no customer input required for this part of the migration as the Alma types are fixed. The following chart describes the material types. It is for informational purposes only and cannot be modified.
     
    LDR posn 06 LDR posn 07 007 posn 00 Alma Material Type Code Alma Material Type Name
          MAGNETIC Magnetic Media
    A a c d i m h MICROFORM Microform
    a c d m s c ELEC Electronic Resource
    a a c d m   BOOK Book
    a c d e f g b i s   ISSUE Journal issue
    c d     SCORE Musical Score
    e f     MAP Map
    j i     RECORD Record LP,78,or 45
    M     ELEC Electronic Resource
    T     MANUSCRIPT Manuscript
    O     KIT Kit
    K     GRAPHIC Graphic
    p g r     OTHER Other
    <default> <default>   BOOK Book

    Fulfillment/Patrons

    Customer Input

    Questionnaire Tab

    Complete the following in the Questionnaire tab:

    Enter a two-letter code for the default conversational language for your users

    Code: PATRON_LANG
    Default: en
    Options: Use the two-letter codes as defined in ISO 639-1. Consult the codes from https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes.

    Which identifier should be used as the patron's Primary Identifier?

    Code: PATRON_PRIMARYID
    Default: UNIV ID
    Options: Using the Horizon Field Mapping Form, map the identifiers exported from Horizon to the following list: UNIV ID, BARCODE, ADDL ID 1, ADDL ID 2, ADDL ID 3. Then, select the identifier to be used as primary for all patrons.
    Further information: The identifier selected here is used as the match point for externally managed patron records to match with an external authentication system such as LDAP or Shibboleth. There is no password for external users. Additionally, this identifier is the primary identifier for internally managed patrons.
    See also: Identification Numbers, Internal? Question on the User Group tab.

    How should we construct a password for internally managed patrons?

    Code: PATRON_PASSWORD
    Default: LASTNAME
    Options: The option that is selected is used by all internal patrons as their initial password. When logging in for the first time, internal patrons use the identifier you selected in the previous question as the primary identifier. In this question you select the default password. The options are:
    • LASTNAME: The patron’s last name is placed in the password field.
    • PRIMARYID: The identifier selected as the primary ID is placed in the password field.
    • CONSTANT: You can enter a constant string in the cell.
    • FROM_EXPORT: Use the value from the PASSWORD field in the patron export. If this option is selected, the password must be sent unencrypted.
    Further Information: Externally managed patrons do not use an Alma password for authentication. Since they are externally managed, they use an external authentication system such as LDAP or Shibboleth.

    If patron password selection = CONSTANT, enter the string here

    Code: PASSWORD_CONSTANT
    Default: None
    Options: If you select CONSTANT for the previous question, provide the string here. By selecting CONSTANT and assigning a string, you require all internal patrons to initially log on with the password/string.
    Further Information: It is likely that the internally managed users use the Alma patron database for authentication. Therefore, a default password must be assigned for these users.

    Currency for patron fines

    Code: CURRENCY
    Default: USD
    Options: Use the three-letter code (for example, USD, EUR, GBP) for the currency used for patron fines. For a list of valid codes, consult http://en.wikipedia.org/wiki/ISO_4217.

    User Group Tab

    The user group is used to distinguish groups of patrons from each other in determining different levels of circulation policies. Typical user groups are faculty, staff, and undergrad.
    If patrons are being migrated, then this mapping table is mandatory.
    Horizon patron institute: The Horizon patron institute code, found in the patron institute field of the patron extract.
    Horizon Description: A description of the Horizon patron institute, for informational purposes only. This column is not used in the mapping to Alma user group.
    Alma User Group Code: The mapped group code in Alma. You can use the same codes that you used in Horizon, or you can use different codes. You can also collapse groups if desired, for example, having Freshman and Sophomore from Horizon both map to Undergrad in Alma. Do not use special characters, for example, slashes (/) or spaces in the code.
    Alma User Group Description: The description of the Alma User Group. This description is loaded into the Alma code table as the description displayed in the user interface. This description can be changed easily after migration.
    Internal? Y or N: Alma categorizes users as either external or internal. External patrons are managed and authenticated by an external system, such as through a regular load from the bursar’s office/campus student information system. Internal patrons are created and managed internally. Examples of internal patrons would be minority cases where community borrowers or alumni use library services. If you select Yes, all of the patrons in the Alma userGroup are categorized as internal. If you select No, all of the patrons in the Alma userGroup are categorized as external.
    External users are fully external (except patron notes), including all user identifiers, authentication, and address information.
    Notes/Comments: Add any notes or comments for the Horizon User Profile. This column is not used during migration.
    Further information: See also the following questions in the Questionnaire tab, regarding internal and external users:
    • Which identifier should be used as the patron's Primary Identifier?
    • How should we construct a password for internally managed patrons?
    See also the sections on internal/external patrons and passwords for internal users.

    User Language Tab

    Horizon stores a free-text language code in the language field in the patron record. Provide the list of available language codes from Horizon and their description, along with the language code as it should be in Alma.
    This mapping table is not mandatory. If no languages are listed here, the default language from the Questionnaire tab (PATRON_LANG) will be used.
    Horizon language: The Horizon language code as found in the language field in the patron extract.
    Horizon language description: A description of the Horizon language code, for informational purposes only. This column is not used in the mapping.
    Alma language code: The language code as desired in Alma. The Alma language is two-letter ISO 639-1 format: see https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes.
    Comment: Use this field to add any comments about the language codes.

    Campus Code Tab

    This mapping is not mandatory if you do not maintain separate patron campuses.
    Horizon patron location: The value of the patron location as found in the location field of the patron extract.
    Horizon Location Description: A description of the location field, for informational purposes only. This column is not used in the mapping.
    Alma Campus Code: The Alma campusCode desired. You may map the codes one-to-one, or you may use this map to collapse codes if desired.
    Alma Campus Code Description: A description of the Alma campusCode, for informational purposes only. This field is not loaded into Alma.
    Further Information: The Alma User Campus field is used to determine a patron’s affiliation for ILL or cross-campus borrowing. If your library maintains the location field in Horizon for a similar purpose, map the location value to the Alma Campus Code value with this map.

    User Block Tab

    Horizon stores patron block information in the burb file, which also contains fines and fees. If an entry in the burb file has an amount <> 0, then we create a fine from the entry.
    When the entry amount = 0, it is either a block or a note. If a block code from the burb file is listed on this tab, then a block is placed on the patron’s record in Alma. If the entry amount = 0 and the code is NOT listed on this block tab, then we assume the entry is a note and a note is placed on the patron’s record in Alma.Provide the list of blocks from Horizon and their description, along with the block code as it should be in Alma. As implied in the previous paragraph, do not include codes that are notes on this tab.
    This mapping table is not mandatory.
    Horizon block: The Horizon patron block code as found in the block field in the burb patron extract (this may very well be simply ‘1’).
    Horizon block description: A description of the Horizon patron block code, for informational purposes only. This column is not used in the mapping.
    Alma Block code: The block code desired in Alma.
    Alma Block description: The description of the block code in Alma. The value in this column is loaded to the server in the userBlock code table. This description can be updated after migration.
    Comment: Use this field to add any comments about the block.

    Fine Fee Type Tab

    Horizon stores patron fine/fee information in the burb file, which also contains blocks and notes. If a block code from the burb file is listed on this tab, then a monetary fine will be created in Alma. If it is listed on the User Block tab, then a block or a note will be created. List all of the Horizon block codes from the burb file that indicate that a fine is assessed against a patron. Then, map the code to the appropriate Alma FineFee Type.
    Horizon block : List all of the values from the block field in the Horizon burb extract that indicate that money is owed. If there is no value in the Horizon form that corresponds to a block value but there is an amount listed, then theALMAME_VAL_NOT_FOUND value will be used for all outstanding fine/fees.
    Horizon Description: A description of the block value, for assistance in filling out this form. This column is not used in the mapping routine.
    Alma Fine Types: Possible values in Alma are listed in the drop-down list.
    Further Information: Outstanding patron bills from Horizon are migrated to Alma Fines and Fees. Only the currently owed amount is migrated. If any partial payments have been made before conversion, they are not reflected on migration to Alma.

    Further Explanation – Fulfillment/Patrons

    Internal/External Patrons

    Alma categorizes users as either external or internal. External patrons are managed by an external system, such as through a regular load from the bursar’s office/campus student information system. Internal patrons are created and managed internally. Examples of internal patrons are community borrowers or alumni. Use one of the following two ways to define a patron as internal or external:
    • Provide a field called INTERNAL_EXTERNAL in the Horizon patron extract, containing either “INTERNAL” or “EXTERNAL”.
    • Identify patrons as internal or external by user group on the Horizon Migration Form, User Group tab, Internal? Yes or No column. For example: all faculty are EXTERNAL and all community borrowers are INTERNAL.

    Identification Numbers

    The migration program allows for six different types of user identifiers: University ID, Barcode, and Additional ID 1, 2, 3, and 4. Select one of these identifier types as the primary ID – the primary unique identifier that the patron uses to authenticate via Primo. Internal patrons authenticate with the primary ID and a password, and external patrons use the primary ID as the match point with an external authentication system. Use the User Identifier section in the Horizon Field Mapping Form to map a local Horizon identifier to the Alma expected identifier types. Then, select an Alma identifier type to be the Primary ID using the PATRON_PRIMARYID question on the Questionnaire tab.
    When selecting the primary ID, the first identifier found in the field is used as the primary ID, and all subsequent identifiers are kept in the userIdentifier section. The primary ID must be unique, so if there are duplicates, the first unique ID found is migrated as is, and the IDs for the second and subsequent patrons with the same ID are given a suffix of -1, -2, etc. The original identifier is stored in the non-unique userIdentifier field so that the patron can still be retrieved using that identifier.
    The primary ID that you select is not also written to the patron identifier section in the Alma patron record. The identifiers that are NOT selected as the primary ID are written to the patron identifier section in Alma.
    When an identifier is written to the identifier section and there are multiple instances, the first one found for each type is active and the subsequent ones are inactive.
    If the identifier selected for the primary ID is not present, the migration program creates an identifier for the patron based on the patron original ID, prefixed with ID. The migration programs do not fill in the primary ID with a non-selected identifier.
    Select BARCODE, UNIV_ID or ADDL ID 1, 2, 3, or 4 as the primary ID type for all patrons in the Questionnaire tab of the Horizon Migration Form.

    Loans

    Active loan transactions are migrated from Horizon to Alma. Completed loan transactions are not included in the migration to Alma.

    Acquisitions

    Customer Input

    Questionnaire Tab

    Complete the following in the Questionnaire tab:

    Migrate Acquisitions

    Code: ACQ_MODE
    Options: Select Yes or No depending on whether or not you have contracted with Ex Libris to migrate any Acquisitions data.

    Central Order Library

    Code: CENTRAL_ORDER_LIB
    Default: None
    Options: See explanation below in Default Order Library
    Default Order Library
    Code: DEFAULT_ORDER_LIB
    Default: First library found on the Alma Library list
    Options for Central and Default Order Library: The ORDR_LIBR field specifies the order location for orders in Horizon. The migration attempts to map the ORDR_LIBR field to the corresponding Alma Library. If you want to override this ORDR_LIBR field and instead assign an order library to all orders migrated, fill in a value for the Central Order Library question. Otherwise, if you want to use the ORDR_LIBR field to determine the order library, leave the Central Order Library blank and fill in a value in the Default Order Library question. In this case, the migration attempts to determine a library based on the ORDR_LIBR field and only when a library is not specified or a mapping is not found does it use the Default Order Library as a second choice.

    Default currency for Ledgers/Funds

    Code: ACQ_CURRENCY
    Default: USD
    Options: List the currency used for all of your funds. Orders can have other currencies and be translated to the default currency, but funds must have a single base currency.
    The currency should be a three-letter code, as listed in http://en.wikipedia.org/wiki/ISO_4217
    Default language of conversation with vendors
    Code: VENDOR_LANG
    Default: en
    Options: Specify the default vendor language for your vendors. Use the two-letter codes as defined in ISO 639-1. Consult the codes from https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes.

    Fiscal Period Cycle Pattern

    Code: FISCAL_PERIOD
    Default: 01-07-1 (fiscal period starts on July 1 (01-07) and lasts for one year (-1).
    Options: To have functioning ledgers, fiscal periods are required. Specify your fiscal period as DD-MM-C (Day-Month-Cycle). For example, a one year fiscal period starting on January 1 is indicated by: 01-01-1. A one year fiscal period starting on July 1 is indicated by: 01-07-1.
    Alma currently supports one-year fiscal period cycles.

    Which year do you use to name the fiscal year?

    Code: FISCAL_PERIOD_NAME
    Default: second
    Options: Specify if the fiscal period is named with the first year or the second year.
    • second – if fiscal period runs July 1 2014 through June 30 2015, then the fiscal year is named 2015.
    • first – if fiscal period runs July 1 2014 through June 30 2015, then the fiscal year is named 2014.
    If your fiscal period runs from January 1 through December 31, this question is not necessary.

    Current Fiscal Year

    Code: CURRENT_FISCAL_PERIOD
    Default: determine by date of conversion
    Options: This question is important around the fiscal period close, depending on whether or not you have run fiscal period close in your legacy ILS or if you will run it in Alma after migration. If you do not know how to answer this, select determine by date of conversion. The options are:
    • Determine by date of conversion – The conversion program uses the fiscal period that includes the date of conversion.
    • 2014-2015 – Select this option if the date of conversion is later than the fiscal period to which you want your orders to migrate. For example, if the migration date is July 3, 2014, and the previous fiscal period ended on June 30, 2014, select this to put all of your orders in the fiscal period that ended on June 30, 2014. Select this option if you want to run fiscal period close in Alma instead of in your old system.
    • 2015-2016 – If the date of conversion is earlier than the start date of the desired fiscal period, select this option. For example, if the migration date is June 15, 2014, and the next fiscal period begins on July 1, 2014, select this option to put all of your orders in the next fiscal period. Select this option if you want to perform the fiscal period rollover in your legacy ILS prior to conversion.

    Accrual Accounting

    Code: ACCRUAL_ACC_FY
    Default: No, do not make an additional Fiscal Year
    Options: If your library uses accrual accounting, you can instruct Ex Libris to make an additional fiscal year. When an additional fiscal year is created, it will be after the current fiscal year. For example, if the current active fiscal year is 2016, then the additional year, also active, will be 2017. The options are the following:
    • No – do not make an additional fiscal year.
    • Yes-No Funds – make an additional fiscal year but leave it empty. The library then needs to create funds for this fiscal year after go-live.
    • Yes-duplicate funds – make an additional fiscal year and also fill it with funds that are the same codes as the funds in the current fiscal year. No allocations are made.

    Default claiming period

    Code: ORDER_CLAIM
    Default: 90
    Options: Default claim used for vendors and orders (if applicable), in days

    Renewal Date

    Code: RENEWAL_DATE
    Default: none
    Options: Default renewal date for subscriptions. If your subscriptions are generally ordered on the same cycle and you do not provide that renewal date in the order data itself, place that date here. The first choice of populating this mandatory field for ongoing orders is based on explicit renewal date information in the order, the second is to populate based on an answer to this question (if populated), and the default is set the renewal date = migration + 1 Year. The default is used only if no renewal date is provided in the orders and no answer is provided in the migration form questionnaire.

    Fund Prefix

    Code: FUND_PREFIX
    Default: none/blank
    Options: If you are combining data from two or more separate databases into a single combined institution in Alma, then indicate a prefix here that will be used to distinguish the former fund codes in Alma after migration. Provide a string to be used to prefix all fund codes in the database. A hyphen is NOT provided. For example, if your fund code is SCIENCE-MONO, and you put UWS- here, the final fund code is UWS-SCIENCE-MONO. Leave this question blank to leave the fund code as is.
    See also the similar Bib Key Prefix in inventory.

    Further Explanation – Acquisitions

    Fund Input File

    Fund records are submitted in CSV format and loaded to Alma. They are not extracted directly from Horizon. See the Horizon to Alma Data Delivery Specification document to see the file format required for funds.
    The funds in the input file are only created for the current fiscal year.
    Initial allocations for the migrated funds are created from the Allocation field of the Fund Input file.

    Transactions of Amount 0.00  

    Horizon allows for transactions to be of value 0.00 for all purchase orders (encumbrances). In Alma, fund transactions can be of amount 0.00 only when it is an encumbrance and when the associated PO is of type GIFT, DEPOSITORY, EXCHANGE, or TECHNICAL. All other encumbrances of amount 0.00 are changed to 1.00.

    Purchase Orders

    Only open purchase orders are migrated, and they are all linked to the budgets of the current fiscal year.
    The status of the purchase order is determined as follows:
    • When cancel_date is not NULL, then CANCELLED
    • When order_date is null, then NEW
    • When received_date is not NULL and PO_LINE_TYPE is not *OT, then WAITING_FOR_INVOICE
    • else SENT
    The type of purchase order is determined by the renewal_type:
    • when renewal_type = 2, then PRINT_CO
    • when renewal_type = 0, then PRINT_OT

    Physical to Electronic (P2E) Processing

    This section describes the process of correctly categorizing resources as electronic in Alma. In Horizon, all resources are stored as physical in the database, even if the record represents an electronic item. During migration, all records are initially converted to Alma as physical. A second process converts records that you identify as electronic to the electronic format. It is up to you to provide a list of records that are identified as electronic, in the following format:
    123475,portfolio
    12345,package
    12346,db
    The words portfolio, package, and db are not case-sensitive; therefore, both portfolio and Portfolio are acceptable.

    Customer Input

    Questionnaire Tab

    Complete the following in the Questionnaire tab:

    Which Holdings or Bib field stores electronic link information

    Code: P2E_LINK
    Options: Provide a 3 digit Marc field code + subfield: 856u. Only one field/subfield is allowed.
    Recommendation: 856 u
    Default: If this is left empty, no tag is used.

    Which Holdings or Bib field stores electronic link public note

    Code: P2E_NOTE
    Options: Provide a 3 digit Marc field code + subfield: 856z. Only one field/subfield is allowed.
    Recommendation: 856 z
    Default: If this is left empty, no tag is used.

    Which Holdings or Bib field stores electronic provider name information

    Code: P2E_PROVIDER
    Options: Provide a 3 digit Marc field code + subfield: 856m. Only one field/subfield is allowed.
    Recommendation: 856 m
    Default: If this is left empty, no tag is used.
    For the questions on the Questionnaire tab, only one field/subfield is allowed per question.

    Alma Location Tab

    Electronic Location Column

    Identify which locations indicate an electronic holding or item record. A single bibliographic record may contain holdings for multiple locations, but only the holdings/items for electronic locations need to be identified. Identify the locations in the in the Electronic Location? column in the Alma Location tab of the Horizon Migration Form.

    Purchase Orders

    Line Types and Electronic Orders

    The PO line types are all descriptions based on a print order. All orders are stored in Horizon as print, and so are migrated to Alma initially as print using the print line types. The physical to electronic (P2E) process identifies orders attached to electronic bibliographic records and transforms the order to electronic. In other words, if an order migrates as PRINT_SO, is attached to a bibliographic record that you identify as electronic and is in an electronic location, then it is changed to the corresponding electronic standing order line type by the P2E process.

    Further Explanation – P2E

    If you have multiple 856 links in a single bibliographic record identified as electronic, a different inventory link for that bibliographic record is created for each URL found in the record. In addition, if you have two item records with different electronic locations attached to the same bibliographic record, a different inventory link is created for each location, as well.
    For more information on the electronic migration approach to Alma, refer to Electronic Resource Handling in Alma Migration.

    Appendix A – Post-Migration Process Statuses

    The process statuses (codes) from the local system are mapped to the indexed internal note 1 field of the Alma item. These items are considered not available after migration when process = Technical – Migration.
    These fields are currently indexed in the item keyword and advanced searches.
    When searching for physical items, a staff user can search by item process status code with the general keyword search and then by facet if before searching, Process type = Technical – Migration and with the advanced search filter when Process type = Technical – Migration.
    In order to give items real Alma statuses or remove the Technical – Migration status, scan the barcode of the item to various configured departments (via receiving, for example), request a move to various departments/temp locations, or just scan the item for return, which removes the status from the item.
    You can also use the Scan In API, described here: https://developers.exlibrisgroup.com...le-of-barcodes.
    Additionally, it is also possible to configure the GetIt (Primo) services to display or not display items with this process status in the GetIt Item list.
    • Was this article helpful?