Horizon to Alma Data Delivery and Migration Guide

Last updated
Save as PDF
Share
1. Share
2. Tweet
3. Share

Migration Overview

Horizon is an Integrated Library System (ILS) produced by SirsiDynix. This document serves two purposes:

A step-by-step guide to filling out the Horizon Migration Form.
An explanation of the data files expected from Horizon, the fields in those files, as well as migration rules for Horizon to Alma.

The procedure for migrating from the Horizon (Sirsi) ILS to Ex Libris’ Alma consists of the following steps:

Data Files:

Extract the relevant data elements from Horizon into flat files (customer responsibility).
Validate the extracted flat files using Ex Libris’ Migration File Validation Tool. Depending on the size of the extracts, the customer may choose to validate a small sub-set of data to ensure that the data format is valid, including the header and field information, prior to validating the entire extract.
Also using the Migration File Validation Tool, indicate which fields from Horizon map to Ex Libris expected fields (customer responsibility). The files and field names below can be used as a reference during this process.
Confirm that the number of records in each file, as determined by the Migration File Validation Tool, matches the number of records exported from Horizon.
Once the files are validated and the record counts are confirmed, upload the files to Ex Libris’ secure file server, using the Migration File Validation Tool and the customer MFT credentials.
Transform the data elements, based on the Field Mapping as indicated in the Migration File Validation Tool, into an intermediate conversion XML format (Ex Libris responsibility).
Load the transformed data into Alma (Ex Libris responsibility).

For all files, the maximum file size is 2GB. Prepare the data files in the exact format as specified in Files Requested From Horizon with the naming conventions as described there.

Migration Form:

Complete the Horizon Migration Form prior to the actual delivery of the data, using the information in this guide. The lead time depends on your project schedule. Validate the Migration Form using the online Migration Form Validation Tool, and download the validated Migration Form, which shows the validation report on the Report tab. Send the validated Migration Form to your Ex Libris Project Manager.

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

Recommendations for Using this Guide

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.

Files Requested from Horizon

Ex Libris expects a certain set of files to be exported from Horizon, listed below. As files are extracted, be sure that the extracted file description, such as data elements and lengths, matches the description in Expected File Formats.

The data elements listed are those that Ex Libris expects to use in conversion. Not all data elements that exist in Horizon are necessary to transfer to Alma.

The scope of your specific conversion is agreed upon in your Alma contract.

DO NOT OPEN/UPDATE any delimited file extracts you provide to Ex Libris in Excel. This may ruin the appropriate delimiter formatting and text formatting and may result in corrupted data.

The following is the default naming convention:

CustomerName+DataType+sequence+date+[.<file_extension>].</file_extension>

For example: centralu_bib_01_20120420.mrc, centralu_bib_02_20120420.mrc, centralu_bib_03_20120420.mrc, etc.

Ex Libris recommends a maximum of 200,000 records per MARC file and 400,000 for other types of records (items, orders, etc). All records in a single file must be homogeneous – all of the lines in the file must have the same number of fields, and those fields must contain the same type of data. Additionally, all of the records must be delimited in the same manner.

Using the Migration Form Validation Tool

The Horizon Migration Form is used by the migration programs to convert your data for use in Alma. Therefore, it is important that the data entered by the customer is valid so that the migration can continue on schedule.

Your sandbox contains an online validation tool that helps ensure that your data is valid before you submit the form to Ex Libris. Information about this online validation tool can be found at: Validating the ILS Migration Form.

After you have completed the form, visit the link in your sandbox to begin the validation process.

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.

Bibliographic Records

Bibliographic records are expected in MARC format. Standard MARC is preferred, but files in MARCXML format are also acceptable. The character encoding expected from Horizon is UTF-8. If your library prefers to export in a different character encoding such as MARC8, inform your Ex Libris project manager. Deliver all files with the same character encoding.

Provide suppressed bibliographic records in a separate MARC file.

If you have loaded bibliographic records from an electronic resources management system (such as SFX) into Horizon, it is recommended that they not be included in the bibliographic record export to avoid unnecessary duplication with records loaded directly from the external management system. If you want Ex Libris to detect and not migrate the duplicate records, ensure that a 035 |a field with specific string (such as ‘(SFX)’) in the field content is provided so that they can be identified, and answer No to the question about SFX bibliographic record on the Questionnaire tab of the Horizon Migration Form.

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.

Bibliographic Record Number

For some customers, the out-of-the-box Horizon export does not include a bibliographic record number. If your bib record does not contain the bibliographic record number, we recommend copying the Horizon bibliographic record number from the bib_control table into the actual bibliographic record. We recommend using the 999 $a for the bibliographic record key in the bibliographic record. If the number is in some other tag/subfield, indicate it in the Migration File Validation Tool.

Holdings

For Horizon migrations, holdings records can be generated in Alma in the following different ways:

In MARC Holdings format
From the serial holdings csv file
From summary statement tags embedded in the bibliographic record (See Holdings from a Bib Tag)
Based on information from the item tag, if the item is not already attached to a holdings record created from the other three methods

Serial Holdings
Expected Field Name	Notes
file: holding_summary
copy#	links to ‘copy’ file
run_code	when 'supp', display_text* will be put in 867. When 'index', use 868. Else, use 866.
display_text_from	first part of summary statement
display_text_to	second part of summary statement
file: copy
copy#
bib#	links to bib
serial#	links to serial issue file (see Serial Issues – Items section)
location	use in Alma Location Tab
collection	use in Alma Location Tab

Serial Holding Notes

Any additional subfields not listed above may be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column.


Note Name	Default Local Field
PUBLIC_NOTE
NON_PUBLIC_NOTE	CHECK_NOTE, INT. NOTE

Holdings From a Bib Tag

If there is information in a field embedded in the bibliographic record, the migration programs can generate a holding record from it. Fill in the values of the following fields in the Holdings section of the Migration File Validation Tool. If the SUMM_LIB_CODE and SUMM_LOC_CODE match an existing holding record on the same bibliographic record, even a holding record that was generated from items attached to the same holdings record, then the summary holding statement will be attached to that holdings record, regardless of call number. In other words, the summary holdings record will be placed on the holdings record with the same library and location, even if 852_SUBFIELDS_FOR_HOL contains call number subfields for matching like bchi. If there is no existing holding record on the bib with the same location, then a new holding record will be generated.


Expected Field Name	Value	Notes
SUMM_TAG		Five characters; tag+2 indicators. May use # as wildcard, for example, 866## or 86#3#. Wildcard allowed for third digit and indicators but not first two digits. To indicate a space character, use b, for example 866b1.
SUMM_SUBFIELDS		Multiple subfields allowed, e.g. abz. May use # to indicate all subfields.
SUMM_CALLNO		Textual call number to be used in all newly generated holdings records if desired.
SUMM_LIB_SUBF		A single subfield code (like 'a') which contains a library code in local ILS format. Do NOT enter a different bib tag. The migration program searches for a subfield within the SUMM_TAG bib tag.
SUMM_LOC_SUBF		A single subfield code (like 'a') which contains a location code in local ILS format. Do NOT enter a different bib tag. The migration program searches for a subfield within the SUMM_TAG bib tag.
SUMM_LIB_CODE		If SUMM_LIB_SUBF is not provided or the subfield is not found, this is used for all records as a default. Provide a library code in local ILS format.
SUMM_LOC_CODE		If SUMM_LOC_SUBF is not provided or the subfield is not found, this is used for all records as a default. Provide a location code in local ILS format.
SUMM_PUBLIC_NOTE_SUBF		Public note, will be placed in 852 $z of the generated holding record
SUMM_NON_PUBLIC_NOTE_SUBF		Non-public note, will be placed in 852 $x of the generated holding record

Items

Extract all items, in CSV format. The following table lists the expected fields for item migration. If your item fields have different names, indicate the field mapping in the Items section of the Migration File Validation Tool. The maps that are indicated in the Notes column below are found in the Horizon Migration Form. See the 'Customer Input' section below for information on how to fill out the maps.


Expected Field Name	Notes
item#
ibarcode
bib#
location	Use Alma location map
collection	Use Alma location map
call_reconstructed
copy_reconstructed	maps to Description field in Alma (like 'Vol. 1 (1980) - vol 12 (1992)')
copy#	Used to link between item and copy files
volume
price
creation_date	Create Date is not retained in Alma; if you wish to keep this, move it to a note.
last_update_date
last_inventory_date
inventory_number
itype	Use item type map
item_status	Use item status map
last_cko_date	To see this value in Alma, search for the item under 'Physical Items' and on the results list click 'Other details'.
n_ckos	To see this value in Alma, search for the item under 'Physical Items' and on the results list click 'Other details'. Alma increments the loan count for items currently on loan, so it is recommended that you send (loans - 1) for currently loaned items.
call_type
provenance
receive_number	In order to use the Receiving Number in Alma, you must configure an item sequence of type Receiving Number (Config menu -> Resources -> General -> Item Sequences). See Configuring Physical Item Sequences.
storage_loc_id	Storage Location ID
n_inhouse_uses	To see this value in Alma, search for the item under 'Physical Items' and on the results list click 'Other details'.
last_in_lib_use_date	To see this value in Alma, search for the item under 'Physical Items' and on the results list click 'Other details'.

Inventory Price/Replacement Cost
Expected Field Name	Notes
price	Both fields may be filled with the local ‘price’ field from Horizon, if desired. The REPLACEMENT_COST will be used to assess fines if the item is lost. The value from Horizon is received like '10000', and the migration programs change this to 100.00.
REPLACEMENT_COST

Item Notes

Any additional subfields not listed above may be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. If you use other field names or have fields that you want to include in the migration, but are not expected by Ex Libris, you can rearrange, add, or subtract fields in the Note Type column as necessary. The text in the Note Label column are used as a prefix to the subfield contents and can be modified, as desired. If you want to include multiple local fields in the same Alma note, copy the line in the spreadsheet as many times as needed for all note name/local field combinations.


Note Type	Local Field
PUBLIC NOTE
FULFILMENT_NOTE
FULFILMENT_NOTE
NON_PUBLIC_NOTE_1
NON_PUBLIC_NOTE_2
NON_PUBLIC_NOTE_3
STAT_NOTE_1
STAT_NOTE_2
STAT_NOTE_3

Item Statistics Notes (STAT_NOTE_*) can use controlled vocabulary when statistics_note_controlled is set to true. For more information, see Configuring Item Statistics Notes.

Secondary Item File

You may want to provide item descriptive information in a secondary file. For example, you have a description in the format Vol. 12 No. 2 (2015 February), but Alma recommends that enumeration and chronology information are without labels and are in separate fields. You can provide your description in a secondary item file.

With the exception of the item_key and barcode, all other fields will force blank if an empty field is provided. In other words, if you have an item description in Alma, and you provide a blank description in this file, the incoming blank will be 'written' to Alma, meaning the Alma description will be deleted.

We recommend that EnumX and ChronX fields contain only numbers, for example '12' instead of 'Vol. 12' and '2' instead of 'Feb'. However, it is programmatically time-consuming to distinguish between an invalid use (Vol. 12) and a valid use (12A), so in the interest of processing quickly, we allow any string in EnumX and ChronX fields. Do not provide a full date in a single field. Split any dates into three, for example 4 Feburary 2020 is ChronI=2020, ChronJ=2, ChronK=4.

Even though it is not recommended, if for any reason you need to provide a full date in a single field, put a tick (') before the date in the Excel cell so that it is treated like text (instead of the Excel date format).

Provide the secondary item file in Excel format (xls or xlsx) format, with the following fields:

Expected Field Name	Notes
item_key	Provide either item_key or barcode, but not both. If both are provided, item_key is preferred Always provide both fields, even when one is empty. E.g.
barcode
description	Provide in a format such as: Vol. 12, No. 6 (February 2015)
enumA	For example, “12”.
enumB	For example, "6".
enumC
enumD
enumE
enumF
enumG
enumH
chronI	For example, "2015"
chronJ	For example, "2".
chronK
chronL
chronM

Serial Issues (Items)

Extract all serial issues, in CSV format, that will be used to create items in Alma. The following table lists the expected fields for serial issues migration. If your issue fields have different names, indicate the field mapping in the Serial Issues section of the Migration File Validation Tool. Serial issues are linked to serial holdings (see Serial Holdings) through the serial# field. The maps that are indicated in the Notes column below are found in the Horizon Migration form. See the 'Customer Input' section below for instructions on how to complete these maps.

No attempt is made to deduplicate or merge serial issues with items. There are not any overlapping identifiers which could help determine equality.


Expected Field Name	Notes
Icopy#
bib#
media_type	use Alma Item Type map
serial#	links to serial holdings file
copy_issue_status	use Alma Item Base Status map
location	use in Alma Location Tab
collection	use in Alma Location Tab
Enum
free_enum
issue_date	Item's issue date in Alma
expected_date	Expected arrival date
display_text	Item's description
status_date	used to calculate arrival date

Item Notes


Note Type	Local Field
PUBLIC NOTE
FULFILMENT_NOTE
FULFILMENT_NOTE
NON_PUBLIC_NOTE_1
NON_PUBLIC_NOTE_2
NON_PUBLIC_NOTE_3
STAT_NOTE_1
STAT_NOTE_2
STAT_NOTE_3

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 bibliographic system number (Horizon bib key) 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. Multiple strings are allowed, use a semicolon to separate: (SFX);WaSeSS;EBC

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 Linked Entry fields?

Indicate if you use internal system numbers in linking fields. Internal system numbers from your legacy system are not continued in Alma, and therefore should be changed to MMSID (the Alma internal system number).

MARC fields: $w subfield for tags 76x-78x, 80x, 81x, and/or 83x

Unimarc fields: $1 subfield with prefix 001 for fields 423, 461, 462, 463, 464 [example: bib key 99999 in tag 461 = 461 $100199999]

Code: LINKED_ENTRY_W

Default: No

Options: If you answered Yes to this question, the internal system numbers in the subfield $w or $1001 of the specified tags are converted from the former 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 or $1001 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, your previous ILS may store the information in bibliographic fields 76x-78x, 80x, 81x, and 83x $w for MARC, and 423, 461, 462, 463, 464 for Unicode. If the number in the $w or $1001 of the linking tags is the internal legacy ILS 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 linking field 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. For more information on configuring related records, see Configuring Related Records for Physical Inventory.

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 library and location only, select bc here. If you have many items in the same bibliographic record in the same library/location but different call numbers WITHIN that library/location and you want each of them to have their own distinct holdings record, specify additional call number subfields. Acceptable subfields: bchijklmp.

The library and location codes are matched after the Alma Location Mapping has been performed, meaning the match is done on the Alma version of the library/location codes.

Further Information: See Determining Groups of Holding Records and Changing the Holdings Record Grouping.

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 and MERGE_PATRON_PREFIX in Fulfillment.

Move 001/003 to 035 or 935

Code: 001_035_935

Default: 035

Options: If your incoming bibliographic records have a number in the 001, then the migration programs move it elsewhere as (<003>)<001>. For example: (OCoLC)12345. To move to the 035, which is the default, then select 035 in the dropdown. If you are part of a consortium and are using OCLC numbers to determine matching records when linking to the NZ, you may wish to move this number to the 935 so that the moved number does not interfere with another matching key you may be using. If you are not linking to the NZ, then this question is likely not useful. Default: 035

Ex Libris marks the moved 035 or 935 with $9 ExL to indicate that the migration programs generated this field.

Further information: If an 035 exists in the record already with the identifier that was in the 001, then a second (duplicate) tag is NOT made. Also, when checking if the identifier already exists, the migration programs compare to the $a only. Meaning, if an existing tag contains

001 12345

003 OCoLC

035 $a(OCoLC)12345 $z (OCoLC)54321

then the existing 035 $a is considered a duplicate and a second tag is not created.

Add institution suffix to Bib ID

Code: BIBID_INST_SUFFIX

Default: No

Options: When moving the legacy bibliographic identifier to the 035 or 935, you can choose to add the institution code to the end of the string, like 12345-34ABC where 12345 is the legacy bib ID and 34ABC is the institution code. This may be used in conjunction with other bib identifier options, such as BIB_KEY_PREFIX and MARC_OC.

Yes = include suffix

No = do not include suffix

Use subfield indicators in item call number (AltCallNo)

Code: ITEM_CALLNO_SUBFIELD

Default: Yes

Options: When generating an Item Call Number field (also known as AltCallNo), you can decide if the string contains subfield indicators. Default = Yes

Yes = $h PZ3.A93 Pr16 $i A975
No = PZ3.A93 Pr16 A975

For more information on when an Item Call Number is generated, see the section Changing the Holding Record Grouping, which depends on the question 852_SUBFIELDS_FOR_HOL.

Add $9 LOCAL to specified tags

Code: NZ_LOCAL_TAGS

Default: empty

Options: Add $9 LOCAL to specified bib tags, for use in consortia where an IZ environment links to an NZ. Tags marked as Local will be kept in the IZ, and not moved to the NZ.

Format for this input: tag + indicator. Use # for any/wildcard, and b for the space character. Separate with semicolon.

Example: 59###; 69###;960##;970##;090b#

The wildcard works only for the third digit of the tag and the indicators. Examples:

CORRECT: 95###

INCORRECT: 9####

Also, 900-949 cannot be used here, as described in the Migration Considerations for Consortia guide.

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.

The Alma Library Code may not be the same as the Alma Customer Code nor the Alma Institution Code .

Alma Library name: Maximum 255 characters. This is visible to the public. This must be unique. For example, you cannot have two libraries with code LIBA and LIBB and have them both called 'Library'. They must have different names.

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.

Incoming Horizon Location and Collection fields are case-sensitive; Main is a different code than MAIN.

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. Further, the item status description field is written to internal note 1 for all items where there was a status, regardless of the shelf/not on shelf designation.

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. Also, treat a status that is duplicated by an Alma workflow status the same way. That is, if an item status is 'Checked out' but you will also migrate a loan for this item, do not migrate the 'Checked out' status. The migrated loan record will indicate that the item is not available (checked out). Further, if you DID migrate the 'Checked out' status, you would have duplicated statuses, and also Alma will not remove the 'Checked out' status once the loan is returned, so it would stick around longer than it is needed.

If you want the temporary locations (such as new bookshelf 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 Information

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 Item 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 Item 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 ItemCallNo)

item 3 (with PN 567 .M457 stored in ItemCallNo)

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 <item barcode>-<item id>.

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 material type in migration is derived from the resource type which is constructed by Alma based on the bib header information. To see a description of how the resource type is determined, see the Resource Type Field description.

Fulfillment/Patrons

Patrons

Extract all patrons. In order to migrate any area of fulfillment (fines/ fees, loans, requests), all patrons must be migrated. Multiple patron files are expected from Horizon: borrower, borrower address, borrower phone, borrower barcode, and borrower bstat.

Additionally, provide a city_st file which translates city codes to actual city names. The city_st file will look something like the following:

RAPIDSD,”Rapid City”,”South Dakota”

The patron files are expected in standard CSV format. The fields in the following table are expected. Indicate the local field names for the expected fields in the Patrons section of the Migration File Validation Tool.


Field Name	Notes
file: borrower
borrower#	original borrower ID; Often this is used twice - for original borrower ID and also UNIV_ID (or another identifier). To map twice, use the plus sign (+) to the left of the field name.
name_reconstructed	Will be split as follows: "Smith, John Paul" Last name = Smith First name = John Middle name = Paul
location	use Campus Code map
btype	use UserGroup map
birth_date
gender	acceptable values: m, M, f, F, or blank
expiration_date	may be left empty
creation_date
last_update_date
language
title
file: borrower address
borrower#	needed to link to main file
address_type	see Address section below to assign address types
valid_from_date
valid_to_date
address1
address2
address3
address4
postal_code
city_st	also provide the city_st file that will be used to translate the city/state code to the city and state.
email_name
email_address
File: borrower phone
borrower#	needed to link to main file
phone_no
phone_type	see phone type section below to assign phone types
file: borrower barcode
borrower#	needed to link to main file
bbarcode	see identifier selection below
file: borrower bstat
borrower#	needed to link to main file
bstat	do not list a local field here: you may choose to put this in the UserStatCategory fields below, or notes
file: borrower burb - from fine/fee file
block.borrower#	needed to link to main file
block.reference#
block.item#
block.date
block.block	See description below ('Borrower Burb file') for the three options for this field: block, patron note, or fine.
block.comments

Borrower Burb file

Blocks and patron notes will be added to the patron record from the combined fine/fee/block/note file, borrower_burb.

There are three possibilities for a line from the burb file:

Block: When a value from the the burb 'block' field is listed in the User Block tab of the Horizon Migration Form, then the information will be transferred to the patron record as a block.
Note: When a value from the burb 'block' field is not listed on the User Block tab in column A, nor in the fine fee type tab, then it is transferred to Alma as a patron note.
Fine: When a value from the burb ‘block’ field is listed on the Horizon Migration Form Fine Fee Type tab, the information will be transformed to a patron fine in Alma. See the Fines and Fees section for more information.

User Identifiers

There can be a number of fields in the patron record that are user identifiers. The types of identifiers that are available for migration into Alma are listed in the left column. List the field names from Horizon in the middle column (typical field names are provided below). Change the field names and/or order of the middle column to suit your library’s extract. The values in the left column cannot be changed. Use the values in the left column to select the appropriate primary identifier in the Questionnaire tab of the Horizon Migration Form.

If there is a field that contains a note specific to the identifier, for example “This barcode was declared lost”, then put the field name for the note in the third column.


Alma Identifier Type	Horizon Field Name	Horizon Note for Identifier
UNIV_ID	borrower#
BAR	barcode.bbarcode	barcode.lost_date; barcode.barcode_type
ADDL_ID_1	borr_ldap_dn
ADDL_ID_2	student#
ADDL_ID_3	second_id
ADDL_ID_4

User Preferred Address

There may be a number of addresses, phone numbers, and email addresses in the Horizon borrower address. You may decide which addresses, phone numbers, or email addresses are the preferred ones in Alma. If the preferred entry is empty, the secondary one becomes preferred. Additionally, select an address type for each address: Home, School, Alternative, Work, All. Phone types are: Home, Mobile, Office, OfficeFax, All. Email types are: Personal, School, Work, All.


Horizon Type value from file	Alma type (select from dropdown box)	Preferred address designation
Preferred Address Selection	Type one of the address types in the next column:	(type either 0 or 1 here, or whichever Address type is listed in the file)
Address TYPE value (from borrower address file)	Alma Address Type
0	Home, School, Alternative, Work, All
1	Home, School, Alternative, Work, All
	Home, School, Alternative, Work, All
Make similar selections for Phone and email

User Statistical Categories

There may be a number of fields in the borrower bstat file or the borrower record itself that function as a statistical category only, for example, a student’s department or major. The way the student borrows can be determined by the user group, but you may want to track the department, so that you can get more detailed statistics on how law students borrow, for example. We provide you the option to map the data from any field to the user statistical categories in Alma.


User Statistical Category	Local Field Name	Field Label
USER_STAT_CATEGORY		STAT:
USER_STAT_CATEGORY		CAMPUS:
USER_STAT_CATEGORY		SCHOOL:

You can add more lines as necessary, up to a maximum of 10 lines. To map the values, use the UserStatCategories map in the Horizon Migration Form. If a value is not found in the map, it is migrated as is. If you use a label, the userStatCategory map tries to map the field including the label. The first column in the userStatCategory map would be: LABEL: value, for example: SCHOOL: Law. The migration programs do not put a colon; if you want a colon for easier reading, include it in the field label as above. However, they do add a space between the label and the value.

In the Migration File validation tool, provide labels to the right of the field:

Then, in the migration form, use that label as a prefix to the values in the field. Be sure to put a space between the label and the code:

In the case above, you can see that if there were no prefix to the fields, it would not be possible to distinguish between 'UN' from PC1 and 'UN' in PC2.

Notes

Any additional fields not listed above may be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris. If you use other field names or have fields that you want to include in the migration, but are not expected by Ex Libris, you can rearrange, add, or subtract fields on the right, as necessary. If you want to include multiple local fields in the same Alma note, copy the line in the spreadsheet as many times as needed for all note name/local field combinations.


Note Name	Information
LIBRARY_NOTE
BARCODE_NOTE
ADDRESS_NOTE
CIRC_NOTE	CIRC_NOTE is marked by the migration programs as a popup note. This is the only user note which migration marks as a popup note.
OTHER_NOTE	OTHER_NOTE is set as User Viewable by the migration programs. This is the only note which migration marks as user viewable.

Active Loans

Extract only current circulation transactions, in standard CSV format. The fields in the following table are expected. Indicate the local field names for the expected fields in the Loans section of the Migration File Validation Tool.

Completed loan transactions are not included in the migration to Alma. In other words, only loans where the item which is currently checked out to patrons are migrated to Alma. We do not migrate loan history. Total number of checkouts per item record can be transferred in the inventory migration. To keep a history of loans per patron and item, customers may export a file prior to go-live to keep as an archive.


Field Name	Notes
circ#	original loan id; optional
borrower#	Matches user ID in patrons.
item#	Matches item ID in items.
due_date	When extracting, you may need to link to the item file to get this date.
due_time
cko_user_id
last_cko_date	When extracting, you may need to link to the item file to get this date.


Note Name	Default Local Fields
NON_PUBLIC_NOTE	proxy_borrower#
NON_PUBLIC_NOTE	ill_request#
NON_PUBLIC_NOTE	cko_circ_program
NON_PUBLIC_NOTE	rental_amount

Fines and Fees (Burb file)

Extract only current fines/fees, blocks and notes in CSV format. Blocks and patron notes will be added to the patron record from this file.

When a burb type (field ‘block’) is listed in the Horizon Migration Form User Block tab, then the information will be transferred to the patron record, either as a block or a note (see Patron section above for more info). When a burb type (field ‘block’) is listed on the Horizon Migration Form Fine Fee Type tab, the information will be transformed to a patron fine in Alma. When the migration programs can detect that multiple lines in this file represent a single transaction, the lines will be grouped together and the Alma Fine Fee type that is generated will be mapped from the first block type of the group. Secondary block types will be listed in the notes.

The fields in the following table are expected. Indicate the local field names for the expected fields in the Fines & Fees section of the Migration File Validation Tool.

The default date of the fine is the conversion date, and the default fine type is Overdue Fine.


Field Name	Notes
borrower#	links to patron record
reference#
item#	links to item record
date
block	use in Fine Fee Type or User Block map
amount	Total amount will be kept; if you want individual amounts, also put this field in notes below. Fine can be postiive or negative, but not zero. Negative indicates a credit.
comment

Any additional fields not listed above may be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris. If you use other field names or have fields that you want to include in the migration but are not expected by Ex Libris, you can rearrange, add, or subtract fields on the right, as necessary.


Note Name	Default Local Fields
FINE_FEE_COMMENT	(none)

Active Requests

Provide only requests which are currently on the hold shelf and waiting for pickup from the patron. The fields in the following table are expected. Indicate the local field names for the expected fields in the Requests section of the Migration Validation tool.


Field Name	Notes
item#	links to item
borrower#	links to patron
pickup_location	will be sent through Alma Location tab
request_date
on_hold_date
hold_exp_date


Note Name	Default Local Fields
NON_PUBLIC_NOTE	comment

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. Additionally, the language code zh-tw (Taiwanese Mandarin) is accepted.

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.

See also: Identification Numbers, Internal? Question on the User Group tab.

How should we handle duplicate identifiers in the same patron?

Code: DUP_ID_SAME_PATRON

Default: DISCARD

Options: Alma does not allow duplicate identifiers anywhere, even in the same patron. If the patron has the same number in two or more different identifier types, we can either not migrate the second one, or disambiguate it with -1, -2 etc.

DISCARD: do not migrate the second and subsequent identifiers
ADD_SUFFIX: add -1, -2, etc

Default: DISCARD

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.

Merge Patron Prefix

Code: MERGE_PATRON_PREFIX

Default: No

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 incoming patron record original IDs. This prefix is only added to the internal patron identifier, it is not added to barcodes or usernames or UNIV_ID. If you are not merging institutions, leave this question blank.

See also: BIB_KEY_PREFIX and FUND_PREFIX

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 question in the Questionnaire tab:

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

See also the section on internal/external patrons.

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.

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.

Unlike other mapping tabs, the campus code and description are not loaded as a code table to Alma. Customers should set up campuses in Alma.

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.

User Stat Categories Tab

Use this tab if you use statistical categories in your patron records and you want them to migrate to Alma. In Horizon, it is possible to have multiple fields that contain statistical codes. Some examples are degree program, school/department, or year such as sophomore, junior, etc.

Before filling in this tab, specify in the Patrons tab of the Generic to Alma Field Mapping form which fields from your legacy ILS are migrated to statistical categories in Alma. You can include a label before each category to distinguish between categories in different fields. For example, you can have LAW in USER_CATEGORY1 and also LAW in USER_CATEGORY2. If desired, use a prefix to distinguish between the two, for example, CAT1: LAW and CAT2: LAW.

The migration engine adds a space between the label you specified in the Field Mapping form and the value. So if you included a label 'CAT:' in the field mapping, then use 'CAT: a' here (if 'a' is an incoming value).

Horizon Statistical Category: List all of the values from all of the fields you chose to put into the statistical category mapping. Include the label applied if it is important to distinguish between values in different fields.

Statistical Category Description: A description of the individual categories, for information only. This field is not used in the mapping to Alma.

userStatCategory Code: The Alma Statistical Category code desired. This code is used to retrieve groups of patron records with various reporting tools.

userStatCategory Description: The description of the Alma Statistical Category Code. This value is loaded into the code table for userStatCategories. This description can be easily updated after migration.

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 for the patron. You may map multiple identifiers from your previous ILS. You may also consider mapping email address, a common matchpoint in authentication systems, to an additional ID field.

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.

Identifiers may not be duplicated, even within the same patron record. See the questionnaire question DUP_ID_SAME_PATRON for options.

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.

Acquisitions

Vendors

Provide the vendors files (vendor and vendor addresses) in CSV format. The fields in the following table are expected. Indicate the local field names for the expected fields in the Vendors section of the Migration File Validation Tool.


Field Name
file: vendor main file
vendor#
vendor	links to order record
name
status
currency	use currency map in migration form
cust_number
vendor_discount
first_claim_delay
timestamp
vendor_fin_sys_code	financial system code
file: Vendor addresses
vendor#
descr
address1
address2
address3
address4
contact_phone
contact_email
contact_fax

Any additional fields not listed above may be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris. If you use other field names or have fields that you want to include in the migration but are not expected by Ex Libris, you can rearrange, add, or subtract fields on the right, as necessary.


Note Name	Local Field
VENDOR_NOTE

Orders

Provide purchase order files in standard CSV format. Four separate files are expected: PO, PO line, PO line item, and PO line item budget amount (not 'PO line item budget' - please export 'PO line item budget amount').

Export the PO line item and PO line item budget amount files with only the PO line items that are currently open. This is the only way to indicate to the migration programs which PO lines are open.

The fields in the following table are expected. Indicate the local field names for the expected fields in the Orders section of the Migration File Validation Tool.

At the top of the Orders tab, list your current fiscal year. For more information about how the fiscal year is names, see the Fiscal Period questions on the Questionnaire tab of the Horizon Migration Form.


Field Name	Notes
PO file
po#	internal key used to link PO to Lines and Line items. Not used in Alma later
po_number	must be unique per vendor in Alma. This is the PO Number in Alma.
vendor#	links to vendor file
currency	use currency map in migration form
location	Ordering library (acq unit)
renewal_type
creation_date	Create Date is not retained in Alma; if you wish to keep this, move it to a note.
last_update_date
PO Line file
PO#
line	must be unique in Alma; migration will concatenate order number + line number to make a unique key in Alma
last item
bib#	links to bib file
isbn
issn
unit_price
material_type
PO Line Item (contains only open PO line items) - this file indicates multiple ordered item quantities for the above related line
po#	this relates to the PO above
line	this relates to the PO Line above
item	This is used to determine quantity of items ordered for the related PO Line
item#	this links to individual items. This can be repeated if multiple copies are ordered for a single line
location	intended inventory library for ordered items
collection	intended inventory location for ordered items
order_date
receive_date
cancel_date
next_claim_date
approve_date
barcode
PO Line Item Budget Amount (do not use PO Line Item Budget) - this can contain multiple funding sources for a single line
po#
line
item	A sequence to differentiate when there are multiple copies for a line
budget	Links to fund file
amount

Any additional fields not listed above may be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris. If you use other field names or have fields that you want to include in the migration but are not expected by Ex Libris, add them on the right as needed. The vendor reference number, the additional number, and the receiving note may only be listed once, but you may make as many duplicate lines for PO_NOTE and POL_NOTE as necessary.


Note Name	Notes
POL_VEND_REF_NO	This line cannot be duplicated; place only one local field name here.
POL_ADDL_NO	This line cannot be duplicated; place only one local field name here.
POL_RECEIVING_NOTE	This line cannot be duplicated; place only one local field name here.
PO_NOTE	This line can be repeated as many times as necessary; multiple local fields can be placed in this note.
POL_NOTE	This line can be repeated as many times as necessary; multiple local fields can be placed in this note.

Funds

Fund records are not exported from Horizon. Rather, they are entered into an Excel migration form, then exported to CSV and delivered to Ex Libris for loading into Alma. All funds must be listed on a single tab (the first tab on the spreadsheet) before exporting to CSV. You can submit separate CSV files, but they must be physically separate files and not multiple tabs on the same sheet. Each csv file must contain a header line with the field names, as described below.

In the fund file, LEDGER CODE, LEDGER NAME, FUND CODE, and FUND NAME are mandatory. Ledgers are mandatory and if your institution does not have ledgers in the current ILS, define one general ledger for use in Alma.

Note that fund codes and ledger codes are unique across the entire fiscal period, not just within specific hierarchies. Therefore, there should be no fund code or ledger duplication in the spreadsheet submitted, since all of the funds and ledgers go into a single active fiscal period. Ledger codes are included in the unique constraint; ledger codes cannot be the same as any fund code.

Funds are grouped under summary funds, and summary funds/funds are grouped under ledgers. Only one level of summary fund is allowed in the extract; however, it is a simple task in Alma to create a new summary fund after migration and drag other summary funds underneath it.

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.


Field Name	Notes
LEDGER CODE	May be repeated across lines to group funds under a single ledger.
LEDGER NAME	May be repeated across lines to group funds under a single ledger.
SUMMARY FUND CODE	Not mandatory, may be repeated across lines.
SUMMARY FUND NAME	Not mandatory, may be repeated across lines.
FUND CODE	Alphanumeric, not repeatable. This must be unique, even across ledgers.
FUND NAME	Alphanumeric, repeatable.
LIBRARY	Must be in the Alma Library List on the Migration Form. The library code must match the code in the migration form exactly – the match is case-sensitive. There can be multiple libraries here, separated by a semicolon. This field can be left empty, which means that all libraries in the institution can use the fund. If the central order library is used in the migration form, this field is ignored and all funds are set to the institution level, meaning that all libraries in the institution can use the fund.
EXT ID	External ID for linking to an external source, if one exists.
ALLOCATION	Allocation, in dollars, of the current fiscal year’s funds.
FY	Fiscal Year YYYY
NOTE	optional note for the fund

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 and MERGE_PATRON_PREFIX

Currency Code Tab

Use this tab to map Horizon currency codes in the CURRENCY field of the vendor and order records to Alma currency codes.

Horizon CURRENCY: The value of the Currency field as found in the Horizon vendor and order extracts

Horizon CURRENCY Description: A description of the CURRENCY field, for information only. This column is not used in the mapping.

Alma Currency: Select only from the list of currencies in the dropdown box. Only currently supported currencies are listed since we only make fund transactions for the current fiscal year. If you are mapping a defunct currency, map it to the replacement currency. For example, FRF should map to EUR. If you wish to retain the fact that the order was placed in FRF then also place the CURRENCY field in a note on the Purchase Order.

Further Explanation – Acquisitions

Open purchase orders only

Only open purchase orders are migrated, and they are all linked to the budgets of the current fiscal year.

Transactions of Amount 0.00

Horizon allows for transactions to be of value 0.00 for all purchase orders (encumbrances). In Alma, encumbrances or open orders of amount 0.00 are changed to 1.00. The following types of orders (Acq method) can be open with amount 0 on the order, but with with no transaction/link to fund: GIFT, DEPOSITORY, EXCHANGE, TECHNICAL, and orders with the 'no charge' flag set to Y.

Acq Method

There is currently no incoming field that can be used to determine the Acquisition Method for an order. If your library has a field they would like to use, consult with your Ex Libris representative.

The default Acq method is PURCHASE. If you wish to change this, inform your Ex Libris representative. The options are: PURCHASE, APPROVAL, GIFT, VENDOR_SYSTEM (purchase at vendor system), DEPOSITORY, EXCHANGE, TECHNICAL, LEGAL_DEPOSIT

PO Entry Point

The status (entry point) 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

PO Line Type

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

This method may not work for all order types, especially standing orders which do not have a renewal date. Previous Horizon customers have retrieved the standing orders into separate files (standing order nonmonographic, and standing order continuous). So they provided three order files:

file 1: PRINT_SO

file 2: PRINT_SO_NONMON

file 3: subject to the check on renewal_type above

If you wish to provide order files like this, inform your Ex Libris representative.

FYI the following Line Types are possible in Alma

PRINT_OT – printed book one time. This is used for one time or infrequent orders of specific items, for example, a printed book, E book, or a musical score, that is not published repetitively. The order is at the item level.
PRINTED_BOOK_OT: Print Book One Time
PRINT_CO – journal/continuation. This is used for orders that are repeated on a regular basis. An example is monthly subscriptions to physical or electronic material such as journals. The order is at the holding level, and items in the holding record are received periodically.
PRINTED_JOURNAL_CO: Print Journal - Subscription
PRINT_SO – standing order monograph. This is used for orders that are not repeated on a frequent or regular basis. For example, this type of PO line is used for purchasing all the printed books by a particular author when they are published, or where a series of books are being published, but not necessarily on a regular basis. The receipt of new material involves a new bibliographic, holdings, and item record.
PRINTED_BOOK_SO: Print Book - Standing Order
PRINT_SO_NONMON - Standing Order Non-Monograph – Similar to continuous orders.

"In Review"

The migration programs fill out the following elements based on incoming data:

PO Line type
PO Entry Point
PO Invoice Status
Send date
Expected receiving interval/date

Alma can have a further status of 'In Review'. Migration does not set the 'In Review' status, but rather the 'In Review' status is set by a series of rules using the elements above and possibly other elements. The initial set of rules used to determine these further statuses is not controlled by the customer; it is controlled by Alma Development. Customers are often frustrated by the statuses set for NEW orders:

when NEW and OT (one time), the status is set to 'In Review'
when NEW and CO or SO (continuous), the status is set to 'Waiting for Renewal'

You can find out more about the PO Review Rules, and how to turn rules on or off, by consulting the page Configuring Purchasing Review Rules.

Linked Inventory/Receiving Location for Monographic Orders

Monographic orders in Alma are linked to item records. Orders in Horizon sometimes have a linked item record listed in the po line. If there is an item on the related bibliographic record but there is no direct link from the po line file, we cannot always link the order to the item. Without a direct link, we do attempt to find an item on the related bib record by looking for items in the same intended inventory location.

When an order does not have a linked item record or we cannot find one using matching inventory locations, there is no real place in Alma to put the expected inventory location that migrates from Horizon. To indicate the expected inventory location in lieu of a linked inventory item, the migration programs place the inventory location codes into the PO line receiving note, which appears at the top of the summary screen on the Alma PO line.

After go-live, the receiving operator should do one of the following:

1. In the case that there is no item on the linked bibliographic record, and the expected item arrives, generate an item using the information from the receiving note prior to receiving the order.

2. In the case that there is an existing (migrated) item on the linked bibliographic record: these items do not appear on the Receving workbench. These items will have to be manually received by updating the item receiving date and then link the item to a POL.

Linked inventory for Continuous Orders

Continuous orders (standing orders and subscriptions) are linked to holding records. Generally there are holding records for most continuous orders, so an order can be linked to an existing holdings record.

When an order does not have a linked holding record, the location is again put into the receiving note (as above for monographic orders), and the receiving operator should either link the order to an existing holdings record or generate a holding/item record prior to receiving the order in Alma.

Physical to Electronic (P2E)

Most non-Alma ILS systems store records for both physical and electronic items in the same format, which is a physical format. Alma has different record formats for electronic and physical items. Records that initially migrated as physical but actually represent electronic materials can be converted to electronic format after migration to Alma.

Provide a list of Horizon bibliographic system numbers that represent electronic resources and an indication if these electronic resources are portfolios, packages, or database resources. The list should be a comma separated text file containing lines that represent each e-resource. Structure each line as follows: <bibnumber>,<resource type>

For example:

000000001,Portfolio

000000002,DB

During the P2E process, all resources must either be categorized as a portfolio or a database (DB). It is not possible to generate packages during P2E processing, since packages require at least one portfolio. A database is essentially a zero-title package. Post migration, when you add portfolios to the db, you can change them to type 'package'.

The words portfolio and db are not case-sensitive; therefore, both portfolio and Portfolio are acceptable. In addition, indicate which locations represent electronic in the Location tab of the Horizon Migration Form. The migration will only convert items, holdings and orders that belong to an electronic location to an electronic format. This is especially important if your library has holdings of different formats attached to the same bibliographic record, for example you have a print version and an electronic version of the same title.

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.

If you provide a bibliographic record in the P2E file, the migration programs will generate an electronic resource for the bib, even if there is no valid URL. An example of an invalid URL might be an 856 tag with an indicator which does not match the specific indicator in the question P2E_LINK, below. For example, if you say that we use 85641u for the P2E_LINK, and you provide a bib record *without* a 85641u but that bib record is in the p2e file, then we will generate a local e-resource without any link at all (an empty resource). Be careful which bibs are placed in the bib file.

Further, the P2E process attempts to identify an order related to the identified inventory for conversion to electronic. Similarly to items and holdings, orders are initially migrated as print and are transformed to electronic through the p2e process. See the guide https://knowledge.exlibrisgroup.com/Alma/Implementation_and_Migration/Migration_Guides/Electronic_System_Migrations/Electronic_Resource_Handling_in_Alma_Migration for more information.

Customer Input

Questionnaire Tab

For each of the following three questions (P2E_LINK, P2E_NOTE, and P2E_PROVIDER), you can use indicators in the following manner:

Specific indicators: 85641u – only tags with 41 as the indicator is used.
No indicator (# is used for a blank character, for example: 8564#u) – only tags with 4<blank> as an indicator are used.
All possible indicators: 8564*u – tags with 4 as the first indicator are used. The second indicator is not taken into account.
The space character operates the same way as an asterisk (*), for example: 8564 u is the same as 8564*u.
Special Request: If you need to specify multiple specific indicators, for example 85641 and 85642, it cannot be coded in the migration form but your ExL representative can make a special request to the migration team.

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.

Migration Overview

Recommendations for Using this Guide

Related Documentation

Files Requested from Horizon

Using the Migration Form Validation Tool

Inventory

Bibliographic Records

Bibliographic Record Number

Holdings

Serial Holding Notes

Holdings From a Bib Tag

Items

Item Notes

Secondary Item File

Serial Issues (Items)

Item Notes

Customer Input

Questionnaire Tab

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

MARC Organizational Code

List Prefix for bibs from SFX or other management system

Do you use internal system numbers in Linked Entry fields?

Internal record designation for Linked Entry fields $w

Indicate which 852 subfields to use to determine unique holdings records

Limit exported records by location

Bib Key Prefix

Move 001/003 to 035 or 935

Add institution suffix to Bib ID

Use subfield indicators in item call number (AltCallNo)

Add $9 LOCAL to specified tags

Alma Library Tab

Alma Location Tab

ALMAME_VALUE_NOT_FOUND

Alma Location Name and Alma External Location Name

Collapsing Locations

Shelving Scheme Tab

Item Type Tab

Item Base Status Tab

Further Information

Determining Groups of Holding Records

Changing the Holdings Record Grouping

Item Barcodes

Material Type

Fulfillment/Patrons

Patrons

Borrower Burb file

User Identifiers

User Preferred Address

User Statistical Categories

Notes

Active Loans

Fines and Fees (Burb file)

Active Requests

Customer Input

Questionnaire Tab

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

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

How should we handle duplicate identifiers in the same patron?

Currency for patron fines

Merge Patron Prefix

User Group Tab

User Language Tab

Campus Code Tab

User Block Tab

User Stat Categories Tab

Fine Fee Type Tab

Further Explanation – Fulfillment/Patrons

Internal/External Patrons

Identification Numbers

Acquisitions

Vendors

Orders

Funds

Customer Input

Questionnaire Tab

Migrate Acquisitions

Central Order Library

Default Order Library

Default currency for Ledgers/Funds

Default language of conversation with vendors