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

    Solars to Alma Data Delivery and Migration Guide

    Migration Overview

    Solars is the Integrated Library System produced by Inek.
    This page serves two purposes:
    • A step-by-step guide to filling out the Solars (Inek) to Alma Migration Form.
    • An description of the data files expected from Solars, as well as an explanation of some of the migration rules for Solars to 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:
    • Files Expected - the files expected from Solars as well as a list of fields in each.
    • Questionnaire Tab – Instructions for individual questions asked on the Questionnaire tab of the Migration Form.
    • Individual Tabs – Instructions for how to fill in individual tabs on the migration form.
    • Further Explanation – Explanations of migration processes that need more explanation and/or do not need customer input.
    We recommend that you look at the Questionnaire tab section and the individual tabs in each area to assist in filling in the migration form.
    If you have further questions about any of the data input or about the migration in general, see the more detailed explanations in the Further Explanations sections.

    Related Documentation

    Ex Libris migrates your acquisitions and course data only if this service is purchased by your institution and is stipulated in your contract with Ex Libris.
    The procedure for migrating from the Solars (Inek) ILS to Ex Libris’ Alma consists of the following steps:
    • Indicate which local fields correspond to Ex Libris' expected fields using the Solars (Inek) Field Mapping form, prior to data delivery (customer responsibility).
      Validate the flat files using Ex Libris’ validation tool Excel. It is recommended that this step be done against a small sub-set of data to ensure that the header of each of your flat files and the filled in field mapping form match each other.
    • Extract the relevant data elements from Solars into flat files (customer responsibility).
    • Upload the files to Ex Libris’ secure file (MFT) server along with the Solars Delivered Files form and the executed/validated Non-Ex Libris to Alma Validation Tool (customer responsibility).
    • Transform the data elements, based on the Solars (Inek) Field Mapping form, into an intermediate conversion XML format (Ex Libris responsibility).
    • Load the transformed data into Alma (Ex Libris responsibility).
    Deliver the Solars (Inek) Field Mapping form and validated data validation output to Ex Libris along with the Solars Migration Form prior to the actual delivery of the data. The lead time depends on your project schedule. Provide the Solars Delivered Files form, which lists the file names and the record counts for each file at the same time that you provide your data extract files.
    For all files, the maximum file size is 2GB.
    Provide the Solars data elements in flat files, and place them on the Ex Libris secure file server. Prepare the data files with the naming conventions as described in Appendix – File Delivery and Form.
    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.

    Excel Forms for Solars

    Solars Field Mapping Form
    Prior to submitting your extracted files, complete the Solars (Inek) Field Mapping form. Submit the Solars Field Mapping Form and the Solars Migration Form at the same time. In the Solars Field Mapping Form, indicate which data elements (files) you plan to provide in the Overview tab of the spreadsheet. On the subsequent tabs, indicate your local Solars field names and how they map to our expected field names.
    Even when the names of the fields being provided are the same as the ones listed in the ExL Expected Field Name column, the Local Field Name column for the fields being provided must still be filled in.
    In addition, there are various note fields for each data element on the various tabs. For fields that are not expected by Ex Libris – meaning, there is no functional place for the data element in the corresponding Alma data structure – place the field in a note in the record. Specify which note type you want the field to go to at the bottom of each tab in the Solars Field Mapping Form.
    Solars Code Mapping Form
    There are many codes in Solars that are stored in the system as numbers, which the Solars interface translates to useful information. When migrating to Alma, the migration programs can translate these numeric codes to readable values for viewing in the note field in Alma. Supply the Solars Code Mapping Form with the values and their translations for each field desired.
    The tab of the Code Mapping form should be labeled FIELD (file type), for example, BOOK_TYPE (item). The tab itself will contain numeric values that can be found in the BOOK_TYPE field of the item record, for example, along with their translations to words. UTF-8 can be used in this form.
    Additionally, for each field that will be placed in the notes in Alma, there is a Note Label column in the Note section on the Solars (Inek) Field Mapping form, which is used as a prefix for each note.
    Solars Delivered Files Form
    At the time you submit the requested data files, submit the completed Solars Delivered Files Form. List the files, record counts, and encoding for each file delivered to the secure file server.
    Solars Migration Form
    The Solars Migration Form is a separate Excel spreadsheet that contains information on how to migrate information that is specific to your local implementation of Solars. For example, your local location codes and item types are converted to codes and types that can be used by Alma.

    Expected File Formats

    Expected file formats for Solars data varies by file. See the descriptions below. Ex Libris expects a certain set of files to be exported from Solars. 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 Solars, but are not necessary to bring to Alma.
    The scope of your specific conversion is agreed upon in your Alma contract.
    As you extract data from any area requested below, provide it to Ex Libris via the MFT secure file server. This facilitates the transformation analysis and expedites the conversion process. Information on the MFT connection will be provided by Ex Libris. For more information, see Appendix – File Delivery and Form.

    Inventory

    Alma uses bibliographic, holding, and item records. Solars has bibliographic and item records, so MARC holdings records are created during migration based on information in the Solars item record and possibly the serial issue/checkin record and the item supplements.

    Bibliographic Records

    Bibliographic records are expected in MARC or KORMARC format. Standard MARC is preferred, but files in MARCXML format are also acceptable. The character encoding expected from Solars is UTF-8. If your library prefers to export in a different character encoding such as MARC8, inform your Ex Libris project manager. Deliver all files with the same character encoding.
    There should be a unique and consistent former system number in each bibliographic record. This is typically in the 001 field in Solars. Whichever field it is in, it should be unique and should be present for every single record. Indicate where the former system number is on the Bibliographic tab of the field mapping form.
    If you have loaded SFX MARCIt records into Solars, 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 Solars Migration Form.

    Suppressed Records

    Previous customers who migrated from Solars to Alma did not provide suppressed bibliographic records. Suppressed records are those that are in the system, can be seen by cataloging staff, but cannot be seen by the public.  If you wish to provide information about suppressed bibliographic records, inform your Ex Libris project representative.

    Bibliographic Class ID

    Solars stores information about the bibliographic record in a separate CMAST file. The migration program moves the Class information from this file to a tag in the bibliographic record.
    Provide the CMAST file in csv format, one record per line. The fields in the line are delimited by ‘|’. The following fields are used.
    Field Name Notes
    C_ID Used to find bibliographic record
    CLASS_ID Value from this field will be placed in specified tag of bibliographic record
    Q_ID  
    Specify the tag that will be used to store the relationship in the migrated bibliographic record. Up to five characters can be specified, including indicators. Recommended tag: 990.

    Linking Bibs with Relations and Groups

    Solars links bibliographic records together using Relations (C2R) and Groups (C2G). The migration programs will generate links between bibliographic records based on information in these files.
    Relations: C2R and RELATION_MST
    Provide the C2R file in csv format, one record per line. The fields in the line are delimited by ‘|’. The following fields are used.
    Field Name Notes
    C_ID Checkin ID (used to get bib number)
    CLASS_ID Values in this field can be found in RELATION_MST file
    Q_ID Related Checkin ID (used to get related bib number)
    Additionally, provide the RELATION_MST file which provides the type of relationship it is.
    Finally, specify the tag that will be used to store the relationship in the migrated record. Up to five characters can be specified, including indicators. Recommended tag: 777.
    Groups: C2G and CGROUP
    Provide the C2G file in csv format, one record per line. The fields in the line are delimited by ‘|’. The following fields are used.
    Field Name Notes
    C_ID Checkin ID (used to get bib number)
    PC_ID Related Checkin ID (used to get related bib number)
    GROUP_ID Values in this field can be found in CGROUP file
    Additionally, provide the CGROUP which provides the type of relationship it is.
    Finally, specify the tag that will be used to store the group relationship in the migrated bib record. Up to five characters can be specified, including indicators. Recommended tag: 777.

    Bib Additional Info (Notes)

    Solars stores notes about a bibliographic records in separate Additional Info tables. These notes can be exported from Solars and the migration programs will add them to the related bibliographic record in a tag specified by you.
    The Additional Info file should be exported from Solars using the normal export routine. The records are in a csv file, with the fields deliminted by ‘|’. The file should contain the following fields:
    Field Name Notes
    DATA  
    C_ID bibliographic number
    R_ID type of additional info (1, 2, or 3). 
    Specify which tag in the bibliographic record that will contain the note type. You can specify up to five characters, including indicators.
    Additional Info Type Suggested Tag
    R_ID type 1 505
    R_ID type 2 500
    R_ID type 3 590 

    Holding Records

    Alma requires MARC holdings records. Solars does not have MARC holdings records, so the migration process will generate MARC holdings records for use in Alma based on item records.

    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 the Holdings tab of the Solars (Inek) Field Mapping Form. 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, the summary holding 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 holdings 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

    Items are expected in a separate CSV file, one record per line, with the fields delimited by ‘|’.
    The following fields are expected. The expected field names are listed in column A of the Items tab of the Solars (Inek) Field Mapping form. Specify the local (delivered) field name in column B.
    There may be additional fields in the item file, but they are not used functionally in Alma and can be placed in notes fields for future reference.
    Expected Field Notes
    BRCH_CODE Use as Library in Alma Location Tab
    IDID Item’s barcode; used to link from loans and requests
    C_ID Link to the bib ID
    CALL_NO_PREFIX

    A call number string is created from these four fields like: 

    $k CALL_NO_PREFIX $h CLASS_CODE $i CALL_NO_ITEM $m CALL_NO_SUFFIX

    The above call number string is used to match an item to a holding record, if at least $h is included in 852_subfields_for_hol. 

    If a holding record is not present, then the above call number string is used when generating a holding record.  Further, if only bc is used in 852_subfields_for_hol, then this call number could*  be placed in the ITEM_CALL_NUMBER field when multiple items are grouped together into a single holding record. 

    * 'could' because incoming ITEM_CALL_NUMBER will be placed in Alma's ITEM_CALL_NUMBER if present.  If incoming ITEM_CALL_NUMBER is NOT present, then the above call number string is placed in the ITEM_CALL_NO according to the descriptions in "Determining Groups of Holding Records" and "Changing the Holding Record Grouping" sections below.

    CLASS_CODE
    CALL_NO_ITEM
    CALL_NO_SUFFIX
    CALL_NO_VOL  
    CALL_NO_COPY  
    DATE_CREATE  
    TOT_CHG_CNT

    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.

    REC_COPY_SEQNO  
    LOC_CODE Use as Location in Alma Location Tab
    CIRC_STAT Use in itemBaseStatus and in item Type map
    MODIFY_DATE  
    ACQ_ID  
    ITEM_CALL_NUMBER If this is present, then the value will be placed in ITEM_CALL_NUMBER.  This value takes precedence over a possible value from the above CALL_NO* fields, according to the descriptions in "Determining Groups of Holding Records" and "Changing the Holding Record Grouping" sections below.
    Temporary library   
    Temporary location   
    Temporary call number type   
    Temporary call number The temporary call number, along with all of the other Temporary fields, are processed separately from the CALL_NO* fields and the ITEM_CALL_NUMBER field.
    LOCAL_RECEIPT_PRICE Both of these fields may be filled with the local price field from Solars if desired. The LOCAL_RECEIPT_PRICE will be placed in the inventory_price field, and the REPLACEMENT_COST will be used to assess fines if the item is lost.
    REPLACEMENT_COST

    Lost Loans

    Additionally, information from the Lost Loans file will be put into an Item Note. Specify in which item note type to place the information by putting ‘LOST_LOAN’ in one of the note types in the item note section (below). The typical note type is FULFILLMENT_NOTE.

    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, add, or subtract fields in the Default Local Subfield column as necessary.
    The text in the Note Label column are used as a prefix to the subfield contents and can be modified. The note label can be in Unicode. If you want to include multiple local fields in the same Alma note, copy the line in the spreadsheet as many times as needed for all note name/local field combinations.
    Note Name Default Local Field Note Label
    PUBLIC NOTE    
    FULFILMENT_NOTE LOST_LOAN  
    NON_PUBLIC_NOTE_1 NOTE  
    NON_PUBLIC_NOTE_1 BOOK_TYPE  
    NON_PUBLIC_NOTE_2 REG_MST_NO  
    NON_PUBLIC_NOTE_2 REC_COPY_SEQNO  
    NON_PUBLIC_NOTE_3 LOCAL_RECEIPT_PRICE  
    NON_PUBLIC_NOTE_3 NET_PRICE  
    STAT_NOTE_1    
    STAT_NOTE_2    

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

    Secondary Item File

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

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

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

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

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

    Expected Field Name Notes
    item_key

    Provide either item_key or barcode, but not both. If both are provided, item_key is preferred

    Always provide both fields, even when one is empty.  E.g. 

    clipboard_e1888f183c7491b3d966f927eef32dfd8.png

    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  

    Item Supplements

    Information from the Item Supplement files will also be used to generate items. There are three files expected: The Metadata file (MAST), the LST file, and the type of Supplement file.
    All three item supplement files should be provided in csv format, with each field delimited by ‘|’.

    Metadata file (MAST)

    The following fields are expected. The expected field names are listed in column A of the Supplements tab of the Solars (Inek) Field Mapping form. Specify the local (delivered) field name in column B.
    There may be additional fields in the item file, but they are not used functionally in Alma and may be placed in notes fields for future reference.
    Expected Fields Notes
    SIDID  
    BRCH_CODE Use as Library in the Alma location tab
    IDID Use to link to item record and bibliographic record
    IDID_SEQ  
    SUPPL_ID  
    CIRC_STAT Use in Item Base Status tab and Item Type tab
    CALL_NO_PREFIX  
    CLASS_CODE  
    CALL_NO_ITEM  
    CALL_NO_SUFFIX  
    CALL_NO_VOL  
    CALL_NO_COPY  
    LOC_CODE Use as Location in Alma Location Tab

    LST File

    The following fields are expected. The expected field names are listed in column A of the Supplement tab of the Solars (Inek) Field Mapping form. Specify the local (delivered) field name in column B.
    There may be additional fields in the item file, but they are not used functionally in Alma and may be placed in notes fields for future reference.
    Expected Fields Notes
    SUPPL_ID Links to MAST file
    NOTE  
    TYPE_ID Links to Type of Supplement file
    BRCH_CODE  

    Type of Supplement

    The type of supplement file is also expected, although the fields are used as reference and are not mapped directly. The following chart describes the Alma item type as derived from the supplement type:
    Alma Material Type Solars Supplement Type
    Book  
    DVD  
    CD-ROM  
    Audio cassette  
    Computer Disk  
    Map  
    Technical Drawing  
    Pamphlet  
    Other  

    Serial Checkin = Items

    Alma migration makes item records from the unbound records in the Serial Checkin (Issues) file. Provide the checkin file in csv format, one record per line, with fields delimited by ‘|’.
    If serial checkins/items will be generated, but ACQ is not part of the contracted migration, you must still provide the two Purchase Order files ACQ_MST and SER_MST, along with the Q_INFO_VIEW file, so that we can get a link from checkins to the bibliographic record. The rest of the ACQ_MST and SER_MST files is not used.
    Specify the local field names on the Serial Issues tab of the Solars (Inek) Field Mapping form.
    Expected Fields Notes
    CHKIN_NO  
    IMID Link to Acq order -> Q_ID -> bib ID
    BRCH_CODE Use as Library in Alma Location tab
    LEVEL1  
    LEVEL2  
    LEVEL3  
    LEVEL4  
    LEVEL5  
    COPY_NO  
    MATERIAL_TYPE  
    VOLUME  
    EXPT_DATE  
    CHKIN_STAT  
    PROC_DATE  
    CLASS_NO  
    IDID Link to Item record
    CHKIN_TYPE  
    WORKER  
    LOC_CODE Use as Location in Alma Location Tab
    NOTE_NO  
    PROC_STAT  
    Additionally, we get call number and bib linking information from the Q_INFO_VIEW file.
    Expected Fields Notes
    Q_ID Links to checkin file
    CALL_NBR  
    C_ID Bibliographic record #

    Item Supplement Notes

    Any additional subfields not listed above can be put into notes. The possible note fields in Alma items are listed in the following table 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, add, or subtract fields in the Default Local Subfield column as necessary.
    The text in the Note Label column are used as a prefix to the subfield contents and can be modified. The note label may be in Unicode. If you want to include multiple local fields in the same Alma note, copy the line in the spreadsheet as many times as needed for all note name/local field combinations.
    Note Name Default Local Field Note Label
    PUBLIC NOTE    
    FULFILMENT_NOTE    
    NON_PUBLIC_NOTE_1 VOL_BALANCE  
    NON_PUBLIC_NOTE_1 RECEIPT_BOOK_CNT  
    NON_PUBLIC_NOTE_2 PUBL_DATE  
    NON_PUBLIC_NOTE_2 RECEIPT_TYPE  
    NON_PUBLIC_NOTE_3 ORD_NO  
    NON_PUBLIC_NOTE_3    
    STAT_NOTE_1    
    STAT_NOTE_2    
    STAT_NOTE_3    

    Customer Input - Inventory

    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
    Code: TIMEZONE
    Options: 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 (Solars bibliographic system number) to the 035 $a field:
    (MOC)<Solars 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 Solars former system number is generally in the 001 field. Customers should specify where the former system number is in the Solars Field Mapping form.
    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 Solars 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 Solars 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. 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: 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 the Determining Groups of Holding Records and Changing the Holding Record Grouping section below.
    Limit exported records by location
    Code: LIMIT_BY_LOCATIONS
    Default: No
    Options: If your export contains all of the data from a shared database, and you wish to only migrate a part of that export to Alma, then the migration programs can filter the data according to locations listed on the Location Tab. In this case, the ALMAME_VALUE_NOT_FOUND line on the location tab is not used. Inventory and Acquisitions are filtered by locations on the Location Tab, and Fulfillment is filtered based on campus codes in the Campus Code Tab. Use this option only if agreed upon with your Ex Libris project manager.
    Bib Key Prefix
    Code: BIB_KEY_PREFIX
    Default: empty
    Options: If you are combining data from two or more separate databases into a single combined institution in Alma, then indicate a prefix here that will be used to distinguish the former system numbers in Alma after migration. For example, the different systems likely had completely different bibs for system number 12345 and you want to be able to search for the specific bib from your own institution after go-live. The prefix does not include a hyphen so if you want a hyphen in the number (e.g. PQ-12345), then include it in the string. If you are not merging institutions, leave this question blank.
    See also 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. 

    Add institution suffix to Bib ID 

    Code: BIBID_INST_SUFFIX

    Default: No

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

    Yes = include suffix

    No = do not include suffix

    Use subfield indicators in item call number (AltCallNo)

    Code: ITEM_CALLNO_SUBFIELD

    Default: Yes

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


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

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

    Add $9 LOCAL to specified tags

    Code: NZ_LOCAL_TAGS

    Default: empty

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

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

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

    If you include 9#### here, only 950-999 will be included, since only 950-999 (and not 900-949) are included, 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. Unicode characters are acceptable. Alma Library name: Maximum 255 characters. This is visible to the public.
    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 Solars field is the BRCH_CODE in the item record, which is the higher level of location and is comparable to the Alma library. Use the Alma Libraries tab in the Solars Migration Form to indicate your list of Alma libraries. The actual mapping from the Solars library Solars BRCH_CODE to the Alma library is done in conjunction with the LOC_CODE 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 Solars BRCH_CODEs and LOC_CODEs 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.
    Solars BRCH_CODE: Value from the Library field in the item extract from Solars. The ALMAME_VAL_NOT_FOUND line is required to catch any location codes you may have missed.
    Solars LOC_CODE: Value from the LOC_CODE field in the item extract from Solars.
    Alma Library Code: The library that contains this BRCH_CODE/LOC_CODE combination in Alma. You can use the same branch codes that you used in Solars, but it is not required. This code must be present on the Alma Library Tab, column A. The match is case-sensitive. See Libraries and Locations in Orders on page 30 about how this Library Code value may also be used as the ordering library in order migration.
    Alma Location Code: The new location code for this library/location combination in Alma. It can be a maximum of 10 characters (Unicode is acceptable). You can use the same location codes in Alma that you used in Solars, but this is not required. You may also use this form to collapse locations, for example refa and refb in Solars 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. Unicode is acceptable.
    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.
    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. 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 Solars code to an easily identifiable code such as XXX or unused just in case any stray items are still in your Solars 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.
    Solars Branch Code Solars Location Code Alma Library Code Alma Location Code Alma External Loc Desc Suppress from Externalization
    ALMA_ME_ VALUE_NOT _FOUND ALMAME_ VALUE_NOT _FOUND MAIN UNASSIGNED 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 Solars 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 Solars code to an easily identifiable code, such as XXX if any stray items are still in your Solars database.
    If you collapse location codes, you may have lines in the table such as the following:
     
    Solars 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.

    Item Type Tab

    Use this tab to migrate the Solars Item CIRC_STATUS or Serial checkin PROC_STAT 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.
    Solars CIRC_STATUS or PROC_STAT: The value in the CIRC_STATUS field from items or the PROC_STAT field from checkins in Solars. The item type is used to differentiate between items when determining how items circulate.
    Solars Description: The description of the Solars item type, for information only. This column is not used during the mapping process.
    Alma itemPolicy: The Alma value for the item type. This sheet can be used to collapse item types if desired.
    Alma itemPolicy Description: This description is loaded into Alma as the display text for the item types. These values can be changed after migration. Maximum 255 characters.
    You can optionally include an ALMAME_VAL_NOT_FOUND line at the top of the map. If this line is included, any value not found or any blank value is assigned the value in the ALMAME_VAL_NOT_FOUND line. If the ALMAME_VAL_NOT_FOUND line is not included, any value not found, including blanks, is left as blank in Alma.

    Item Base Status Tab

    Use this tab to map your item CIRC_STATUS or checkin PROC_STAT, plus the CHKIN_STAT from serials, to an item status in Alma.
    Solars CIRC_STATUS or PROC_STAT: The Circ status or Proc status in Solars.
    Solars CHKIN_STAT: Optionally, the checkin status, used as a determiner for checkins.
    Description: A short description of the status in Solars, if desired, for note purposes while filling out this form. This column is not used for migration.
    Base Status: In Alma, the base status indicates whether or not the item is on the shelf. Indicate whether or not an item with this status is on the shelf. For example, NewBooks is on the shelf (1), but Withdrawn is not (0).
    Further Information: 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.
    For migration, all item statuses that are indicated as not on the shelf (0) from Solars 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.
    Post-migration, you can search for values in Internal Note 1 and then move the items 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 – Post-Migration Process Statuses for more information.

    Further Explanation - Inventory

    Bibliographic Records

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

    Serials

    The migration programs generate item records out of unbound serial checkin records. In order to migrate serial checkins, we must have the ACQ_MST order file (even if Acquisitions is not being migrated) so that we may link the serial checkin to the bib record using the IMID and Q_ID fields.
    Items are not generated from the Bound Items file, since they are all present in the main item file.

    Determining Groups of Holding Records

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

    Changing the Holdings Record Grouping

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

    Item Barcodes

    The item barcode must be unique in Alma, but it may be left blank.
    The item barcode is migrated according to the following rules:
    • If the barcode is empty, leave it as is.
    • If the barcode exists but is not unique:
      • First item barcode encountered – migrate as is.
      • Second and subsequent item barcodes encountered – migrate as <item barcode>-<item id>.

    Material Type from Bib Fixed Fields

    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.
    Solars customers may provide a material type in a subfield of the item tag (typically 999) of the exported bibliographic records, and use the Material Type tab to map them to valid Alma material types. The material type you indicate determines the item's material type.
    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.

    Fulfillment

    Patrons

    Extract all patrons. In order to migrate any area of fulfillment (fines/ fees, loans, requests), all patrons must be migrated. Provide the files in CSV format, one record per line, with the fields delimited by ‘|’.
    The fields in the following table are expected. Indicate the local field names for the expected fields in the Patrons tab of the Solars Migration Form.
    Field Name Notes
    IPID  
    JUMIN_BUNHO  
    PAT_TYPE Use in User Group map
    DATE_REGIST  
    DATE_EXPRD May be left empty
    DATE_BLK_EXPRD  
    DEPOSIT_AMT  
    PAT_STAT  
    UPDATE_DATE  
    USERNAME  
    WORKER  
    BRCH_CODE Use in campus code map

    Patron Block File

    Patron blocks are provided in a separate file. The following fields are expected. Specify your local fields in the Patrons tab of the Solars Field Mapping Form.
    Field Name Notes
    BLOCK_KEY        
    BLOCK_NO  
    BLOCK_TYPE  
    DATE_CREATE  
    DATE_BLK_EXPRD  
    BLOCK_MSG  
    IDID  

    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 Solars 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, Address 1 is home, Address 2 is work, and so on.
    If any of the addresses contain a country code or name, the migration programs do not standardize it.
    Alma Address Field Solars 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.LINE ADDR1 (Leave blank)
    etc ZIP1 (Leave blank)
    USER_ADDR2 Select type: Select an address type for all address 2 lines here
    USER_ADDR2.LINE ADDR2 (LEAVE blank)
    etc ZIP2 (Leave blank)
    Emails: Select type for each Select Preferred email: Which is the preferred email out of all emails?
    EMAIL EMAIL For this particular email, which type should it be?
    EMAIL2 EMAIL2 For this particular email, which type should it be?
    EMAIL_OPT EMAIL_OPT 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?
    PHONE1 PHONE1 For this particular phone, which type should it be?
    PHONE2 PHONE2 For this particular phone, which type should it be?
    PHONE3 PHONE3 For this particular phone, which type should it be?
    FAX_NO FAX_NO 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 Solars 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 Solars Migration Form.
    Alma Identifier Type Solars Field Name
    UNIV_ID ALT_PID
    BAR PID
    ADDL_ID_1 EMAIL
    ADDL_ID_2 FAX_NO
    ADDL_ID_3  
    ADDL_ID_4  

    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 user group, but you may want to track the department, so that you can get more detailed statistics on how Law students borrow, for example. Since there can be more than one field that has statistical information, we provide you the option to map the data from any field to the User Statistical Categories in Alma.
    User Statistical Catagory Local Field name Field Label
    USER_STAT_CATEGORY COLLEGE_CODE COLLEGE:
    USER_STAT_CATEGORY DEPT_CODE DEPT:
    USER_STAT_CATEGORY    
    You can add more lines as necessary, up to a maximum of 10 lines. To map the values, use the UserStatCategories map in the Solars Migration Form. If a value is not found in the map, it is migrated as is. If you use a label, the userStatCategory map tries to map the field including the label. The first column in the userStatCategory map would be: LABEL: value, for example: COLLEGE: Law.  The migration program does not provide a colon, so if you want it to be present, include it in the label as above.  The migration program does provide a space between the label and the value.

    If you use this prefix, be sure to use the prefix again in the Migration Form Mapping tab for User Stat Categories, in column A (incoming data).   In the Field Mapping form, provide labels to the right of the field:

    clipboard_e2aa93036138a14009b7d157e0f2d5e72.png

    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:

    clipboard_e05c1bc84e8c6add0f665c0882acc3c50.png

    In the case above, you can see that if there were no prefix to the fields, it would not be possible to distinguish between 'b' from PC1 and 'b' 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 table in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris. If you use other field names or have fields that you want to include in the migration, but are not expected by Ex Libris, you can rearrange, add, or subtract fields on the right, as necessary.
    The text in the Note Label column are used as a prefix to the subfield contents and can be modified. The note label may be in Unicode. If you want to include multiple local fields in the same Alma note, copy the line in the spreadsheet as many times as needed for all note name/local field combinations.
    Note Name Information
    LIBRARY_NOTE  
    BARCODE_NOTE  
    ADDRESS_NOTE  
    OTHER_NOTE OTHER_NOTE is set as user Viewable by the migration programs.  This is the only note which migration marks as user viewable.
    CIRC_NOTE The '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.

    Active Loans

    Extract only current circulation transactions. The loans file is expected in csv format, one record per line, with the fields delimited by ‘|’.
    Lost loans are handled in the item section.
    The fields in the following table are expected. Indicate the local field names for the expected fields in the Loans tab of the Solars Field Mapping Form.
    Field Name Notes
    BRCH_CODE  
    IDID Item ID
    DATE_CHG  
    TIME_CHG  
    DATE_DUE  
    TIME_DUE  
    RENEW_CNT If > 0, then renewed.  If you want to know the total number of renewals, also put in note
    IPID Links to patron ID
    Any additional fields not listed above may be put into notes. The possible note fields in Alma items are listed in the following table in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris.
    The text in the Note Label column are used as a prefix to the subfield contents and can be modified. The note label may be in Unicode. If you want to include multiple local fields in the same Alma note, copy the line in the spreadsheet as many times as needed for all note name/local field combinations.
    Note Name Default Local Fields Note Label
    NON_PUBLIC_NOTE DATE_EXP_NOTICE  
    NON_PUBLIC_NOTE RENEW_CNT  
    NON_PUBLIC_NOTE NOTE_DESC  
    NON_PUBLIC_NOTE CHG_TYPE  

    Fines and Fees (Bills)

    Extract only current fines and fees. Fines and fees that have a zero balance are not migrated to Alma.
    Deposit amounts, stored on the patron’s record in Solars, are migrated as a credit in Alma. Fines and fees, which come from a separate fine/fee file (described here), are migrated as debits.
    Provide the fines and fees file in csv format, one record per line, with the fields delimited by ‘|’.  The fields in the following table are expected. Indicate the local field names for the expected fields in the Fines & Fees tab of the Solars Field Mapping Form.
    Field Name Notes
    DATE_CREATE  
    BALANCE_AMT  
    BRCH_CODE  
    IDID Link to item
    IPID Link to patron
    FINE_TYPE Use fine type map in Migration Form
    REC_WORKER  
    Any additional fields not listed above can be put into notes. The possible note fields in Alma items are listed in the following table in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris.
    The text in the Note Label column are used as a prefix to the subfield contents and can be modified. The note label may be in Unicode. If you want to include multiple local fields in the same Alma note, copy the line in the spreadsheet as many times as needed for all note name/local field combinations.
    Note Name Default Local Fields Note Label
    FINE_FEE_COMMENT ORG_FINE_AMT  
    FINE_FEE_COMMENT ORG_DATE_CHG  
    FINE_FEE_COMMENT ORG_DATE_DUE  

    Customer Input - Fulfillment

    Questionnaire Tab

    Enter a two-letter code for the default conversational language for your users
    Code: PATRON_LANG
    Default: en
    Options: Use the two-letter codes as defined in ISO 639-1. Consult the codes from https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes. Additionally, the language code zh-tw (Taiwanese Mandarin) is accepted.
    Which identifier should be used as the patron's Primary Identifier?
    Code: PATRON_PRIMARYID
    Default: UNIV ID
    Options: Using the Poalris Field Mapping Form, map the identifiers exported from Polaris 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, both internal and external.
    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 BRCH_CODE 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 BRCH_CODE 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.
    See also: Campus Code Tab

    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

    Currency Code Tab

    Use this tab to map the currency code values in Solars (CURR_CODE) to a valid Alma currency code.
    Solars CURR_CODE: The Solars currency code, taken from the order file.
    Solars Description: A description of the Solars currency code, for reference only. This column is not used in migration.
    Alma Currency code: A valid currency code in Alma. For a list of valid codes, consult http://en.wikipedia.org/wiki/ISO_4217. For inactive currencies such as those replaced by the Euro, use the replacement currency code.

    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.
    Solars PAT_TYPE: The Solars patron type code, found in the PAT_TYPE field of the patron extract.
    Solars Description: A description of the Solars 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 Polaris, or you can use different codes. You can also collapse groups if desired, for example, having Freshman and Sophomore from Solars both map to Undergrad in Alma. Do not use special characters, for example, slashes (/) or spaces in the code.
    Alma User Group Description: The description of the Alma User Group. This description is loaded into the Alma code table as the description displayed in the user interface. This description can be changed easily after migration.
    Internal? Y or N: Alma categorizes users as either external or internal. External patrons are managed and authenticated by an external system, such as through a regular load from the bursar’s office/campus student information system. Internal patrons are created and managed internally. Examples of internal patrons would be minority cases where community borrowers or alumni use library services. If you select Yes, all of the patrons in the Alma userGroup are categorized as internal. If you select No, all of the patrons in the Alma userGroup are categorized as external.
    Notes/Comments: Add any notes or comments for the Polaris 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 as the patron's Primary Identifier?

    User Stat Categories Tab

    This tab is used to migrate the statistical categories in your patron records (if you have them) to Alma. In Solars, it is possible to have multiple fields that contain statistical codes.

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

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

    Solars Stat 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 STAT_CATEGORY in the list, list all of the values from all three fields in Solars. 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.

    User Block Tab

    Solars stores patron block information in the BLOCK_TYPE and BLOCK_NO fields in the secondary patron block file. Provide the list of available blocks from Solars and their description, along with the block code as it should be in Alma.
    This mapping table is not mandatory.
    Solars BLOCK_TYPE and BLOCK_NO: The Solars Block type and block number, in the format: ‘block_type 1 and block_no 1’.
    Solars block Description: A description of the Solars block codes, 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 USER_STATUS.

    Campus Code Tab

    Use this tab only if you answered Yes to the question on the Questionnaire tab: Use a map for the BRCH_CODE to campus code migration? This mapping is not mandatory if you do not maintain separate patron campuses.
    Solars BRCH_CODE: The value of the patron home library as found in the BRCH_CODE field of the patron extract.
    Solars BRCH_CODE Description: A description of the BRCH_CODE field, for informational purposes only. This column is not used in the mapping.
    Alma Campus Code: The Alma campusCode. You may map the codes 1-to-1, or you may use this map to collapse codes.
    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.
    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

    Solars FINE_TYPE: List all of the values from the FINE_TYPE field in the Solars extract.
    Solars Description: A description of the FINE_TYPE, 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 Solars 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.
    Additionally, the patron deposit amount is reflected in Alma, but the deposit amount comes from a field in the patron record.

    Further Explanation – Fulfillment

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

    Identification Numbers

    The migration program allows for six different types of user identifiers: University ID, Barcode, and Additional ID 1, 2, 3, and 4. Select one of these identifier types as the primary ID – the primary unique identifier for the patron.  You may map multiple identifiers from your previous ILS.  You may also consider mapping email address, a common matchpoint in authentication systems, to an additional ID field.
    The following appears in the Solars Field Mapping Form:
    User Identifiers: Values in column A are the type of identifiers allowed for migration purposes; values in column B are your local Solars field names - change them as appropriate for your own data. Use the values in column A to make a selection for the Primary identifier selection in the Migration Form, questionnaire tab. ##.
    A B
    UNIV_ID ALT_PID
    BAR PID
    ADDL_ID_1 EMAIL
    ADDL_ID_2 FAX_NO
    ADDL_ID_3  
    ADDL_ID_4  
    So, if you put ALT_PID in the UNIV_ID field in the Field Mapping form, and you want that to be the user’s primary identifier, choose UNIV_ID for the user identifier question in the 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 Solars Migration Form.

    Acquisitions

    Vendors

    Provide the vendor file in csv format, one record per line, with fields delimited by ‘|’.
    The fields in the following table are expected. Indicate the local field names for the expected fields in the Vendors tab of the Solars Field Mapping Form.
    Field Name Notes
    CUST_NO Matches cust_no in order files
    CUST_NAME  
    SHORT_NAME  
    ZIP_CODE  
    ADDR  
    DETAIL_ADDR  
    ZIP_CODE2  
    ADDR2  
    DETAIL_ADDR2  
    PHONE1  
    FAX  
    MAJ_MAIL  
    HOMEPAGE  
    MANAGER  
    MANAGER_DEPT  
    MANAGER_TEL  
    UPDATE_DATE  
    NATN_CODE  
    Any additional fields not listed above can be put into notes. The possible note fields in Alma items are listed in the following table in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris.
    The text in the Note Label column are used as a prefix to the subfield contents and can be modified. The note label may be in Unicode. If you want to include multiple local fields in the same Alma note, copy the line in the spreadsheet as many times as needed for all note name/local field combinations.
    Note Name Default local Field Note Label
    VENDOR_NOTE BANK  
    VENDOR_NOTE ACCOUNT  
    VENDOR_NOTE BANK2  
    VENDOR_NOTE ACCOUNT2  
    VENDOR_NOTE REMARKS  
    VENDOR_NOTE RECEIPT_TYPE  
    USER_NOTE MEMBER_ID  
    ADDRESS_NOTE    
    DETAILS_NOTE    

    Purchase Orders

    There are many files that are expected from Solars in order to generate an order in Alma. The following table lists the expected files and where they are used.
    File Name Description Where to Use
    *_purchaseorder_acq_mst.csv Master file for monographic POs – links to value file with ACQ_ID + BRANCH_CODE mono + ser
    *_purchaseorder_acq_value.csv Contains the values (money) of the order mono + ser
    *_purchaseorder_ordl_mst.csv   mono + ser
    *_purchaseorder_dona_info.csv Donation information – notes mono + ser
    *_purchaseorder_note_mst.csv Notes mono + ser
    * acq_reg_info Specifically provides item location info and links to the item file mono + ser
    *_serial_q_info_view.csv Contains a link to the ordered bib number (C_ID) (from checkins, but used here)
    *_purchaseorder_ser_mst.csv MASTER: master file for serial POs ser
    *_purchaseorder_ser_ordl_mst.csv ORDL file: secondary file, linked to ORD file with BRCH_CODE and ORD_NO, also linked to master file with BRCH_CODE and IMID ser

    Monographic Orders

    Provide all order records in csv format, one record per line, with fields delimited by ‘|’.
    The fields in the following table are expected. Indicate the local field names for the expected fields in the Monographic Orders tab of the Solars Field Mapping Form.
    Field Name Notes
    FILE: ACQ_MST  
    BRCH_CODE Use as Library in Alma Location Map
    ACQ_ID Link to ACQ_ID in item
    REQ_DATE  
    ENT_DATE  
    IPID Use here only if the field contains a valid patron identifier; otherwise put the field in a note.
    BOOK_FLAG Use in Reporting Code map
    USE_TYPE Use in Reporting Code map
    IPID  
    RECEIPT_TYPE Use in the POAcqType map
    WORKER  
    DONA_NO Links to DONA_INFO file
    NOTE_NO Links to NOTE_MST file
    Q_ID Use to get bib_id in Q_info file
    CUST_NO If CUST_NO in ORDL_MST is blank, use this CUST_NO
    ORDER_MESSAGE  
    File: ACQ_VALUE  
    BRCH_CODE  
    ACQ_ID  
    COPY_CNT  
    CURR_CODE Use in the Currency Code map
    UNIT_PRICE  
    ADD_COST  
    EXCH_RATE  
    UPDATE_DATE  
    PAY_DATE  
    File: ORDL_MST  
    BRCH_CODE  
    ACQ_ID  
    CUST_NO  
    ORD_DATE  
    NOTE_NO  
    DELIVER_TYPE  
    File: DONA_INFO  
    BRCH_CODE  
    DONA_NO  
    DONA_DATE  
    DONA_TYPE  
    SEND_TYPE  
    SEND_GRP_NO  
    File: NOTE_MST  
    BRCH_CODE  
    ACQ_ID  
    NOTE_NO  
    NOTE_DESC  
    File: ACQ_REG_INFO  
    BRCH_CODE Branch code of the associated order (ordering unit)
    ACQ_ID  
    IDID Identifier of items that are related to order BRCH_CODE-ACQ_ID
    Any additional fields not listed above can be put into notes. The possible note fields in Alma items are listed in the following table in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris.
    The text in the Note Label column are used as a prefix to the subfield contents and can be modified. The note label may be in Unicode. If you want to include multiple local fields in the same Alma note, copy the line in the spreadsheet as many times as needed for all note name/local field combinations.
    LOCAL_PAY_PRICE is put into a note on the Purchase Order Line.
    Note Name Default Local field Note Label
    PO_NOTE ACQ_TYPE  
    POL_NOTE LOCAL_PAY_PRICE  
    POL_RECEIVING_NOTE    

    Serial Orders

    Provide all order records in csv format, one record per line, with fields delimited by ‘|’.
    The fields in the following table are expected. Indicate the local field names for the expected fields in the Serial Orders tab of the Solars Field Mapping Form.
    Field Name Notes

    File: SER_MST

     
    BRCH_CODE  
    IMID Links to SER_ORDL_MST (with BRCH_CODE)
    ACQ_ID Links to item file
    CLAM1_ITVL  
    File: SER_ORD_MST  
    This file is not needed  
    File: SER_ORDL_MST  
    BRCH_CODE  
    RECEIPT_TYPE  
    ORD_DATE  
    COPY_CNT  
    CNTR_SDATE  
    INV_REG_DATE  
    CURR_CODE  
    ADD_PRICE  
    EXCH_RATE  
    CHECK_DATE  
    WORKER  
    NOTE_NO  
    IMID

    Links to SER_MST file (with BRCH_CODE)

    CUST_NO  
    SUBSCRIBE_FEE  
    Any additional fields not listed above may be put into notes. The possible note fields in Alma items are listed in the following table in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris.
    The text in the Note Label column are used as a prefix to the subfield contents and can be modified. The note label may be in Unicode. If you want to include multiple local fields in the same Alma note, copy the line in the spreadsheet as many times as needed for all note name/local field combinations. The POL_RECEIVING_NOTE, the POL_VEND_REF_NO, and the POL_ADDL_NO should have only one local field per note.
    LOCAL_PAY_PRICE is put into a note on the Purchase Order Line.
    Note Name Default Local Fields Note Label
    PO_NOTE PUBL_STAT  
    POL_NOTE LOCAL_PAY_PRICE  
    POL_RECEIVING_NOTE This line cannot be duplicated; place only one local field name here.  
    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.  

    Funds

    Fund records are not exported from Solars. 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.
    The funds in the input file are only created for the current fiscal year. Initial allocations for the migrated funds are created from the Allocation field of the Fund Input file.
    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, since all of the funds go into a single active fiscal period. This uniqueness restriction applies across ledger codes, summary fund codes, and fund codes.
    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.  Matches fund code in order file.  This must be unique, even across ledgers.
    FUND NAME Alphanumeric, repeatable.
    LIBRARY Must be in the Alma Library List on the Solars Migration Form. The library code must match the code in the migration form exactly – match is case-sensitive. There can be multiple libraries here, separated by a semicolon. This field can be left empty, which means that all libraries in the institution can use the fund.
    If the central order library is used in the migration form, this field is ignored and all funds are set to the institution level, meaning that all libraries in the institution can use the fund.
    EXT ID External ID for linking to an external source, if one exists.
    ALLOCATION Allocation, in dollars, of the current fiscal year’s funds.

    Customer Input - Acquisitions

    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 BRCH_CODE field specifies the order location for orders in Solars. The migration attempts to map the BRCH_CODE field to the corresponding Alma Library. If you want to override this BRCH_CODE 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 BRCH_CODE 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 BRCH_CODE 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.
    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.
    Date to Indicate which Orders are Open
    Code: PO_DATE_OPEN
    Default: today (conversion date)
    Options: (YYYYMMDD or today)
    Further explanation: The migration programs look at the CHECK_DATE of the serial subscription, and compare it to the date you list here. If CHECK_DATE is earlier than this date, the order is closed. If CHECK_DATE is equal to or after this date, the order is open/sent. To use the date of conversion, type today.
    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

    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.
    RECEIPT_TYPE: The value of the RECEIPT_TYPE field in Solars, found in your order extract.
    RECEIPT_TYPE description: A description of the Receipt Type in Solars, 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 Receipt Type for use while filling out this form. This field is not used by the migration programs.
    Further explanation: 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.

    Reporting Code Tab

    This tab is optional if you are migrating orders.
    Solars BOOK_FLAG: Value of the Book Flag field in Solars, found in the BOOK_FLAG field in your order extract.
    Solars USE_TYPE or DONA_TYPE: Value of the Use Type or Dona Type field in Solars, found in your order extract.
    Description: A description of the BOOK_FLAG and USE_TYPE/DONA_TYPE field, for information only. This field is not used in the mapping to Alma.

    Further Explanation – Acquisitions

    PO Entry Point

    All monographic orders are migrated as CLOSED in Solars. For serial orders, if the CHECK_DATE is later than today, the order is SENT. Otherwise, the serial order is CLOSED.

    PO Line Type

    Monographic orders are migrated as PRINT_OT, and Serial orders are migrated as PRINT_CO. If the order is linked to a bibliographic record that is in the P2E (print to electronic) file, the order is transformed to the corresponding electronic order type (OT or CO) when the P2E process is run. See the P2E section for more information.

    "In Review"

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

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

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

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

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

    Transactions of Amount 0.00

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

    Libraries and Locations in Orders

    There are two different locations that are needed for the order:
    • ordering location – an acquisition unit
    • inventory location – destination of the inventory related to this order
    The inventory location is taken from the BRCH_CODE/LOC_CODE of the related item.
    The ordering location for Solars is taken from the order’s BRCH_CODE – there is no LOC_CODE for the ordering location. The BRCH_CODE needs to be mapped to an Alma library. The migration process uses the Alma Location Tab (see inventory section above) to map the single value BRCH_CODE to an Alma Library code. Since the map is two-level (BRCH_CODE/LOC_CODE – Library/Location), the migration programs take the first library found for the specified branch code.
    For example, in the following table:
    BRCH_CODE LOC_CODE Alma Library Alma Location
    01 08 Main Stacks
    01 02 Main Reference
    01 04 Archives Local
    There are two different Alma libraries for the single BRCH_CODE 01, Main and Archives. Since there is no LOC_CODE for the ordering unit in the order, we can only use BRCH_CODE in the map. The first line that matches BRCH_CODE 01 is used, in this case, Main.

    Orders for Multiple Bibliographic Records

    An order may have multiple items and/or multiple bibliographic records associated with it. If an order is associated with multiple bibliographic records, a single order is created and linked to the first bibliographic record found. The order is still linked to the inventory of the other bibliographic records. All of the inventory for all of the bibliographic records are listed in the Ordered Items section of the single PO Line.

    Serial Records Spanning Multiple Years

    Serial orders are often kept open or renewed over multiple years, with the same order being invoiced and received many times. In Solars, multiple copies of the same order are created. In Alma, there is only one copy of the order that is rolled over year after year. When migrating to Alma, the most recent serial order is placed in a SENT status, and the previous orders are placed in a CLOSED status. The most recent order is determined by CHECK_DATE.

    Monographic and Serial Orders

    In Solars, serial and monographic orders share some but not all of their information. The following is a chart that describes how serials (SER_MST) and monographic (ACQ_MST) orders are processed. Generally, the chart says:
    • Only make monographic orders if there is an item found in acq_reg_info file
    • Only make monographic orders if there is NOT a related serial order
    • Do not make a serial order if there was not a related acq_mst record
    • Serial orders can either be linked to item records through acq_reg_info file or to bib records through the q_info file
    flowchart.png

    Physical to Electronic (P2E) Processing

    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 Solars bibliographic system numbers that represent electronic resources and an indication if these electronic resources are portfolios or database resources. The list should be a comma separated text file containing lines that represent each e-resource. Structure each line as follows: 
    For example:
    000000001,Portfolio
    000000002,DB
    The words portfolio and db are not case-sensitive; therefore, both portfolio and Portfolio are acceptable.
    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'.
    In addition, indicate which locations represent electronic in the Location tab of the Solars Migration Form. The migration only converts items, holdings, and orders that belong to an electronic location in 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.
    During migration, all records are initially converted to Alma as physical. A second process converts records that you identify as electronic to the electronic format. 

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

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

    Customer Input

    Questionnaire Tab

    For each of the following three questions (P2E_LINK, P2E_NOTE, and P2E_PROVIDER), you can use indicators in the following manner:
    • Specific indicators: 85641u – only tags with 41 as the indicator is used.
    • No indicator (# is used for a blank character, for example: 8564#u) – only tags with 4 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 Electronic Location? column in the Alma Location tab of the Solars 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 Millennium 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.

    Further Explanation – P2E

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

    Appendix

    File Delivery and Form

    Each time data files are provided to Ex Libris in the formats indicated in Expected File Formats on page 7, place them on the secure drop-point on the Ex Libris MFT server with the access credentials provided by your Ex Libris project manager.
    The following is the default naming convention:
    CustomerName+DataType+sequence+date+[.].
    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.
    Provide the Solars Delivered Files Form along with the submitted files.

    Post-Migration Process Statuses

    The process statuses (codes) from the local system are mapped to the indexed internal note 3 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.
    • Was this article helpful?