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

    Virtua (III and VTLS) to Alma Data Delivery and Migration Guide

    Virtua is the Integrated Library System produced by VTLS, Inc., and which was purchased by Innovative Interfaces in 2014.  Subsequently, Innovative was purchased by ProQuest. Innovative/PQ refers to the product as vtls-Virtua, but for the purposes of this guide we will refer to it as Virtua, and sometimes Virtua (VTLS).
    This document serves three purposes:
    • A step-by-step guide to filling out the Virtua (VTLS) Migration Form.
    • A list of files required from Virtua/VTLS in order to migrate your data to Alma, including information about individual fields and how they map to Alma.
    • Further explanation of the migration rules for Virtua to Alma which do not require any customer input.

    Recommendations for Using this Guide

    This document is divided into four areas:
    • Inventory
    • Fulfillment
    • Acquisitions
    • Physical to Electronic
    Each area has the following sections:
    • File Validation: Information on files that are expected from Virtua and where incoming fields are mapped in Alma, including functional implications.  
    • Migration Form: Questionnaire Tab – Instructions for individual questions asked on the Questionnaire tab of the Migration Form.
    • Migration Form: Individual Tabs – Instructions for how to fill out individual tabs on the Migration Form. (Examples: Alma Library Tab, User Group Tab, PO Line Type Tab).
    • 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 out 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.

    Migration Overview

    The procedure for migrating from III/VTLS' Virtua to Ex Libris’ Alma consists of the following steps:

    Data Files

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

    For all files, the maximum file size is 2GB. 

    The Migration File Validation Tool is new in January 2019. Customers who used the legacy Field Mapping Form in their testload should continue to use it for their cutover. Check with your Ex LIbris consultant to use the Field Mapping form.

    Expected Files from Virtua

    Ex Libris expects a certain set of files to be exported from Virtua. The general expected file deliveries are listed below. The data elements listed for each are those that Ex Libris expects to use in conversion. Some data elements may exist in Virtua but are not necessary to bring to Alma.
    The scope of your specific conversion is agreed upon in your Alma contract.
    With the exception of bibliographic/item and holdings records which are expected in MARC format, all files are expected in CSV format with one record per line, fields delimited by quotes and commas, and multiple values within fields delimited by quotes and semicolons (for example two levels of address or multiple barcode values).
    The following is the default naming convention:
    CustomerName+DataType+sequence+date+[.<file_extension>]
    For example: centralu_bib_01_20120420.mrc, centralu_bib_02_20120420.mrc, centralu_bib_03_20120420.mrc, etc.
    Ex Libris recommends a maximum of 200,000 records per MARC file and 400,000 for other types of records (items, orders, etc).
    All records in a single file must be homogeneous – all of the lines in the file must have the same number of fields, and those fields must contain the same type of data. Additionally, all of the records must be delimited in the same manner.
    Provide the Virtua Delivered Files Form along with the submitted files.

    Migration Form and Validation

    Complete the Virtua Migration Form prior to the actual delivery of the data. The lead time depends on your project schedule.  The Virtua (III-VTLS) form is used by the migration programs to convert your data for use in Alma. Therefore, it is important that the data entered by the customer is valid so that the migration can continue on schedule.

    Your sandbox contains an online validation tool that helps ensure that your data is valid before you submit the form to Ex Libris. Information about this online validation tool can be found at: Validating the ILS Migration Form. Validate the Migration Form using the online Validation Tool, then download the validated Migration Form, which shows the validation report on the Report tab.  Send the validated Migration Form to your Ex Libris Project Manager.

    Inventory

    Bibliographic Records

    Bibliographic records are expected in MARC format. Standard MARC is preferred, but files in MARCXML format are also acceptable. The character encoding expected from Virtua is UTF-8 or MARC8. Deliver all files with the same character encoding.
    On migration, if a 001 field is present in the bib record, it is moved to an 035 field, along with the related 003 field, with a $9 value of ExL. Additionally, the former system number is placed in the 035 field using the institution code and the MARC organization code, as described in the MARC_OC question on the questionnaire tab of the Virtua migration form.
    If you use standard 7XX fields for linking between bibliographic records, this is leveraged during migration. If the relationships are based on your bibliographic record system numbers, provide the field that contains these system numbers in the migration form. Note: If you have loaded SFX MARCIt records into Virtua, 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 the records can be identified, and answer No to the question about SFX bibliographic record on the Questionnaire tab of the Virtua Migration Form.
    If the MARC holding record is migrated from Virtua, the 852 $b field is replaced with the newly-mapped $b and $c subfields. Use the questionnaire question MOVE_852C_SUBF to preserve any information that was in 852 $c in the Virtua holding record. If the MARC holding record is created based on information from the item, then additionally the $h and $i subfields are filled with the call number from the Virtua item field (item tag subfields $a and $b).
    For Virtua customers who are exporting MARC holding records, the migration process attaches migrated items to the MARC holding record. For Virtua customers who are not exporting MARC holding records or are exporting partial MARC holdings records, the migration process creates MARC holding records based on information in the Virtua item records.
    The following records types are handled as follows:
    • Bibliographic records with embedded items – Bibliographic records are expected in MARC format. The item records associated with each bibliographic record are expected in a tag in each bibliographic record.
    • Physical Inventory (item) records – Alma stores physical inventory records that are generated from the embedded items in the bibliographic record file.
    • Holdings records – Alma requires MARC Holdings records. We expect to receive a MARC Holding file from Virtua that contains holdings records for some, but not all bibliographic records. For items that do not have an existing holding record, holding records are generated upon conversion from location and call number information from the item records.
    • Electronic Resources (E-Resources) – 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. Provide a list of bibliographic records that represent electronic materials so they can be converted to electronic format after migration to Alma. The possible types of electronic resources are packages, databases, and portfolios.
    Bibliographic records are migrated as is and each bibliographic record may be modified in the following way during migration:
    • Australian customers will have ALL Bibs marked for Libraries of Australia Publish, if relevant.
    • OCLC records (records with an 035 |a with an OCLC-official prefix) will be marked for OCLC publish, if relevant.
    • The LDR position 9 (character coding scheme) is set to a indicating Unicode.
    Alma requires a MARC holding record for all items. During the migration process, the Alma library and Alma location are put in the following places in the MARC holding record:
    • The Alma library is placed in the 852‡b field.
    • The Alma location is placed in the 852‡c field.

    Suppressed Records

    If you are able to determine which bibliographic records are in the catalog but are not shown to the public (suppressed records), provide a separate text file containing the bibliographic record number for each suppressed record, one record number per line.

    Holdings

    Alma requires MARC Holdings records. There are multiple options for delivering holdings records from Virtua:
    • MARC Holdings – records are delivered in MARC format. Holdings are generated for any item records with no related MARC holdings.
    • From Bib – Summary statement embedded in a bib tag.
    • None – No holdings records are delivered. In this case, holdings records are generated from item information.

    MARC Holdings Records

    On migration, Ex Libris removes the contents of the 852 $a in MARC holdings records. If you want to preserve the information in the 852 $a, move it to a separate subfield prior to delivery for migration.
    If multiple 852 fields exist in a MARC holding record, the first 852 field is used and the subsequent fields are changed to 952. If a single 852 tag has multiple $b (incoming Virtua location) subfields, only the first instances of those two subfields are used and the extra $b is moved to $v.
    The incoming holding record has only a single level of location, expected in $b, but will use the Alma Location tab to map to two levels in Alma - $b and $c.  Call number subfields such as $h and $i remain as is.

    Holdings from a Bib Tag – Serials

    If there is information in a field embedded in the bibliographic record, the migration programs can generate a holdings record from it. To use this feature, indicate Yes on the Overview tab for Holdings from embedded bib tag (summary statement), and also fill in the values of the following fields in the Holdings section of the Migration File Validation Tool.
    If the SUMM_LIB_CODE and SUMM_LOC_CODE match an existing holdings record on the same bibliographic record, even a holdings record that was generated from items attached to the same holdings record, then the summary holdings statement will be attached to that holdings record, regardless of call number. In other words, the summary holding 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 bib with the same location, then a new holdings record is generated.
    Expected Field Name Mandatory Notes
    SUMM_TAG Yes 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 Yes Multiple subfields allowed, e.g. abz. May use # to indicate all subfields.
    SUMM_CALLNO No Textual call number to be used in all newly generated holdings records if desired.
    SUMM_LIB_SUBF No upper level of location.  Virtua has only one incoming level of location, so use this. This should be a single subfield code (like 'b') that 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_LOC_SUBF No do not use for Virtua migrations
    SUMM_LIB_CODE Yes If SUMM_LIB_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_LOC_CODE Yes do not use for Virtua migrations
    SUMM_PUBLIC_NOTE_SUBF No Public note, will be placed in 852 $z of the generated holding record
    SUMM_NON_PUBLIC_NOTE_SUBF No Non-public note, will be placed in 852 $x of the generated holding record

    Holdings from a Bib tag – Non-Serial

    If there is information in a field embedded in the bibliographic record that contains only a call number (no serial summary statement), the migration programs can generate a holdings record from it. To use this feature, indicate Yes on the Overview tab for Holdings from embedded call number tag, and fill in the values of the following fields in the Holdings section of the Migration File Validation Tool. If there is no existing holdings or item record on the bibliographic record, a new holdings record is generated for this bibliographic record, that is, we will only make a new holdings record if the bibliographic record is standalone.
    Expected Field Name Mandatory Notes
    HOLREC_TAG Yes Can be tag+indicators like 090##
    HOLREC_CALL_H Yes Information that will be put in 852 call number subfield h (call number first part)
    HOLREC_CALL_I No The rest of these are subfields for 852 - other call number parts.   See http://www.loc.gov/marc/holdings/hd852.html for usage
    HOLREC_CALL_J No  
    HOLREC_CALL_K No  
    HOLREC_CALL_M No  

    Determining Groups for Holding Record Creation/Matching

    If an existing MARC holding record from Virtua is found that matches the location or call number of the item, the item is linked to the MARC holding record. Otherwise, a new holding record is created for each group of item records that share the same location or call number. The permanent location and call number in Alma is stored only in the holding record. All items attached to the holding record inherit the permanent location and call number from the holding record. For example, if a bibliographic record has five items with no associated holding record:
    • 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 holding record’s call number, the differing call number is stored in the item’s Item Call Number field.

    Changing the Holding Record Grouping/Matching

    As part of the migration process, the customer must decide which criteria to use to group or match items to existing holdings and also to determine if multiple items belong on the same holding record. The location as mapped from Virtual to Alma is: $b Library $c Location $h Call Number Level 1 $i Call Number Level 2. By default, the migration programs compare $b and $c, but the customer can decide to change this to also include $h and $i based on items in their collection.
    For example, if there are four items and a single holding record on the same bibliographic record with the following call numbers:
    item 1 $b main $c stacks $h PN 567 $i .M4
    item 2 $b main $c stacks $h PN 567 $i .M4
    item 3 $b main $c stacks $h PN 567 $i .M4 2010
    item 4 $b bio $c flr1 $h PN 567 $i .M457
    holding record A $b main $c stacks $h PN 567 $i .M4
    When only $b and $c are used to determine a holding record group, the following is the result in Alma:
    Holding record A (migrated) $b main $c stacks $h PN 567 $i .M4
    item 1
    item 2
    item 3 (original call number stored in ItemCallNo field in the item)
    Holding record (generated) $b bio $c flr1 $h PN 567 $i .M457
    item 4
    When the holding record group is based on more subfields, for example $b $c $h $i, the following is the result in Alma: Holding record (migrated) $b main $c stacks $h PN 567 .M4
    item 1
    item 2
    Holding record (generated) $b main $c stacks $h PN 567 $i .M4 2010
    item 3
    Holding record (generated) $b bio $c flr1 $h PN 567 $i .M457
    item 4
    Decide which 852 subfields should be used to determine holding record groups by answering the question in the Questionnaire tab of the Virtua (VTLS) Migration Form, Indicate which 852 subfields to use to determine unique holding records.

    Call Number Type

    The 852 field has a first indicator that indicates what the call number type is. You need to indicate what class scheme to use when holding records are created using information from the item. Fill in the Call Number Type column on the Alma Location tab of the Virtua Migration form to indicate the class scheme per location.
    The available call number types can be found at http://www.loc.gov/marc/holdings/hd852.html.
    Supported on migration:
    # - No information provided
    0 - Library of Congress classification
    1 - Dewey Decimal classification
    2 - National Library of Medicine classification
    3 - Superintendent of Documents classification
    4 - Shelving control number
    5 - Title
    6 - Shelved separately
    8 - Other scheme
    Not supported on migration:
    7 - Source specified in subfield $2

    Items

    Item information is expected to be provided in one of two ways:
    • In tags embedded in the bibliographic record. Indicate which tag contains the item on the Embedded Items section of the Migration File Validation Tool. MARC holdings are not normally expected when the items are embedded in the bibliographic record, but any type of holding can be provided (MARC or from-a-tag-in-bib). 
    • In a separate CSV file, containing one item record per line. Indicate the local field names of your local item CSV file in the Items section of the Migration File Validation Tool. MARC holdings may or may not be expected if the items are delivered in an external CSV file.

    Items Embedded in the Bib Record

    The following table lists the expected subfields for item migration when the item is embedded in the bibliographic record. If your item subfields have different contents, indicate the subfield mapping in the Embedded Items section of the Migration File Validation Tool. Also, indicate on the same tab which tag contains the item record, such as 949.
    The maps that are indicated in the Notes column below are found in the Virtua Migration Form. See Inventory – Migration Guide for instructions on how to complete this form.
    Expected Field Name Expected Subfield Notes
    LOCATION D use Alma Location map. If only one level of location provided, use this one.
    Copy Number F  
    Item Class (Item Type) X use Item Type map
    Item Barcode 6  
    Call Number 1st part a  
    Call Number 2nd part b  
    Accession number e  
    Item Call Number a Be aware that if the 852_subfields_for_hol is set to 'bc' then the item call number may be filled in with a non-matched call number, and this field (and the next) may not be able to be used.
    Item Call Number b  
    Item Status s use Item Base Status map
    Units 9 This is an item description, for example: Vol 1 No 12 (Dec 2017)
    RECEIVE_NUMBER   Optional - In order to use the Receiving Number in Alma, you must configure an item sequence of type Receiving Number (Config menu -> Resources -> General -> Item Sequences).  See Configuring Physical Item Sequences.
    NO_LOANS  

    Optional – to pass the number of loans for the item. To see this value in Alma, search for the item under 'Physical Items' and on the results list click 'Other details'.

    Alma increments the loan count for items currently on loan, so it is recommended that you send (loans - 1) for currently loaned items.

    DATE_LAST_RETURN  

    Optional – to pass the last loan return date YYYMMDD of the item. To see this value in Alma, search for the item under 'Physical Items' and on the results list click 'Other details'.

    Note: the actual field in Alma is "Last Loan Date", which is not exactly the same as the "Last Return Date".  There is no "Last Return Date" field in Alma, so this is the best option for this value.

    Inhouse Use   Optional – to pass the number of inhouse uses (browse) for the item. To see this value in Alma, search for the item under 'Physical Items' and on the results list click 'Other details'.
    Inventory Number   Optional
    Copy ID   optional
    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 is used as a prefix to the subfield contents and can be modified, as desired. If you want to include multiple local fields in the same Alma note, copy the line in the spreadsheet as many times as needed for all note name/local field combinations.
    Note Name Default Local Subfield Note Label
    PUBLIC NOTE p Public note
    FULFILMENT_NOTE q Check-in note
    FULFILMENT_NOTE r Check-out note
    NON_PUBLIC_NOTE_1 o Internal Note
    NON_PUBLIC_NOTE_2    
    NON_PUBLIC_NOTE_3 d EPN
    STAT_NOTE_1    
    STAT_NOTE_2    
    STAT_NOTE_3    

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

    Items in CSV

    The following table lists the expected fields for item migration if the items are provided in a separate CSV file. Indicate the local field names in the Items CSV section of the Migration File Validation Tool.
    Customers who have provided items in CSV format may or may not also provide MARC Holdings. When MARC holdings are delivered, Ex Libris removes the contents of the 852 $a. If you want to preserve the information in the 852 $a, move it to a separate subfield prior to delivery for migration.
    The maps that are indicated in the Notes column below are found in the Virtua Migration Form. See Inventory – Migration Guide for instructions on how to complete this form.
    Expected Field Name Notes
    ITEM_ID  
    PARENT_TYPE Usually “Holdings”, so that the item will inherit the holding record’s library and location
    PARENT_ID This is a Holding record id, which is only used if the customer provides MARC holding records and the items are directly linked to MARC holdings.
    BIB_ID  
    BARCODE  
    ITEM_CLASS Use item type map (first column)
    STATUS Use itemBaseStatus map, and item type map (second column)
    UNITS Textual description of the item, for example, Vol. 1 No. 3 (Mar 2015)
    LOCATION Used in Alma Location Tab, Location column
    CALL_NUMBER_H this data element will be placed in 852 $h of the holding record
    CALL_NUMBER_I this data element will be placed in 852 $i of the holding record
    CALL_NUMBER_J this data element will be placed in 852 $j of the holding record
    SHELFLOCATION If this location is different than the LOCATION, then this will be set as the item's temporary location. If your library does not operate this way and SHELFLOCATION is simply the only location, then put SHELFLOCATION in the LOCATION field in the Migration File Mapping tool, and do not provide a mapped field for SHELFLOCATION.
    CIRCCOUNT  
    INHOUSE_USE  
    COPY_ID  
    INVENTORY_NUMBER  
    The same Virtua field may be mapped to both PURCHASE_PRICE and REPLACEMENT_COST, if desired

     

    PURCHASE_PRICE Inventory price
    REPLACEMENT_COST Use this only if the value is an actual replacement cost, which is used as a fine amount for a lost item
    Any additional fields not listed above may be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. The subfields listed in the 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 in the Local Field column as necessary. The text in the Note Label column is used as a prefix to the subfield contents and can be modified, as desired. If you want to include multiple local fields in the same Alma note, copy the line in the spreadsheet as many times as needed for all note name/local field combinations.
    Note Name Local Field Name Note Label
    PUBLIC NOTE NUMBER_OF_PIECES Public note
    FULFILMENT_NOTE PUBLIC_NOTE Check-in note
    FULFILMENT_NOTE   Check-out note
    NON_PUBLIC_NOTE_1 STAFF_NOTE  
    NON_PUBLIC_NOTE_2    
    NON_PUBLIC_NOTE_3   EPN
    STAT_NOTE_1    
    STAT_NOTE_2    
    STAT_NOTE_3    

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

    Enrich Items with Information from 853/863 from MARC Holdings

    Additionally, if the items in the Items in CSV file are directly related to holdings records, Ex Libris can populate the item’s DESCRIPTION and ENUM/CHRON fields with information from the 853/863 from the linked MARC Holdings record, if the Item in the CSV file does not have a description field. The UNIT field from the item is used first, and if it is empty, Ex Libris generates the description field from the MARC holdings. The description is generated for individual items based on the information in the 853/863 of the attached holding record. The algorithm for this is:
    • The barcode in the 863 $p of the holding record must match the barcode in the item.
    • Attach the item to the holding record with the corresponding 863 $p. (We are not going to go looking for an 863 $p. We expect it to be on the attached holding.)
    • If there are multiple 853s in a single holding record, the $8 is used to link between the 853 and its 863s.
    • The description is generated as follows: 853 $a + 863 $a + 853 $b + 853 $b etc., for all of the subfields abcdefghijklm. Spaces are placed between the data elements for readability. When there are parentheses around the word in the 853, do not show the word.
    • The original 853/863 is left in the holding record when it is loaded into Alma, but the 863s will no longer be used (you are encouraged to remove them post go-live). The 853 may be used in the future for serial prediction.

    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 Barcodes

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

    Because it is possible to use the barcode as the link between item and loan, request, or fine, if one of those is linked to an item with a duplicated barcode, it will be linked to the item with the unsuffixed barcode.

    Material Type

    The material type in Alma is a description of the type of material the item is such as book, map, issue, DVD, compact disc, etc. It is controlled by a fixed list of physical resource material types in Alma. Each item in Alma must have a material type specified.
    The migration automatically assigns an item material type on migration, 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 item material type in migration is derived from the bibliographic resource type, which is constructed by Alma based on the bibliographic header information. To see a description of how the material type is determined, see the Resource Type Field description.  

    Areas/Fields Not In Scope

    Boundwiths: Ex Libris does not expect to receive items from Virtua that are linked to multiple bibliographic records. If your library has cases where two or more bibliographic records are linked to the same item, consult your Ex Libris project manager.

    Inventory – Migration Form

    Alma requires bibliographic, holdings, and item records. Virtua may or may not have a holding record for each item. On migration, an attempt is made to link an item to an existing holding record. If a holding record is not found for an item, one is created based on information in the Virtua item record. See the MARC Holding Records section for more information.

    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, CUST_NAME – these are mandatory and must be filled in.
    Default: N/A
    Options: This question is mandatory.
    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).

    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 Virtua 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 the bibs that you want to exclude from loading into Alma. The migration programs search for the string in the 035 $a field of the MARC record. If you do not want to exclude any such records, leave this field blank.
    If the migration programs identify bib records containing the prefix in the 035 $a and the records in Virtua 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.

    MARC Organizational Code

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

    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, indicate bc here. If you have many items on the same bibliographic record in the same library/location but different call numbers WITHIN that library/location, and you want each of them to have their own distinct holding record, specify additional call number subfields. Acceptable subfields are: bchijklmp.
    The library and location codes are matched after the Alma Location Mapping has been performed, meaning the match is done on the Alma version of the library/location codes.

    Do you want to use a call number in the generated holdings records?

    Code: CALL_NO_IN_HOL

    Default: Yes

    Options: Yes or No

    Further Information: You may choose to generate holding records without any call number, so that the 852 contains only $b (library) and $c (location).   Values in the incoming Item Call Number field are placed in the Alma Item Call Number, and AltCallNo is not used when this is set to Yes.  Further, customers should only use ‘bc’ for the 852_CALL_NO_FOR_HOL question when this is No.

    Move 852$c to Another Subfield

    Code: MOVE_852C_SUBF
    Default: k
    Options: optional
    Further Information: If you have data in your Virtua holdings record 852 $c, it must be moved to a different subfield to accommodate the two levels of location in Alma – Alma Library and Location are in 852 $b and $c. Decide to which subfield you want the $c information moved. If you wish to delete the subfield entirely, leave the response blank. 
    Subfield $c is only moved for the relevant 852 tag. This means that if there are multiple 852 tags in the same holding record, the $c is only moved for the first 852 tag to make room for the sublocation in $c in Alma.

    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.  bibliographic records without location information (standalone bibs) are included.
    Inventory and Acquisitions are filtered by locations on the Location Tab, and Fulfillment is filtered based on campus codes in the Campus Code Tab. Use this option only if agreed upon with your Ex Libris project manager.

    Bib Key Prefix

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

    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

    Move 001/003 to 035 or 935

    Code: 001_035_935

    Default: 035

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

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

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

    001 12345

    003 OCoLC

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

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

    Use subfield indicators in item call number (AltCallNo)

    Code: ITEM_CALLNO_SUBFIELD

    Default: Yes

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


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

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

    Add $9 LOCAL to specified tags

    Code: NZ_LOCAL_TAGS

    Default: empty

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

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

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

    Alma Library Tab

    Use this tab to create a list of Libraries in Alma. At least one library is mandatory.
    Alma Library Code: Maximum 10 characters. Mixed case is valid, but not recommended. Do not use special characters or spaces. Allowed: - and _ (hyphen and underscore). Not allowed: !@#$%^&*()+=/?><.,\|]}[{`~ or the space character.
    The Alma Library Code may not be the same as the Alma Customer Code or the Alma Institution Code.
    Alma Library name: Maximum 255 characters. Visible to the public.
    Address lines: Alma allows you to specify address, phone, and e-mail information about each library. It is mandatory for a library to have a shipping/billing address in order to place orders in Alma. The migration process sets the designated address provided with all possible types in Alma (shipping, billing, claiming, etc.). At least one address line is mandatory.
    Email: An email address is mandatory. The migration process sets the email address provided with all possible email address types in Alma.
    Phone: The phone number must contain dashes (nnn-nnn-nnnn). A phone number with no dashes is not accepted by the migration program. Not mandatory.
    Default language: Indicate the language of patrons and/or staff members if it differs for each library. Use two-letter codes as defined in ISO 639-1. Consult the codes at https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes
    Further Explanation: Alma has two levels of location: library and physical/shelving location. Virtua may have one level or two levels, depending on local implementation.  Locations in Virtua are generally analogous to the physical/shelving locations in Alma. Libraries are higher level units which contain groups of locations. Alma libraries serve as higher-level repositories for physical records and also determine policy groupings for their management and fulfillment. The lower-level physical location does not determine policy for an item and is only the physical shelving location or collection. All physical resources in your institution must belong to a library.
    If your implementation of Virtua has two levels of location (upper and lower), these may map directly into Library and Location in Alma.  If you have only one level, you will need to group your Virtua locations into library groupings. The first step is to determine the list of libraries, using this tab. Next, map locations into Alma libraries and locations using 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.

    Alma Location Tab

    Use this tab to map your Virtua locations to Alma libraries and locations. 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.
    Virtua Location Code: Value from the Location field in the item extract, 949 $g in the embedded item tag in the bib, or the 852$c in the MARC holdings extract from Virtua. If your library is migrating items from a CSV file, this is in the LOCATION field of the item file.
    The ALMAME_VAL_NOT_FOUND line is required to catch any location codes you may have missed.
    Virtua Location Description: A description of the location, for assistance in filling out this form. This column is not used in the mapping routine.
    Alma Library Code: The Library which will contain this location in Alma. This code must be present on the Alma Library Tab, column A. The match is case-sensitive.
    Alma Location Code: The new location code for this location in Alma. It can be a maximum of 10 characters. You can use the same location codes in Alma that you used in Virtua, but this is not required. You may also use this form to collapse locations if desired, for example, refa and refb in Virtua both map to ref in Alma. Mixed case is valid, but not recommended. Do not use special characters or spaces. Allowed: - and _ (hyphen and underscore). Not allowed: !@#$%^&*()+=/?><.,\|]}[{`~ or the space character.
    Call Number Type: List the call number type for any newly created holdings records, based on the values for the 852 first indicator. (http://www.loc.gov/marc/holdings/hd852.html). If we cannot determine the call number type from the item record itself, we use this as a default for all items in the location.
    Alma Location Name: A description for this location as seen/used by library staff members. The same location name cannot be used for different locations in the same library, but the same location name can be used for different locations in different libraries. See the examples in the Further Information section below for what is acceptable and not acceptable. Maximum 255 characters.
    Alma External Location Name: A description for this location as seen/used by the public. The same name can be used for as many different locations as desired. For example, the location names may be Archives A and Archives B, but the external location names can both be Archives. Maximum 255 characters.
    Electronic Location? (Yes or No): Used by the P2E migration process to determine if a holding/item/order should be converted to electronic. See 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 wish to stop using a location code after migration, map the Virtua code to an easily identifiable code such as XXX or unused just in case any stray items are still in your Virtua database.

    ALMAME_VALUE_NOT_FOUND

    The ALMAME_VALUE_NOT_FOUND line must be included at the top of the list of locations, in case any location codes were overlooked when completing this map. For example, you may think 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.
    Virtua Upper Level Location Virtua Lower Level Location Alma Library Alma Location Code Alma Location Desc Alma External Loc Desc etc
    ALMA_ME_ VALUE_NOT _FOUND   MAIN UNASSIGNED Problem location from Migration Problem: See Library Staff  
    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 III 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 III code to an easily identifiable code such as XXX if any stray items are still in your III database.
    If you collapse location codes, you may have lines in the table such as the following:
    Virtua Upper Level Location Virtua Lower Level Location Alma Library Alma Location Code Alma Location Name Alma External Loc Name Suppress from Externalization Electronic Location
    MAIN reserves MAIN RESERVES Reserves Reserve Yes No
    MAIN reservesElec MAIN RESERVES Reserves ReserveElec Yes Yes
    MAIN reservesShort MAIN RESERVES Reserves Reserve Yes No
    MAIN 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 Base Status Tab

    Use this tab to map your item statuses to Alma. This tab is not mandatory if you do not want to migrate your item statuses to Alma.
    STATUS (or $s): The value in the status field from the Millennium item extract. The status typically indicates what is happening to the item, such as in binding, in repair, lost, etc.
    Description: The description of the STATUS code. The text in this column is written to the internal note 1 in the item in Alma. Maximum 255 characters.
    baseStatus: 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, lib use only is on the shelf (1), but withdrawn is not (0).
    Further Information: Alma has a process type that indicates the status of an item depending on the Alma workflow (item is on loan, item is sent to the bindery, etc.), but the process type is dependent on the corresponding Alma workflow.  It is important that during migration, we do not duplicate a status that is also present based on a work flow.  Examples of this are: On loan and Requested - waiting for pickup.  The loan and the request record will migrate and consequently the item will be listed as not available because of the presence of the loan and/or request record.
    For migration, all item statuses that are indicated as not on the shelf (0) from Millennium 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.
    You should include any status that indicates 'Available', but indicate that the item is on shelf and then leave the mapped description column 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.
    Post migration, you can search for and re-route items with values in the internal note 1 to the appropriate handling or department in Alma. This process can also be used as a configurable criterion for suppressing items from display in the Get It services screens from discovery systems. See Appendix A - Post-Migration Process Statuses for more information.

    Item Type Tab

    Use this tab to migrate the Virtua Item Class ($x) and optionally the Virtua Item Status ($s) to the Alma Item Type. Optional. The item type in Alma is not required, so if you leave this tab blank, no item policies in Alma are created.
    Virtua Item Type: The value in the item type field of the Virtua item. The item type is used to differentiate between items when determining how something circulates.
    Virtua Description: The description of the Virtua item type, for information only. This column is not used during the mapping process.
    Virtua Item Status: (Optional) If the item type is not enough to determine the item policy in Alma, then the item status may be used as a distinguishing factor. This field is not mandatory and you may only choose to fill it in where distinction is needed.
    Virtua Item Status Description: The description of the Virtua item status, 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 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.

    Fulfillment/Patrons

    The following records types are handled as follows:
    • Patrons – generated from a patron extract from Virtua. In order to migrate any area of fulfillment (fines/ fees, loans, requests), all patrons must be migrated.
    • Loans – generated from the circulation transaction extract for active loans only.
    • Hold requests - provide only active hold requests where the item is on the hold shelf waiting to be picked up.
    • Fines/Fees - active (open) transactions only

    Ex Libris does not expect to receive course reserve information.    If your library wants to migrate course details, consult your Ex Libris project manager.

    Patrons

    Extract all patrons. Provide the patron files in csv format. The fields in the following table are expected. Indicate the local field names for the expected fields in the Patrons section of the Migration File Validation Tool.
    Field Name Notes
    PATRON_ID  
    PATRON_TYPE use "User Group" map
    LAST_FIRST_NAME Use this if the patron’s name is delivered in a single field and structured like: “Jones, Danny”
    LAST_NAME Use LAST_NAME and FIRST_NAME fields if patron’s name is delivered in two separate fields
    FIRST_NAME Use LAST_NAME and FIRST_NAME fields if patron’s name is delivered in two separate fields
    PREFIX  
    PRIMARY_ADDRESS  
    POSTAL_CODE  
    CITY  
    STATE  
    COUNTRY The migration programs do not standardize this country name/code.
    PRIMARY_TELEPHONE  
    SECONDARY_TELEPHONE  
    PRIMARY_E_MAIL  
    SECONDARY_E_MAIL  
    HOME_LIBRARY use “Campus Code” map if desired
    PREFERRED_LANGUAGE  
    SECONDARY_ADDRESS  
    POSTAL_CODE_SECONDARY  
    CITY_SECONDARY  
    STATE_SECONDARY  
    COUNTRY_SECONDARY The migration programs do not standardize this country name/code
    BARCODE This is the only patron ID currently expected from Virtua. If you have others, fill in your own field names. The value in column C  is used in the Virtua Migration Form to select which ID is used for the primary identifier.
    BIRTH_DATE Must contain full date. Year alone is not acceptable.
    PRIVILEGES_EXPIRE may be left empty
    BLOCK_1 use in User Block mapping tab on VTLS migration form
    BLOCK_2  
    BLOCK_3  
    BLOCK_NOTE_1 an optional note which is associated with the block code
    BLOCK_NOTE_2  
    BLOCK_NOTE_3  
    Any additional fields not listed above are not functional and may be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris. If you use other field names or have fields that you want to include in the migration, but are not expected by Ex Libris, you can rearrange, add, or subtract fields on the right, as necessary. If you want to include multiple local fields in the same Alma note, copy the line in the spreadsheet as many times as needed for all note name/local field combinations.
    Note Name Default Local Field
    LIBRARY_NOTE NOTE
    LIBRARY_NOTE NOTE_TYPE
    BARCODE_NOTE  
    ADDRESS_NOTE PREFIX
    ADDRESS_NOTE NOTICE_DELIVERY_PREF
    ADDRESS_NOTE  
    CIRC_NOTE CIRC_NOTE is marked by the migration programs as a popup note. This is the only user note which migration marks as a popup note.
    OTHER_NOTE This note is marked as user viewable by migration.  This is the only note which migration marks as user viewable.

    User Stat 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 PATRON TYPE, but you may want to track the department, so that you can get more detailed statistics on how Law students borrow, for example. We provide you the option to map the data from any field to the User Statistical Categories in Alma.

    If you have categories which overlap, such as LAW as department and LAW as major, you can prefix the category in the Migration File Validation tool, using the 'prefix' input box to the right of the mapped field.  For example you can say DEPT: LAW and MAJ: LAW.  The validation tool will not provide a colon, so if want the colon be sure to include it , e.g. 'DEPT:', but it 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). 

    You may provide up to 10 statistical categories.

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

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

    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.
    ##User Identifiers: values in column A are the expected Virtua field names; values in column B are your local field names. Values in column C are values to use when choosing a primary ID in the Virtua Migration Form.##
    A B C

     

     

    UNIV_ID

    BARCODE

    BARCODE

    BAR

     

     

    ADDL_ID_1

     

     

    ADDL_ID_2

     

     

    ADDL_ID_3

     

     

    ADDL_ID_4

    Typical Virtua customers have only the BARCODE as the user identifier, but if your library has additional identifiers, fill them in columns B and C. Then, on the Virtua (VTLS) Migration Form, Questionnaire tab, select the identifier from column C to use for the primary identification number for your internal and external patrons to use when authenticating from an external system (for example Primo).
    Whichever identifier is chosen for 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 an identifier type from the drop-down list.

    Active Loans

    Extract only current circulation transactions, in csv format.
    The fields in the following table are expected. Indicate the local field names for the expected fields in the Loans section of the Migration File Validation Tool.
    Field Name Notes
    BARCODE matches barcode |6 in bib/item file
    CHECKOUT_DATE  
    DUE_DATE  
    PATRON_ID matches PATRON_ID in patrons
    Any additional fields not listed above may be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris. If you use other field names or have fields that you want to include in the migration but are not expected by Ex Libris, you can rearrange, add, or subtract fields on the right, as necessary.
    Note Name Default Local Field
    NON_PUBLIC_NOTE CHECKOUT_LOCATION
    NON_PUBLIC_NOTE NAME
    NON_PUBLIC_NOTE LOCATION
    NON_PUBLIC_NOTE SHELFLOCATION
    NON_PUBLIC_NOTE CHECKOUT_TYPE
    NON_PUBLIC_NOTE LAST_NOTICE_DATE

    Fines/Fees

    Extract only open fine/fee transactions with an outstanding balance, in csv format.
    The fields in the following table are expected. Indicate the local field names for the expected fields in the FineFee section of the Migration File Validation Tool.
    Field Name Notes
    ITEMID Matches item ID in item file
    BALANCE  
    DESCRIPTION Use in Fine Fee Type map
    ITEM_DUE_DATE This is mapped to the Alma Fine Fee Create Date. Alma does not store the Item Due Date in the fine.
    LOCATION_ID  
    PATRON_ID Matches user ID in patron file
    Any additional fields not listed above may be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris. If you use other field names or have fields that you want to include in the migration but are not expected by Ex Libris, you can rearrange, add, or subtract fields on the right, as necessary.
    Note Name Default Local Fields
    FINE_FEE_COMMENT  

    Requests

    Extract only active/trapped hold requests which are on the shelf waiting for patron pickup, in csv format. The fields in the following table are expected. Indicate the local field names for the expected fields in the Requests section of the Migration File Validation Tool.
    Field Name Notes
    ITEM_ID Matches item ID in items
    LOCATION  
    DATE_PLACED  
    PATRON_ID Matches user ID in patrons
    DATE_SET Date item was trapped and placed on hold shelf
    EXPIRATION_DATE If no local field, then put a constant for the number of days after DATE_SET for expiration. For example, if you put '10' then the expiration date will be 10 days after the DATE_SET
    Any additional fields not listed above may be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris. If you use other field names or have fields that you want to include in the migration but are not expected by Ex Libris, you can rearrange, add, or subtract fields on the right, as necessary.
    Note Name Default Local Fields
    NON_PUBLIC_NOTE  

    Fulfillment/Patrons – Migration Form

    Patron records are required if loans, requests, or fines are being migrated. Patron records can be updated post-migration with the patron update routines.

    Questionnaire Tab

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

    Code: PATRON_PRIMARYID
    Default: UNIV ID
    Options: Using the Virtua (VTLS) Field Mapping Form, map the identifiers exported from Virtua into the following list: UNIV ID, BARCODE, ADDL ID 1, ADDL ID 2, ADDL ID 3. Then, select here the identifier which should be used as primary for all patrons.
    Further Information: The identifier selected here is used as the match point for externally managed patron records to match up with an external authentication system such as LDAP or Shibboleth.  Additionally, this identifier will be the primary identifier for internally managed patrons. It is highly recommended to use the Primary Identifier as the identifier for authentication. Note that Primary Identifier is not case-sensitive, as opposed to all other identifiers, which are case-sensitive.
    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

    Enter a two-letter code for the default conversational language for your users (for example en or fr)

    Code: PATRON_LANG
    Default: en
    Options: Use the two-letter codes as defined in ISO 639-1. Consult the codes from https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes. Additionally, the language code zh-tw (Taiwanese Mandarin) is acceptable.

    Currency for patron fines

    Code: CURRENCY
    Default: USD
    Options: Use the three-letter code 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 HOME_LIBRARY to campus code migration?

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

    Request Default Destination Library

    Code: REQUEST_LIBRARY
    Default: None
    Options: If the requests file does not contain a destination library/location, the library you enter for this question is used as the default for where patrons will usually pick up requests from the hold shelf.

    Merge Patron Prefix 

    Code: MERGE_PATRON_PREFIX

    Default: No

    Options: If you are combining data from two or more separate databases into a single combined institution in Alma, then indicate a prefix here that will be used to distinguish the incoming patron record original IDs.  This prefix is only added to the internal patron identifier, it is not added to barcodes or usernames or UNIV_ID.  If you are not merging institutions, leave this question blank.

    See also: BIB_KEY_PREFIX and FUND_PREFIX

    User Group Tab

    The user group is used to distinguish groups of patrons from each other in determining different levels of circulation policies. Typical user groups are faculty, staff, undergrad, etc.
    If patrons are being migrated, then this mapping table is mandatory.
    Virtua PATRON_TYPE: The Virtua patron type code, found in the PATRON_TYPE field of the patron extract.
    Virtua Description: A description of the Virtua patron type code, here for information only. This column is not used in the mapping to Alma user group.
    Alma userGroup Code: The mapped group code in Alma. You may choose to use the same codes that you used in Virtua, or you may choose to use different codes. You may also choose to collapse groups if desired, for example, having Freshman and Sophomore both map to Undergrad in Alma. Do not use special characters, for example slashes (/) or spaces in the code.
    Alma userGroup Description: The description of the Alma userGroup. This description is loaded into the Alma code table as the description seen 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. When Y, all of the patrons in the Alma userGroup are categorized as internal. When N, all of the patrons in the Alma userGroup are categorized as external.
    External users are fully external (except patron notes), including all user identifiers, authentication, and address information. See also the following question on the Questionnaire tab, regarding Internal or External users:
    • Which identifier should be used as the patron's Primary Identifier?

    Campus Code Tab

    Use this tab only if you answered Yes to the question on the Questionnaire tab: Use a map for the HOME_LIBRARY to campus code migration? This mapping is not mandatory if you do not maintain separate patron campuses.
    The Alma User Campus field is used to determine a patron’s affiliation for ILL or cross-campus borrowing. If your library maintains the HOME_LIBRARY field in Virtua for a similar purpose, map the HOME_LIBRARY value to the Alma Campus Code value with this map.
    Virtua HOME_LIBRARY: The value of the patron home library as found in the HOME_LIBR field of the patron extract.
    Virtua HOME_LIBRARY Description: A description of the HOME_LIBRARY field, for information only. This column is not used in the mapping.
    Alma campusCode: The Alma campusCode desired. You may map the codes 1-to-1, or you may use this map to collapse codes if desired.
    Alma campusCode Description: A description of the Alma campusCode, for informational purposes only. This field is not loaded into Alma.

    Fine Fee Type Tab

    Use the tab to specify the type of fine/fee as it is migrated to Alma, based on the type of the fine/fee from Virtua.
    Virtua DESCRIPTION: List all of the values from the DESCRIPTION field in the Virtua extract.
    Virtua Description: A description of the DESCRIPTION field, 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 fines from Virtua 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.

    Acquisitions

    The following records types are handled as follows:
    • Vendors – migrated from the vendor extract.
    • Funds – generated for the current fiscal year based on a single list of funds; allocation transactions are generated for the current fiscal year only.
    • Purchase Orders – migrated from the purchase order extract. Encumbrance transactions are generated for the current fiscal year only.

    Vendors

    Provide the vendor file in csv format. The fields in the following table are expected. Indicate the local field names for the expected fields in the Vendors section of the Migration File Validation Tool.
    Field Name Notes
    VENDOR_ID  
    NAME  
    ADDRESS_1  
    ADDRESS_2  
    ADDRESS_3  
    CITY  
    COUNTY_OR_PARISH  
    STATE_OR_PROVINCE  
    POSTAL_CODE  
    COUNTRY_CODE  
    TELEPHONE_NUMBER  
    FAX_NUMBER  
    CONTACT not repeatable
    EMAIL_ADDRESS  
    CLAIM_INTERVAL  
    ORDER_LEAD_TIME  
    PREFERRED_LANGUAGE  
    URL  
    FINANCIAL_SYSTEM_CODE  
    Any additional fields not listed above may be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris. If you use other field names or have fields that you want to include in the migration but are not expected by Ex Libris, you can rearrange, add, or subtract fields on the right, as necessary.
    Note Name Default Local Fields
    VENDOR_NOTE CLAIM_INTERVAL
    VENDOR_NOTE RECLAIM_INTERVAL
    VENDOR_NOTE ORDER_CURRENCY
    VENDOR_NOTE INVOICE_CURRENCY
    VENDOR_NOTE PAYMENT_CURRENCY

    Funds

    Fund records are collected into an Excel migration form, then exported to CSV and delivered to Ex Libris for loading into Alma. Funds are not extracted from Virtua directly. All funds must be listed on a single tab (the first tab on the spreadsheet) before exporting to CSV. You can submit separate CSV files, but they must be physically separate files and not multiple tabs on the same sheet. Each csv file must contain a header line with the field names, as described below.
    In the fund file, LEDGER CODE, LEDGER NAME, FUND CODE, and FUND NAME are mandatory. Ledgers are mandatory and if your institution does not have ledgers in the current ILS, define one general ledger for use in Alma. Note that fund codes are unique across the entire fiscal period, not just within specific hierarchies. Therefore, there should be no fund code duplication in the spreadsheet submitted, since all of the funds go into a single active fiscal period.
    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 (This is the fund code that links to the fund code in the extracted order record.)  Must be unique, even across ledgers.
    FUND NAME Alphanumeric, repeatable
    LIBRARY Must be in the Alma Library List on the Virtua 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.
    FY Fiscal Year YYYY
    NOTE optional note for the fund

    Encumbrances

    Transactions from active purchase orders are created as encumbrances in Alma when the orders fund reference is valid and exists. An active purchase order is defined as one in which the mapped PO entry point is NEW, SENT, or WAITING_FOR_INVOICE and is in the current fiscal year.

    Transactions of Amount 0.00

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

    Orders

    Provide the purchase order file in csv format. The fields in the following table are expected. Indicate the local field names for the expected fields in the Orders section of the Migration File Validation Tool.
    Ex Libris expects to receive a purchase order file with a single line for each purchase order line. Each purchase order line that is attached to the same purchase order header in Virtua should have a common number in the PURCHASE_ORDER_ID field. On migration, the purchase order lines are grouped according to the PURCHASE_ORDER_ID and are attached to the same purchase order header for loading into Alma.
    Field Name Notes
    PURCHASE_ORDER_ID Purchase order header number. It is used to group multiple purchase order lines together.
    BIBLIOGRAPHIC_ID  
    PRICE  
    DATE_DUE  
    QTY_ORDERD  
    CURRENCY  
    QTY_INVOICED  
    SUBSCRIPTION_BEGINS  
    SUBSCRIPTION_ENDS  
    CANCEL_DATE  
    FUND CODE Links to a fund code in the fund file. This can be provided in multiples, separated by a semicolon. For example: “...”,“fund1”;”fund2”;”fund3”,”…”
    LOCATION_ID  
    INTERNAL_LINE_ID Purchase order line number.
    ORDER_STATE Use in the PO Entry Point map
    VENDOR_ID Links to the vendor ID in the vendor file.
    ORDER_TYPE Use in the PO Line Type map
    REQUESTOR_ID Only provide a local field name here if the local field contains an identifier that links to the patron file. Otherwise, put the information in the notes.
    ACQ_METHOD This must either contain Alma Acq Method values of PURCHASE, APPROVAL, GIFT, VENDOR_SYSTEM, DEPOSITORY, EXCHANGE, TECHNICAL, LEGAL_DEPOSIT, or be left blank. If blank, all are set to PURCHASE.
    ACCOUNT_PERCENT Percentage of fund distribution. When there is one fund code, this is assumed to be 100 percent. When there are multiple fund codes, the number of values should match the number of values in FUND_CODE.  For example: “...”,“25”;”25”;”50”
    REPORTING_CODE_1

    Use the PO Reporting Code map to map values to the Alma Reporting Code field.  The values in columns C and D are used to make the 1st Reporting Codes code table.  No prefix is necessary here since the PO Reporting Code map allows only one incoming value.

    Note: this needs to be manually filled in until the Migration File Validation Tool is updated.

    REPORTING_CODE_2

    Use the PO Reporting Code 2 map to map values to the Alma Reporting Code 2  field.  The values in columns C and D are used to make the 2nd Reporting Codes code table. No prefix is necessary here since the PO Reporting Code 2 map allows only one incoming value.

    Note: this needs to be manually filled in until the Migration File Validation Tool is updated.

    REPORTING_CODE_3

    Use the PO Reporting Code 3 map to map values to the Alma Reporting Code 3 field.  The values in columns C and D are used to make the 3rd Reporting Codes code table. No prefix is necessary here since the PO Reporting Code 3 map allows only one incoming value.

    Note: this needs to be manually filled in until the Migration File Validation Tool is updated.

    Any additional fields not listed above may be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris. If you use other field names or have fields that you want to include in the migration but are not expected by Ex Libris, add them on the right as needed. The vendor reference number, the additional number, and the receiving note may only be listed once, but you may make as many duplicate lines for PO_NOTE and POL_NOTE as necessary.
    Note Name Default Local Field
    POL_VEND_REF_NO This line cannot be duplicated; place only one local field name here.
    POL_ADDL_NO This line cannot be duplicated; place only one local field name here.
    POL_RECEIVING_NOTE This line cannot be duplicated; place only one local field name here.
    PO_NOTE INTERNAL_PURCHASE_ORDER_ID
    PO_NOTE VENDOR
    PO_NOTE PURCHASE_REQUEST_STATUS
    POL_NOTE SUBJECT_CODE_ID
    POL_NOTE SUBJECT
    POL_NOTE ISBNISSN
    POL_NOTE TITLE
    POL_NOTE AUTHOR
    POL_NOTE PUBLISHER
    POL_NOTE PLACE_OF_PUBLICATION
    POL_NOTE PUBLICATION_DATE
    POL_NOTE MUSIC_NUMBER
    POL_NOTE PRIORITY
    POL_NOTE QTY_PAID
    POL_NOTE COVERAGE
    POL_NOTE HOLDINGS_ID
    POL_NOTE REQUESTOR_ID
    POL_NOTE REQUESTOR
    POL_NOTE SOURCE_ID
    POL_NOTE SOURCE_OF_SELECTION

    Orders from the HOL Tag

    In some cases, order information can be stored in a field in the holding record. To make orders out of such a field, fill in the information on this tab.
    Specify the tag and indicators, such as 941## (# means any value)
    Make an order record if 008 position 06 equals 3 or 4. Do not make an order record if 008 position 06 equals 1, 2, or 5. Add notes from all 930 tags in the holding record and all subfields except $x. (930 is repeatable.)
    Field Name Notes
    $a Vendor-ID Purchase order header number. Used to group multiple purchase order lines together.
    $b Vendor Title Number  
    $c P.O. #  
    $e Order Date  
    $i Claim Interval  
    $m Subject Code  
    Defaults: There are no inputs expected from the data, so all orders will have the same selected value. Select from the available choices from the drop-down lists.
    Acquisition Method PURCHASE, APPROVAL, GIFT, VENDOR_SYSTEM, DEPOSITORY, EXCHANGE, TECHNICAL
    PO Line Entry Point NEW, SENT, CLOSED, CANCELLED
    PO Line Type PRINTED_BOOK_OT, PRINTED_JOURNAL_CO, PRINTED_BOOK_SO, PRINT_OT, PRINT_CO, PRINT_SO, PRINT_SO_NONMON, OTHER_SERVICES_OT, OTHER_SERVICES_CO
    Subscription Interval Constant (days)
    Expected Receipt Date Constant (date)

    Notes

    Other fields from the tag may be placed in the order notes.
    Note Name Default Local Field
    POL_NOTE  
    POL_NOTE  
    POL_NOTE  

    Acq - Further Information

    POL Copies/Inventory Handling

    Alma has a very tight inventory to POL connection. Not all ILS source systems have the same requirement that inventory be linked to orders. Due to this, the migration process cannot always link inventory to orders. The following describes various cases:
    • One Time Orders
      • One time orders generally do not link to any specific item in source ILS systems. Only with a specific item id in hand can the location/copy information on such POLs be created.
      • Since there is generally no such connection, we pass only the intended library/location and quantity in the POL receiving note, which most source systems do provide. This information allows the receiving/purchase operator upon receipt to:
        • Open the POL and add the relevant copy which is being received - presuming the item wasn't created prior to the receipt.
        • At this point, the item can be received normally.
      Less common case instead of 2a. in case the item was pre-created before receipt, open the item editor and link to the relevant POL, then proceed to step 2b.
    • Ongoing Continuous/Subscriptions/Non-monographic Standing Orders
      These order types often link to a specific holding record in source ILS systems. If they do, receiving occurs in Alma as usual. This is why a location/copy for continuous orders (which means an actual holdings record ID association was made to the order) are related to such orders.
    • Alma supports only one order line per holding, while source systems may allow more than one order per holding. Therefore, in migration processing, the most recent open order is chosen for holdings that has more than one order line reference.
    • Older orders will not have copy information and will also not undergo P2E.
    • Some orders do not have any holding relationship in the source system.
    If there is no holding reference for any of the reasons described above, the operator still has full capabilities to receive, if one of the following steps are implemented:
    • If the holding to receive upon exists – From the holding editor, link the holding to a specific order (taking into account that it is limited to one order from that holding).
    • If the holding to receive upon does not yet exist – From the PO line edit page, select Add holding/copies to create and link a new holding to the order. This allows the receiving of new items.

    POL Material Types

    This is not migrated and is not relevant for ongoing use or for reporting.
    The material type on the order is only functional in the workflow for new orders, before the inventory related to the order has been created. Once the inventory exists, the POL material type is non-functional. This is the case for all orders.
    Reporting wise, the order – material type connection is between the inventory related to their orders and the inventory's material type. The order material type is not in use for reporting.

    PO Invoice Status

    Even though no invoices are migrated from Virtua, the PO has a field to indicate the invoice status of the order. The invoice status can be:
    • NO_INVOICE
    • PARTIALLY_INVOICED
    • FULLY_INVOICED
    Continuous orders must not be FULLY_INVOICED.
    For the Virtua migration, the invoice status is determined by checking QTY_INVOICED. If the value in this field is 0 or empty, then the Invoice Status is NO_INVOICE. Else the QTY_INVOICED is > 0 and the Invoice Status is PARITALLY_INVOICED (PRINT_CO) or FULLY_INVOICED (PRINT_OT).

    PO Acquisition Method

    The acquisition method in Alma is an indication of how the order is acquired. The following are possible values for the acquisition method:
    • PURCHASE
    • APPROVAL
    • GIFT
    • VENDOR_SYSTEM
    • DEPOSITORY
    • EXCHANGE
    • LEGAL_DEPOSIT
    The Virtua native export does not have a field that indicates Acq method, so typically all orders have the Acquisition method of PURCHASE. However, if customers want to add an additional field to the Virtua order extract to indicate the Acquisition method, they may do so.

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

    Acqusitions – Migration Form

    Questionnaire Tab

    ACQ mode

    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

    Default Order Library

    Code: DEFAULT_ORDER_LIB
    Default: First library found on the Alma Library list
    Options for Central and Default Order Library: The LIBRARY_ID field specifies the order location for orders in Virtua. The migration attempts to map the LIBRARY_ID field to the corresponding Alma Library. If you wish to override this LIBRARY_ID field and instead assign an order library to all orders migrated, then fill in a value for the Central Order Library question. Otherwise, if you want to use the LIBRARY_ID 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 LIBRARY_ID 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.
    If you choose to use DEFAULT_ORDER_LIB, and therefore attempt to map the LIBRARY_ID field to an Alma location, this requires that your LIBRARY_ID values be included in the Alma Location Tab map in the Migration Form. LIBRARY_ID values are often not the same values as inventory Location fields.

    What is your currency?

    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

    Enter a default language of conversation with vendors

    Code: VENDOR_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.

    Fiscal Period Cycle Pattern

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

    Which year do you use to name the fiscal year?

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

    Current Fiscal Year

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

    Accrual Accounting

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

    Default claiming period

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

    Renewal Date for Serials Subscriptions

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

    Fund Prefix

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

    Currency Code Tab

    Use this tab to map Virtua currency codes in the CURRENCY field of the order record to Alma currency codes.
    Virtua CURRENCY: The value of the Currency field as found in the Virtua order extract.
    Virtua CURRENCY Description: A description of the CURRENCY field, for information only. This column is not used in the mapping.
    Alma Currency: Select only from the list of currencies in the dropdown box. Only currently supported currencies are listed since we only make fund transactions for the current fiscal year. If you are mapping a defunct currency, map it to the replacement currency. For example, FRF should map to EUR. If you wish to retain the fact that the order was placed in FRF then also place the CURRENCY field in a note on the Purchase Order.

    PO Line Type Tab

    Use this tab to map the Virtua Order Type of the Virtua order extract to the Alma PO Line Type.
    Virtua ORDER_TYPE: The value of the Order Type field as found in the Virtua order extract. Be sure to check the extract, because some Virtua customers have had numeric values such as 0, 1, etc., and some customers have had textual values such as Monograph, Serial, etc.
    Virtua Order Type Description: A description of the Order Type field, for information only. This column is not used in the mapping.
    Alma PO Line Type: Select only from the list of line types in the drop-down list. The following are the possible line types that are used in Alma:
    • PRINT_OT – printed book one time. This is used for one time or infrequent orders of specific items, for example, a printed book, E book, or a musical score, that is not published repetitively. The order is at the item level.  If the only physical items that you order are books, this type is essentially the same as Print Book - One Time.
    • PRINTED_BOOK_OT: Print Book One Time
    • PRINT_CO – journal/continuation. This is used for orders that are repeated on a regular basis. An example is monthly subscriptions to physical or electronic material such as journals. The order is at the holding level, and items in the holding record are received periodically.
    • PRINTED_JOURNAL_CO: Print Journal - Subscription
    • PRINT_SO – standing order monograph. This is used for orders that are not repeated on a frequent or regular basis. For example, this type of PO line is used for purchasing all the printed books by a particular author when they are published or where a series of books are being published, but not necessarily on a regular basis. The receipt of new material involves a new bibliographic, holdings, and item record.  If the only physical items that you order are books, this type is essentially the same as Print Book - Standing Order.
    • PRINTED_BOOK_SO: Print Book – Standing Order
    • PRINT_SO_NONMON – Standing Order Non-Monograph – Similar to continuous orders.
    • OTHER_SERVICES_OT: Other Services One Time – Various non-inventory orders for services purchased from a vendor. Both one-time behavior and repetitive behavior are available. This should only be applied to orders without inventory. For electronic resources, see PO Line Types and Electronic Orders.
    • OTHER_SERVICES_CO: Other Services Subscription. This should only be applied to orders without inventory. For electronic resources, see PO Line Types and Electronic Orders.
    Further Information: Use this tab to define the line type of the migrated order. The PO may move through Alma workflows differently according to what type of item is on order. For example, a monographic order is opened, sent to the vendor, received, invoiced, and closed. However, a serial order may be received and invoiced many times and may remain open indefinitely.
    Alma does have other PO Line types, but they are not available for use in migration.
    The PO Line Type is determined based on the ORDER_TYPE field in Virtua. A typical map is when the ORDER_TYPE = Monograph, then the line type is PRINT_OT.
    The mapped PO Line Type is used in the next tab, the PO Entry Point map.

    PO Line Types and Electronic Orders

    In conjunction with the P2E process described in the P2E section above, orders related to e-inventory directly are updated to an electronic order type. Each of the above order types has an analogous type in the electronic realm. For example, a PRINT_CO order identified as associated with an electronic portfolio would become an electronic title subscription order if the order is attached to a bibliographic record identified as electronic.

    PO Entry Point Tab

    Use this tab to map the Virtua order state of the Virtua order extract to the Alma PO Entry Point.
    Virtua ORDER_STATE: The value of the Order State field as found in the Virtua order extract. Be sure to check the extract because some Virtua customers have had numeric values such as 0, 1, etc., and some customers have had textual values such as ordered, approved, etc.
    Virtua Order State Description: A description of the Order State field, for information only. This column is not used in the mapping.
    Alma PO Line Type (mapped): Select only from the list of line types in the drop-down list. The following are the possible mapped line type options:
    • blank – any line type is fine
    • *OT – One-Time (monographic) line types
    • *SO or *CO – Standing Order or Continuous Order (Serial) line types
    Alma PO Entry Point: Select only from the list of available entry points in the drop-down list. The following are the possible values for PO Entry Point:
    • NEW – The order has been created, but not sent to the vendor yet. Orders can have status NEW for years while librarians are reviewing what to order, or they can have status NEW for a short while if the acquisitions staff created the order to send to the vendor immediately.
    • SENT – The order has been sent to the vendor and funds have been encumbered/committed. The item has not been received yet for one-item orders, or the item has been received for continuous orders. Continuous orders that continue to be invoiced/received remain with SENT status (which can be considered as a sub-status of waiting for renewal within Alma) until they are closed.
    • WAITING_FOR_INVOICE – Use only for one-time orders. The item has been received, but not the invoice. Invoice status must not be FULLY_INVOICED.
    • CLOSED – The order has been received and invoiced. Nothing else will be received on this order. (Do not use for open continuous orders that you are still receiving.)
    • CANCELLED – Cancelled order.

    PO Reporting Code Tabs

    Use these tabs if you wish to map values from Virtua to the Alma Reporting Code fields. These tabs are not required.

    When an encumbrance transaction is created in Alma, the acquisitions staff can classify the transaction with a reporting code. Later, reports can be used to retrieve transactions with the same reporting code. Reporting codes are often (but not always) used to classify a purchase as serial, monograph, or electronic, for state or nation-wide reporting purposes.

    Virtua incoming field: The value in the incoming Virtua field.  A typical incoming field is $m Subject Code.

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

    Alma Reporting Code: The desired code value for the reporting code in Alma. You may choose to collapse incoming values if desired.

    Alma Reporting Code Description: The name for the reporting codes in Alma. This field is used to create a code table that is loaded into Alma. This value can be easily changed after migration.

    Further Information:  Alma has three Reporting Code code tables: 1st Reporting Code, 2nd Reporting Code, and 3rd Reporting Code.  The three mapping tabs correspond to the respective code tables.  

    REPORTING_CODE_1 (Virtua) -> PO Reporting Code Tab -> 1st Reporting Code code table

    REPORTING_CODE_2 (Virtua) -> PO Reporting Code Tab 2 -> 2nd Reporting Code code table

    REPORTING_CODE_3 (Virtua) -> PO Reporting Code Tab 3 -> 3rd Reporting Code code table

    Since each incoming field from Virtua maps to a single mapping tab and code table, a prefix is no longer necessary to distinguish between different incoming values.

    Physical to Electronic (P2E) Processing

    In Virtua, all resources are categorized as physical in the database, even if the record represents an electronic item. All records are converted to Alma as physical initially. A second process converts records identified as electronic to the electronic format. You provide a list of records that are identified as being electronic, as part of the data delivery, in the following format:
    vtlsl123475,portfolio
    vtls12346,DB
    During the P2E process, all resources must either be categorized as a portfolio or a database (DB).  It is not possible to generate packages during P2E processing, since packages require at least one portfolio.   A database is essentially a zero-title package.  Post migration, when you add portfolios to the db, you can change them to type 'package'.
    The words portfolio and db are not case-sensitive; therefore, both portfolio and Portfolio are acceptable.
    If you provide a bibliographic record in the P2E file, the migration program generates an electronic resource for the bibliographic record, even if there is no valid URL. An example of an invalid URL is an 856 tag with an indicator that does not match the specific indicator in the question P2E_LINK. For example, if you say that we use 85641u for the P2E_LINK, and you provide a bibliographic record without a 85641u, but that bibliographic record is in the p2e file, then the migration program generates a local e-resource without any link (an empty resource). Be careful which bibliographic records are placed in the bib file.
    Further, the P2E process attempts to identify an order related to the identified inventory for conversion to electronic. Similar to items and holdings, orders are initially migrated as print and are transformed to electronic through the p2e process. See Electronic Resource Handling in Alma Migration for more information.

    Questionnaire Tab

    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 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 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 subfield is allowed.
    Recommendation: 856 m
    Default: If this is left empty, no tag is used.

    Alma Location Tab

    Electronic Location Column

    Identify which locations indicate an electronic holding or item record. A single bibliographic record may contain holdings for multiple locations, but only the holdings/items for electronic locations need to be identified. Identify the locations in the in the Electronic Location? column in the Alma Location tab of the Virtua (VTLS) 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 Virtua 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, it is changed to the corresponding electronic standing order line type by the P2E process.

    Further Information

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

    Appendix A – Post-Migration Process Statuses

    The process statuses (codes) from Virtua 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. To do this in bulk, see this KCS article: https://knowledge.exlibrisgroup.com/Alma/Knowledge_Articles/Items_not_in_place_(not_available)_-_how_to_fix_in_bulkbatch%3F
    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?