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

    AbsysNET to Alma Data Delivery and Migration Guide

    Migration Overview

    AbsysNET is the Integrated Library System produced by Baratz.
    This document serves two purposes:
    • A step-by-step guide to filling out the AbsysNET to Alma Migration Form.
    • An explanation of the the fields in the AbsysNET Field Mapping Form, plus migration rules for AbsysNET to Alma that do not require any customer input,
    The procedure for migrating from the AbsysNET ILS to Ex Libris’ Alma consists of the following steps:
    • Indicate which local fields correspond to Ex Libris' expected fields using the AbsysNET Field Mapping Form prior to data delivery (customer responsibility).
    • Validate the flat files using Ex Libris’ Validation Tool Excel. It is recommended that this step be done against a small subset of data to ensure that the header of each of your flat files and the filled in field mapping form match each other. Note that the validation only works for CSV files. If you do not modify the AbsysNET flat files after exporting them from AbsysNET, there is no need to validate them before sending them to Ex Libris.
    • Extract the relevant data elements from AbsysNET into standard files (customer responsibility).  This is done using standard AbsysNET extract tools.
    • Upload the files to Ex Libris’ secure file server along with the AbsysNET Delivered Files form and the executed/validated Non-ExLibris to Alma Validation Tool (customer responsibility).
    • Transform the data elements, based on the Field Mapping form, into an intermediate conversion XML format (Ex Libris responsibility).
    • Load the transformed data into Alma (Ex Libris responsibility).
    Deliver the AbsysNET Field Mapping form and validated data validation output to Ex Libris along with the AbsysNET Migration Form prior to the actual delivery of the data. The lead-time depends on your project schedule. Provide the AbsysNET Delivered Files List, which lists the file names and the record counts for each file at the same time that you provide your data extract files.
    For all files, the maximum file size is 2 GB.  Prepare the data files with the naming conventions as described in Appendix – File Delivery and Form.
    DO NOT OPEN/UPDATE any delimited file extracts you provide to Ex Libris in Excel. This may ruin the appropriate delimiter formatting and text formatting and may result in corrupted data.

    Recommendations for Using this Guide

    This document is divided into four areas:
    • Inventory
    • Fulfillment
    • Acquisitions
    • Physical to Electronic
    Each area has the following sections:
    • Field Explanations - File delivery requirements and explanations of individual fields where relevant, to be used when filling out the Field Mapping Form.
    • Questionnaire Tab – Instructions for individual questions asked on the Questionnaire tab of the Migration Form.
    • Individual Tabs – Instructions for how to fill in individual tabs on the Migration Form.
    • Further Explanation – Explanations of migration processes that need more explanation and/or do not need customer input.
    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.  

    AbsysNET Field Mapping Form

    Prior to submitting your extracted files, complete the AbsysNET Field Mapping form. The AbsysNET Field Mapping form and the AbsysNET Migration Form should be submitted at the same time. In the AbsysNET Field Mapping Form, indicate which data elements (files) you plan to provide in the Overview tab of the spreadsheet. On the subsequent tabs, indicate how your local AbsysNET field names map to our expected field names.
    Even when the names of the fields being provided are the same as the ones listed in the ExL Expected Field Name column, the Local Field Name column for the fields being provided must still be filled in.
    In addition, there are various note fields for each data element on the various tabs. For fields that are not expected by Ex Libris – meaning, there is no functional place for the data element in the corresponding Alma data structure – place the field in a note in the record. Specify which note type you want the field to go to at the bottom of each tab in the AbsysNET Field Mapping form.

    AbsysNET Delivered Files Form

    At the time you submit the requested data files, submit the completed AbsysNET Delivered Files Form. List the files, record counts, and encoding for each file delivered to the secure file server.

    AbsysNET Migration Form

    The AbsysNET Migration Form is a separate Excel spreadsheet that contains information on how to migrate information that is specific to your local implementation of AbsysNET. For example, your local location codes and item types will be converted to codes and types that can be used by Alma. 

    Expected File Formats

    Expected file formats for AbsysNET data varies by file. See the descriptions below. Ex Libris expects a certain set of files to be exported from AbsysNET. We have included the general expected deliveries below. The data elements listed for each are those that Ex Libris expects to use in conversion. Some data elements may exist in AbsysNET but are not necessary to bring to Alma.
    The scope of your specific conversion is agreed upon in your Alma contract.
    As you extract data from any area requested below, provide it to Ex Libris via a secure connection to the MFT secure file server. This facilitates the transformation analysis and expedites the conversion process. Information on the MFT connection will be provided by Ex Libris. For more information, see Appendix – File Delivery and Form.
    For the files listed below that are not bibliographic records with embedded items, we expect an extract using the tools available with AbsysNET API access. Our understanding is that API access is an extra cost for many customers. If your institution does not have API access, you may need to request extracts directly from AbsysNET support.

    Inventory

    Bibliographic Records

    Bibliographic records are expected in UNIMARC or MARC format. The character encoding expected from AbsysNET is UTF-8. Deliver all files with the same character encoding.
    There should be a unique and consistent former system number in each bibliographic record. This is typically in the 002 field in AbsysNET, but it may also be found in some other field. Whichever field it is in, it should be unique and should be present for every single record. Indicate where the former system number is on the Bibliographic tab of the field mapping form.
    If you have loaded SFX MARCIt (or another electronic resource management system) records into AbsysNET, it is recommended that they not be included in the bibliographic record export to avoid unnecessary duplication with records loaded directly from SFX. If you want Ex Libris to detect and not migrate the SFX records, ensure that a 035 |a field with (SFX) in the field content is provided so that they can be identified, and answer “No” to the question about SFX bibliographic record on the Questionnaire tab of the AbsysNET Migration Form.

    Suppressed Bibliographic Records

    In Alma, bibliographic records can be set to be suppressed in the OPAC. Similarly it may be possible in AbsysNET to not show certain records to the public. If your system has suppressed bibliographic records that are not shown to the public, provide a file of AbsysNET bib keys in a separate text file, one key per line. The AbsysNET bib key is the number typically found in field 002 of the bib record for UNIMARC records.

    Holding Records

    Alma requires MARC Holdings records. There are two options for generating holding records in Alma:
    • 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.

    Non-MARC Serial Holdings 

    If non-MARC serial holdings are provided, they should be sent as a CSV file. The file can be mapped to the generic serial holdings format included in the Holdings tab of the AbsysNET Field Mapping form.

    The following format is used for an AbsysNET holding record in CSV format. Records should be provide one record per line, with quotes and commas. Provide a header at the top. If something is allowed to be repeatable, provide the repeated information with a semicolon.

    MARC Holdings
    Expected Field Name Repeat-able? Notes
    TITULO N Mandatory.  Links to the related bib record
    BIBLIOTECA N First level of location
    LOCALIZATION N Second level of location
    SUMMARY_STATEMENT   will be placed in 866 $a

    If you have fields which are not in the above table but wish to keep them in a note, place those fields in the note section

    Note type Notes
    NON_PUBLIC_NOTE placed in 852 $x
    PUBLIC_NOTE placed in 852 $z

    Holdings From a Bib Tag

    If there is information in a field embedded in the bibliographic record, the migration programs can generate a holding record from it. Fill in the values of the following fields in the AbsysNET Field Mapping Form, Holdings tab. If the SUMM_LIB_CODE and SUMM_LOC_CODE match an existing holding record on the same bibliographic record, even a holdings record that was generated from items attached to the same holdings record, the summary holdings statement will be attached to that holdings record, regardless of call number. In other words, the summary holdings record will be placed on the holdings record with the same library and location, even if 852_SUBFIELDS_FOR_HOL contains call number subfields for matching like bchi. If there is no existing holdings record on the bib with the same location, a new holding records will be generated.
    Expected Field Name Value Notes
    SUMM_TAG   Five characters; tag+2 indicators.  May use # as wildcard, for example, 866## or 86#3#.  Wildcard allowed for third digit and indicators but not first two digits. To indicate a space character, use b, for example 866b1.
    SUMM_SUBFIELDS   Multiple subfields allowed, e.g. abz. May use # to indicate all subfields.
    SUMM_CALLNO   Textual call number to be used in all newly generated holdings records if desired.
    SUMM_LIB_SUBF   A single subfield code (like 'a') which contains a library code in local ILS format. Do NOT enter a different bib tag. The migration program searches for a subfield within the SUMM_TAG bib tag.
    SUMM_LOC_SUBF   A single subfield code (like 'a') which contains a location code in local ILS format. Do NOT enter a different bib tag. The migration program searches for a subfield within the SUMM_TAG bib tag.
    SUMM_LIB_CODE   If SUMM_LIB_SUBF is not provided or the subfield is not found, this is used for all records as a default. Provide a library code in local ILS format.
    SUMM_LOC_CODE   If SUMM_LOC_SUBF is not provided or the subfield is not found, this is used for all records as a default. Provide a location code in local ILS format.
    SUMM_PUBLIC_NOTE_SUBF   Public note, will be placed in 852 $z of the generated holding record
    SUMM_NON_PUBLIC_NOTE_SUBF   Non-public note, will be placed in 852 $x of the generated holding record

    Items

    Item information is expected to be provided in a separate csv file. The file should be one record per line, with the field names in the first line of the file, with quotes and commas separating the fields.
    “Field1”,”Field2”,”Field2”, etc.
    Indicate which tag contains the item on the Items tab of the AbsysNET Field Mapping Form.
    The following table lists the expected fields for item migration. If your item fields have different contents, indicate the subfield mapping in the Items tab of the AbsysNET Field Mapping Form.
    The maps that are indicated in the Notes column below are found in the AbsysNET Migration Form. See the accompanying AbsysNET Migration Guide for instructions on how to complete this form.
    Expected Field Name Description Note
    COBARC Code-barres  
    COFSAD createDate This is not migrated. Place in a note if you want to retain the original create date.
    COUSAD createdBy  
    COFSMD updateDate  
    COUSMD updateBy  
    CONTIT No de titre links to bib record 
    COCOCL Localisation use in Alma Location map in migration form
    COFREC Date de réception  
    COCOCP Type exemplaire use in Item Type map in migration form
    COCOSU Succursale use in Alma Location map in migration form
    COSIGN Cote data will be placed in 852 $h
    COSIGS-Call_Number_2 Cote supplémentaire place field COSIGS here to have the data be placed in 852 $i (second part of regular call number)
    COSIGS-Item_Call_Number Cote supplémentaire

    place field COSIGS here to have the data be placed in Item Call Number.

    If customer uses this option, they MUST use 'bch' in the 852_subfield_for_hol question; if they use 'bc', then differing call number information may be lost - we can't put both into the same field Item_call_number.

    COSTAT Situation exemplaire use in item status map in migration form
    CONREG No de registre is placed in INVENTORY_NO in Alma
    COFINV Date de Récolement is placed in INVENTORY_DATE in Alma
    COCOPR Provenance  
    CONPRE Nbr de prêts

    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.

    COFULT Date de retour  
    COCOCS Support use in Material Type map in migration form
    COIDVO Identifiant de volume is placed in item DESCRIPTION field
    Price COVALU Inventory Price
    REPLACEMENT_COST COVALU Use only if this is an actual replacement cost. If not, put only in the Inventory price field above.
    P2E_LINK P2E_LINK URL access to this material.  This value is transferred to the holding record 856 subfield u, and then is used during the p2e process. 
    P2E_NOTE P2E_NOTE This value is transferred to the holding record 856 subfield z, and then is used during the p2e process.  
    TEMP_LIBRARY Temporary Library  
    TEMP_LOCATION Temporary Location  
    TEMP_ITEM_TYPE Temporary item type  
    TEMP_CALL_NUMBER temporary call number  
    TEMP_CALL_NO_TYPE temporary call number type  
    PAGES pages  
     
    To update Enumeration and Chronology fields, use the Secondary Item File, below.

    Item Barcodes

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

    If duplicate item barcodes are found, 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 <item barcode>-<item id>.

    Item Notes

    Any additional subfields not listed above may be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. The subfields listed in the Default Local Subfield column are those that are expected by Ex Libris. If you use other field names or have subfields that you want to include in the migration, but are not expected by Ex Libris, you can rearrange, add, or subtract fields in the “Default Local Subfield” column as necessary. The text in the Note Label column are used as a prefix to the subfield contents and can be modified, 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    
    FULFILLMENT_NOTE    
    NON_PUBLIC_NOTE_1    
    NON_PUBLIC_NOTE_1    
    NON_PUBLIC_NOTE_2    
    NON_PUBLIC_NOTE_2    
    NON_PUBLIC_NOTE_3    
    NON_PUBLIC_NOTE_3    
    STAT_NOTE_1    
    STAT_NOTE_2    
    STAT_NOTE_3    

     

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

    Secondary Item File

    You may want to provide item descriptive information in a secondary file. For example, you have a description in the format Vol. 12 No. 2 (2015 February), but Alma recommends that enumeration and chronology information are without labels and are in separate fields. You can provide your description in a secondary item file.
    With the exception of the item_key and barcode, all other fields will force blank if an empty field is provided.  In other words, if you have an item description in Alma, and you provide a blank description in this file, the incoming blank will be 'written' to Alma, meaning the Alma description will be deleted.
    We recommend that EnumX and ChronX fields contain only numbers, for example '12' instead of 'Vol. 12' and '2' instead of 'Feb'.  However, it is programmatically time-consuming to distinguish between an invalid use (Vol. 12) and a valid use (12A), so in the interest of processing quickly, we allow any string in EnumX and ChronX fields.  Do not provide a full date in a single field.  Split any dates into three, for example 4 Feburary 2020 is ChronI=2020, ChronJ=2, ChronK=4.   
    Even though it is not recommended, if for any reason you need to provide a full date in a single field, put a tick (') before the date in the Excel cell so that it is treated like text (instead of the Excel date format). 
    Provide the secondary item file in Excel format (xls or xlsx) format, with the following fields:
    Expected Field Name Notes
    item_key

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

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

    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  

    Electronic Identification (P2E)

    Most non-Alma ILS systems store records for both physical and electronic items in the same format, which is a physical format. Alma has different record formats for electronic and physical items. Records that initially migrated as physical but actually represent electronic materials can be converted to electronic format after migration to Alma.
    Provide a list of AbsysNET bibliographic system numbers that represent electronic resources and an indication if these electronic resources are portfolios, packages, or database resources. The list should be a comma separated text file containing lines that represent each e-resource. Structure each line as follows: <bibnumber>,<resource type>
    For example:
    000000001,Portfolio
    000000002,DB
    During the P2E process, all resources must either be categorized as a portfolio or a database (DB).  It is not possible to generate packages during P2E processing, since packages require at least one portfolio.   A database is essentially a zero-title package.  Post migration, when you add portfolios to the db, you can change them to type 'package'.
    The words portfolio and db are not case-sensitive; therefore, both portfolio and Portfolio are acceptable.
    In addition, indicate which locations represent electronic in the Location tab of the AbsysNET Migration Form. The migration will only convert items, holdings and orders that belong to an electronic location to an electronic format. This is especially important if your library has holdings of different formats attached to the same bibliographic record, for example you have a print version and an electronic version of the same title.

    Customer Input

    Questionnaire Tab

    Institution Code, Customer Code, Institution Name, Customer Name, Time Zone
    Codes: INST_CODE, CUST_CODE – These are filled in by Ex Libris.
    The institution code cannot be the same as a library code.
    INST_NAME and CUST_NAME: Fill these fields in with your institution’s name and your customer name (customer code is only different from the institution code if you are part of a consortium). These are mandatory and must be filled in.
    Default: N/A
    Time Zone: Select your time zone from the drop-down list. If your time zone is not listed, contact your Ex Libris project manager.
    MARC/Country Organizational Code
    Code: MARC_OC
    Default: None; this is not mandatory
    Options: Enter your MARC Organizational code, which will be used to construct the former system number in Alma. Only one code is allowed.
    Further Information: The migration moves the value in the exported record’s former system number field (AbsysNET bibliographic system number) to the 035 $a field:

    (MOC)<AbsysNET record id>-<customer code>

    <(MOC)> is the MARC Organization code specified here. <customer code> is the customer code specified in the CUSTOMER_CODE question above.
    For example: (AbC)u12345-01abc_inst
    The AbsysNET former system number can be in the 002 field of the Unimarc record. Customers should specify where the former system number is in the AbsysNET Field Mapping form.
    List Prefix for bibs from SFX or other management system
    Code: SFX_PREFIX
    Default: ‘(SFX)’
    Options: String. If not indicating a link resolver management system, leave blank.  Multiple strings are allowed: (SFX);WaSeSS;EBC
    Further Informationn: If your AbsysNET catalog contains records imported from SFX or another electronic resources management system and you are also migrating bibliographic records directly from SFX or the other management system, this may result in duplicate bibliographic records in Alma. You can enter a prefix here so that the migration programs can identify these bibs and not migrate them to Alma to avoid creating duplicate SFX records in Alma. The migration programs do not make any attempt to physically merge the two records into one. The default response to this question is ’(SFX)’, but you can enter any prefix that represents bibs that you want to exclude from loading into Alma. The migration programs search for the string in the 035 $a field of the MARC record. If you do not want to exclude any such records, leave this field blank.
    If the migration programs identify bib records containing the prefix in the 035 $a and the records in AbsysNET are connected to a purchase order line and/or physical items, these bib records are still migrated so that the purchase order and/or items can be migrated, but they are automatically suppressed in Alma to avoid end-user discovery duplication.

    Do you use internal system numbers in Linked Entry fields? 

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

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

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

    Code: LINKED_ENTRY_W

    Default: No

    Options: If you answered Yes to this question, the internal system numbers in the subfield w 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 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 location only, select bc here. If you have many items in the same bibliographic record in the same library and location but different call numbers WITHIN that location and you want each of them to have their own distinct holding record, specify additional call number subfields.  Acceptable subfields: bchijklmp.
    The library and location codes are matched after the Alma Location Mapping has been performed, meaning the match is done on the Alma version of the library/location codes.
    Limit exported records by location
    Code: LIMIT_BY_LOCATIONS
    Default: No
    Options: If your export contains all of the data from a shared database, and you wish to only migrate a part of that export to Alma, then the migration programs can filter the data according to locations listed on the Location Tab. In this case, the ALMAME_VALUE_NOT_FOUND line on the location tab is not used. Inventory and Acquisitions are filtered by locations on the Location Tab, and Fulfillment is filtered based on campus codes in the Campus Code Tab. Use this option only if agreed upon with your Ex Libris project manager.
    Bib Key Prefix
    Code: BIB_KEY_PREFIX
    Default: empty
    Options: If you are combining data from two or more separate databases into a single combined institution in Alma, then indicate a prefix here that will be used to distinguish the former system numbers in Alma after migration. For example, the different systems likely had completely different bibs for system number 12345 and you want to be able to search for the specific bib from your own institution after go-live. The prefix does not include a hyphen so if you want a hyphen in the number (e.g. PQ-12345), include it in the string. If you are not merging institutions, leave this question blank.
    See also:  MERGE_PATRON_PREFIX
    Move 001/003 to 035 or 035

    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 created this field.

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

    001 12345

    003 OCoLC

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

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

    Add institution suffix to Bib ID 

    Code: BIBID_INST_SUFFIX

    Default: No

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

    Yes = include suffix

    No = do not include suffix

    Use subfield indicators in item call number (AltCallNo)

    Code: ITEM_CALLNO_SUBFIELD

    Default: Yes

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


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

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

    Add $9 LOCAL to specified tags

    Code: NZ_LOCAL_TAGS

    Default: empty

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

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

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

    Alma Library Tab

    Use this tab to create a list of Libraries in Alma. At least one library is mandatory.
    Alma Library Code: Maximum 10 characters. Mixed case is valid, but not recommended. Do not use special characters or spaces. Allowed: - and _ (hyphen and underscore). Not allowed: !@#$%^&*()+=/?><.,\|]}[{`~ or the space character.
    The Alma Library Code may not be the same as the Alma Customer Code nor the Alma Institution Code. 
    Alma Library name: Maximum 255 characters. This is visible to the public.
    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 Information: The AbsysNET library is in the item subfield |m, which is the higher level of location, and is comparable to the Alma library. Use the Alma Libraries tab in the AbsysNET Migration Form to indicate your list of Alma libraries. The actual mapping from the AbsysNET library to the Alma library is done in conjunction with the home location (|l) in the Alma Location tab.
    If you use an error library (for example “EMPTY”) in the ALMAME_VALUE_NOT_FOUND line of the Location Mapping tab, be sure to list that library here on the Library Tab. It is not mandatory to use an error library; you may also choose to use one of your regular libraries plus a lower-level error location for the items that encounter errors during the mapping process.

    Alma Location Tab

    Use this tab to map your AbsysNET libraries and home locations to libraries and locations in Alma. Filling in this tab is mandatory.
    Include ALL locations of ALL types, including electronic types that may ultimately be deleted in Alma. They still need to be provided in the location tab mapping.
    AbsysNET Library (COCOSU Succursale): Value from the COCOSU Succursale field in the item extract from AbsysNET. The ALMAME_VAL_NOT_FOUND line is required to catch any library/location codes you may have missed.
    AbsysNET Localization (COCOC1): Value from the Localization field in the item extract from AbsysNET.
    Alma Library Code: The library that contains this library/location combination in Alma. You can use the same library codes that you used in AbsysNET, but it is not required. This code must be present on the Alma Library Tab, column A. The match is case-sensitive. Alma Location Code: The new location code for this library/location combination in Alma. It can be a maximum of 10 characters. You can use the same location codes in Alma that you used in AbsysNET, but this is not required. You may also use this form to collapse locations if desired, for example, refa and refb in AbsysNET both map to ref in Alma. Mixed case is valid, but not recommended. Do not use special characters or spaces. Allowed: - and _ (hyphen and underscore). Not allowed: !@#$%^&*()+=/?><.,\|]}[{`~ or the space character.
    Call Number Type: List the call number type for any newly created holdings records, based on the values for the 852 first indicators. (http://www.loc.gov/marc/holdings/hd852.html). If we cannot determine the call number type from the item or holding record itself, we use this as a default for all items in the location.
    Alma Location Name: A description for this location as seen/used by library staff members. The same location name cannot be used for different locations in the same library, but the same location name can be used for different locations in different libraries. See the examples in the Further Information section below for what is acceptable and not acceptable. Maximum 255 characters.
    Alma External Location Name: A description for this location as seen/used by the public. The same name can be used for as many different locations as desired. For example, the location names may be Archives A and Archives B, but the external location names can both be Archives. Maximum 255 characters.
    Electronic Location? (Yes or No): Used by the P2E migration process to determine if a holding/item/order should be converted to electronic. See the Physical to Electronic (P2E) Processing section for more information.
    Suppress from Externalization? (Yes or No): Indicate if the location should be suppressed from being visible to the public. The items are not marked as suppressed, but no holdings or items with this location code are exported to Primo.
    Further Information: Do not leave the Alma location and library code fields blank. If you want to stop using a location code after migration, map the AbsysNET code to an easily identifiable code such as XXX or unused just in case any stray items are still in your AbsysNET database.
    The ALMAME_VALUE_NOT_FOUND line must be included at the top of the list of locations, in case any location codes were overlooked when completing this map. For example, you may think that you do not have any items left in a certain collection, so you leave it off the location map. However, there may be one or two items left or a stray holding record, etc.
    By default, the location code for the ALMAME_VALUE_NOT_FOUND line is UNASSIGNED, which is the default catch-all in Alma in production mode. Ex Libris recommends that you select your primary/largest library as the library code for the line, for example, MAIN as in the example line below. In this case, the items inherit the configurations for the MAIN library.
    AbsysNET Library Code AbsysNET Home Location Alma Library Code Alma Location Code Alma Location Desc Alma External Loc Desc Suppress from Externalization
    ALMA_ME_ VALUE_NOT _FOUND ALMAME_VALUE_NOT_FOUND MAIN UNASSIGNED Problem location from Migration Problem: See Library Staff Yes
    Post-migration, search for items in the “UNASSIGNED” location and correct the records appropriately.
    Alma Location Name and Alma External Location Name
    The Alma Location Name column contains the names of the location codes that are displayed in the staff interface. The names cannot be repeated in the Location Name column when the location codes both belong to the same library, but you can use the same name for two different locations, if these locations belong to different libraries. The Alma External Location Name column contains the names of the location codes that are displayed to library patrons. These names can be repeated within the column without regard for libraries. For example:
    The following is acceptable:
    Library Alma Location Code Alma Location Name Alma External Location Name
    Library A stacks Main Stacks Main Stacks
    Library B stacks Main Stacks Main Stacks
    Library A archa Archives A Archives
    Library B archa Archives B Archives
    Library A archstk Archives Stacks Archives
    Library A archref Archives Reference Archives
    The following is not acceptable:
    Library Alma Location Code Alma Location Name Alma External Location Name
    Library A archstk Archives Archives
    Library A archref Archives Archives
    The Alma library and Alma location are put in the following places in the migrated or newly created MARC holdings record:
    • The Alma library is placed in the 852‡b field.
    • The Alma location is placed in the 852‡c field.
    Collapsing Locations
    This mapping table can be used to collapse location codes – that is, two or more location codes in AbsysNET 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 AbsysNET code to an easily identifiable code such as XXX if any stray items are still in your AbsysNET database.
    If you collapse location codes, you may have lines in the table such as the following:
    AbsysNET Location Code Alma Library Alma Location Code Alma Location Name Alma External Loc Name Suppress from Externalization Electronic Location
    reserves MAIN RESERVES Reserves Reserve Yes No
    reservesElec MAIN RESERVES Reserves ReserveElec Yes Yes
    reservesShort MAIN RESERVES Reserves Reserve Yes No
    reservesPerm MAIN RESERVES Reserves Reserve Yes No
    The two values in bold italic above (ReserveElec as the External Location name, and Yes for Electronic location) are not used in Alma. Since the locations are being collapsed, the first line for the RESERVES Alma location is used, and all subsequent lines below it use the values from the first line.

    Item 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.
    AbsysNET Status (COSTAT): The item status in AbsysNET.
    Description: A short description of the item status in AbsysNET, if desired, for note purposes while filling out this form. This column is not used for migration.
    Base Status: In Alma, the base status indicates whether or not the item is on the shelf. Indicate whether or not an item with this status is on the shelf. For example, NewBooks is on the shelf (1), but Withdrawn is not (0).
    Further Information: For migration, all item statuses that are indicated as not on the shelf (0) from AbsysNET are given the process type of TECHNICAL in Alma. Further, the item status description field is written to internal note 1 for all items where there was a status, regardless of the shelf/not on shelf designation.
    Include any status that may indicate no status, for example Available, but leave column B blank. This migrates the item to Alma with no status and no note 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.
    After migration, you can search for values in Internal Note 1 and then move the items to the appropriate workflow in Alma. Alternately, the search may be used to move an item to a specific department, or the list can be used as a configurable criterion for suppressing items from display in the GetIt services screens in discovery systems. See Appendix A – Post-Migration Process Statuses for more information.

    Item Type Tab

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

    Item Material Tab

    Use this tab to migrate the AbsysNET Material type (COCOCS) to the Alma Material type.
    AbsysNET Material Type (COCOCS): The value in the material type field of the item coming from AbsysNET.
    Material type Description: The description of the AbsysNET material type, for information only. This column is not used during the mapping process.
    Alma Material Type: The Alma value for the material type. Material types in Alma are fixed. You cannot add any new types to the list. Select the appropriate material type from the drop-down list. 
    If this field is not provided, the resource type is determined by the bib header information.  See the Material Type section below.

    Further Explanation – Inventory

    Determining Groups of Holding Records

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

    Changing the Holding Record Grouping

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

    Attaching Items to Existing Holding Records

    The algorithm described above to determine groups of items for generating new holdings records is also used to determine if an item should be attached to an existing MARC holdings record. The question Indicate which 852 subfields to use to determine unique holding records from the Questionnaire tab of the AbsysNET Migration Form is used here as well.
    For example, consider the following records from AbsysNET:
    Holding record A: $b PER $c MFORM $h PN 567 $i .M4
    Holding record B: $b PER $c CURRENT $h Shelved by title
    item 1: PER,MFORM PN 567 .M4
    item 2: PER,MFORM PN 567 .M4 2010
    item 3: PER,MFORM PN 567 .M4 2011
    item 4: PER,CURRENT PN 567 .M457 2012
    When only location (852 $b $c) is used to determine unique holding records, the following is the resulting structure in Alma:
    Holding record A: $b PER $c MFORM $h PN 567 $i .M4
    item 1 (ItemCallNo is empty because the call number matches)
    item 2 (with PN 567 .M4 2010 in ItemCallNo)
    item 3 (with PN 567 .M4 2011 in ItemCallNo)
    Holding record B: $b PER $c CURRENT $h Shelved by title
    item 4 (with PN 567 .M457 2012 in ItemCallNo)
    When the entire call number (852 $b $c $h $i $k) is used to determine unique holding records, multiple additional holding records are created in Alma:
    Holding record A: $b PER $c MFORM $h PN 567 $i .M4
    item 1
    *Holding record B: $b PER $c MFORM $h PN 567 $i .M4 2010
    item 2
    *Holding record C: $b PER $c MFORM $h PN 567 $i .M4 2011
    item 3
    Holding record D: $b PER $c CURRENT $h Shelved by title
    *Holding record E: $b PER $c MFORM $h PN 567 $i .M4 2012
    item 4
    The holdings records with the asterisk (B, C, and E) are created new because the entire call number string of the item did not match the entire call number string of any of the existing holdings records.

    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.
    AbsysNET customers may provide a material type in a subfield of the item tag (typically 999) of the exported bibliographic records. The material type you indicate determines the item's material type.
    An explanation of material types is found on the following page: Configuring Physical Item Material Type Descriptions.  Consult the Alma menu option under Configuration -> Resources -> Physical Material Type Descriptions for a list of Alma material types in use. 
    If not provided in the extract, the migration automatically assigns a material type based on Bibliographic record LDR and 007 fields. There is no customer input required for this part of the migration as the Alma types are fixed.  The material type in migration is derived from the resource type which is constructed by Alma based on the bib header information. To see a description of how the material type is determined from the resource type, see the Resource Type Field description.

    Fulfillment/Patrons

    Patrons

    Extract all patrons in csv format. In order to migrate any area of fulfillment (fines/ fees, loans, requests), all patrons must be migrated.
    The fields in the following table are expected. Indicate the local field names for the expected fields in the Patrons tab of the AbsysNET Field Mapping Form.
    Field Name Description Notes
    LENLEC No lecteur use to link patron to loans, fines, requests
    LEFSAD createDate This is not migrated. Place in a note if you want to retain the original create date.
    LEUSAD createdBy  
    LEFSMD updateDate  
    LEUSMD updatedBy  
    LECOBI Bibliothèque  campus code
    LEAPEL Nom  
    LETI Titre  
    LEIN Middle Name  
    LENOMB Lecteur  
    LECOLP Type  
    LEFCAD Date de fin de droit  
    LEFNAC Date de naissance  
    LEFSUS Date de suspension if present, a block will be created with type 'CONV'
    GENDER   must contain 'Male' or 'Female' or leave blank
    LANG language must contain two-letter ISO code https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes
    BLOCK_TYPE block

    Use these fields only if providing a single block per patron.

    If multiple blocks are provided for a single patron, provide the blocks in a separate file.  See User Block section below.

    BLOCK_NOTE block
    BLOCK_CREATE block
    BLOCK_EXPIRY block

    User Addresses

    There can be multiple addresses, emails, and phone numbers in the patron record. The fields that are available for migration into Alma are listed in the left column. The field names from the AbsysNET extract are in the two right hand columns. Put the field names for preferred address in the Preferred column, and the field names for the secondary address in the Secondary address section. Finally, decide which type of address this should be defined as, using the last field in the column, “Address type (select)”.
    Alma Address Field AbsysNET Field Name 
    ADDRESS_LINE_1 LEDI11
    ADDRESS_LINE_2 LEDI12
    ADDRESS_LINE_3 LEDI13
    ADDRESS_LINE_4  
    ADDRESS_LINE_5  
    ADDRESS_CITY  
    ADDRESS_STATE  
    ADDRESS_CODE LEDIZ1
    ADDRESS_COUNTRY If country is provided, it must be a three-letter ISO country code, which can be found here https://en.wikipedia.org/wiki/ISO_3166-1_alpha-3
    ADDRESS_NOTE  
    ADDRESS_START  
    ADDRESS_END  
    Address Type (Select): ALL
    SEC_ADDRESS_LINE_1 LEDI21
    SEC_ADDRESS_LINE_2 LEDI22
    SEC_ADDRESS_LINE_3 LEDI23
    SEC_ADDRESS_LINE_4  
    SEC_ADDRESS_LINE_5  
    SEC_ADDRESS_CITY  
    SEC_ADDRESS_STATE  
    SEC_ADDRESS_CODE LEDIZ2
    SEC_ADDRESS_COUNTRY If country is provided, it must be a three-letter ISO country code, which can be found here https://en.wikipedia.org/wiki/ISO_3166-1_alpha-3
    SEC_ADDRESS_NOTE  
    SEC_ADDRESS_START  
    SEC_ADDRESS_END  
    Secondary Address Type (Select): ALL
    PHONE The preferred phone should go in PHONE_PREFERRED, other phones in PHONE_x
    EMAIL The preferred email should go in EMAIL_PREFERRED, other emails in EMAIL_x

    User Identifiers

    There may be a number of fields in the patron record that are user identifiers. The types of identifiers that are available for migration into Alma are listed in the left column. The typical expected field names from AbsysNET are in the right column. Change the field names and/or order of the right column to suit your library’s extract. The values in the left column cannot be changed. Use the values in the left column to select the appropriate primary identifier in the Questionnaire tab of the AbsysNET Migration Form. If there is a field in AbsysNET which contains a note specific to the identifier, place that in the far right column.
    Alma Identifier Type AbsysNET Field Name AbsysNET Field Name for Note
    UNIV_ID LEDDNI  
    BAR LENLEC  
    ADDL_ID_1 LEDDNN  
    ADDL_ID_2    
    ADDL_ID_3    
    ADDL_ID_4    

    User Statistical Categories

    There may be a number of fields in the patron record that function as a statistical category only, for example, a student’s department or major. The way the student borrows can be determined by the P TYPE, but you may want to track the department, so that you can get more detailed statistics on how Law students borrow, for example. Since AbsysNET has a large number of fields that are customizable, we provide you the option to map the data from any field to the User Statistical Categories in Alma.
    User Statistical Category Local Field Name Field Label
    USER_STAT_CATEGORY HOME INST INST
    USER_STAT_CATEGORY DEPT DEPT
    USER_STAT_CATEGORY SCHOOL SCHOOL
    You can add up to 10 incoming fields. To map the values, use the UserStatCategories map in the AbsysNET Migration Form. If a value is not found in the map, it is migrated as is. If you use a label, the userStatCategory map tries to map the field including the label. The first column in the userStatCategory map would be: LABEL: value, for example: SCHOOL: Law.
    If you use this prefix, be sure to use the prefix again in the Migration Form Mapping tab for User Stat Categories, in column A (incoming data).   In the Field Mapping form, provide labels to the right of the field:

    clipboard_e2aa93036138a14009b7d157e0f2d5e72.png

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

    clipboard_e05c1bc84e8c6add0f665c0882acc3c50.png

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

    Notes

    Any additional fields not listed above may be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris. If you use other field names or have fields that you want to include in the migration, but are not expected by Ex Libris, you can rearrange, add, or subtract fields on the right, as necessary. If you want to include multiple local fields in the same Alma note, copy the line in the spreadsheet as many times as needed for all note name/local field combinations.
    Note Name Information
    LIBRARY_NOTE  
    BARCODE_NOTE  
    ADDRESS_NOTE  
    OTHER_NOTE The 'OTHER_NOTE' is marked by the migration programs as viewable by the user.  This is the only note which migration marks as user viewable.  
    CIRC_NOTE The 'CIRC_NOTE' is marked by the migration programs as a popup note. This is the only user note which migration marks as a popup note.

    User Blocks (if multiple blocks per patron)

    If a single block is provided per patron, the blocks can be provided within the patron record.  Otherwise, if there can be multiple blocks for a single patron, provide the blocks in this separate file.  

    Address Field Instructions
    PATRON_ID There may be multiple lines in the file for a single patron ID - meaning that the patron has multiple blocks.
    BLOCK_TYPE Use the User Block tab in the migration form.  
    BLOCK_NOTE  
    BLOCK_CREATE  If this is not present, migration will use use patron create date, then patron migration date.  
    BLOCK_EXPIRY  

    Active Loans

    Extract only current circulation transactions.  Completed loan transactions are not included in the migration to Alma.
    When a loan due date in AbsysNET is empty, the due date in Alma is set to one year from the conversion date.
    The fields in the following table are expected. Indicate the local field names for the expected fields in the Loans tab of the AbsysNET Field Mapping Form.
    Field Name Description Notes
    PRBARC Code-barres links to item ID in item file
    PRFSAD create date  
    PRUSAD create_user  
    PRFSMD update date  
    PRUSMD update_user  
    PRPRSU Succursale du prêt  
    PRCOCL Localisation  
    PRNLEC Lecteur links to ORIGINAL_ID in patron file
    PRFPRE Date de prêt  
    PRFDEV Date de retour  
    PRRECL Nbr de réclamations checks if the loan was recalled; to keep actual number of recalls, also put this field in notes
    PRNREN Nbr de renouvellements checks if the loan was renewed; to keep actual number of renewals, also put this field in notes
    PRCORN Origine renouvellement  
    PRRERE Date de réclamation de réservation  
    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  

    Active Requests on the Hold Shelf

    Extract only request transactions where the item is trapped and on the hold shelf waiting for pickup.
    The fields in the following table are expected. Indicate the local field names for the expected fields in the Requests tab of the AbsysNET Field Mapping Form.
    Field Name Notes
    REFSAD  
    REUSAD  
    REFSMD  
    REUSMD  
    RERESU  
    REBARC item barcode
    RENLEC links to User ID in patron file
    RECOSU  
    REFCRE  
    REFCOM  
    REFFIN  
    Any additional fields not listed above may be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris. If you use other field names or have fields that you want to include in the migration but are not expected by Ex Libris, you can rearrange, add, or subtract fields on the right, as necessary.
    Note Name Local Fields
    NON_PUBLIC_NOTE  

    Questionnaire Tab

    Complete the following in the Questionnaire tab of the Migration Form.
    Default Patron Language
    Enter a two-letter code for the default conversational language for your users
    Code: PATRON_LANG
    Default: en
    Options: Use the two-letter codes as defined in ISO 639-1. Consult the codes from https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes. Additionally, the language code zh-tw (Taiwanese Mandarin) is accepted.

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

    Code: PATRON_PRIMARYID
    Default: UNIV ID
    Options: Using the AbsysNET Field Mapping Form, map the identifiers exported from AbsysNET to the following list: UNIV ID, BARCODE, ADDL ID 1, ADDL ID 2, ADDL ID 3. Then, select the identifier to be used as primary for all patrons.
    Further Information: The identifier selected here is used as the match point for externally managed patron records to match with an external authentication system such as LDAP or Shibboleth.  Additionally, this identifier is the primary identifier for internally managed patrons. It is highly recommended to use the Primary Identifier as the identifier for authentication.  Notice 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

    Currency for patron fines
    Code: CURRENCY
    Default: USD
    Options: Use the three-letter code (for example, USD, EUR, GBP) for the currency used for patron fines. For a list of valid codes, consult http://en.wikipedia.org/wiki/ISO_4217.
    Use a map for the patron campus 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 AbsysNET patron campus (LOCOBI) field to distinguish between different user groups for resource sharing activities like ILL borrowing. If you select Yes, fill in the mapping from the LOCOBI field to the Alma CampusCode field on the Campus Code tab. If you select No, all users are simply considered part of the same group for resource sharing activities.
    See also: Campus Code Tab
    Merge Patron Prefix
    Code: MERGE_PATRON_PREFIX
    Default: No
    Options: If you are combining data from two or more separate databases into a single combined institution in Alma, then indicate a prefix here that will be used to distinguish the incoming patron record original IDs.  This prefix is only added to the internal patron identifier, it is not added to barcodes or usernames or UNIV_ID.  If you are not merging institutions, leave this question blank.
    See also: BIB_KEY_PREFIX

    User Group Tab

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

    User Stat Categories Tab

    This tab is used to migrate the statistical categories in your patron records (if you have them) to Alma.

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

    The migration engine adds a space between the label and the value.

    AbsysNET USER_CATEGORY: List all of the values from all of the fields that you want to put into the statistical category mapping. For example, if you use three different fields from the patron record, list all of the values from all three fields in AbsysNET. Include the label applied if it is important to distinguish between values in different fields.
    Source Description: A description of the individual categories, for information only. This field is not used in the mapping to Alma.
    Alma Stat Category: The Alma Statistical Category code desired. This code is used to retrieve groups of patron records with various reporting tools.
    Alma Stat Category Description: The description of the Alma Statistical Category Code. This value is loaded into the code table for userStatCategories. This description can be updated after migration.
    Further Information: Alma has a Statistical Categories field in the patron record that can be used to retrieve statistics on groups of patrons. AbsysNET has three different user category fields and Alma has only one.

    Campus Code Tab

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

    Further Explanation – Fulfillment

    Internal/External Patrons

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

    Identification Numbers

    The migration program allows for six different types of user identifiers: University ID, Barcode, and Additional ID 1, 2, 3, and 4. Select one of these identifier types as the primary ID – the primary unique identifier for the patron.  You may map multiple identifiers from your previous ILS.  You may also consider mapping email address, a common matchpoint in authentication systems, to an additional ID field.
    The following appears in the AbsysNET Data Delivery Form:
    User Identifiers: values in column A are the expected AbsysNET 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 AbsysNET Migration Form.
    UNIV ID LEDDNI UNIV ID
    P BARCODE LENLEC P BARCODE
    ADDL ID 1 LEDDNN ADDL ID 1
    ADDL ID 2   ADDL_ID_2
    ADDL ID 3   ADDL_ID_3
    ADDL ID 4   ADDL_ID_5
    So, for example, if you want the field LEDDNI to be used for the primary ID for your users in Alma, select ‘UNIV_ID’ for the primary ID question on the Questionnaire tab of the AbsysNET Migration Form.
    When selecting the primary ID, the first identifier found in the field is used as the primary ID, and all subsequent identifiers are kept in the userIdentifier section. The primary ID must be unique, so if there are duplicates, the first unique ID found is migrated as is, and the IDs for the second and subsequent patrons with the same ID are given a suffix of -1, -2, etc. 
    Identifiers may not be duplicated, even within the same patron record. See the questionnaire question DUP_ID_SAME_PATRON for options.
    If the identifier selected for the primary ID is not present, the migration program creates an identifier for the patron based on the patron original ID, prefixed with ID. The migration programs do not fill in the primary ID with a non-selected identifier.Select BARCODE, UNIV_ID or ADDL ID 1, 2, 3, or 4 as the primary ID type for internal or external patrons in the Questionnaire tab of the AbsysNET Migration Form.

    Acquisitions

    Ex Libris migrates your acquisitions data if you have purchased premium migration services.  Expected files are: Vendors, Funds, and Orders.
    If you are not migrating Acquisitions, there are still some questions on the Questionnaire tab that must be answered in order to begin using Acquisitions in Alma post go-live.

    Vendors

    Provide the vendor file in comma delimited format, as a standard Millennium extract. The following fields are expected.

    Vendor accounts are mandatory in Alma, so the migration programs generate a single vendor account for each vendor migrated from AbsysNET.

    Field Name Notes
    SECUENCIAL Absys Vendor code
    Nobmbre tercero Vendor name
    Direccion Vendor address
    Ciudad Vendor city
    Pais Vendor country
    Telefono Vendor telephone
    Correo electronico Vendor email
    NIT National Tax ID
    ID Acreedor SAP Additional code for Vendor
    VENDOR_NOTE Multiple fields may be mapped here.  There there is only one type of vendor note.

     

    Orders

    AbsysNET provides an order header and multple lines per header.  

    Field Name Notes
    AANADQ Purchase order number
    AAFSAD create date
    AAUSAD created by
    AAFSMD update date
    AAUSMD updated by
    AANPRV vendor code; links to vendor record.  Required
    AAFPED send date
    AACOMO currency, in 3-letter ISO, like USD, EUR, AUD
    AASTAT entry point; use in PO Entry Point map
    AACOSU library
    AAFPRE Expected activation date
    AACOPR Acq Method; use in PO Acq Method and PO Line Type maps
    PO_NOTES multiple fields may be mapped to PO Notes.
    Lines
    ADNSEQ PO Line Number (POL Reference)
    ADFSAD Create date
    ADUSAD created by
    ADFSMD update date
    ADUSMD updated by
    ADNADQ links to header file
    ADNTIT Bib ID; required.  In Alma, a purchse order must be linked to inventory.
    ADCOCU Fund code; links to a fund code in the FUND file
    ADESTI Amount, in currency specified by AACOMO
    ADPEDI Item quant
    POL_NOTE multiple fields may be mapped to POL Notes

    Funds

    Fund records are collected in an Excel form and then exported to CSV format and submitted to Ex Libris. Funds are not extracted from AbsysNET directly. All funds must be listed in the first tab of a spreadsheet before exporting to CSV. Files in Excel format are not accepted by Ex Libris. Also, since the file must be exported to CSV before submitting, there is no possibility of having multiple Excel tabs in the submitted file. 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 legacy ILS, define one general ledger for use in Alma.

    Note that fund codes, summary codes, and ledger codes are unique across the entire fiscal period, not just within specific hierarchies – so in the file submitted, there should be no fund or ledger code duplication since all of the funds and ledgers go into a single active fiscal period. This uniqueness restriction applies across ledger codes, summary fund codes, and fund codes.  See the section 'Uniqueness examples' below for further explanation on this point.

    Funds are grouped under summary funds, and summary funds or allocated funds are grouped under ledgers. Only one level of summary fund is allowed in the extract; however, you can create a new summary fund in Alma after migration and drag other summary funds underneath it in the hierarchical fund structure.

    You can use the LIBRARY field to differentiate the funds of multiple campuses or libraries from one another. The library code must be a valid AbsysNET location code.

    The FUND CODE in this file must match a fund code used by AbsysNETs order records to make an encumbrance transaction in Alma that links the order to the fund.

    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 within the same ledger.  See the section 'Uniqueness examples' 
    SUMMARY FUND NAME Not mandatory, may be repeated across lines within the same ledger. See the section 'Uniqueness examples' 
    FUND CODE

    Alphanumeric, not repeatable (This is the fund code that links to the fund code in the Millennium order record.)  THis must be unique, even across ledgers. 

    If providing invoices and therefore funds across multiple fiscal years, all funds must still be unique.  In that case, codes should be like this: 

    Current year fund code unsuffixed, like BOOKS

    Previous year fund codes have a suffix of the year, like BOOKS-2020, BOOKS-2019.  You may only submit previous year funds if you are also submitting invoices.  Submit only single-year funds if you are submitting orders but not invoices.

    FUND NAME Alphanumeric, repeatable.
    LIBRARY The values here must be in the AbsysNET library list. Matching is case sensitive. There can be multiple libraries n this field, separated by a semicolon. This field can be left empty, which means that all locations 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 local currency, of the current fiscal year’s funds. Enter only the numbers with decimal places, not the currency symbol.  For example: 10000.00.
    FY Fiscal Year YYYY.   Typically this is the active fiscal year.  AbsysNET customers may only provide funds for one fiscal year (the active fiscal year).  Multiple fiscal years are only allowed if customers are providing invoices.
    NOTE optional note for the fund
    Uniqueness Examples

    When creating funds, the fund codes must be unique.  The only exception to this is the summary fund code, which may be repeated but only within the same ledger to indicate a hierarchy.  See the table below for more examples of uniqueness in fund codes.

     

    Ledger code Summary fund code Allocated Fund Code Fiscal Year Comment
    L1 ARTS MUSIC 2021 "ARTS" may be repeated here because this indicates a single summary fund ARTS in the ledger L1, which contains two allocated funds below it (MUSIC and DRAMA).
    L1 ARTS DRAMA 2021
    L1 SCIENCE BIOLOGY 2021  
    L2 ARTS PERFORM 2021 "ARTS" may not be repeated here in the L2 ledger because it is already being used in the L1 ledger.
    L2 ARTS TACTILE 2021
    L2 SCITECH BIOLOGY 2021 "BIOLOGY" may not be repeated here since it is already in use in the L1 ledger
    L2 SCITECH BIOLOGY_L2 2021 Either come up with a completely different fund code or put a ledger suffix on the fund code.
    L1 ARTS MUSIC 2020 both "ARTS" and "MUSIC" may not be used here since they are being used in Ledger L1 in FY 2021.  Codes may not be repeated even in different fiscal years.
    L1 ARTS_2020 DRAMA_2020 2020 This is a correct use of fund codes for funds in different fiscal years.  Funds in different fiscal years is only available for customers who provide invoices.
    L1 BOOKS L2 2021 "L2" as an Allocated Fund Code is not allowed here because it is already being used as a ledger code.
    L1 BOOKS ARTS 2021 "ARTS" as an Allocated Fund Code is not allowed here because it is already being used as a Summary Fund Code.

    Questionnaire Tab

    Complete the following in the Questionnaire tab:
    Migrate Acquisitions
    Code: ACQ_MODE
    Options: Select Yes or No depending on whether or not you have contracted with Ex Libris to migrate any Acquisitions data.
    Default currency for Ledgers/Funds
    Code: ACQ_CURRENCY
    Default: USD
    Options: List the currency used for all of your funds. Orders can have other currencies and be translated to the default currency, but funds must have a single base currency.
    The currency should be a three-letter code, as listed in http://en.wikipedia.org/wiki/ISO_4217
    Default language of conversation with vendors
    Code: VENDOR_LANG
    Default: en
    Options: Specify the default vendor language for your vendors. Use the two-letter codes as defined in ISO 639-1. Consult the codes from https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes.
    Fiscal Period Cycle Pattern
    Code: FISCAL_PERIOD
    Default: 01-07-1 (fiscal period starts on July 1 (01-07) and lasts for one year (-1).
    Options: To have functioning ledgers, fiscal periods are required. Specify your fiscal period as DD-MM-C (Day-Month-Cycle). For example, a one year fiscal period starting on January 1 is indicated by: 01-01-1. A one year fiscal period starting on July 1 is indicated by: 01-07-1.
    Alma currently supports one-year fiscal period cycles.
    Which year do you use to name the fiscal year?
    Code: FISCAL_PERIOD_NAME
    Default: second
    Options: Specify if the fiscal period is named with the first year or the second year.
    • second – if fiscal period runs July 1 2014 through June 30 2015, then the fiscal year is named 2015.
    • first – if fiscal period runs July 1 2014 through June 30 2015, then the fiscal year is named 2014.
    If your fiscal period runs from January 1 through December 31, this question is not necessary.
    Current Fiscal Year
    Code: CURRENT_FISCAL_PERIOD
    Default: determine by date of conversion
    Options: This question is important around the fiscal period close, depending on whether or not you have run fiscal period close in your legacy ILS, or if you will run it in Alma after migration. If you do not know how to answer this, select determine by date of conversion. The options are:
    • Determine by date of conversion – The conversion program uses the fiscal period that includes the date of conversion.
    • 2013-2014 – Select this option if the date of conversion is later than the fiscal period to which you want your orders to migrate. For example, if the migration date is July 3, 2014, and the previous fiscal period ended on June 30, 2014, select this to put all of your orders in the fiscal period that ended on June 30, 2014. Select this option if you want to run fiscal period close in Alma instead of in your old system.
    • 2014-2015 – If the date of conversion is earlier than the start date of the desired fiscal period, select this option. For example, if the migration date is June 15, 2014, and the next fiscal period begins on July 1, 2014, select this option to put all of your orders in the next fiscal period. Select this option if you want to perform the fiscal period rollover in your legacy ILS prior to conversion.
    Accrual Accounting
    Code: ACCRUAL_ACC_FY
    Default: No, do not make an additional fiscal year
    Options: If your library uses accrual accounting, you can instruct Ex Libris to make an additional fiscal year. When an additional fiscal year is created, it will be after the current fiscal year. For example, if the current active fiscal year is 2016, then the additional year, also active, will be 2017. The options are the following:
    • No, do not make an additional fiscal year.
    • Yes-No Funds ¬ make an additional fiscal year but leave it empty. The library will then need to create funds for this fiscal year after go-live.
    • Yes-duplicate funds – make an additional fiscal year and also fill it with funds that are the same codes as the funds in the current fiscal year. No allocations are made.
    Central Order Library or Default 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 Order Location field specifies the order location for orders in the previous system. The migration attempts to map the location field to the corresponding Alma Library. If you want to override this field and instead assign an order library to all orders migrated, fill in a value for the Central Order Library question. Otherwise, if you want to use the order location field to determine the order library, leave the Central Order Library question 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 order location field and only when a library is not specified or a mapping is not found does it use the Default Order Library as a second choice.

    Default claiming period 

    Code: ORDER_CLAIM

    Default: 90

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

    Fund Prefix 

    Code: FUND_PREFIX

    Default: none/blank

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

    See also BIB_KEY_PREFIX and MERGE_PATRON_PREFIX

    PO Entry Point Tab 

    The entry point value is used to determine where PO falls in the workflow in Alma. The PO entry point is mandatory in Alma, so the ALMAME_VALUE_NOT_FOUND line is required to catch any AASTAT (status) values that may not have been found in the map.

    Additionally, since all possible values for the AASTAT field in Millennium cannot be accommodated in the Alma values, every original AASTAT value is placed in the note field for each individual migrated order for reference after migration.

    AASTAT: The possible values for the order status in Millennium, found in the AASTAT field in your order extract (header).

    Description: The description of the AASTATfield, for information only. This field is not used in the mapping to Alma.

    poEntryPoint: The desired order status in Alma. Select from one of the values in the drop-down box. The following options are available:

    • 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 be NEW for just 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. A SENT continuous order is set to waiting for renewal if the subscription to date is earlier than the renewal date.
    • 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 Line Type Tab 

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

    AACOPR: Value of the order type field in AbsysNET, found int he AACOPR field in your order extract (header).

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

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

    • PRINT_OT – printed book one time. This is used for one time or infrequent orders of specific items, for example, a printed book, E book, or a musical score, that is not published repetitively. The order is at the item level. If the only physical items that you order are books, this type is essentially the same as Print Book - One Time.
    • PRINTED_BOOK_OT: Print Book One Time
    • PRINT_CO – journal/continuation. This is used for orders that are repeated on a regular basis. An example is monthly subscriptions to physical or electronic material such as journals. The order is at the holding level, and items in the holding record are received periodically.
    • PRINTED_JOURNAL_CO: Print Journal - Subscription
    • PRINT_SO – standing order monograph. This is used for orders that are not repeated on a frequent or regular basis. For example, this type of PO line is used for purchasing all the printed books by a particular author when they are published or where a series of books are being published, but not necessarily on a regular basis. The receipt of new material involves a new bibliographic, holdings, and item record. If the only physical items that you order are books, this type is essentially the same as Print Book - Standing Order.
    • PRINTED_BOOK_SO: Print Book – Standing Order
    • PRINT_SO_NONMON - Standing Order Non-Monograph – Similar to continuous orders.
    • OTHER_SERVICES_OT: Other Services One Time – Various non-inventory orders for services purchased from a vendor. Both one-time behavior and repetitive behavior are available. This should only be applied to orders without inventory. For electronic resources, see Line Types and Electronic Orders.
    • OTHER_SERVICES_CO: Other Services Subscription. This should only be applied to orders without inventory. For electronic resources, see Line Types and Electronic Orders.

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

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

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

    Line Types and Electronic Orders 

    The above line types are all descriptions based on a print order. All orders are stored in Symphony as print and so are migrated to Alma initially as print using the above line types. The physical to electronic (P2E) process identifies orders attached to electronic bibliographic records and transforms the order to electronic. In other words, if an order migrates as PRINT_SO, is attached to a bibliographic record you identify as electronic and is in an electronic location, it is changed to the corresponding electronic standing order line type by the P2E process. See the section on Physical to Electronic Processing below for more information on the overall P2E process.

    PO Acq Method Tab 

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

    AACOPR: The value of the AACOPR field in AbsysNET, found in your order extract (header).

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

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

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

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

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

     

    Physical to Electronic (P2E) Processing

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

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

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

    Questionnaire Tab

    For each of the following three questions (P2E_LINK, P2E_NOTE, and P2E_PROVIDER), indicators may be used in the following manner:
    • Specific indicators: 85641u
    Only tags with indicators 41 will be chosen
    • No indicator – meaning, the # is used for a blank character: 8564#u
    Only tags with indicators 4 will be chosen
    • All possible indicators: 8564*u
    Any tag with first indicator 4 will be chosen, regardless of what the second indicator is
    The space character operates the same way (8564*u == 8564 u)
    • Multiple specific indicators: 85641, 85642 (separate with a comma)
    Special Request: If you need to specify multiple specific indicators, for example 85641 and 85642, place it 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

    This question does NOT control whether or portfolio or DB is created.  This package only controls which URL to use after the decision to make a package has been made.  See the P2E Guide for more explanation.
    Code: P2E_LINK
    Options: Provide a 3 digit Marc field code + subfield: 856u. Only one field/subfield is allowed.
    Recommendation: 856 u
    Default: If this is left empty, no tag is used.

    Which Holding or Bib field stores electronic link public note

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

    Which Holding or Bib field stores electronic provider name information

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

    Alma Location Tab

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

    Further Explanation – P2E

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

    Barcode Modifications

    AbsysNET stores item barcodes and patron barcodes in the database in a shorter format than is on the item.  AbsysNET uses internal routines to match the full barcode (on the item) with the shortened barcode in the database.

    Alma stores the entire barcode in Alma as is.  Therefore, when migrating to Alma, we need to modify the exported (shortened) barcode to be the full barcode which matches the item.

    There are a number of different routines that can be used to modify barcodes.  Customers specify these routines using the 'Barcode Modification' tab of the AbsysNET Field Mapping form.

    Examples
    INPUT Columns: we will use these columns to identify which barcodes will be changed OUTPUT columns: after identifying barcodes, this is how they are modified
    patron or item operator length prefix range begin range end output string padding when =< Checkdigit routine (X)
    item length = 9 4     3111NNNNNNNNNX   Luhn
    patron length =< 8       21114NNNNNNNNX 0 Mod10
    item length = 9 1,2     0115NNNNNNNNNX   Luhn
    item range 6   000003 993148  114NNNNNNX   Luhn
    item length = 8 3     390000NNNNNNNN    
    patron length = 5 0     14NNNNNX   Luhn
    patron length = 6 0     015NNNNNNX   Mod10

     

    Input Columns

    These columns are used to determine which barcodes will be modified.

    Patron or Item: Indicate if the barcode is a patron barcode or an item barcode.

    Operator: there are three choices

    • length = : Length of the barcode is exactly equal to the number in the 'length' column
    • length =<  : Length of the barcode is less than or equal to the number in the 'length' column
    • range : The length of the field is equal to the number in the 'length' column, and also the number is between the two values 'range begin' and 'range end'. 

    Length: used with 'Operator' column.

    Prefix: the barcode begins with the specified number(s).

    Range: used with the Operator column, when option 'range' is selected.

    Output Columns

    After we have identified the barcodes which should be modified, this is how they are modified.

    Output string: N represents the original number, and there should be as many Ns as the length.  Example, length = 6, then NNNNNN is in the output string.   The other numbers around the NNNNNN represent what should be added to the string.  An X indicates the checkdigit to be added, routine specified in column 'Checkdigit routine'. 

    Example, for an original barcode whose length is 6.  

    114NNNNNNX

    means, add 114 to the beginning of the number, and then add a checkdigit at the end.

    If the incoming number is 123456, then the final number is 1141234569, where the 9 is a calculated checkdigit.

    Padding when =<:  If the original operator is =<, then we can add padding to the original number.

    Example, for an original barcode whose length is 4, but the operand said =< 6.

    87NNNNNN, padding 0

    If the incoming number is 1234, then the final number is 87001234.  THe two zeroes are added to move the number from 4 digits to 6 digits in length.

    Checkdigit routine:  Specify the checkdigit routine to use.  The two options are Luhn or Mod10. If you use a different checkdigit routine, inform your Ex Libris representative.

    Appendix A – File Delivery and Form

    Each time data files are provided to Ex Libris in the formats indicated in Expected File Formats, place them on your drop-point on the Ex Libris secure file server with the access credentials provided by your Ex Libris project manager.
    The following is the default naming convention:
    CustomerName+DataType+sequence+date+[.].
    For example: centralu_bib_01_20120420.mrc, centralu_bib_02_20120420.mrc, centralu_bib_03_20120420.mrc, etc.
    Ex Libris recommends a maximum of 200,000 records per MARC file and 400,000 for other types of records (items, orders, etc).
    All records in a single file must be 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.
    For security purposes, the file names listed on the secure file server are not displayed after you upload them.
    Provide the AbsysNET Delivered Files Form along with the submitted files.

    Appendix B – Post-Migration Process Statuses

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