Symphony to Alma Data Delivery and Migration Guide

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

Symphony is the Integrated Library System produced by SirsiDynix.

This document serves two purposes:

A step-by-step guide to filling out the Symphony to Alma Migration Form.
An explanation of fields mapped from Symphony to Alma, which you will do using the Migration File Validation tool.

For specific instructions on how to use the File Validation Tool, see Migration File Validation Tool. The Further Information sections in each functional area below will help explain the functional implications of incoming fields and how they map into Alma.

Recommendations for Using this Guide

This document is divided into four areas:

Inventory
Fulfillment
Acquisitions
Physical to Electronic

Each area has the following sections:

File Validation: Information on files that are expected from Symphony and where incoming fields are mapped in Alma, including functional implications.
Migration Form: Questionnaire Tab – Instructions for individual questions asked on the Questionnaire tab of the Migration Form.
Migration Form: Individual Tabs – Instructions for how to fill out individual tabs on the Migration Form. (Examples: Alma Library Tab, User Group Tab, PO Line Type Tab).

Validate your files exported from Symphony, and map local fields to Alma fields, using the Migration File Validation Tool.

The Migration Form can be filled out by following instructions in the Questionnaire Tab and Individual Tabs sections.

Migration Overview

The procedure for migrating from Sirsi's Symphony ILS to Ex Libris’ Alma consists of the following steps:

Data Files, Migration File Validation Tool

Extract the relevant data elements from Symphony into flat files (customer responsibility).
Validate the extracted flat files using Ex Libris’ Migration File Validation Tool. Depending on the size of the extracts, customer may choose to validate 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 Symphony 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 Symphony.
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 (MFVT) 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 Expected File Formats with the naming conventions as described there.

Migration Form

Complete the Symphony Migration Form prior to the actual delivery of the data. 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.

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.

Additional Manipulation for Order and Invoice Files for Symphony (optional)

In this document, in the order and invoice sections, there are some instructions about extra manipulation that may be needed for orders and invoices (if invoices are being provided). These major areas are:

Order link to bib, a direct link not available in standard Symphony export
Order link to invoice with orderline key (if invoices are being provided)
Invoice export - this is not a standard Symphony export and must be done completely by the customer

For more information on these, see the relevant sections below: Order: Link to Inventory, and Invoices. Also, instructions on these are available from your Ex Libris project manager and can be emailed to you upon request.

Expected File Formats

Expected file formats for Symphony data varies by file. See the descriptions below. Ex Libris expects a certain set of files to be exported from Symphony. We have included the general expected deliveries below. The data elements listed for each are those that Ex Libris expects to use in conversion. Some data elements may exist in Symphony but are not necessary to bring to Alma.

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

For the files listed below that are not bibliographic records with embedded items, we expect an extract using the extracting tools available with Symphony. Invoices, and orders if you are also providing invoices, must be exported using API access to the database.

File Naming Conventions

The following is the default naming convention:

CustomerName+DataType+sequence+date+[.<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 homogenous – 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. For example, do not delimit with quotes and commas for some records and pipes for others within the same file.

Using the Migration Form Validation Tool

The Symphony 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: S upport and Maintenance.

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

Inventory

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 Symphony is UTF-8. If your library must export in a different character encoding, such as pre-Unicode ANSEL because your library is on the pre-Unicode c-ISAM Symphony database, inform your Ex Libris project manager.

Deliver all files with the same character encoding.

There should be a unique and consistent former system number in each bibliographic record. This is typically in the 001 field in Symphony, but it may also be found in the 035 $a with a prefix of (Sirsi) or some other field. Whichever field it is in, it should be unique and should be present for every single record.

If your system number has inconsistencies, make a note of them to your Ex Libris project consultant. For example, you may use a number like '(Sirsi)u12345' in the bibliographic record 035 $a, and administrative extracts may contain the number like '12345'. This is not common, but it can be accommodated if Ex Libris is notified.

All bibliographic records must have a unique former system number, or they will be rejected. Indicate where the former system number is on the Bibliographic tab of the MFVT.

Do not include more than one 001 field in your MARC exports, since the 001 field is not repeatable in standard MARC. Additionally, Ex Libris is aware that Symphony uses more than one type of key to link auxiliary data to the bibliographic record. The former system number in the previous paragraph may be just one of the keys used as a link. For example, the serial record may link to the bibliographic record using the Sirsi key, an ISSN, or a database key, all in the same file. Ex Libris has a method for using multiple access points to determine the linked bibliographic record.

The item records associated with each bibliographic record are expected in a tag in each bibliographic record. See the Items section below for details on what is expected in the item tag.

If you have loaded SFX MARCIt (or another electronic resource management system) records into Symphony, it is recommended that they not be included in the bibliographic record export to avoid unnecessary duplication with records loaded directly from SFX. If you want Ex Libris to detect and not migrate the SFX records, ensure that a 035 |a field with (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 Symphony Migration Form.

Export hints

If you are having problems exporting all bib records, here are some hints based on feedback from previous customers who migrated from Symphony.

When creating a report, use the 'Extract keys for export MARC' report. You may use filtering in the Report section to not include certain records that you wish to not migrate, but if filtering is causing too many records to not be included, then one option may to export all records. Then, later you can use the SFX_PREFIX questionnaire question to exclude bib records instead.

After creating the report, there are two options for retrieving the records (compilation). You can either export to the client on your PC using a tool called 'MARC Utilities', or you can export to the server. Some customers are restricted from accessing the server, so the client is the safest route. However, very large files may not be able to be downloaded and so server export may be necessary, which may also require interaction with Symphony support if server access is not allowed.

Additions to the bib record

Bibliographic records are migrated as is and each bibliographic record may be marked with Alma management tags in the following way during migration:

Contents of any 001 field are moved to and 035 along with the corresponding 003.

Customers migrating to an NZ may wish to review the Extraneous Identifiers section of the Consortia Migration document to be aware of how the 001/003 moving to 035 may affect matching
Australian customers have ALL Bibs 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.

Suppressed/Shadowed Records

In Alma, bibliographic records can be set to be suppressed in the OPAC. Similarly in Symphony, records not shown in the OPAC are called shadowed. Provide the suppressed bibliographic records in a separate MARC file, similar to the bibliographic record file for normal records. In Symphony, these are called shadowed records, and in Alma they are suppressed from external view.

The suppressed/shadowed records are loaded to Alma like a regular MARC record, only with the suppressed flag set. As such, the record should be in valid MARC format and also should have a bibliographic record key (former system number - usually in the 001) like a normal MARC record. Records without a bibliographic record key will be rejected.

Bibs with a very large number of items

When a bib record has a very large number of item records, and since in Symphony the items are embedded in the bib, this can make the bib record too large to handle according to MARC standards. In this case, Symphony extracts multiple versions of the record, one after another, with the maximum allowed items in each record. For example the first copy of the bib might contain items 1-100, the second might contain 101-124, the third copy 125-201. The bib is exactly duplicated each time. The migration programs handle this situation, as long as the group of bibs is contiguous and in the same file. If the bib group is split across files, we cannot determine the group and the bibs in the second file are in danger of rejection since would find a 'duplicate' bib key.

Boundwith Records

Some Symphony sites manage bibliographic/item boundwith relationships (outside of the standard 76X-78X Marc linking field linking capabilities) where a single item is associated with multiple bibliographic records. The Symphony exported file format expected for that optional file is:

<item_barcode>,<Catkey>

For example:

338191-1001,4738

338191-1001,8666

338191-1001,55288

338191-1001,60993

338191-1001,185390

338191-1001,338193

100829,305428

100829,305986

100829,322523

100829,328191

Alma supports boundwiths by using standard bibliographic record relationships defined by Marc 21 linking fields. The migration process associates the shared item with a parent bibliographic record and creates links to the secondary bibliographic records via the standard 774 linking field.

On migration to Alma, the first bibliographic record attached to an item gets new 774 tags that link to all of the secondary bibliographic records attached to the same item. The secondary bibliographic records are not modified on migration.

Serial Control Records and Issues

Symphony manages serial issues through a master serial control record and associated checkin records or issues. The serial control record contains higher-level subscription information, and the issues contain individual receipt history.

On migration, the serial control record is either attached to an existing MARC holding record, or a new MARC holding record is created if no match is found.

Serial control records are matched to MARC holdings records using the 852_SUBFIELDS_FOR_HOL match string, usually either bc or bch (see following sections for more explanation of the match).

The information from the serial control record is mapped as follows:

HOLDING_CODE -> 852 $b (Library)

HOLDING_CODE -> 852 $c (Location)

BASE_CALLNUM -> 852 $h (call number)

other fields -> 852 $x (notes)

Issue/checkin records from Symphony are migrated to item records in Alma. The Symphony issue/checkin record maps as follows:

SERC_ID -> used to link issues to the holding record associated with the serial control record. There is no bib record key in the issue/checkin record, so this is the only way to link issues to holdings and thereafter bibs.

PRED_LIBRARY -> used to distinguish between multiple serial control records if necessary

PRED_NAME and PRED_NUMERATION -> item description field in Alma

SERC_ID and PRED_ISSUE_ID_S -> newly-created item barcode, as <SERC_ID>-iss-<PRED_ISSUE_ID_S> (example: 12345-iss-31)

Holding Records

Alma requires MARC Holdings records. There are multiple options for delivering holdings records from Symphony:

MARC Holdings – records are delivered in MARC format, for serial information. Holdings will be generated for any item records with no related MARC holdings.
Non-MARC Holdings – records are delivered in CSV format (text, comma delimited). Summary statements and comments are provided in individual fields. In this case, fill in the fields in the MFVT with information on the non-MARC holdings file.
From Bib – Summary statement embedded in a bib tag.
None – no holdings records are delivered. In this case, holdings records are generated from item information.

When delivering MARC Holdings records from Symphony, be sure to export the records using the option to include bibliographic control numbers in the holding record. Use the Export Symphony catalog key to Marc tag = 004 option.

On migration, Ex Libris removes the contents of the 852 $a in MARC holdings records. If you want to preserve the information in the 852 $a, move it to a separate subfield prior to delivery for migration.

If multiple 852 fields exist in a MARC holding record, the first 852 field is used and the subsequent fields are changed to 952. If a single 852 tag has multiple $b (library) and/or $c (location) subfields, only the first instances of those two subfields are used and the extra $b and $c are moved to $v and $w.

If MARC holdings and non-MARC holdings (serial holdings) are provided at the same time, the migration programs attempt to match them by comparing the library and location of the two records. If the location matches, information from the two records are merged into a single record.

Determining Groups of Holding Records

Symphony extracts provide Bibs and items, but not holdings. Holdings are mandatory in Alma, and, therefore are created based on the item data. The permanent location and call number in Alma is only stored in the holding record. All items attached to the generated 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 holding record. If there are any call numbers that differ from the holding record’s call number, the differing call number is stored in the item’s Item Call Number field.

Changing the Holding 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 Symphony, described in the Library, Location and Call Number sections above, are: $b Location $c Collection $h Call Number. By default, the migration programs compare $b and $c, but you can decide to change this based on how you have cataloged items in your collection.

When the holding 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 .M4

item 2 $b main $c stacks $h PN 567 .M457

item 3 $b main $c stacks $h PN 567 .M457

item 4 $b bio $c flr1 $h PN 567 $i .M457

When only $b and $c are used to determine a holding record group, two holding records for the above items are created:

Holding 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)

Holding record $b bio $c flr1 $h PN 567 $i .M457

item 4

When the holding record group is based on more subfields, for example $b $c $h, three holding records are created:

Holding record $b main $c stacks $h PN 567 .M4

item 1

Holding record $b main $c stacks $h PN 567 $i .M457

item 2

item 3

Holding record $b bio $c flr1 $h PN 567 $i .M457

item 4

Decide which 852 subfields will be used to determine holding record groups by answering the question in the Questionnaire tab of the Symphony Migration Form, “Indicate which 852 subfields to use to determine unique holding records”.

Attaching Items to Existing Holding Records

The algorithm described above to determine groups of items for generating new holdings records is also used to determine if an item should be attached to an existing MARC holdings record. The question Indicate which 852 subfields to use to determine unique holding records from the Questionnaire tab of the Symphony Migration Form is used here as well.

For example, consider the following records from Symphony:

Holding record A: $b PER $c MFORM $h PN 567 $i .M4

Holding record B: $b PER $c CURRENT $h Shelved by title

item 1: PER,MFORM PN 567 .M4

item 2: PER,MFORM PN 567 .M4 2010

item 3: PER,MFORM PN 567 .M4 2011

item 4: PER,CURRENT PN 567 .M457 2012

When only location (852 $b $c) is used to determine unique holding records, the following is the resulting structure in Alma:

Holding record A: $b PER $c MFORM $h PN 567 $i .M4

item 1 (ItemCallNo is empty because the call number matches)

item 2 (with PN 567 .M4 2010 in ItemCallNo)

item 3 (with PN 567 .M4 2011 in ItemCallNo)

Holding record B: $b PER $c CURRENT $h Shelved by title

item 4 (with PN 567 .M457 2012 in ItemCallNo)

When the entire call number (852 $b $c $h $i $k) is used to determine unique holding records, multiple additional holding records are created in Alma:

Holding record A: $b PER $c MFORM $h PN 567 $i .M4

item 1

*Holding record B: $b PER $c MFORM $h PN 567 $i .M4 2010

item 2

*Holding record C: $b PER $c MFORM $h PN 567 $i .M4 2011

item 3

Holding record D: $b PER $c CURRENT $h Shelved by title

*Holding record E: $b PER $c MFORM $h PN 567 $i .M4 2012

item 4

The holdings records with the asterisk (B, C, and E) are created new because the entire call number string of the item did not match the entire call number string of any of the existing holdings records.

Non-Marc Holdings (rarely used)

There may be rare cases where the library can provide summary statement information in a separate text file. This is not common: most customers either provide holdings in MARC format, or they provide it with the Serial Control Record.

If you wish to provide summary statements in a separate file that is generated outside of Symphony, provide the text file in csv format with the fields described below.

Expected Field Name	Local Field Name	Notes
BIB_KEY		Links to bib record
LIBRARY		Use “Alma location” map
LOCATION		Use “Alma location” map
CALL_NUMBER
SUMMARY_STATEMENT		Will be placed in 866 of generated holdings record

Holdings From a Bib Tag

If there is information in a field embedded in the bibliographic record, the migration programs can generate a holdings record from it. Fill in the values of the following fields in Holdings section of the MFVT. If the SUMM_LIB_CODE and SUMM_LOC_CODE match an existing holdings record on the same bibliographic record, even a holdings record that was generated from items attached to the same holdings record, then the summary holdings statement will be attached to that holdings record, regardless of the 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 holdings record on the bibliographic record with the same location, a new holding record is 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

Item information is expected to be provided in tags embedded in the bibliographic record, typically in the 999. Indicate which tag contains the item in the Migration File Validation Tool.

The following table lists the expected subfields for item migration. If your item subfields have different contents, indicate the subfield mapping in the Items section of the Migration File Validation Tool.

The maps that are indicated in the Notes column below are found in Symphony Migration Guide. See the accompanying Symphony Migration Guide for instructions on how to complete this form.

Expected Field Name	Expected Subfield	Notes
Call Number	\|a
Volume Number	\|v	see Volume Information section below. This string is placed in the item's Description field, and is normally like 'Vol. 12 No. 5, May 2020'.
Class Scheme	\|w	use “Call Number Type” map
Copy Number	\|c
Barcode Number	\|i
Library	\|m	use "Alma Location" map
Last Activity mm/dd/yyyy	\|d	placed in item Update Date
Date of last loan return	\|e	Last date YYYYMMDD of the last loan return for the item. To see this value in Alma, search for the item under 'Physical Items' and on the results list click 'Other details'.
Number of Pieces	\|j	maps to PIECES field
Current Location	\|k	use "item base status" map
Home Location	\|l	use "Alma Location" map
Number of loans	\|n	Number of loans for the item. 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.
Number of in house loans	\|q	Number of in-house loans for the item. To see this value in Alma, search for the item under 'Physical Items' and on the results list click 'Other details'.
Item Type	\|t	use "Item Type" map
Acquisitions Date	\|u	maps to Arrival Date
Provenance	\|x
Material Type	\|y	See Material Types section below Note: it is possible to have the material type in any incoming subfield, such as \|x or \|z. However, we must define a default subfield for the Migration File Data Validator (field mapping). So, wherever your incoming Material Type is, map it to \|y in the tool.
Price	\|p	Inventory Price
REPLACEMENT_COST	\|p	Use only if this is an actual replacement cost. If not, put only in the Inventory price field above.
Inventory Number	\|o.NUM_INV
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.

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. The subfields listed in the Default Local Subfield column are those that are expected by Ex Libris. If you use other field names or have subfields that you want to include in the migration, but are not expected by Ex Libris, you can rearrange them using the Migration File Validation Tool. The text in the Note Label column are used as a prefix to the subfield contents and can be modified, as desired.

Note Name	Default Local Subfield	Note Label
PUBLIC NOTE
FULFILMENT_NOTE	\|r	Circulate Flag
FULFILMENT_NOTE	\|o.PUBLIC.
NON_PUBLIC_NOTE_1	\|o	Item Notes or Comments
NON_PUBLIC_NOTE_1	\|o.CIRCNOTE.
NON_PUBLIC_NOTE_1	\|h	Holding Code
NON_PUBLIC_NOTE_2	\|f	Date Inventoried
NON_PUBLIC_NOTE_2	\|g	Times Inventoried
NON_PUBLIC_NOTE_3	\|e	Date Last Charged
NON_PUBLIC_NOTE_3	\|n	Total Charges
STAT_NOTE_1	\|q	In House Charges
STAT_NOTE_2	\|x
STAT_NOTE_3	\|z

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.

Special note prefixes

Some subfields have a code at the beginning of the note

Example:
|o .PUBLIC this note shows to the public
|o .CIRCNOTE this note is a fulfillment popup note
|o .STAFF this note is internal for staff only

In order for the migration tool to handle these different note types, we treat them as different subfields. That is, the migration tool thinks we have the following subfields:

|o.PUBLIC.

|o.STAFF.

|o.CIRCNOTE.

In the migration validation tool, these separate 'subfields' are detected, and presented as options for migrating. If the validation tool detects a 'subfield', it must be mapped, even if you want it to go to the same note as the subfield without any label. If you choose 'Do not migrate' for one of these, for example the O.STAFF. line, then these notes will not be migrated - they will NOT be included in the general 'O' subfield.

Item Barcodes

While Symphony allows item barcodes to be duplicated, Alma does not. The item barcode must be unique in Alma, although it may be left blank.

The item barcode is migrated according to the following rules:

If the barcode is empty, leave as empty in Alma.
If the barcode exists but is not unique:
- First item barcode encountered – migrate as is.
- Second and subsequent item barcodes encountered – migrate as <barcode>-<item_key>.

Serial issues are given a barcode based on the serial control number (SERC_ID) and the issue number (PRED_ISSUE_ID_S). Serial issue barcodes are not required in Alma, but if a serial issue goes on loan or is requested, it is required. Therefore, migration creates a unique barcode, just in case.

Material Types

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.

If not provided in the extract, 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.

Optionally provide a valid Alma item material type code based on information in Symphony. This is not part of the Symphony extract and requires additional manipulation of the file before submission to Ex Libris. Valid values are listed in the table below. The material type and item subfield |y are not Symphony standard; however, customers may place a value in this field for use as a material type that can be mapped to an Alma material type.

Not providing this subfield will populate item material type based on Bib fixed fields.

An explanation of material types is found on the following page: Configuring Physical Item Material Type Descriptions. Consult the Alma menu option under Configuration -> Resources -> Physical Material Type Descriptions for a list of Alma material types in use.

Volume Information – Request Special Export from Symphony

We recommend that you request from Symphony a modification to your bib/item export program so that your volume information is exported in a subfield separate from the call number. The earlier you can request this, the better.

In the standard bib/item export, the volume information for an item is included with the call number of the item. In this case, we have call number information like this:

LB 1139.23 .E27 2006 V.1 NO. 11

LB 1139.23 .E27 2006 V.1 NO. 12

LB 1139.23 .E27 2006 V.2 NO. 1

LB 1139.23 .E27 2006 V.2 NO. 2

In the case above, it is not possible to separate the call number 'LB 1139.23 .E27 2006' away from the volume information to create a holding record with that call number.

Previous Symphony customers have requested and purchased a modification to the bib/item export, which separates the volume information out into a separate subfield. In the above case, there were four items with the same call number, but different volumes. After the request was made, those four items became:

Customers who have Symphony API access can perform this task themselves.

The above information is provided as if the bibs came in MARCXML format. If you are providing bibs in MARC format, the difference is more like:

(where 999 is the tag which contains embedded item information)

=999 \\$aLB 1139.23 .E27 2006 V.1 NO. 11$wLC$c2$i002016319$d12/21/2012$f12/21/2012$g2$lSTACKS$mBARRIE$q1$rN$sY$tREF-BOOK$u8/15/1996$xPRINT$zUNKNOWN

vs, after modification

=999 \\$aLB 1139.23 .E27 2006 $v V.1 NO. 11$wLC$c2$i002016319$d12/21/2012$f12/21/2012$g2$lSTACKS$mBARRIE$q1$rN$sY$tREF-BOOK$u8/15/1996$xPRINT$zUNKNOWN

Separating the volume from the call number is especially important when generating holdings records based on item call numbers. If we use the entire call number to generate holding information, we would make one holding with the modified export, and four holdings with the non-modified export.

After the change is made, subfield $a is mapped to call number, and $v is mapped to Volume number, which is in turn placed in the item's Description field, the normal spot for volume-specific text in Alma.

For more explanation on determining holding record grouping, see the Inventory section in the Symphony to Alma Migration Guide.

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

Holdings and Items from Serial Issues

Symphony customers can provide a serial control record and related serial issues files. Ex Libris will generate very brief MARC holding records from the serial control record and items from the serial issues records. If the serial control record matches a provided MARC holding record, based on the library, location, and 852_SUBFIELDS_FOR_HOLDING, then the notes from the serial control record are added to the matched MARC holding.

Serial Control Record

The serial control record contains very brief holding information for a serial. Besides the location and call number information, other fields from the serial control record are placed in notes. All serial control records are processed the same, there is no checking for active or inactive status.

Provide the serial file in field block format as a Symphony extract that uses API access. The field block format has one field per line, with the beginning and end of the record delimited by the following line:

*** DOCUMENT BOUNDARY ***

The fields in the following table are expected. Indicate the local field names using the Migration File Validation Tool.

The maps that are indicated in the Notes column below are found in the Symphony Migration Form. See the accompanying Symphony Migration Guide for instructions on how to complete the maps.

Field Name	Notes
SERC_ID	Matches SERC_ID in issue record
SERC_TITLE_KEY	Used to identify bib record; matches various fields in bibliographic record such as 035, 020 and 022
BASE_CALLNUM
CLASS
HOLDING_CODE	Use Holding Code map in Migration Form

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.

Note Name	Explanation
PUBLIC_NOTE	Will be placed in 852 $z of generated or matched holding record
ON_PUBLIC_NOTE	Will be placed in 852 $x of generated or matched holding record

Serial Issues = Items

The serial issue record contains very brief item information for a serial issue. Provide the issue file in field block format as a Symphony extract that uses API access. The field block format has one field per line, with the beginning and end of the record delimited by the following line:

*** DOCUMENT BOUNDARY ***

The fields in the following table are expected. Indicate the local field names using the Migration File Validation Tool.

The maps that are indicated in the Notes column below are found in the Symphony Migration Form. See the accompanying Symphony Migration Guide for instructions on how to complete the maps.

Field Name	Notes
SERC_ID	Used to link to Serial record; from there, a link to the bib will be found. Also, used to generate a barcode <SERC_ID>-iss-<PRED_ISSUE_ID_S> (example: 12345-iss-31)
PRED_ISSUE_ID_S	Used to generate a barcode <SERC_ID>-iss-<PRED_ISSUE_ID_S> (example: 12345-iss-31)
PRED_NAME	This is placed in the item description field along with PRED_NUMERATION.
PRED_NUMERATION	This is placed in the item description field along with PRED_NAME.
RCPT_DATE
RCPT_DATE_CREATED

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.

Note Name	Explanation
PUBLIC_NOTE
FULFILLMENT_NOTE
ON_PUBLIC_NOTE
STAT_NOTE_1
STAT_NOTE_2
STAT_NOTE_3

Electronic Identification (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 Symphony bibliographic system numbers that represent electronic resources and an indication if these electronic resources are portfolio 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 Symphony 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.

Inventory - Migration Form

Alma uses bibliographic, holding, and item records. Symphony has bibliographic and item records, and depending on the installed features of the local Symphony system, may provide MARC holding records. In cases where Symphony does not provide MARC holding records, they are created during migration, based on information in the Symphony item record and possibly the serial issue record.

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 former system number field (Symphony bibliographic system number) to the 035 $a field:

(MOC)<Symphony 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

The Symphony former system number can be in the 001 field or the 035 $a with a prefix of (Sirsi). Customers should specify where the former system number is in the Migration File Validation Tool.

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 Symphony catalog contains records imported from SFX or another electronic resources 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 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 Symphony 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 holding 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/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 holding record, specify additional call number subfields. Acceptable subfields are: 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 Holding 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. Bib records without any location information (standalone bibs) are included.

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

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.

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 Symphony library is in the item subfield |m, which is the higher level of location, and is comparable to the Alma library. Use the Alma Libraries tab in the Symphony Migration Form to indicate your list of Alma libraries. The actual mapping from the Symphony library to the Alma library is done in conjunction with the home location (|l) 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 Symphony libraries and home locations 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.

Symphony Library (999|m): Value from the Library field in the item extract or the 852$b in the MARC holdings extract from Symphony. The ALMAME_VAL_NOT_FOUND line is required to catch any location codes you may have missed.

Symphony Home Location (|l): Value from the HOME_LOCATION field in the item extract or the 852 $c in the MARC holdings extract from Symphony. Additionally, for libraries that are migrating serial control records and issues, include the HOLDING_CODE values. See the Serial Migration explanation below.

Alma Library Code: The library that contains this library/location combination in Alma. You can use the same library codes that you used in Symphony, but it is not required. 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 Symphony, but this is not required. You may also use this form to collapse locations if desired, for example refa and refb in Symphony 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 holding record itself, we use this as a default for all items in the location.

The migration does not replace indicators for any incoming MARC holding records

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 the Physical to Electronic (P2E) Processing section 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 Symphony code to an easily identifiable code such as XXX or unused just in case any stray items are still in your Symphony database.

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 holding 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.

Symphony Library Code	Symphony Home Location	Alma Library Code	Alma Location Code	Alma Location Desc	Alma External Loc Desc	Suppress from Externalization
ALMA_ME_ 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

The following is not acceptable:

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

This mapping table can be used to collapse location codes – that is, two or more location codes in Symphony 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 Symphony code to an easily identifiable code such as XXX if any stray items are still in your Symphony database.

If you collapse location codes, you may have lines in the table such as the following:

Symphony Location Code	Alma Library	Alma Location Code	Alma Location Name	Alma External Loc Name	Suppress from Externalization	Electronic Location
reserves	MAIN	RESERVES	Reserves	Reserve	Yes	No
reservesElec	MAIN	RESERVES	Reserves	*ReserveElec*	Yes	*Yes*
reservesShort	MAIN	RESERVES	Reserves	Reserve	Yes	No
reservesPerm	MAIN	RESERVES	Reserves	Reserve	Yes	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.

Holding Code Tab

Use this tab to map the Symphony HOLDING_CODE to Symphony Library and Home Location values.

HOLDING_CODE: Symphony holding code found in the serial control, issue, and order records

Description: Description of the Symphony holding code, not used in the migration programs

Symphony Library code: Used as input to the Alma Location Tab

Symphony Home Location code: Used as input to the Alma Location Tab

Further Information: The HOLDING_CODE in Symphony is used in the subscription and the order to indicate the eventual physical location of an order/subscription. When item records are made in Alma from the Symphony issue record, the HOLDING_CODE is used to assign the library and location in the Alma item record. Additionally, the holding (destination) library and location for the order record is assigned using the HOLDING_CODE map.

The input to this map is the Symphony HOLDING_CODE. The output from this map is Symphony Library and Home location, which is used as input to the Alma Location tab. DO NOT use Alma codes as the output to this map.

Additionally, the SERC_LIB in the serial control record is not used to determine the item’s destination location – only the HOLDING_CODE is used for that. The SERC_LIB indicates the ordering library for the order.

Shelving Scheme Tab

Alma will generate a first indicator for the 852 based on the Shelving Scheme tab.

SHELVING_SCHEME: The values in the Shelving Scheme tab as delivered in the extract from Symphony. The commonly used values are included in the tab, but you can make additions or changes as necessary.

852 1st Indicator: List the value that should be used in the 852 first indicator field when generating a holding 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 Symphony Migration Form.

The migration programs do not correct/update the indicators on an existing/incoming MARC holding record.

Item Type Tab

Use this tab to migrate the Symphony 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.

Symphony Item Type (999 |t): The value in the item type field of the Symphony item. The item type is used to differentiate between items when determining how items circulate.

Symphony Description: The description of the Symphony 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 Current Location in Symphony to an item status in Alma.

Symphony Current Location (999 |k): The current location in Symphony. In Symphony, this indicates both a status (at bindery, missing) and a temporary location (New Book Shelf). List all current locations in this tab.

Description: A short description of the current location in Symphony, which will be written to Internal Note 1.

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: The Symphony current location field consists of two different concepts in Alma: a processing status and a temporary location. The processing status is when an item may be in binding, in repair, or internally being handled by a specific library department. The temporary location is when the item is not at its normal shelf location and is being held elsewhere temporarily (such as the new books shelf or on reserve). Alma also has a process type that indicates the status of an item depending on the Alma workflow (item is on loan, item is on shelf for request pickup, etc.), but the process type is dependent on the corresponding Alma workflow, so do not include process types for loaned or requested items.

For migration, all item statuses that are indicated as not on the shelf (0) from Symphony 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.

If you want the temporary locations (such as new book shelf or reserve) to be changed to actual temporary locations in Alma after migration, you can search for values in Internal Note 1 and then move the items to the appropriate location. Alternately, the search may be used to move an item to a specific department, or the list can be used as a configurable criterion for suppressing items from display in the GetIt services screens in discovery systems. See Appendix A – Post-Migration Process Statuses for more information.

Material Type Tab

Use this tab to migrate the Symphony Material type (|y) to the Alma Material type. The material type and item subfield |y are not Symphony standard; however, customers may place a value in this field for use as a material type that can be mapped to an Alma material type.

Symphony Material Type (|y): The value in the material type field of the item coming from Symphony.

Material type Description: The description of the Symphony material type, for information only. This column is not used during the mapping process.

Alma Material Type: The Alma value for the material type. Material types in Alma are fixed. You cannot add any new types to the list. Select the appropriate material type from the drop-down list.

If this field is not provided in the extract, Alma migration assigns the item material type based on the fixed fields in the bib as described in section Material Type section above.

Fulfillment (Patrons and Circulation)

Patrons

Extract all patrons. In order to migrate any area of fulfillment (fines/ fees, loans, requests), all patrons must be migrated.

Provide the patron file in field block format as a Symphony extract that uses API access. The field block format has one field per line, with the beginning and end of the record delimited by the following line:

*** DOCUMENT BOUNDARY ***

The fields in the following table are expected. Indicate the local field names using the Migration File Validation Tool.

Optionally, add a new field at the end of each patron record called INTERNAL_EXTERNAL with one of two values: INTERNAL or EXTERNAL. This field indicates if the patron is managed internally by the library (for example, community borrowers) or externally (for example, students in the bursar’s system). If this field is not provided, indicate whether or not the patron is Internal or External on the User Group tab of the Symphony Migration Form.

Field Name	Notes
PREFERRED_ADDR	In the 'Expected Field' column, select PREFERRED_ADDR, and then in the 'Extra Data' column, select the address which should be marked preferred in Alma.
PREFERRED_EMAIL	In the 'Expected Field' column, select PREFERRED_EMAIL, and then in the 'Extra Data' column, select the email which should be marked preferred in Alma.
PREFERRED_PHONE	In the 'Expected Field' column, select PREFERRED_PHONE, and then in the 'Extra Data' column, select the phone which should be marked preferred in Alma.
USER_ID	This maps to an internal field which stores the original ID of the patron, used to match against loans and fines and blocks. If you wish to use this as an Identifier, then you should ALSO map it to a user identifier field such as UNIV_ID or BAR (barcode). To map to two fields, use the plus sign (+) to the left of the incoming field name. The validator tool will warn you that there are duplicate identifiers in the same patron, which is not allowed for 'regular' idenitfiers. Since this is just a warning, it is fine to ignore the warnings.
USER_TITLE
USER_FIRST_NAME
USER_MIDDLE_NAME
USER_LAST_NAME
USER_PREFERRED_NAME
USER_LIBRARY
USER_PROFILE	use "User Group" map
USER_STATUS	use "User Block" map. if using the external Block File, then do not use this field. Use either USER_STATUS here, or use the Block file, but not both.
USER_ROUTING_FLAG
USER_PRIV_GRANTED	date not repeatable
USER_PRIV_EXPIRES	External users may have an empty expiration date. For internal users, migration sets a migration date (migration date + 1 year) if one is not present.
USER_BIRTH_DATE
USER_PREF_LANG
DAYPHONE
USER_ADDR1.LINE
USER_ADDR1.LINE1
USER_ADDR1.LINE2
USER_ADDR1.LINE3
USER_ADDR1.LINE4
USER_ADDR1.POSTALCODE
USER_ADDR1.EMAIL
USER_ADDR1.DAYPHONE
USER_ADDR1.PHONE
USER_ADDR1.FAX
USER_ADDR2.LINE
USER_ADDR2.LINE1
USER_ADDR2.LINE2
USER_ADDR2.LINE3
USER_ADDR2.LINE4
USER_ADDR2.POSTALCODE
USER_ADDR2.EMAIL
USER_ADDR2.PHONE
USER_ADDR2.DAYPHONE
USER_ADDR2.FAX
USER_ADDR3.EMAIL
USER_ADDR3.LINE
USER_ADDR3.PHONE
USER_ADDR3.POSTALCODE
INTERNAL_EXTERNAL	optional; this will be used to determine a patron's internal or external status. If this field is not present, then migration will consult the User Group tab, Internal? column.

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 Symphony patron extract, containing either “INTERNAL” or “EXTERNAL”.
Identify patrons as internal or external by user group on the Symphony Migration Form, User Group tab, Internal? Yes or No column. For example: all faculty are EXTERNAL and all community borrowers are INTERNAL.

If both methods are provided, the INTERAL_EXTERNAL field is preferred.

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.

The following appears in the Symphony Data Delivery Form:

##User Identifiers: values in column A are the expect Symphony field names; values in column B are your local field names. Values in column C are values to use when choosing a username in the Symphony Migration Form.##
USER_ALT_ID	UNIV_ID
USER_ID	BAR
USER_WEB_AUTH	ADDL_ID_1
USER_XINFO.INACTVID	ADDL_ID_2
USER_XINFO.PREV_ID	ADDL_ID_3
USER_XINFO.PREV_ID2	ADDL_ID_4

So, for example, if you want the USER_WEB_AUTH to be used for the primary ID for your users in Alma, select ‘ADDL_ID_1’ for the primary ID question on the Questionnaire tab of the Symphony Migration Form.

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 internal or external patrons in the Questionnaire tab of the Symphony Migration Form.

Block File

The block file is not required, but some customers may provide it.

Expected Field Name	Notes
USER_ID	Links to User ID in patron file
ITEM_ID	Links to item barcode in item
REASON	Use in "User Block" map on migration form
LIBRARY	If you want this in the block note, assign it to NOTE in the migration file validation tool, otherwise select 'Don't Migrate'
UNITS	If you want this in the block note, assign it to NOTE in the migration file validation tool, otherwise select 'Don't Migrate'
END_DATE	Placed in Block Expiry Date
CREATE_DATE	If you want this in the block note, assign it to NOTE in the migration file validation tool, otherwise select 'Don't Migrate'
NOTE	If you want this in the block note, assign it to NOTE in the migration file validation tool, otherwise select 'Don't Migrate'

User Addresses

There can be several addresses, emails, and phone numbers in the patron record. The fields that are available for migration into Alma are listed in the left column. The values in the left column cannot be changed. The field names from your Symphony extract are in the middle column.

Decide which address is preferred and in the right column, the type of address. For example, you may decide that Address 2 is the mailing address, that Address 1 is home, that Address 2 is work, and so on.

Alma Address Field	Symphony Field Name	Preference and Type selection
Preferred Address Selection	Select preferred:	USER_ADDR1
USER_ADDR1	Select type:	select an address type for all address 1 lines here
USER_ADDR1	home, work, school, alternative	(leave blank)
etc		(leave blank)
USER_ADDR2	Select type:	select an address type for all address 2 lines here
USER_ADDR2	home, work, school, alternative	(leave blank)
etc		(leave blank)
USER_ADDR3	Select type:	select an address type for all address 3 lines here
USER_ADDR3	home, work, school, alternative	(leave blank)
etc		(leave blank)
Emails: Select type for each	Select Preferred email:	Which is the preferred email out of all emails?
USER_ADDR1.EMAIL	personal, work, school, ccAddress	For this particular email, which type should it be?
etc		For this particular email, which type should it be?
Phones: Select type for each	Select Preferred phone:	Which is the preferred phone out of all phones?
USER_ADDR1.PHONE	home, mobile, office, officeFax	For this particular phone, which type should it be?
USER_ADDR1.DAYPHONE		For this particular phone, which type should it be?

User Identifiers

There may 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. The typical expected field names from Symphony are in the right column. Change the field names and/or order of the right 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 Symphony Migration Form. If there is a field in Symphony which contains a note specific to the identifier, place that in the far right column.

Alma Identifier Type	Symphony Field Name	Symphony Field Name for Note
UNIV_ID	USER_ALT_ID
BAR	USER_ID
ADDL_ID_1	USER_WEB_AUTH
ADDL_ID_2	USER_XINFO.INACTVID
ADDL_ID_3	USER_XINFO.PREV_ID
ADDL_ID_4	USER_XINFO.PREV_ID2

User Statistical Categories

There may be a number of fields in the patron record 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 P TYPE, but you may want to track the department, so that you can get more detailed statistics on how Law students borrow, for example. Since Symphony has a large number of fields that are customizable, 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	HOME INST	INST:
USER_STAT_CATEGORY	DEPT	DEPT:
USER_STAT_CATEGORY	SCHOOL	SCHOOL:

You can add up to 10 incoming fields. To map the values, use the UserStatCategories map in the Symphony Migration Form. If a value is not found in the map, it is migrated as is. You may provide a label if needed/required, for example if you have two different cateogries and they have the same value, for example DEPT: LAW and DEGREE: LAW. The migration program does not provide a colon so include it in your label if you want it. 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.

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.

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 to User Viewable by the migration programs. This is the only note which migration marks as user viewable.

Active Loans

Extract only current circulation transactions. Completed (checked-in) loan transactions are not included in the migration to Alma.

Provide the loan file in field block format as a Symphony extract that uses API access. The field block format has one field per line, with the beginning and end of the record will look something like this:

*** DOCUMENT BOUNDARY ***

FORM=LDCHARGE

.USER_ID. |ablahblah

.CALL_ITEMNUM. |aPQ4406 .H6

.ITEM_ID. |a0201900094719

.ITEM_COPYNUM. |a1

.CHRG_DC. |a20161104

.CHRG_LIBRARY. |aLRC

.CHRG_DATEDUE. |a20170106

*** DOCUMENT BOUNDARY ***

FORM=LDCHARGE

.USER_ID. |a0000

.CALL_ITEMNUM. |aQL713.2 .R53

.ITEM_ID. |a0202000477622

.ITEM_COPYNUM. |a1

.CHRG_DC. |a20181016

.CHRG_LIBRARY. |aLRC

.CHRG_DATEDUE. |a20181030

If your library uses loan transactions to track item statuses in addition to an item status on the item record, exclude those loans from the extract. For example, if an item is lost, it may be checked out to a patron called LOST and also have a current location (item status) of Lost in the item record. Additionally, items checked out to INTRANSIT patrons should be eliminated from the loan extract. The fields in the following table are expected. Indicate the local field names using the Migration File Validation Tool.

Field Name	Notes
ITEM_ID	matches barcode \|i in bib/item file
CHARGE_DATE
DUE_DATE	Note: When a loan due date in Symphony is NEVER, the due date in Alma is set to one year from the conversion date.
RENEWAL_DATE	NOTE: this is not commonly included in the loan export. If you want the renewal date included, check with Symphony support.
LIBRARY
USER_ID	matches USER_ID in patrons
NUM_OVERDUE_NOTICES	When >= 4 then this loan is declared LOST; if you want to also keep the original number, put also in a note
NUM_RENEWALS	Only checking for > 0; if you want the original number, put also in a note NOTE: this is not commonly included in the loan export. If you want the renewal date included, check with Symphony support.
NUM_RECALLS	Only checking for > 0; if you want the original number, put also in a note
CLAIMED_RETURNED_DATE	If this date has value, then a loan status of "Claimed Returned" is set. If you also wish to retain the actual date, put it in a note.

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.

Note Name	Default Local Fields
NON_PUBLIC_NOTE	LAST_NOTICE_DATE
NON_PUBLIC_NOTE	CLAIMED_RETURNED_DATE
NON_PUBLIC_NOTE	NUM_OVERDUE_NOTICES
NON_PUBLIC_NOTE	NUM_RENEWALS

Fines and Fees (Bills)

Extract only current bills, or fines and fees as they are called in Alma.

Provide the bills file in field block format as a Symphony extract that uses API access. The field block format has one field per line, with the beginning and end of the record delimited by the following line:

*** DOCUMENT BOUNDARY ***

The fields in the following table are expected. Indicate the local field names using the Migration File Validation Tool.

Field Name	Notes
ITEM_ID	matches barcode \|i in bib/item file
BILL_AMOUNT	outstanding balance
BILL_REASON	use in fine fee type map in migration form
BILL_DATE	date fine was created (if return date empty)
RETURN_DATE	date fine was created
BILL_LIBRARY	this value will be sent through the location map
USER_ID	matches USER_ID in patrons

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.

Note Name	Default Local Fields
FINE_FEE_COMMENT	AMOUNT
FINE_FEE_COMMENT	DUE_DATE
FINE_FEE_COMMENT	CHARGE_DATE

Active Requests on the Hold Shelf

Extract only request transactions where the item is trapped and on the hold shelf waiting for pickup. Provide the request files in one of two ways: in field block format as a Symphony extract that uses API access, or in csv format. The fields in the following table are expected in both cases. Indicate the local field names using the Migration File Validation Tool.

Field Name	Notes
ITEM_ID	matches barcode \|i in bib/item file
ITEM_LIBRARY
DATE
EXPIRY_DATE	if not present then migration will use migration date + 30
USER_ID	matches USER_ID in patrons
HOLD_PICKUP_LIBRARY

Any additional fields not listed above may be put into notes. T

Note Name	Default Local Fields
NON_PUBLIC_NOTE	(none)

Course Reserves

Courses are considered unique by the combination of Course and Reserve Desk. Multiple lines in the csv file may be provided with the same Course and Reserve Desk but with different items. All of the items for the same Course and Reserve Desk will be combined into a single reading list in Alma.

Extract active course reserves. Provide the request files in csv format as a Symphony extract that uses API access. The fields in the following table are expected. Indicate the local field names using the Migration File Validation Tool.

Courses are considered unique by the combination of Course and Reserve Desk. Multiple lines in the extracted csv file may be provided with the same Course and Reserve Desk, but with different items. All of the items for the same Course and Reserve Desk are combined into a single reading list in Alma.

Field Name	Notes
Reserve Desk	Use Course Unit map
Course Start	This is required; if not provided, the migration date is used.
Date Expired	This is required; if not provided, the migration date + 1 year is used.
Course ID
Course Name
Term	use Course Term map
Date Created
Status
Item ID

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. T

Field Name	Notes
COURSE_NOTE	Instructor

Reading List Items -> Bibs

Elements of the reading list in Symphony are stored at the item level so that the individual item record is attached to the reading list. In Alma, the reading list stores information at the bibliographic record level. During migration, we swap the item key with the related bib key, so it looks like titles are on reserve instead of items. As a result, if a reading list contains multiple items from the same bibliographic record, only a single link to the bibliographic record is migrated.

Faculty/Department

The Instructor in Symphony is a free text field to specify the instructor of the course. In Alma, this field is linked to the user record itself so that the instructor of the course is linked to the instructor’s Alma user record. Since there is no way to parse the free text in Instructor, the professor/instructor text is mapped to a note on migration to Alma.

Fulfillment/Patrons - Migration Form

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 acceptable.

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

Code: PATRON_PRIMARYID

Default: UNIV ID

Options: Using the MFVT, map the identifiers exported from Symphony 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.

Use a map for the USER LIBRARY to campus code migration?

Code: CAMPUS_CODE_MAP

Default: No

Options: Select Yes for this option only when you maintain and use different values in the Symphony USER LIBRARY field to distinguish between different user groups for resource sharing activities like ILL borrowing. If you select Yes, fill in the mapping from the USER LIBRARY to the Alma CampusCode field on the Campus Code tab. If you select No, all users are simply considered part of the same group for resource sharing activities.

List any pseudo-patrons which we should ignore in the loans file

Code: IGNORE_PATRONS_FOR_LOANS

Default: none

Options: Pseudo-patrons are used in Symphony in place of item process statuses. List patron codes (USER_ID field) separated by comma, for example: INTRANANNEX,INTRANNEXLAW. Note that you can keep the patron codes for statuses that you want to keep, such as MISSING or LOST. Do not list here the statuses that you want to keep.

Course Reserve to Course Unit Map

Code: COURSE_UNIT_MAP

Default: No

Options: No = do not use the course unit tab to map Symphony UNIT_CODE to an Alma course unit. If the map is not used, then a default Alma COURSE_UNIT is used for all courses migrated to Alma. This is recommended for most libraries that have a simple administrative structure for managing course reserves. Yes = use the course unit tab to map the Symphony UNIT_CODE to an Alma course unit. This is recommended for a small subset of libraries that have multiple administrative units for managing course reserves.

Request Default Destination Library

Code: REQUEST_LIBRARY

Default: None

Options: If the requests file does not contain a destination library/location, the library you enter for this question is used as the default for where patrons will usually pick up requests from the hold shelf. This library code should be in Symphony format, as it is sent through the Alma Location tab map.

Due Date for “NEVER” Loans

Code: NEVER_DUE_DATE

Default: One year from date of conversion

Options: Alma does not allow loans with an indefinite due date. Provide a due date for your loans of type NEVER.

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.

Symphony USER_PROFILE: The Symphony patron type code, found in the USER_PROFILE field of the patron extract.

Symphony Description: A description of the Symphony patron type code, 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 Symphony, or you can use different codes. You can also collapse groups if desired, for example, having Freshman and Sophomore from Symphony 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 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. 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.

Notes/Comments: Add any notes or comments for the Symphony User Profile. This column is not used during migration.

Further Information: See also the following question in the Questionnaire tab, regarding internal and external users:

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

User Language Tab

Symphony stores patron preferred language information in the USER_PREF_LANG field in the patron record. Provide the list of available language codes from Symphony and their description, along with the language code as it should be in Alma. 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.

This mapping table is not mandatory. If fields are left blank, all patrons are assigned the default patron language as defined on the Questionnaire tab (PATRON_LANG).

Symphony USER_PREF_LANG: The Symphony preferred language found in the USER_PREF_LANG field in the patron extract.

Symphony USER_PREF_LANG Description: A description of the Symphony patron preferred language, for informational purposes only. This column is not used in the mapping.

Alma Language Code: The language code desired in Alma.

Alma Language Description: The description of the language. This column is not used by the migration programs.

User Stat Categories Tab

This tab is used to migrate the statistical categories in your patron records (if you have them) to Alma. In Symphony, it is possible to have multiple fields that contain statistical codes, usually named USER_CATEGORY1, USER_CATEGORY2, and USER_CATEGORY3.

Before filling in this tab, specify in the Patrons section of the MFVT which fields from Symphony 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 MFVT 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).

Symphony USER_CATEGORY: List all of the values from all of the fields that you want to put into the statistical category mapping. For example, if you use all three fields of USER_CATEGORY in the list, list all of the values from all fields (up to ten possible fields) in Symphony. Include the label applied if it is important to distinguish between values in different fields.

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

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

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

Further Information: Alma has a Statistical Categories field in the patron record that can be used to retrieve statistics on groups of patrons. Symphony has three different user category fields and Alma has only one.

User Block Tab

SyProvide patron block information in one of two places

- the USER_STATUS field in the patron record

- external Block file

Use one or the other of those block methods, but not both. Examples of Symphony blocks are: BARRED, BLOCKED, or DELINQUENT. Provide the list of available blocks from Symphony and their description, along with the block code as it should be in Alma. This mapping table is not mandatory.

Symphony USER_STATUS: The Symphony patron block code as found in the User Status field in the patron extract. Do not include statuses that indicate the patron is not blocked, such as OK.

Symphony USER_STATUS Description: A description of the Symphony 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 user block type.

When a patron has no blocks in Symphony, the USER_STATUS field has OK in it. Do not include OK in the mapping table. When the patron is OK, there should be no block at all.

Campus Code Tab

Use this tab only if you answered Yes to the question on the Questionnaire tab: Use a map for the HOME LIBR to campus code migration? This mapping is not mandatory if you do not maintain separate patron campuses.

Symphony USER_LIBRARY: The value of the patron home library as found in the HOME_LIBR field of the patron extract.

Symphony USER_LIBRARY Description: A description of the HOME_LIBR 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 1-to-1, or you may use this map to collapse codes if desired.

Alma Campus Code Description: A description of the Alma campusCode, for informational purposes only. This field is not loaded into Alma.

Further Information: The Alma User Campus field is used to determine a patron’s affiliation for ILL or cross-campus borrowing. If your library maintains the HOME_LIBR field in Symphony for a similar purpose, map the HOME_LIBR 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.

Fines and Fees Tab

Symphony BILL_REASON: List all of the values from the BILL_REASON field in the Symphony extract.

Symphony Description: A description of the BILL_REASON, 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 Symphony 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.

Course Unit Tab

Use this tab only if the answer to COURSE_UNIT_MAP (“Map Course Reserve to Course Unit?” is Yes. See the Questionnaire section above for more information.

Symphony UNIT_CODE: List all of the values from the UNIT_CODE field in the Symphony courses extract.

Symphony Description: A description of the UNIT_CODE, for assistance in filling out this form. This column is not used in the mapping routine.

Alma Course Unit: List the Course Unit value for use in Alma.

Further Information: If you do not use this tab, then a default Course Unit will be used for all courses.

Course Term Tab

Use this tab to migrate incoming Course Terms to the list of available course terms in Alma.

Symphony TERM: List all of the values from the TERM field in the Symphony courses extract.

Symphony Description: A description of the Term, for assistance in filling out this form. This column is not used in the mapping routine.

Alma TERM_CODE: Select a Term Code from the dropdown list. The codes cannot be changed, but you can change the descriptions for the codes in Alma later, in the CourseTerms code table.

Further Information: If you do not use this tab, then a default Course Unit will be used for all courses.

Acquisitions

Orders

Historical/Closed Orders

Symphony customers can provide up to 10 years of historical (closed) orders. However, only current open orders (in the current fiscal year) will be linked to funds with an encumbrance transaction. If you provide fund information for closed orders the fund information is placed in a note.

If you provide funds for previous fiscal years, they are only used to make expenditure transactions for invoices.

Linking to Inventory

Alma requires each order record to be linked to inventory. During migration, every attempt is made to identify a bibliographic record or item record that is attached to the order. If no inventory can be identified, the order is rejected/not migrated.

Symphony does not require each order record to be linked to inventory. Therefore, there may be some orders in Symphony that are standalone and are rejected by migration. In Symphony, there may be order records with bibliographic record information, but are not actually cataloged yet. Make sure that all orders have a linked bibliographic record prior to exporting your order files for migration to Alma.

Even when Symphony does have a link to the bibliographic record, sometimes the link is not readily identifiable with the standard order export. Symphony orders export provides identifiers in the order which may link to various tags in the bib, such as ISSN, ISBN, possibly LC number. However, these identifiers have limitations, in that the identifier must be placed in the order by the library staff (this is not always done), and also there may be mismatch problems with duplicate identifiers in bib records or punctuation differences.

Sometimes an order in Symphony is linked to a bib record using the catalog key, which is an internal database number, but the catalog key is not usually a standard field in the order export.

Customers may be able to make a direct link from the order to the bib record using the catalog key, but only using a direct connection to the database, outside of the normal Symphony order extract. For instructions which provide some advice on doing this, contact your Ex Libris project manager who can provide a separate document. If you are able to get the catalog key related to the order line, place it in a field in the order for example called CATALOG_KEY. The order will have two fields: LINE_TITLEID and CATALOG_KEY. However, we don't want to use LINE_TITLEID - we prefer to use CATALOG_KEY. So, in the migration file validation tool where you are allowed to map fields, map CATALOG_KEY to the LINE_TITLEID, instead of using LINE_TITLEID. Placing the CATALOG_KEY in the LINE_TITLEID field using the field mapping will provide a direct link to the bib.

Ex Libris assumes the CATALOG_KEY is in the field you indicate as the bib key in the field mapping form. If this is not the case, that is if CATALOG_KEY links to a different marc field, let your Ex Libris project manager know what the other field is.

When a catalog key is not present, migration attempts to link the order record to bibliographic records using standard identifiers such as ISSN and ISBN. However, there are drawbacks to this since sometimes staff members do not enter the ISSN/ISBN consistently, or the numbers do not match exactly because of extra characters such as parentheses, etc. The best method for assuring your orders have linked inventory is adding the catalog key to the exported order record.

If a bibliographic record can be identified, then the order is migrated. Lack of a bibliographic record is a primary reason for rejection of order records. Lack of a vendor record is another common reason for rejection.

Providing Order Records

Provide order records in field block format as a Symphony extract that uses API access. The field block format has one field per line with the beginning and end of the record delimited by the following line:

*** DOCUMENT BOUNDARY ***

The fields in the following table are expected. Indicate the local field names using the Migration File Validation Tool.

If you will be providing invoices, ORDERLINE_KEY is required to link orders to invoices. See the invoice section below.

Field Name	Notes
ORDR_ID	Purchase order line number must be unique per vendor in Alma. Symphony provides multiple orders with the same order number, each in a different fiscal year. In order to avoid duplication in Alma, the migration engine appends the year to the order number for non-current fiscal years; the current year does not have a year appended. If invoices are provided, then the unique order line number will be ORDERLINE_KEY instead. The unique order number described above (i.e. ORDR_ID + year) is still used as the PO_NUMBER (PO header) when invoices are provided.
ORDR_LIBR
ORDERLINE_KEY	Required if providing invoices (see the Invoices section below)
FISCAL_CYCLE	Migration programs check for current fiscal cycle and accrual accounting cycle in fiscal cycle questions of the migration form.
VEND_ID
ORDR_TYPE
ORDR_DATE_READY
ORDR_DATE_MAILED
ORDR_DATE_CANCEL
ERP_NUMBER
LINE_ITEM_ID
LINE_UNIT_PRICE
LINE_VEND_CURR
LINE_EXCHANGE
LINE_COPIES
LINE_EXTEND_PRICE
LINE_TITLEID	Used to link order to bib; customer may also want to keep this in the POL_ADDL_NUM; put CATALOG_KEY here (using the MFVT) if you are able to export orders with the catalog key
LINE_RENEWAL_DATE
NOTE
HOLDING_CODE
DIST_DATE_RECEIVED	Date checked to determine order status. If you want to keep the original date, also put in note.
FUND segment: These fields are repeatable as a group. Fund segments should be embedded within LINE_ITEM segments.
LINE_FUND_ID
FUND_DATE_PAID
FUND_AMT_PAID
FUND segment ends

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.

Note Name	Default Local Field
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.

Inventory related to Orders: Items, Holdings

After the correct bibliographic record has been identified, orders can further be linked directly to an item or a holding. First, an attempt is made to use direct links specified in the order record, and second, an attempt is made to find a related inventory using intended inventory location.

In Alma, certain orders can have item records associated with them, and other orders can have holding records associated with them. Generally speaking, non-monographic orders are linked to a holding record, and monographic (one time) orders are linked to an item record.

The specific chart for Items vs Holdings is below:

POL_ LINE_TYPE	Link to Holdings	Link to Items
PRINTED_JOURNAL_CO PRINT_CO PRINT_SO_NONMON	Y	N
PRINTED_BOOK_OT PRINT_OT PRINTED_BOOK_SO PRINT_SO	N	Y
OTHER_SERVICES_*	N	N

* Other Services orders are intended to be used for services not related to inventory and are therefore used very rarely.

Order Linked to Appropriate Item or Holding

When an item record is linked to a monographic order in Symphony, the migration programs attempt to link the order record to the linked item record. If multiple orders are linked to a single inventory (item), the first order found will be linked to the inventory. There is no attempt made to select the 'best' order to link to the item at this point, and Alma cannot link inventory directly to multiple orders. The second and subesequent orders is loaded as not linked to inventory but has the intended inventory location in the receiving note.

Orders Linked to Non-Appropriate item or Holding or Not Linked

There maybe cases where an order in Symphony has a linked item but it is not the correct type - i.e. a continuous order cannot be linked to an item. In this case, the migration programs will not link any inventory to the order. Similarly there may be orders in Symphony which are not linked to an item, and are only linked at the bib level. In these cases, the migration program attempts to link orders to existing inventory based on location match, and again only one inventory can be linked to a single order.

When no location match is found, the inventory location is placed in the receiving note.

Linking Orders and the Implication with P2E

Once an order has been linked to inventory, if the inventory will be transformed to electronic later in the migration process by P2E, then linked orders receive first priority for transforming.

Stated another way: during P2E, an inventory record may be transformed to electronic. An order will be transformed to electronic along with the inventory. When selecting the related order that will be transformed, priority is given to an order that is linked directly to the inventory, even if other orders on the same bib and in the same location have more recent status dates or a better status.

Continuous Purchase Orders That Were Invoiced in the Current Fiscal Year

This situation is seen primarily at the end of a fiscal year, just prior to fiscal year rollover. When there is a continuous purchase order in the current fiscal year that has been received and invoiced, there is a potential for there to be double posting of funding amounts.

since the order is considered open/SENT, there will be an encumbrance created for this order
since there is a completed invoice for this order, there will be an expenditure created for this invoice

The encumbrance and the expenditure are on the same fund in the same fiscal year. In Symphony, the invoice and the order are linked and the encumbrance is suppressed from the active amounts. Be aware that this may make the encumbrance amount for certain funds appear higher in Alma than they are in Symphony. This issue is resolved after the encumbrances roll over to the next fiscal year. Until then, customers may want to increase the allowed over-encumbrance percentage for affected funds.

This situation will happen throughout the fiscal year, but is more pronounced at the end of the year after many continuous orders have been received and invoiced. At the beginning of the fiscal year, this situation is not as pronounced, because not very many continuous orders will have been invoiced. If you are migrating around the end/beginning of a fiscal year, you may want to consider rolling over in Symphony prior to migration in order to lessen the effects of this situation.

Orders, Invoices, and Fund Balances

During the migration process, fund transactions are generated for the following:

Open Orders in the current fiscal year (encumbrances)
Invoices in all fiscal years (expenditures)

Notice that encumbrances are not generated for orders in any previous (non-active) fiscal years. Therefore, fund balances in previous (non-active) fiscal years will only reflect invoice transactions (expenditures).

Symphony, on the other hand, shows encumbrances for orders in previous (non-active) fiscal years. This will make the fund balances in Symphony and Alma very different, and customer should be aware of this when checking their data.

Transactions of Amount 0.00

Symphony 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.

PO Entry Point (Status)

The following algorithm is used to determine the place in the ordering workflow. *OT means One-Time, determined by the PO Line Type mapping tab. *SO and *CO mean Standing order or Continuous order, also determined by PO Line Type tab.

When FISCAL_CYCLE is earlier than the current fiscal cycle, then CLOSED. Alma does not allow open orders in previous fiscal years.

When FUND_DATE_PAID has a date (is not NEVER) and POL_LINE_TYPE = *OT, then CLOSED

When ORDR_DATE_CANCEL has a date which is earlier than today, then CANCELLED

When DIST_DATE_RECEIVED has a date AND mapped POL_ACQ_METHOD = ‘GIFT’ and POL_LINE_TYPE = *OT, then CLOSED

When DIST_DATE_RECEIVED has a date (and POL_ACQ_METHOD is not GIFT) and POL_LINE_TYPE = *OT, then WAITING_FOR_INVOICE

When ORDR_DATE_MAILED has a date (is not NEVER), then SENT

else NEW

Orders in Review Status or Waiting for Renewal

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.

Invoices

Provide the invoice file in xml format as a Symphony extract that uses API access (Print Invoice Report).

Modifications to the Invoice Extract

If you want to migrate invoices from Symphony, you MUST modify the standard invoice and order output, and provide the fund file differently.

Most customers have difficulty with these steps. Be sure to get the invoice file out early so that Ex Libris can check it in advance of your first testload file delivery.

Perform the following steps to modify the invoice and order output:

Add a unique order identifier, <orderlinekey>, to the invoice line. Additionally, you must modify the orders so that a matching ORDERLINE_KEY is in the related order. The standard fields, <orderlinenumber> and LINE_ITEM_ID, are not enough to provide a unique link between the two files.
Programming hint: In order to link order lines with invoice lines, use the combination invoice id + fiscal cycle + library + vendor code.

The <orderlinekey> *must* be within the individual <invoiceline> stanza. Only one <orderlinekey> per <invoiceline> stanza is allowed.
Add the fundID(s) to the invoiceLine stanza. The standard invoice output from Symphony provides the fundID in a separate fundSummary stanza outside of the invoiceLine stanzas. Ex Libris cannot work with fund information at the invoice header level. It must be at the line level. Ex Libris must have a fund specified per invoice line, within the <invoiceline> stanza.
Add the currency code of the invoice to the invoice header section, in three-character standard currency designation (e.g. USD, EUR).
If the invoice is in a foreign currency, the fund stanzas in the invoiceLine stanzas must contain local currency and foreign currency amounts, along with the exchange rate used at the time of payment.

Also, be sure to include multiple fund stanzas within the invoiceLine stanza in the case of multiple funds per invoice line (split funding). Each line must have the funding sources within the line. The standard Symphony invoice extract includes split funding at the invoice header level, so this must be changed by the customer.

For more information on how this was accomplished by previous Symphony to Alma customers, check with your Ex Libris project manager, and they can provide an extra text file with helpful assistance for doing this extra work.

Additionally, if you are migrating invoices, you must provide all of the funds for all of the fiscal years for which you have invoices. Add an additional field at the end of each fund line with the Fiscal Year. For example, you may have:

MAIN,Main Ledger,,,21345,Film,LIB,,$0.00,2026

MAIN,Main Ledger,,,21345-25,Film,LIB,,$0.00,2025

MAIN,Main Ledger,,,21345-24,Film,LIB,,$0.00,2024

Additionally, the fund codes must be unique, even across fiscal years. The fund code for the current fiscal year should be un-suffixed, and the fund codes for previous (non-active) fiscal years should be suffixed, as shown in the example above.

Fields Expected

The fields in the following table are expected. Indicate the local field names using the Migration File Validation Tool.

There may be fields in the extract that are not listed below. The migration programs do not need the data in the missing fields.

Field Name	Notes
library
invoiceID
vendorID
invoiceControlNumber
total/vendorAmount
total/vendorAmount currency
total/vendorAmountPaid
total/vendorAmountPaid currency	Not a preferred method of currency detection, because it is a single character thtat can be ambiguous (such as $ meaning USD or CAD). It is recommended to use the currency field added post-export.
dateCreated
dateModified
dateInvoiced
dateReady
dateLocked
extendedInfo/entry Note
The fundSummary stanza is ignored in favor of a fund tag or stanza within each invoice line stanzas.
createdBy
modifiedBy
proRata	Y/N
currency	In three-letter ISO code, e.g. USD, EUR, etc.. This is the preferred currency field. If not available, the migration programs attempts to use the single-digit code in total/vendorAmountPaid currency.
invoiceLine: repeatable group, fields below
invoiceLine attribute: lineType	The line type attributes are added to the invoice line note
lineNumber
amountInvoiced/vendorAmountPaid
amountInvoiced/vendorAmountPaid currency
amountInvoiced/nativeAmountPaid
amountInvoiced/exchangeRate
datePaid
checkNumber
orderID
fiscalCycle
Funding: Provide either a single <fundId> tag for all invoice lines, or provide a <fund> stanza for all invoice lines (do not mix). Either the fundId tag or the fund stanza must be within the invoiceLine stanza.
fundId (single tag)	This field is not present in the standard output for all invoice lines. Use an API call to add it to all invoice lines.
fund stanza: <fund> <fundID> <amountPaid currency=”USD”> <fiscalCycle> </fund>	The tag <percentage> might be provided but is needed and is not used by the migration programs.
orderlineKey	This is different than the orderLineNumber that is provided by Symphony. The number for this field is added by an API call, and is a number that can be used to directly link to the order extract’s ORDERLINE_KEY.
NumberOfCopies
vendorFinalPrice
dateCreated
dateModified
createdBy
modifiedBy
numberofLines
numberofLinesPaid

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.

Note Name	Default Local Field
INV_NOTE	numberOfLines
INV_NOTE	numberOfLinesPaid
INV_NOTE	numberOfCopies
INV_NOTE	numberOfCopiesPaid
INVL_NOTE	checkNumber
INVL_NOTE	extendedInfo Note

Vendors

Provide the vendor file in field block format, as a Symphony extract that uses API access. The field block format has one field per line, with the beginning and end of the record delimited by the following line:

*** DOCUMENT BOUNDARY ***

The fields in the following table are expected. Indicate the local field names using the Migration File Validation Tool.

Field Name	Notes
VENDOR_LIBRARY
VENDOR_ID
VENDOR_NAME
VENDOR_ORDER_ACTIVE
VENDOR_PAYING_ACTIVE
VENDOR_CURRENCY
VENDOR_CUSTOMER
VENDOR_ERP_CODE
VENDOR_ADDR1.ATTN
VENDOR_ADDR1.LINE
VENDOR_ADDR1.LINE1
VENDOR_ADDR1.LINE2
VENDOR_ADDR1.LINE3
VENDOR_ADDR1.LINE4
VENDOR_ADDR1.CITY/STATE
VENDOR_ADDR1.ZIP
VENDOR_ADDR1.COUNTRY
VENDOR_ADDR1.PHONE
VENDOR_ADDR1.FAX
VENDOR_ADDR1.EMAIL
VENDOR_ADDR2.ATTN
VENDOR_ADDR2.LINE
VENDOR_ADDR2.LINE1
VENDOR_ADDR2.LINE2
VENDOR_ADDR2.LINE3
VENDOR_ADDR2.LINE4
VENDOR_ADDR2.CITY/STATE
VENDOR_ADDR2.ZIP
VENDOR_ADDR2.COUNTRY
VENDOR_ADDR2.PHONE
VENDOR_ADDR2.FAX
VENDOR_ADDR2.EMAIL
VENDOR_EDI.XFER_USER
VENDOR_EDI.XFER_PASS
VENDOR_EDI.XFER_SCR
VENDOR_EDI.XFER_ADDR

Vendor Addresses

There can be several addresses, emails, and phone numbers in the vendor record. The fields that are available for migration into Alma are listed in the left column. The values in the left column cannot be changed. The field names from your Symphony extract are in the middle column.

Indicate which address is preferred and in the right column, indicate the type of address. For example, you may decide that Address 2 is the order address and that Address 1 is the payment, and Address 1 is the preferred address to use for the vendor.

Alma Address Field	Symphony Field Name
Preferred Address Selection	Select preferred vendor address with dropdown box: Addr1 o Addr2
VENDOR_ADDR1
VENDOR_ADDR1.LINE
etc
VENDOR_ADDR2
VENDOR_ADDR2.LINE
etc
Emails	Select which email should be preferred
VENDOR_ADDR1.EMAIL
VENDOR_ADDR2.EMAIL
Phones	Select which phone should be preferred
VENDOR_ADDR1.PHONE
etc

Vendor 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.

Note Name	Default Local Field
VENDOR_NOTE	VENDOR_AMTINVNOFUND
VENDOR_NOTE	VENDOR_CPINVNOFUND
VENDOR_NOTE	VENDOR_NUMCYCLES
VENDOR_NOTE	VENDOR_NUMINVOICES
VENDOR_NOTE	VENDOR_XINFO.NOTE
VENDOR_NOTE	VENDOR_XINFO.COMMENT

Funds

Fund records are not exported from Symphony. 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 and ledger codes are unique across the entire fiscal period, not just within specific hierarchies. Therefore, there should be no fund or ledger code duplication in the spreadsheet submitted. This uniqueness restriction applies across ledger codes, summary fund codes, and fund codes.

For Symphony migrations which migrate only orders, all of the funds go into a single active fiscal period. Therefore, when migrating only orders (not invoices), there is only one fiscal year and the fund codes in that fiscal year have to be unique among themselves.

However, when a Symphony customer is also migrating invoices, the customer makes multiple entries for each fund code, one for each fiscal year. In this case, the funds must still have different codes. Since in Alma the fund code is maintained as it rolls over to the next fiscal period, the recommendation is that the fund codes be structured like:

current fiscal year: CODE

previous fiscal years: CODE-2019, CODE-2018,CODE-2017, etc.

Ledger codes should be disambiguated in the same way when invoices for multiple fiscal years are being migrated.

The invoice file must be updated so the fund_id in the invoices matches the corresponding fund code in the fund file. It is not necessary to update the fund codes in the order file, since only the current open orders are linked to a fund - so the FUND_ID in the order file can remain as CODE (example code for a fund in the current fiscal year). Orders from previous fiscal years may have the fund structured like CODE, but since orders in previous fiscal years are closed automatically and are not linked to funds, this CODE only goes to a note in the PO.

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.

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. Must be unique, even across ledgers.
FUND NAME	Alphanumeric, repeatable
LIBRARY	Library code, in the Symphony form of the code. 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 base (local) currency, of the current fiscal year’s funds.
FY	Fiscal year, if customer is providing previous year funds for invoices.
NOTE	Will be placed on Note tab of funds screen

Acquisitions - Migration Form

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 Symphony. 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.
2013-2014 – 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.
2014-2015 – 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 will then need 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 for Serials Subscriptions

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 one is to populate based on an answer to this question (if populated). The default is 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, 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 BIB_KEY_PREFIX and MERGE_PATRON_PREFIX

Holding Code Tab

The Holding Code Tab is used to assign the destination (inventory) library and location for Symphony orders. See Holding Code Tab.

PO Line Type Tab

This tab is mandatory if you are migrating orders. Include a line for ALMAME_VAL_NOT_FOUND since this field is mandatory in Alma.

ORD_TYPE: Value of the order type field in Symphony, found in the ORD_TYPE field in your order extract.

order Type Description: A description of the ORD_TYPE field, for information only. This field is not used in the mapping to Alma.

poLineType: The Alma line type value. Select one of the following line types from the drop-down list:

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. If the only physical items that you order are books, this type is essentially the same as Print Book - One Time.
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. If the only physical items that you order are books, this type is essentially the same as Print Book - Standing Order.
PRINTED_BOOK_SO: Print Book – Standing Order
PRINT_SO_NONMON - Standing Order Non-Monograph – Similar to continuous orders.
OTHER_SERVICES_OT: Other Services One Time – Various non-inventory orders for services purchased from a vendor. Both one-time behavior and repetitive behavior are available. This should only be applied to orders without inventory. For electronic resources, see Line Types and Electronic Orders.
OTHER_SERVICES_CO: Other Services Subscription. This should only be applied to orders without inventory. For electronic resources, see Line Types and Electronic Orders.

Since monographic one time orders (PRINTED_BOOK_OT) in Alma are connected to a specific item and in Symphony orders are not necessarily connected to specific items, it is required that sent monographic one time orders be manually connected to their orders in order to receive them in Alma.

Further Information: Use this tab to define the line type of the migrated order. The PO may move through Alma workflows differently according to what type of item is on order. For example, a monographic order is opened, sent to the vendor, received, invoiced, and closed. However, a serial order may be received and invoiced many times and may remain open indefinitely.

Alma does have other PO Line types, but they are not available for use in migration.

Line Types and Electronic Orders

The above line types are all descriptions based on a print order. All orders are stored in Symphony as print and so are migrated to Alma initially as print using the above 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 you identify as electronic and is in an electronic location, it is changed to the corresponding electronic standing order line type by the P2E process. See the section on Physical to Electronic Processing below for more information on the overall P2E process.

PO Acq Method Tab

Use this tab to determine the Acquisition Method of an order in Alma. The acquisition method is an indication of how the order is acquired.

ORDR_TYPE: The value of the ORDR TYPE field in Symphony, found in your order extract.

ORDR_TYPE Description: A description of the Order Type in Symphony, for information purposes only. This field is not used in the mapping to Alma.

poLineAcqMethod: The Acquisition method in Alma. AcqMethod is mandatory in Alma. If not found, then use PURCHASE. Select one of the following values from the drop-down list:

PURCHASE – normal workflow
GIFT – not sent to vendor and no invoicing or payment
EXCHANGE – not sent to vendor and no invoicing or payment
APPROVAL – pre-established delivery plan - normal workflow except not sent to vendor
VENDOR_SYSTEM – the order is placed at the vendor site so that sending it to the vendor is not required. The normal workflow is followed except that the order is not sent to the vendor.
DEPOSITORY – usually from the government. The order is not sent to vendor and there is no invoicing or payment.
TECHNICAL – no fund or amount required
LEGAL_DEPOSIT – does not require fund or price, and uses a special version of the PO Line order letter

Comment: Add any comments about ORDR_TYPE for use while filling out this form. This field is not used by the migration programs.

Further Information: The PO Acq Method is mandatory in Alma, so the ALMAME_VALUE_NOT_FOUND line is required to catch any values that may not have been found in the map.

Currency Code Tab

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

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

Symphony 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.

Physical to Electronic (P2E) Processing

This section describes the process of correctly categorizing resources as electronic in Alma. In Symphony, all resources are stored as physical in the database, even if the record represents an electronic item. During migration, all records are initially converted to Alma as physical. A second process converts records that you identify as electronic to the electronic format. It is up to you to provide a list of records that are identified as electronic, in the following format:

123475,portfolio

12346,db

The words portfolio and db are not case-sensitive; therefore, both portfolio and Portfolio are acceptable.

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.

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.

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 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 Holding 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 Holding 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 Holding 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 Symphony Migration Form.

PO Line Type Tab

Line Types and Electronic Orders

The PO line types are all descriptions based on a print order. All orders are stored in Symphony as print, and so are migrated to Alma initially as print using the above 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.

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 may 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.

Recommendations for Using this Guide

Related Documentation

Migration Overview

Data Files, Migration File Validation Tool

Migration Form

Additional Manipulation for Order and Invoice Files for Symphony (optional)

Expected File Formats

File Naming Conventions

Using the Migration Form Validation Tool

Inventory

Bibliographic Records

Export hints

Additions to the bib record

Suppressed/Shadowed Records

Bibs with a very large number of items

Boundwith Records

Serial Control Records and Issues

Holding Records

Determining Groups of Holding Records

Changing the Holding Record Grouping

Attaching Items to Existing Holding Records

Non-Marc Holdings (rarely used)

Holdings From a Bib Tag

Items

Item Notes

Special note prefixes

Item Barcodes

Material Types

Volume Information – Request Special Export from Symphony

Secondary Item File

Holdings and Items from Serial Issues

Serial Control Record

Notes

Serial Issues = Items

Notes

Electronic Identification (P2E)

Inventory - Migration Form

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 holding records

Limit exported records by location

Bib Key Prefix

Move 001/003 to 035 or 935

Use subfield indicators in item call number (AltCallNo)

Add $9 LOCAL to specified tags

Alma Library Tab

Alma Location Tab

Alma Location Name and Alma External Location Name

Collapsing Locations

Holding Code Tab

Shelving Scheme Tab

Item Type Tab

Item Base Status Tab

Material Type Tab

Fulfillment (Patrons and Circulation)

Patrons

Internal/External Patrons

Identification Numbers

Block File

User Addresses

User Identifiers

User Statistical Categories

Notes

Active Loans

Fines and Fees (Bills)

Active Requests on the Hold Shelf

Course Reserves

Reading List Items -> Bibs

Faculty/Department

Fulfillment/Patrons - Migration Form

Questionnaire Tab

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

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

How should we handle duplicate identifiers in the same patron?

Currency for patron fines

Use a map for the USER LIBRARY to campus code migration?