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

    Libero to Alma Data Delivery and Migration Guide

    Migration Overview

    Libero is the Integrated Library System provided by the company LIB-IT. Libero is used primarily used by libraries in Germany.
    This document serves two purposes:
    • A step-by-step guide to filling out the Libero Migration Form.
    • An explanation of the  expected files from Libero and associated migration rules.
    The procedure for migrating from the Libero Integrated Library system to Ex Libris’ Alma consists of the following steps:
    • Indicate which local fields correspond to Ex Libris' expected fields using the Libero 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.
    • Extract the relevant data elements from Libero into flat files (customer responsibility).
    • Upload the files to Ex Libris’ FTP server along with the Libero Delivered Files form and the executed/validated Non-ExLibris to Alma Validation Tool (customer responsibility).
    • Transform the data elements, based on the Libero Field Mapping form, into an intermediate conversion XML format (Ex Libris responsibility).
    • Load the transformed data into Alma (Ex Libris responsibility).
    Deliver the Libero Field Mapping form and validated data validation output to Ex Libris along with the Libero Migration Form prior to the actual delivery of the data. The lead time depends on your project schedule. Provide the Libero Delivered Files form, which lists the file names and the record counts for each file, at the same time that you provide your data extract files.
    For all files, the maximum file size is 2GB.
    Provide the Libero data elements in flat files, and place them on an Ex Libris FTP server. Prepare the data files with the naming conventions as described in Appendix – FTP Drop Point 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:
    • Files Expected - a description of the data files expected from Libero, along with descriptions of fields.
    • Questionnaire Tab – Instructions for individual questions asked on the Questionnaire tab of the Migration Form.
    • Individual Tabs – Instructions for how to fill out the individual tabs on the migration form. (Examples: Alma Library Tab, User Group Tab, PO Line Type Tab).
    • Further Explanation – Explanations of migration processes that need more explanation and/or do not need customer input.
    We recommend that you look at the Questionnaire Tab section and the individual tabs in each area to assist in filling out the migration form.
    If you have further questions about any of the data input or about the migration in general, see the more detailed explanations in the Further Explanations sections.

    Related Documentation

    • This document is intended to complement two forms:
      • Libero Migration Form – an Excel spreadsheet that is read by the migration programs. It provides further information regarding the migration process and the steps required for migration to Alma.
      • Libero Field Mapping Form - an Excel spreadsheet used to map incoming fields to the Ex Libris expected fields.  
    • Prerequisites: Basic knowledge of Alma and Libero key concepts and architecture and the requirements listed in Getting Ready for Alma and Discovery Implementation.
    • It is recommended that you view the Introduction to the Alma Configuration Process video session before completing your migration form, as the mapping and migration of libraries and locations have implications for subsequent configurations.
    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.

    Excel Forms 

    Prior to submitting your extracted files, complete the Libero Field Mapping form. Indicate which data elements (files) you plan to provide in the Overview tab of the spreadsheet. On the subsequent tabs, indicate your local Libero field names and how they map to our expected field names.
    Even when the name of the field provided is the same as that listed in the ExL Expected field name, 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. 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 Libero Field Mapping form.
    At the time you submit the requested data files, submit the completed Libero Delivered Files Form. List the files, record counts, and encoding for each file delivered to the FTP server.
    Finally, provide the Libero Migration form, which maps incoming data to Alma data, at the time that you deliver your files.  The Migration Form should be validated using the online validation tool.

    Requested Files from Libero

    Ex Libris expects a certain set of files to be exported from Libero. The general expected file deliveries are listed below. The data elements listed for each are those that Ex Libris expects to use in conversion. Some data elements may exist in Libero 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 below, provide it to Ex Libris via an FTP connection. This facilitates the transformation analysis and expedites the conversion process. Information on the FTP connection is provided by Ex Libris. For more information, see Appendix – FTP Drop Point Delivery and Form.
    With the exception of bibliographic and holdings records which are expected in MARC format, all files are expected in CSV format with one record per line, fields delimited by quotes and commas, and multiple values within fields delimited by quotes and semicolons (for example two levels of address or multiple barcode values).

    Inventory

    • Bibliographic records – Bibliographic records are expected in MARC21 format. Ex Libris expects these records to be exported from the bibliographic utility BSZ.
    • BSZ-to-Libero mapping file – A translation file mapping the BSZ identification number to the Libero identification number. This file also includes an indication if the bibliographic record is suppressed from public view.
    • Holdings records – Alma requires MARC Holdings records. We expect to receive a MARC Holding file from BSZ that contains holdings records for some, but not all bibliographic records. Ex Libris will retain only those holdings records with serial summary information (866 tags). Additionally, the holding records from BSZ do not link to Libero item records.
    • Physical Inventory (item) records – Ex Libris expects two item files: a main item file and a secondary call number file. Additionally, if purchase orders are NOT being migrated, the item order information can be included in the item record as a note.
    • Serials information – Ex Libris expects seven different files related to serials. All of the data elements in the serials files will be placed in a note in the first MARC holding record found on the related bibliographic record.
    • Electronic Resources (P2E file) – Most non-Alma ILS systems store records for both physical and electronic items in the same format, which is a physical format. Alma has different record formats for electronic and physical items. Provide a list of bibliographic records that represent electronic materials so they can be converted to electronic format after migration to Alma. The possible types of electronic resources are packages, databases, and portfolios. The identification number in this file is expected as a BSZ identifier.
    Alma requires bibliographic, holdings, and item records. Data for Libero comes from two places: the bibliographic vendor BSZ provides bibliographic and serials holdings records in MARC format, and Libero provides item, fulfillment, and acquisitions information in CSV format.
    The BSZ holdings records do not have a shelving location associated with them, so they are migrated as a standalone holding record attached to the bibliographic record. Ex Libris will migrate only those holding records that have a serial summary statement (866 tag) present.

    The Libero item records are not linked to any existing MARC holding record, so the migration programs will generate a MARC holding record based on information in the item. No attempt will be made to link items to existing holding records, because items have location information and the BSZ holding records do not.

    Additionally, the migration programs make holdings records based on information in the serials files. The holdings created from serials generally contain note information.
    See the MARC Holding Records section for more information on how MARC holding records are generated.

    Bibliographic Records

    Bibliographic records are expected in MARC format, usually extracted from the bibliographic utility BSZ. Standard MARC is preferred, but files in MARCXML format are also acceptable. The character encoding expected from BSZ is UTF-8 or MARC8. Deliver all files with the same character encoding.
    If you use standard 7XX fields for linking between bibliographic records, this is leveraged during migration. If the relationships are based on your bibliographic record system numbers, provide the field that contains these system numbers in the migration form.
    If you have loaded SFX MARCIt records into BSZ, it is recommended that they not be included in the bibliographic record export to avoid unnecessary duplication with records loaded directly from SFX. If you want Ex Libris to detect and not migrate the SFX records, ensure that a 035 |a field with (SFX) in the field content is provided, so that the records can be identified, and answer No to the question about SFX bibliographic record on the Questionnaire tab of the Libero Migration Form.

    Link between BSZ and Libero + Suppressed Records

    Since the bibliographic records are coming from BSZ and the rest of the data is coming from Libero, Ex Libris requires a translation file for the BSZ ID and the Libero ID. Additionally, in this file, provide a column indicating whether or not the record should be suppressed from public view. We expect the following fields for this file:
    • The bibliographic record identifier from BSZ
    • The related identifier from Libero (used to link to items, loans, orders, etc.)
    • An indication if the bibliographic record should be suppressed

    Holdings

    Holding records can be migrated or generated from Libero in three different ways:
    • From the MARC holding file extracted from BSZ. Items do not attach to these records, because the holding records do not have local holding codes
    • From a bibliographic tag, such as an 866, with summary holdings statements (optional)
    • From information in the item records, if the item is not already attached to a record from a bibliographic tag

    MARC Holdings

    As part of the BSZ extract, provide holdings records in MARC format. Ex Libris expects that the MARC holdings will not have location information, so all MARC holdings from BSZ will be given a default location code. They will be attached to the correct bibliographic record, but no item records will be attached to the holdings. In other words, the MARC holdings records from BSZ will be migrated as standalone holding records.
    On migration, Ex Libris will remove the contents of the 852 $a in MARC holdings records. If you want to preserve the information in the 852 $a, move it to a separate subfield prior to delivery for migration.
    If multiple 852 fields exist in a MARC holding record, the first 852 field is used and the subsequent fields are changed to 952. If a single 852 tag has multiple $b (library) and/or $c (location) subfields, only the first instances of those two subfields are used and the extra $b and $c are moved to $v and $w.

    Holdings From a Bib Tag

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

    Items

    Item information is expected to be provided in two different files:
    • The main item file, delivered in CSV format. This file will include a Libero bibliographic ID, and Ex Libris will use the Libero ID to BSZ ID file to attach the item to the correct BSZ bib record.
    • A secondary file containing multiple call numbers for each item, also delivered in CSV format.
    The following table lists the expected fields for item migration. If your item fields have different contents, indicate the subfield mapping in the Bibs& Items tab of the Libero Field Mapping Form.
    The mappings indicated in the Notes column below are found in the Libero Migration Form. See the accompanying Libero to Alma Migration Guide for instructions on how to complete this form.
    Expected Field Name Notes
    Libero Identnummer Titeldaten = Libero ID (Title) links to bib-ID
    Barcode = Item barcode links to loan, request and fine files
    Signatur = Main call number

    If a holding record is present, then this is used to match an item to a holding record, if $h is included in 852_subfields_for_hol. 

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

    * 'could' because Item Call Number (below) will be placed in ITEM_CALL_NUMBER if present.  If Item Call Number is NOT present, then Main call number is placed in the ITEM_CALL_NO according to the descriptions in "Determining Groups of Holding Records" and "Changing the Holding Record Grouping" sections below.

    Exemplar-Richtlinie = Item Policy/Item Type use item type map on Migration Form (1st column)
    Exemplar-status = Item Status use itemBaseStatus map
    Bibliotek = Library use Alma Location map on Migration Form
    Standort = Location use Alma Location map on Migration Form
    Item call number If this is present, then the value will be placed in ITEM_CALL_NUMBER.  This value takes precedence over a possible value from the Main Call Number, according to the descriptions in "Determining Groups of Holding Records" and "Changing the Holding Record Grouping" sections below.
    Gesamtanzahl Ausleihen = Total no. of loans

    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.

    Datum der letzten Rückgabe = Date of the last return To see this value in Alma, search for the item under 'Physical Items' and on the results list click 'Other details'.
    Medientyp = Material type use item type map on Migration Form (2nd column)
    Inventory Number Maps to the Inventory Number in Alma

    Inventory Price/Replacement Cost

    Inventory Price/Replacement Cost
    Expected Field Name Notes
    Ersatzkosten = Replacement price Both fields may be filled with the local ‘Ersatzkosten’ field from Libero if desired.  The REPLACEMENT_COST will be used to assess fines if the item is lost.
    REPLACEMENT_COST

    Secondary Call Number File (mehrfachsignaturen)

    Secondary Call Number File (mehrfachsignaturen)
    Expected Field Name Notes
    Signatur = Call number The field from the secondary item file containing call numbers. Ja = call number goes to Item AltCallNumber field; Nein = call number goes to note field
    Hauptsignatur-Kennzeichnung = Main call # indication 1 = Yes, 0 =No
    Any additional fields not listed above can be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. The subfields listed in the Default Local Subfield column are those that are expected by Ex Libris. If you use other field names or have subfields that you want to include in the migration, but are not expected by Ex Libris, you can rearrange, add, or subtract fields in the Default Local Subfield column as necessary. The text in the Note Label column is used as a prefix to the subfield contents and can be modified, as desired. If you want to include multiple local fields in the same Alma note, copy the line in the spreadsheet as many times as needed for all note name/local field combinations.
    Note Name Local Fields
    PUBLIC NOTE  
    FULFILMENT_NOTE  
    NON_PUBLIC_NOTE_1  
    NON_PUBLIC_NOTE_2  
    NON_PUBLIC_NOTE_3  
    STAT_NOTE_1  

    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.  For example: 

    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  

    Serial information

    Serial information is expected to be provided in seven different files:
    • Serials acronyms & frequency
    • Serials notes (financial)
    • Serials notes (distribution)
    • Serials notes (general notes)
    • Serials notes (other notes)
    • Serials notes (Receiving note)
    • Serials notes (subscriptions)
    All of the above files are linked together by the Libero bibliographic identifier. All files are expected in CSV format. Only one field is currently expected in the serial files: the Libero Title ID. Other fields are placed in the notes fields. Indicate which fields are expected in the Serials tab of the Libero Field Mapping Form.
    Expected Field Name Notes
    RSN = Libero Title ID  
    Bibliotek = Library
    Library, location, and summary statement were not found in the Libero serials files, but they are options if the customer can retrieve them.
    Standort = Location
    Übersicht = Summary statement
    Any additional fields not listed above can 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 fields that you want to include in the migration, but are not expected by Ex Libris, you can rearrange, add, or subtract fields in the Local field column as necessary. 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.
    Information in the NON_PUBLIC_NOTE will be placed in an 852 $x of the holding record. Information in the PUBLIC_NOTE will be placed in an 852 $z of the holding record.
    Note Name Local Field
    NON_PUBLIC_NOTE  
    PUBLIC_NOTE  

     

    Customer Input - Inventory

    Questionnaire Tab

    Institution Code, Customer Code, Institution Name, Customer Name, Time Zone
    Codes: INST_CODE, CUST_CODE – these are filled in by Ex Libris
    INST_NAME, CUST_NAME – these are mandatory and must be filled in.
    Default: N/A
    Options: This question is mandatory.
    INST_NAME and CUST_NAME: Fill these fields in with your institution’s name and your customer name (this is only different from the institution name if you are part of a consortium).
    List Prefix for bibs from SFX or other management system
    Code: SFX_PREFIX
    Default: ‘(SFX)’
    Options: String. If not indicating a link resolver management system, leave blank.
    Further Information: If your Libero catalog contains records imported from SFX or another electronic resources management system and you are also migrating bibliographic records directly from SFX or the other management system, this may result in duplicate bibliographic records in Alma. You can enter a prefix here so that the migration programs can identify these bibs and not migrate them to Alma to avoid creating duplicate SFX records in Alma. The migration programs do not make any attempt to physically merge the two records into one.
    The default response to this question is (SFX), but you can enter any prefix that represents the bibs that you want to exclude from loading into Alma. The migration programs search for the string in the 035 $a field of the MARC record. If you do not want to exclude any such records, leave this field blank.
    If the migration programs identify bibliographic records containing the prefix in the 035 $a and the records in Libero are connected to a purchase order line and/or physical items, these bibliographic records are still migrated so that the purchase order and/or items can be migrated, but they are automatically suppressed in Alma to avoid end-user discovery duplication.
    MARC Organizational Code
    Code: MARC_OC
    Default: None; this is not mandatory
    Options: Enter your MARC Organizational code, which will be used to construct the former system number in Alma. Only one code is allowed. In Germany, these are the same as ISIL and are managed by the Staatsbibliotek zu Berlin.
    Further Information: The migration moves the value in the exported record’s 001 field (BSZ bibliographic system number) to the 035 $a field:
    (MOC)<BSZ 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)123456-49abc
    Do you use internal system numbers in $w of Linked Entry fields?

    Indicate if you use internal system numbers in fields 76x-78x, 80x, 81x, and/or 83x, subfield $w, to link bibliographic records to each other.

    Code: LINKED_ENTRY_W
    Default: No
    Options: If Yes, the internal system numbers are converted from the BSZ system number to the Alma system number.
    Internal record designation for Linked Entry fields $w
    Code: LINKED_ENTRY_PREFIX
    Default: blank
    Options: If there are internal system numbers in $w, indicate if they have a prefix that is used to identify these numbers (for example, (abc)12345). If the system numbers in $w do not have a prefix (for example, 12345), leave this question blank.
    If No for the LINKED_ENTRY_W question, then leave 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, BSZ may store the information in bibliographic fields 76x-78x. If the number in the $w of the linking tags is the internal BSZ 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 rather 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 $w field (along with $z and $x) 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.
    Indicate which 852 subfields to use to determine unique holding records
    Code: 852_SUBFIELDS_FOR_HOL
    Default: bc (library and location only, not call number)
    Options: To group all items on a single bibliographic record by library/location only, indicate bc here. If you have many items on the same bibliographic record in the same library/location but different call numbers WITHIN that library/location, and you want each of them to have their own distinct holding record, specify additional call number subfields.  Acceptable subfields: 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.
    See sections: Determining Groups for Holding Record Creation/Matching, Changing the Holding Record Grouping/Matching
    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. Use this option only if agreed upon with your Ex Libris project manager.
    Bib Key Prefix
    Code: BIB_KEY_PREFIX
    Default: empty
    Options: If you are combining data from two or more separate databases into a single combined institution in Alma, then indicate a prefix here that will be used to distinguish the former system numbers in Alma after migration. For example, the different systems likely had completely different bibs for system number 12345 and you want to be able to search for the specific bib from your own institution after go-live. The prefix does not include a hyphen so if you want a hyphen in the number (e.g. PQ-12345), then include it in the string. If you are not merging institutions, leave this question blank.
    See also the MERGE_PATRON_PREFIX and FUND_PREFIX.
    Move 001/003 to 035 or 935

    Code: 001_035_935

    Default: 035

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

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

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

    001 12345

    003 OCoLC

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

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

    Use subfield indicators in item call number (AltCallNo)

    Code: ITEM_CALLNO_SUBFIELD

    Default: Yes

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


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

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

    Add $9 LOCAL to specified tags

    Code: NZ_LOCAL_TAGS

    Default: empty

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

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

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

    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. 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 Libero Alma-Bibliotek, which is the higher level of location, is comparable to the Alma library. Use the Alma Libraries tab in the Libero Migration Form to indicate your list of Alma libraries. The actual mapping from the Libero Alma-Bibliotek to the Alma library is done in conjunction with the Standort (Location) in the Alma Location tab.
    : If you use an error library (for example “EMPTY”) in the ALMAME_VALUE_NOT_FOUND line of the Location Mapping tab, be sure to list that library here on the Library Tab.

    Alma Location Tab

    Use this tab to map your Libero libraries and locations to Alma libraries and locations. Mandatory.
    Include ALL locations of ALL types, including electronic types that may ultimately be deleted in Alma. They still need to be provided in the location tab mapping.
    Libero Library Code: Value from the Alma-Bibliotek field in the item extract from Libero. The ALMAME_VAL_NOT_FOUND line is required to catch any library codes that you may have missed.
    Libero Location Code: Value from the Location field in the item extract from Libero. The ALMAME_VAL_NOT_FOUND line is required to catch any location codes that you may have missed.
    Libero Location Description: A description of the location, for assistance in filling out this form. This column is not used in the mapping routine.
    Alma Library Code: The Library that will contain this location in Alma. This code must be present on the Alma Library Tab, column A. The match is case-sensitive.
    Alma Location Code: The new location code for this location in Alma. It can be a maximum of 10 characters. You can use the same location codes in Alma that you used in Libero, but this is not required. You may also use this form to collapse locations if desired, for example refa and refb in Libero both map to ref in Alma. Mixed case is valid, but not recommended. Do not use special characters or spaces. All owed: - and _ (hyphen and underscore). Not allowed: !@#$%^&*()+=/?><.,\|]}[{`~ or the space character.
    Call Number Type: List the call number type for any newly created holdings records, based on the values for the 852 first indicator. (http://www.loc.gov/marc/holdings/hd852.html). If we cannot determine the call number type from the item record itself, we use this as a default for all items in the location.
    Alma Location Name: A description for this location as seen/used by library staff members. The same location name cannot be used for different locations in the same library, but the same location name can be used for different locations in different libraries. See the examples in the Further Information section below for what is acceptable and not acceptable. Maximum 255 characters.
    Alma External Location Name: A description for this location as seen/used by the public. The same name can be used for as many different locations as desired. For example, the location names may be Archives A and Archives B, but the external location names can both be Archives. Maximum 255 characters.
    Electronic Location? (Yes or No): Used by the P2E migration process to determine if a holding/item/order should be converted to electronic. See the Physical to Electronic (P2E) Processing section for more information.
    Suppress from Externalization? (Yes or No): Indicate if the location should be suppressed from being visible to the public. The items are not marked as suppressed, but no holdings or items with this location code are exported to Primo.
    Further Information: Do not leave the Alma location and library code fields blank. If you want to stop using a location code after migration, map the Libero code to an easily identifiable code such as XXX or unused in case any stray items are still in your Libero database.
    ALMAME_VALUE_NOT_FOUND
    The ALMAME_VALUE_NOT_FOUND line must be included at the top of the list of locations, in case any location codes were overlooked when completing this map. For example, you may think you do not have any items left in a certain collection, so you leave it off the location map. However, there may be one or two items left, or a stray holding record, etc.
    By default, the location code for the ALMAME_VALUE_NOT_FOUND line is “UNASSIGNED”, which is the default catch-all in Alma in production mode. Ex Libris recommends that you select your primary/largest library as the library code for the line, for example, “MAIN” as in the example line below. In this case, the items inherit the configurations for the MAIN library.
    Libero Location code Libero Locn Desc Alma Library Alma Location Code Alma Location Desc Alma External Loc Desc etc
    ALMA_ME_ VALUE_NOT _FOUND   MAIN UNASSIGNED Problem location from Migration Problem: See Library Staff  
    Post-migration, search for items in the “UNASSIGNED” location and correct the records appropriately.
    Alma Location Name and Alma External Location Name
    The Alma Location Name column contains the names of the location codes that are displayed in the staff interface. The names cannot be repeated in the Location Name column when the location codes both belong to the same library, but you can use the same name for two different locations, if these locations belong to different libraries. The Alma External Location Name column contains the names of the location codes that are displayed to library patrons. These names can be repeated within the column without regard for libraries. For example:
    The following is acceptable:
    Library Alma Location Code Alma Location Name Alma External Location Name
    Library A stacks Main Stacks Main Stacks
    Library B stacks Main Stacks Main Stacks
    Library A archa Archives A Archives
    Library B archa Archives B Archives
    Library A archstk Archives Stacks Archives
    Library A archref Archives Reference Archives
    The following is not acceptable:
    Library Alma Location Code Alma Location Name Alma External Location Name
    Library A archstk Archives Archives
    Library A archref Archives Archives
    The Alma library and Alma location are put in the following places in the migrated or newly created MARC holdings record:
    • The Alma library is placed in the 852‡b field.
    • The Alma location is placed in the 852‡c field.
    Collapsing Locations
    This mapping table can be used to collapse location codes – that is, two or more location codes in Libero 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 Libero code to an easily identifiable code such as XXX if any stray items are still in your Libero database.
    If you collapse location codes, you may have lines in the table such as the following:
    Libero 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.
    ITEM STATUS (Exemplar-status): The value in the item status field from the Libero item extract. The status typically indicates what is happening to the item, such as in binding, in repair, lost, etc.
    Description: The description of the item status code. The text in this column is written to the internal note 1 in the item in Alma. Maximum 255 characters.
    baseStatus: In Alma, the base status indicates whether or not the item is on the shelf. Indicate whether or not an item with this status is on the shelf. For example, lib use only is on the shelf (1), but withdrawn is not (0).
    Further Information: Alma has a process type that indicates the status of an item depending on the Alma workflow (item is on loan, item is sent to the bindery, etc.), but the process type is dependent on the corresponding Alma workflow. For migration, all item statuses that are indicated as not on the shelf (0) from Libero are given the process type of TECHNICAL. Further, the item status description field is written to internal note 1 for all items where there was a status, regardless of the shelf/not on shelf designation.
    Include any status that may indicate no status, for example Available, but leave column B blank. This migrates the item to Alma with no status at all, which is how Alma indicates that an item has no status. If any status is in your data but is NOT included in column A, it is given a note of Unknown status.
    Post migration, you can search for and re-route items with values in the internal note 1 to the appropriate handling or department in Alma. This process can also be used as a configurable criterion for suppressing items from display in the Get It services screens from discovery systems. See Appendix - Post-Migration Process Statuses for more information.

    Item Type Tab

    Use this tab to migrate the Libero Item Policy (Exemplar-richtslinie) and optionally the Libero Material type (Medientyp) to the Alma Item Type. 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.
    Libero Item Policy: The value in the item policy field of the item. The item policy is used to differentiate between items when determining how something circulates.
    Item Policy Description: The description of the Libero item policy, for information only. This column is not used during the mapping process.
    Libero Material Type: (Optional) If the item policy from Libero is not enough to determine the item Policy in Alma, then the material type may be used as a distinguishing factor. This field is not mandatory and you may only choose to fill it in where distinction is needed.
    Material Type Description: The description of the Libero material 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 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.
    Further Information: If you will leave column C blank to indicate that we should disregard the value in Mediantyp, then the blank should be at the bottom of the group of column A values.
    Incorrect:
    Item Status desc Medientyp desc itemPolicy
    A   ABC   A1
    A   DEF   A2
    A       A1
    A   GHI   A2
    In the above list, items with values A,GHI will be caught in line 3, because the table is read from the top-down.
    The table should be correctly filled out as follows:
    Item Status desc Medientyp desc itemPolicy
    A   ABC   A1
    A   DEF   A2
    A   GHI   A2
    A       A1
    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.

    Material Type Tab

    Use this tab to migrate the Libero Material type (Medientyp) to the Alma Material type.
    Libero Material Type (Medientyp): The value in the material type field of the item coming from Libero.
    Material type Description: The description of the Libero 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 mapped, the migration will generate a material type from the bib fixed fields.  See the section below on Material Type for information.

    Further Explanation – Inventory

    Bibliographic Records

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

    MARC Holding Records

    Alma requires a MARC holding record for all items. During the migration process, the Alma library and Alma location are put in the following places in the MARC holding record:
    • The Alma library is placed in the 852‡b field.
    • The Alma location is placed in the 852‡c field.>/li>
    When the MARC holding record is created based on information from the item, then additionally the $h and $i subfields are filled with the call number from the Libero item call number field. The item call number is taken from the call number field in the item record, NOT from the secondary call number file.
    As stated in the introduction, the MARC holding records from BSZ do not have location or call number information. Therefore, the 852 $b, $c, and $h are all left blank for MARC holdings records received from BSZ.

    Determining Groups for Holding Record Creation/Matching

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

    Changing the Holding Record Grouping/Matching

    As part of the migration process, the customer must decide which criteria to use to group items that will share a newly-created MARC holding record. The 852 subfields as mapped from Libero are: $b Alma Library/Bibliotek $c Location/Standort $h Call Number. By default, the migration programs compare $b and $c, but the customer can decide to change this to also include $h based on items in their collection.
    For example, if there are four items and a single holding record on the same bibliographic record with the following call numbers:
    item 1 $b main $c stacks $h PN 567 .M4
    item 2 $b main $c stacks $h PN 567 .M4
    item 3 $b main $c stacks $h PN 567 .M4 2010
    item 4 $b bio $c flr1 $h PN 567 $i .M457
    When only $b and $c are used to determine a holding record group, the following is the result in Alma:
    Holding record A: $b main $c stacks $h PN 567 .M4
    item 1
    item 2
    item 3 (original call number stored in ItemCallNo field in the item)
    Holding record B: $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, the following is the result in Alma:
    Holding record A: $b main $c stacks $h PN 567 .M4
    item 1
    item 2
    Holding record B: $b main $c stacks $h PN 567 .M4 2010
    item 3
    Holding record C: $b bio $c flr1 $h PN 567 .M457
    item 4
    Decide which 852 subfields should be used to determine holding record groups by answering the question in the Questionnaire tab of the Libero Migration Form, Indicate which 852 subfields to use to determine unique holding records.

    Call Numbers from Secondary File

    Call numbers for items are taken only from the main item file. The call numbers in the secondary item file (mehrfachsignaturen) go either to the item’s AltCallNumber field (when “Ja”) or to a note (when “Nein”).

    Call Number Type

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

    Item Barcodes

    Alma does not allow item barcodes to be duplicated. The item barcode must be unique in Alma. Barcodes may be left empty.
    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>.

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

    Material Type

    The material type in Alma is a description of the type of material the item is such as book, map, issue, DVD, compact disc, etc. It is controlled by a fixed list of physical resource material types in Alma. Each item in Alma must have a material type specified.

    Customers may provide a material type in the item extract from Libero if desired.  If not provided in the extract, the migration automatically assigns a material type based on Bibliographic record LDR and 007 fields. There is no customer input required for this part of the migration as the Alma types are fixed.   The material type in migration is derived from the resource type which is constructed by Alma based on the bib header information. To see a description of how the resource type is determined, see the Resource Type Field description.

    Areas/Fields Not In Scope

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

    Fulfillment

    Patron records are required if loans, requests, or fines are being migrated. Patron records can be updated post-migration with the patron update routines.
    • Patrons – Ex Libris expects four different patron files from Libero. Ex Libris will combine the files into a single file to generate a patron record in Alma. In order to migrate any area of fulfillment (fines/ fees, loans, requests), all patrons must be migrated.
    • Loans – generated from the circulation transaction extract for active loans only, from Libero.
    • Fines/Fees – generated from the fine/fee extract from Libero. The migration programs will generate fines in Alma for those fines/fees with an outstanding balance. Closed fines/fee transactions will not be migrated.
    • Requests – generated from the request extract from Libero. The migration programs will generate a request record only for those requests that are on the shelf waiting for pickup.

    Patrons

    Extract all patrons. Provide the patron files in csv format. The following files are expected:
    • general user file
    • user Address file
    • additional info file
    • user notes (used only for notes)
    The fields in the following table are expected. Indicate the local field names for the expected fields in the Patrons tab of the Libero Field Mapping Form.
    Field Name Notes
    Nachname = Last name  
    Vorname = First name  
    Anrede = Title  
    Geburtsdatum = Birth date  
    Geschlecht = Gender  
    Benutzerkategorie = User category/group (code) Use the “User Group” map in the migration form
    Campus Code use the Campus Code map in the migration form
    From the user address file
    Straße = Street  
    Straße Zusatz = Street additional info.  
    Stadt = City  
    Postleitzahl = Postal code  
    Land = Country The migration programs do not standardize this country name.  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
    Straße Adresse 2 = Street 2nd address  
    Straße Zusatz = Street 2nd address additional info.  
    Stadt Adresse 2 = City 2nd address  
    Postleitzahl  Adresse 2 = Postal code 2nd address  
    Land Adresse 2 = Country 2nd address  
    Straße Adresse 3 = Street 3rd address  
    Straße Zusatz Adresse 3 = Street 3rd address additional info.  
    Stadt Adresse 3 = City 3rd address  
    Postleitzahl Adresse 3 = Postal code 3rd address  
    Land Adresse 3 = Country 3rd address  
    E-Mail = Email address  
    private Telefonnummer = Phone number (Home)  
    Mobilnummer = Phone number (Mobile)  
    geschäftliche Telefonnummer = Phone number (Work)  
    From the User Additional Information file
    Benutzerstatuscode = user status  
    Benutzerstatuscode Beschreibung = Status code description Use the User Block map in the Migration Form
    Anmeldedatum = first seen on  
    Ablaufdatum = expiration date may be left empty
    letztes Änderungsdatum = last modified date  
    Any additional fields not listed above are not functional and can be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris. If you use other field names or have fields that you want to include in the migration, but are not expected by Ex Libris, you can rearrange, add, or subtract fields on the right, as necessary. If you want to include multiple local fields in the same Alma note, copy the line in the spreadsheet as many times as needed for all note name/local field combinations.
    Note Name Default Local Field
    LIBRARY_NOTE  
    BARCODE_NOTE  
    ADDRESS_NOTE  
    OTHER_NOTE OTHER_NOTE is set as user viewable by the migration programs.  This is the only note which migration marks as user viewable.

    User Identifiers

    There can be a number of fields in the patron record that are user identifiers. The types of identifiers that are available for migration into Alma are listed in the left column. The typical expected field names from Libero 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 Libero Migration Form.
    Alma Identifier Type Librero Field Name
    UNIV_ID  
    BAR  
    ADDL_ID_1  
    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 User Group, but you may want to track the department, so that you can get more detailed statistics on how Law students borrow, for example. Since various ILS systems have different fields for tracking statistical categories, we provide you the option to map the data from any field in your local ILS to the User Statistical Categories in Alma.

    User Statistical Categories
    User Statistical Category Local Field Name Field Label
    USER_STAT_CATEGORY    
    USER_STAT_CATEGORY    
    USER_STAT_CATEGORY    

    Up to 10 incoming fields can be mapped. To map the values, use the UserStatCategories map in the Libero 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 in the Migration Form would be: LABEL: value, for example: SCHOOL: Law.  The validation tool does not provide a colon, so if you want the colon be sure to include it , e.g. 'DEPT:', but the tool does add a space between the label and the value.

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

    clipboard_e2aa93036138a14009b7d157e0f2d5e72.png

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

    clipboard_e05c1bc84e8c6add0f665c0882acc3c50.png

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

    Active Loans

    Extract only current circulation transactions, in csv format.
    The fields in the following table are expected. Indicate the local field names for the expected fields in the Loans tab of the Libero Field Mapping Form.
    Field Name Notes
    Benutzernummer = User ID matches user ID in patron file
    Barcode = Item barcode matches barcode in item file
    Ausleihdatum = Loan date  
    Fälligkeitsdatum = Due date  
    Ausleihstatus = Loan status  
    Anzahl Verlängerungen = No. of renewals Migration uses this to check for renewal status. If you want to keep the number of renewals, also put this in the note field
    Any additional fields not listed above can be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris. If you use other field names or have fields that you want to include in the migration, but are not expected by Ex Libris, you can rearrange, add, or subtract fields on the right, as necessary.
    Note Name Local Field
    NON_PUBLIC_NOTE  

    Requests

    Extract active hold requests, in csv format. Active hold requests are those that are 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 Libero Field Mapping Form.
    Field Name Notes
    Benutzernummer = User ID matches User Id in patron file
    Barcode der Exemplarvormerkung = Item barcode matches barcode in item file
    Request status date = Datum Status Im Vormerkregal  
    User name = Nutzername  
    Bereitstellungsdatum = On hold user notification date  
    Bereitstellungszweigstelle = Library that has the item on hold  
    Any additional fields not listed above can be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris. If you use other field names or have fields that you want to include in the migration, but are not expected by Ex Libris, you can rearrange, add, or subtract fields on the right, as necessary.
    Note Name Local Field
    NON_PUBLIC_NOTE  

    Fines/Fees

    Extract only outstanding fine/fee transactions, in csv format. Outstanding fine/fees are those with an active balance that still needs to be paid.
    The fields in the following table are expected. Indicate the local field names for the expected fields in the Fines & Fees tab of the Libero Field Mapping Form.
    Field Name Notes
    Benutzernummer = User ID Matches user Id in patron file
    Transaktionsdatum = Transaction date  
    Gebührentyp-Code = Fine/fee transaction type (code) Use Fine Fee Type map in Migration Form
    Gebührenbetrag = Fee amount  
    Barcode = Item barcode Matches barcode in item file
    Titel = Title of the bibliographic record  
    Any additional fields not listed above can be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris. If you use other field names or have fields that you want to include in the migration, but are not expected by Ex Libris, you can rearrange, add, or subtract fields on the right, as necessary.
    Note Name Local Field
    NON_PUBLIC_NOTE  
    NON_PUBLIC_NOTE  

    Customer Input

    Questionnaire Tab

    Which identifier should be used as the patron's Primary Identifier?
    Code: PATRON_PRIMARYID
    Default: UNIV ID
    Options: Using the Libero Field Mapping Form, map the identifiers exported from Libero into the following list: UNIV ID, BARCODE, ADDL ID 1, ADDL ID 2, ADDL ID 3. Then, select here the identifier which should be used as primary for all patrons.
    See also: Identification Numbers, Internal? question on the User Group tab
    How should we handle duplicate identifiers in the same patron? 

    Code: DUP_ID_SAME_PATRON

    Default: DISCARD

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

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

    Default: DISCARD

    Enter a two-letter code for the default conversational language for your users (for example en or de)
    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.
    Currency for patron fines
    Code: CURRENCY
    Default: USD
    Options: Use the three-letter code for the currency used for patron fines. For a list of valid codes, consult http://en.wikipedia.org/wiki/ISO_4217.
    Use a map for the 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 your patron records to distinguish between different user groups for resource sharing activities like ILL borrowing. If you select Yes, fill in the mapping from the USER LIBRARY to the Alma CampusCode field on the Campus Code tab. If you select No, all users are simply considered part of the same group for resource sharing activities.

    See also: Campus Code Tab

    Request default destination library
    Code: REQUEST_LIBRARY
    Default: None
    Options: Provide an Alma Library code, which is present on the Alma Library tab of the migration form, which will be used as a default if no request destination library is found in the migrated requests.
    Merge Patron Prefix

    Code: MERGE_PATRON_PREFIX

    Default: No

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

    See also: BIB_KEY_PREFIX and FUND_PREFIX

    User Group Tab

    The user group is used to distinguish groups of patrons from each other in determining different levels of circulation policies. Typical user groups are faculty, staff, undergrad, etc.
    If patrons are being migrated, then this mapping table is mandatory.
    Libero User Group (Benutzerkategorie): The Libero User Group code, found in the Benutzerkategorie field of the patron extract.
    Libero Description: A description of the Libero user group code, here for information only. This column is not used in the mapping to Alma user group
    Alma userGroup Code: The mapped group code in Alma. You may choose to use the same codes that you used in Libero, or you may choose to use different codes. You may also choose to collapse groups if desired, for example, having Freshman and Sophomore both map to Undergrad in Alma. Do not use special characters, for example, slashes (/) or spaces in the code.
    Alma userGroup Description: The description of the Alma userGroup. This description is loaded into the Alma code table as the description seen in the user interface. This description can be changed easily after migration.
    Internal? Y or N: Alma categorizes users as either external or internal. External patrons are managed and authenticated by an external system, such as through a regular load from the bursar’s office/campus student information system. Internal patrons are created and managed internally. Examples of internal patrons are rare cases where community borrowers or alumni use library services. When Y, all of the patrons in the Alma userGroup are categorized as internal. When N, all of the patrons in the Alma userGroup are categorized as external.
    External users are fully external (except patron notes), including all user identifiers, authentication, and address information. See also the following question on the Questionnaire tab:
    • Which identifier should be used as the patron's Primary Identifier?

    User Block Tab

    A user block is assigned to patrons that have a temporary suspension of borrowing privileges. Libero stores patron blocks in the user status (Benutzerstatuscode) field in the patron record.
    This mapping table is not mandatory.
    Do not include an ALMAME_VAL_NOT_FOUND line in this table. It is perfectly acceptable for a patron to not have a block code. If there are statuses in Libero which indicate that a patron is ok to borrow, do not include that status in this table.
    Libero user status: The Libero user status code, found in the Benutzerstatuscode field in the patron extract.
    Libero status Description: A description of the Libero status code, for information only. This column is not used in the mapping.
    Alma userBlock code: The block code desired in Alma.
    Alma userBlock description: The description of the block code in Alma. The value in this column is loaded to the server in the userBlock code table. This description can be easily updated after migration.

    Fine Fee Type Tab

    Outstanding patron fines from Libero are migrated to Alma Fines and Fees. Only the currently owed amount is migrated. If any partial payments have been made before conversion, they are not reflected on migration to Alma.
    Libero Fine Fee Type (Gebuhrentyp-code): List all of the values from the Libero fine fee type field in the Libero extract. Libero Description: A description of the fine fee type, for assistance in filling out this form. This column is not used in the mapping routine. Alma Fine Types: Possible values in Alma are listed in the drop-down list.

    User Stat Categories Tab  

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

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

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

    Incoming patron 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 listed three different three fields that have a patron category in the field mapping form, then list all of the values from all three of those fields here. 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.

    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.

    Incoming patron campus: The value of the patron campus as found in the patron extract.

    Description: A description of the patron campus 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 such a field for a similar purpose, map the value to the Alma Campus Code value with this map.

    Further Explanation – Fulfillment

    Patron 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 Libero Field Mapping Data Delivery Form:
    User Identifiers: values in column A are the expected Libero 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 Libero Migration Form.
    A B C
        UNIV_ID
    BARCODE BARCODE BAR
        ADDL_ID_1
        ADDL_ID_2
        ADDL_ID_3
        ADDL_ID_4
    Typical Libero customers have only the User ID (Benutzernummer) as the user identifier, but if your library has additional identifiers, fill them in columns B and C. Then, on the Libero Migration Form, Questionnaire tab, select the identifier from column C to use for the primary identification number for your internal and external patrons to use when authenticating from an external system (for example Primo).
    Whichever identifier is chosen for the primary ID, the first identifier found in the field is used as the primary ID, and all subsequent identifiers are kept in the userIdentifier section. The primary ID must be unique, so if there are duplicates, the first unique ID found is migrated as is, and the IDs for the second and subsequent patrons with the same ID are given a suffix of -1, -2, etc. 
    Identifiers may not be duplicated, even within the same patron record. See the questionnaire question DUP_ID_SAME_PATRON for options.
    If the identifier selected for the primary ID is not present, the migration program creates an identifier for the patron based on the patron original ID, prefixed with ID. The migration programs do not fill in the primary ID with a non-selected identifier.

    Acquisitions

    • Vendors – migrated from the vendor extract from Libero.
    • Funds – generated for the current fiscal year based on a single list of funds; allocation transactions are generated for the current fiscal year only.
    • Purchase Orders – migrated from the purchase order extract from Libero. Encumbrance transactions are generated for the current fiscal year only.

    Vendors

    Provide the vendor file in csv format. The fields in the following table are expected. Indicate the local field names for the expected fields in the Vendors tab of the Libero Field Mapping Form.
    Field Name Notes
    Lieferantencode = Vendor code  
    Lieferantenname = Vendor name  
    Abteilung = Department  
    Firma (Alternativadresse 1) = Company (alternative address 1)  
    Straße mit Hausnummer = Street name and number  
    Postfach = PO box  
    Postleitzahl = Postal code  
    Stadt = City  
    Staat = Country  
    Telefonnummer geschäftlich = Phone number (Work)  
    Faxnummer = Fax number  
    Anrede Ansprechpartner = Contact person title  
    Ansprechpartner Vorname = Contact person first name  
    Ansprechpartner Nachname = Contact person last name  
    E-Mail = Email address  
    WWW = WWW  
    Steuernummer = Tax number  
    Firma (Alternativadresse) = Company (alternative address)  
    Abteilung (Alternativadresse) = Department (alternative address)  
    Straße mit Hausnummer (Alternativadresse) = Street name and number (alternative address)  
    Postleitzahl (Alternativadresse) = Postal code (alternative address)  
    Stadt (Alternativadresse) = City (alternative address)  
    Staat (Alternativadresse) = Country (alternative address)  
    Ansprechpartner (Alternativadresse) = Contact person (alternative address)  
    E-Mail (Alternativadresse) = Email (alternative address)  
    Telefonnummer 1 (Alternativadresse) = Phone number 1 (alternative address)  
    Telefonnummer 2 (Alternativadresse) = Phone number 2 (alternative address)  
    Faxnummer (Alternativadresse) = Fax number (alternative address)  
    Kundennummer = Account code  
    Lieferantennotizen = Vendor note  
    Lieferantenstatuscode = Vendor status (code)  
    Any additional fields not listed above can be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris. If you use other field names or have fields that you want to include in the migration, but are not expected by Ex Libris, you can rearrange, add, or subtract fields on the right, as necessary.
    Note Name Default Local Field
    VENDOR_NOTE  
    USER_NOTE  
    ADDRESS_NOTE  
    DETAILS_NOTE  

    Funds

    Fund records are collected into an Excel migration form, then exported to CSV and delivered to Ex Libris for loading into Alma. Funds are not extracted from Libero directly. All funds must be listed on a single tab (the first tab on the spreadsheet) before exporting to CSV. You can submit separate CSV files, but they must be physically separate files and not multiple tabs on the same sheet. Each csv file must contain a header line with the field names as described below.
    In the fund file, LEDGER CODE, LEDGER NAME, FUND CODE, and FUND NAME are mandatory. Ledgers are mandatory. If your institution does not have ledgers in the current ILS, define one general ledger for use in Alma.
    Note that fund codes, summary fund codes, and ledger codes are unique across the entire fiscal period, not just within specific hierarchies. Therefore, there should be no fund code duplication in the spreadsheet submitted, since all of the funds go into a single active fiscal period.  Ledger codes are included in the unique constraint; ledger codes cannot be the same as any fund code.
    Funds are grouped under summary funds, and summary funds/funds are grouped under ledgers. Only one level of summary fund is allowed in the extract; however, it is a simple task in Alma to create a new summary fund after migration and drag other summary funds underneath it.
    Field Name Notes
    LEDGER CODE May be repeated across lines to group funds under a single ledger.
    LEDGER NAME May be repeated across lines to group funds under a single ledger.
    SUMMARY FUND CODE Not mandatory, may be repeated across lines.
    SUMMARY FUND NAME Not mandatory, may be repeated across lines.
    FUND CODE Alphanumeric, not repeatable (This is the fund code that links to the fund code in the extracted order record.) This must be unique, even across ledgers.
    FUND NAME Alphanumeric, repeatable.
    LIBRARY Must be in the Alma Library List on the Libero Migration Form. The library code must match the code in the migration form exactly – the match is case-sensitive. There can be multiple libraries here, separated by a semicolon. This field can be left empty, which means that all libraries in the institution can use the fund.
    If the central order library is used in the migration form, this field is ignored and all funds are set to the institution level, meaning that all libraries in the institution can use the fund.
    EXT ID External ID for linking to an external source, if one exists.
    ALLOCATION Allocation, in dollars, of the current fiscal year’s funds.
    FY Fiscal Year, in form YYYY

    Orders

    Provide the purchase order file in csv format. The fields in the following table are expected. Indicate the local field names for the expected fields in the Orders tab of the Libero Field Mapping Form.
    Field Name Notes
    Libero-Identnummer = Libero title ID Links to bib record.  Required.
    Bestellnummer = Order no. this must be unique per vendor in Alma
    Bestellnummner-Zeile = Order line no. this must be unique in Alma; migration will concatenate Order no. + Order line no. to make a unique number
    Lieferanten_Code = Vendor code Links to vendor file
    Haushaltskostenstelle = Fund code Links to fund file
    Notiz für Lieferanten = Vendor note  
    Bestelltyp = Order type Use map: PO Line Type
    Bestellstatus = Order status Use map: PO Entry Point
    Erwerbungstyp = Acquisition type Use map: PO Acq Method
    Exemplarpreis = Item price  
    Rabatt = Discount expressed as a percentage.  Use '5' to express a 5% discount.  Non-negative discounts only.  Decimal point is ok, for example 2.5 is 2.5 percent discount.
    Alma-Bibliothek = Alma Library This code should be present in Library/Location mapping tab
    Aktuelle Zweigstelle = ALma location This code should be present in Library/Location mapping tab
    Bestelldatum = Order sent date  
    Bezahldatum = Payment date This is used to calculate PO Entry Point - the check is only to see if the date is present.  If you also wish to retain this date for information, place it in a note.
    Berichtscode 1 = Reporting Code 1 Use the PO Reporting Code maps to map values to the Alma Reporting Code field.  The values in columns C and D are used to make the 1st Reporting Codes code table.  No prefix is necessary here since the PO Reporting Code map allows only one incoming value per map.
    Berichtscode 2 = Reporting Code 2 3Use the PO Reporting Code maps to map values to the Alma Reporting Code field.  The values in columns C and D are used to make the @nd Reporting Codes code table.  No prefix is necessary here since the PO Reporting Code map allows only one incoming value per map.
    Berichtscode 3 = Reporting Code 3 Use the PO Reporting Code maps to map values to the Alma Reporting Code field.  The values in columns C and D are used to make the 3rd Reporting Codes code table.  No prefix is necessary here since the PO Reporting Code map allows only one incoming value per map.
    Berichtscode 4 = Reporting Code 4 Use the PO Reporting Code maps to map values to the Alma Reporting Code field.  The values in columns C and D are used to make the 4th Reporting Codes code table.  No prefix is necessary here since the PO Reporting Code map allows only one incoming value per map.
    Berichtscode 5 = Reporting Code 5 Use the PO Reporting Code maps to map values to the Alma Reporting Code field.  The values in columns C and D are used to make the 5th Reporting Codes code table.  No prefix is necessary here since the PO Reporting Code map allows only one incoming value per map.

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

    Note Name Default Local Field
    POL_RECEIVING_NOTE This line cannot be duplicated; place only one local field name here.
    POL_VEND_REF_NO This line cannot be duplicated; place only one local field name here.
    POL_ADDL_NO This line cannot be duplicated; place only one local field name here.
    PO_NOTE  
    POL_NOTE  

    Customer Input

    Questionnaire Tab

    ACQ mode
    Code: ACQ_MODE
    Options: Select Yes or No depending on whether or not you have contracted with Ex Libris to migrate any Acquisitions data.

    Enter a default language of conversation with vendors

    Code: VENDOR_LANG
    Default: en
    Options: Use the two-letter codes as defined in ISO 639-1. Consult the codes from https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes.
    Central Order Library
    Code: CENTRAL_ORDER_LIB
    Default: None
    Default Order Library
    Code: DEFAULT_ORDER_LIB
    Default: First library found on the Alma Library list
    Options for Central and Default Order Library: The Library field specifies the order location for orders in Libero. The migration attempts to map the Library field to the corresponding Alma Library. If you want to override the Library field and instead assign an order library to all orders migrated, then fill in a value for the Central Order Library question. Otherwise, if you want to use the Library field to determine the order library, leave the Central Order Library blank and fill in a value in the Default Order Library question. In this case, the migration attempts to determine a library based on the Library field and only when a library is not specified or a mapping is not found does it use the Default Order Library as a second choice.
    If you use DEFAULT_ORDER_LIB and therefore attempt to map the Library field to an Alma location, you must include your Library values in the Alma Location Tab map in the migration Form. Library values are often not the same values as inventory Location fields.
    What is your currency?
    Code: ACQ_CURRENCY
    Default: USD
    Options: List the currency used for all of your funds. Orders can have other currencies and be translated to the default currency, but funds must have a single base currency.
    The currency should be a three-letter code, as listed in http://en.wikipedia.org/wiki/ISO_4217
    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 the fiscal period runs July 1 2014 through June 30 2015, then the fiscal year is named 2015.
    • First – if the 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 examp le, 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:
    • No – do not make an additional fiscal year.
    • Yes – No Funds – make an additional fiscal year but leave it empty. The library will then need to create funds for this fiscal year after go-live.
    • Yes – duplicate funds – make an additional fiscal year and also fill it with funds that are the same codes as the funds in the current fiscal year. No allocations are made.
    Default claiming period
    Code: ORDER_CLAIM
    Default: 90
    Options: Default claim used for vendors and orders (if applicable), in days.
    Fund Prefix
    Code: FUND_PREFIX
    Default: none/blank
    Options: If you are combining data from two or more separate databases into a single combined institution in Alma, then indicate a prefix here that will be used to distinguish the former fund codes in Alma after migration. Provide a string to be used to prefix all fund codes in the database. A hyphen is NOT provided. For example, if your fund code is SCIENCE-MONO, and you put UWS- here, the final fund code is UWS-SCIENCE-MONO. Leave this question blank to leave the fund code as is.
    See also the similar BIB_KEY_PREFIX and MERGE_PATRON_PREFIX

    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.
    Libero Order type (Bestelltyp): Value of the order type field in Libero, found in the Bestelltyp field in your order extract.
    order Type Description: A description of the order type field, for information only. This field is not used in the mapping to Alma.
    poLineType: The Alma line type value. Select one of the following line types from the drop-down list:
    • PRINT_OT – printed book one time. This is used for one time or infrequent orders of specific items, for example, a printed book, E book, or a musical score, that is not published repetitively. The order is at the item level. If the only physical items that you order are books, this type is essentially the same as Print Book - One Time.
    • PRINTED_BOOK_OT: Print Book One Time
    • PRINT_CO – journal/continuation. This is used for orders that are repeated on a regular basis. An example is monthly subscriptions to physical or electronic material such as journals. The order is at the holding level, and items in the holding record are received periodically. 
    • PRINTED_JOURNAL_CO: Print Journal - Subscription
    • PRINT_SO – standing order monograph. This is used for orders that are not repeated on a frequent or regular basis. For example, this type of PO line is used for purchasing all the printed books by a particular author when they are published or where a series of books are being published, but not necessarily on a regular basis. The receipt of new material involves a new bibliographic, holdings, and item record. If the only physical items that you order are books, this type is essentially the same as Print Book - Standing Order.
    • PRINTED_BOOK_SO: Print Book – Standing Order
    • PRINT_SO_NONMON - Standing Order Non-Monograph – Similar to continuous orders.
    • OTHER_SERVICES_OT - Other Services One Time – Various non-inventory orders for services purchased from a vendor. Both one-time behavior and repetitive behavior are available. This should only be applied to orders without inventory. For electronic resources, see Line Types and Electronic Orders.
    • OTHER_SERVICES_CO: Other Services Subscription. This should only be applied to orders without inventory. For electronic resources, see Line Types and Electronic Orders.
    Further Information: Use this tab to define the line type of the migrated order. The PO may move through Alma workflows differently according to what type of item is on order. For example, a monographic order is opened, sent to the vendor, received, invoiced, and closed. However, a serial order may be received and invoiced many times and may remain open indefinitely.
    Alma does have other PO Line types, but they are not available for use in migration.
    Line Types and Electronic Orders
    The above line types are all descriptions based on a print order. All orders are stored in Libero migrate 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.
    Libero Acquisition type (Erwerbungstyp): The value of the Acquisition type field in Libero, found in your order extract. Order type description: A description of the Order Type in Libero, for information purposes only. This field is not used in the mapping to Alma.
    poLineAcqMethod: The Acquisition method in Alma. AcqMethod is mandatory in Alma. If not found, then use PURCHASE. Select one of the following values from the drop-down list:
    • PURCHASE – normal workflow
    • GIFT – not sent to vendor and no invoicing or payment
    • EXCHANGE – not sent to vendor and no invoicing or payment
    • APPROVAL – pre-established delivery plan - normal workflow except not sent to vendor
    • VENDOR_SYSTEM – the order is placed at the vendor site so that sending it to the vendor is not required. The normal workflow is followed except that the order is not sent to the vendor.
    • DEPOSITORY – usually from the government. The order is not sent to vendor and there is no invoicing or payment.
    • TECHNICAL – no fund or amount required
    • LEGAL_DEPOSIT – does not require fund or price, and uses a special version of the PO Line order letter
    Comment: Add any comments about ORDR_TYPE for use while filling out this form. This field is not used by the migration programs.
    Further Information: The PO Acq Method is mandatory in Alma, so the ALMAME_VALUE_NOT_FOUND line is required to catch any values that may not have been found in the map.

    PO Entry Point

    The entry point value is used to determine where PO falls in the workflow in Alma. The following are the possible values for poEntryPoint:

    • NEW – The order has been created but not sent to the vendor yet. Orders can have status NEW for years while librarians are reviewing what to order, or they can have status NEW for a short while if the acquisitions staff created the order to send to the vendor immediately.
    • SENT – The order has been sent to the vendor and funds have been encumbered/committed. The item has not been received yet for one-item orders, or the item has been received for continuous orders. Continuous orders that continue to be invoiced/received remain with SENT status (which can be considered as a sub-status of waiting for renewal within Alma) until they are closed.
    • WAITING_FOR_INVOICE – Use only for one-time orders. The item has been received, but not the invoice. Invoice status must not be FULLY_INVOICED.
    • CLOSED – The order has been received and invoiced. Nothing else will be received on this order. (Do not use for open continuous orders that you are still receiving.)
    • CANCELLED – Cancelled order.

    For the migration from Libero, first the migration program checks if Bezahldatum = Payment date has value and it is a One-Time (OT) order. If so, the PO is set to CLOSED. Then, the program checks the PO Entry Point map.

    Libero Order Status (Bestellstatus): The value of the Order Status field in Libero.

    poLineType: The mapped PO Line Type (mapped in the PO Line TYpe tab)

    Alma PO Entry Point: select an entry point for this order in Alma. Possible values are described above and can be selected from the dropdown.

    PO Reporting Code Tabs 

    Use this tab if you wish to map values from the Libero reporting code field to the Alma Reporting Code field. These tabs are not required.

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

    Libero Reporting Code: The value of the reporting code in order record, found in the POL_REP_CODE_* fields in the order extract.

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

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

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

    Further Explanation – Acquisitions

    Purchase Orders

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

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

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

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

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

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

    Funds

    Encumbrances
    Transactions from active purchase orders are created as encumbrances in Alma when the orders fund reference is valid and exists. An active purchase order is defined as one in which the mapped PO entry point is NEW, SENT, or WAITING_FOR_INVOICE and is in the current fiscal year.
    Transactions of Amount 0.00
    Libero allows for transactions to be of value 0.00 for all purchase orders (encumbrances). In Alma, fund transactions can be of amount 0.00 only when it is an encumbrance and when the associated PO is of type GIFT, DEPOSITORY, EXCHANGE, or TECHNICAL.
    All other encumbrances of amount 0.00 are changed to 1.00.

    Physical to Electronic (P2E) Processing

    Provide a list of Libero bibliographic system numbers that represent electronic resources and an indication if these electronic resources are portfolio or database resources. The list should be a comma separated text file containing lines that represent each e-resource. The bibliographic identifier in this file is expected as a BSZ identifier. The format of each line is as follows: <bibnumber>,<resource type>
    For example:
    000000001,Portfolio
    000000003,db
    The words portfolio and db are not case-sensitive; therefore, both portfolio and Portfolio are acceptable.

    It is not possible to use the P2E process to generate a package; by definition, packages must have portfolios associated with them.  Instead, you may migrate packages as type database, which is basically a zero-title package, and then change the database to a package (with titles) post-migration.

    All records are converted to Alma as physical initially. A second process converts records identified as electronic to the electronic format. 

    If you provide a bibliographic record in the P2E file, the migration programs will generate an electronic resource for the bib, even if there is no valid URL. An example of an invalid URL might be an 856 tag with an indicator 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* an 85641u but that bib record is in the p2e file, then we will generate a local e-resource without any link at all (an empty resource).  Be careful which bibs are placed in the bib file.

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

    Customer Input

    Questionnaire Tab

    For each of the following three questions (P2E_LINK, P2E_NOTE, and P2E_PROVIDER), you can use indicators in the following manner:
    • Specific indicators: 85641u – only tags with 41 as the indicator is used.
    • No indicator (# is used for a blank character, for example: 8564#u) – only tags with 4<blank> as an indicator are used.
    • All possible indicators: 8564*u – tags with 4 as the first indicator are used. The second indicator is not taken into account.
      The space character operates the same way as an asterisk (*), for example: 8564 u is the same as 8564*u.
    • Special Request: If you need to specify multiple specific indicators, for example 85641 and 85642, it cannot be coded in the migration form but your ExL representative can make a special request to the migration team.
    Which Holding or Bib field stores electronic link information
    Code: P2E_LINK
    Options: Provide a 3 digit Marc field code + subfield: 856u. Only one subfield is allowed.
    Recommendation: 856 u
    Default: If this is left empty, no tag is used.
    Which Holding or Bib field stores electronic link public note
    Code: P2E_NOTE
    Options: Provide a 3 digit Marc field code + subfield: 856z. Only one subfield is allowed.
    Recommendation: 856 z
    Default: If this is left empty, no tag is used.
    Which Holding or Bib field stores electronic provider name information
    Code: P2E_PROVIDER
    Options: Provide a 3 digit Marc field code + subfield: 856m. Only one subfield is allowed.
    Recommendation: 856 m
    Default: If this is left empty, no tag is used.

    Alma Location Tab

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

    PO Line Type Tab

    Line Types and Electronic Orders
    The PO line types are all descriptions based on a print order. All orders are stored in Libero as print, and so are migrated to Alma initially as print using the above line types. The physical to electronic (P2E) process identifies orders attached to electronic bibliographic records and transforms the order to electronic. In other words, if an order migrates as PRINT_SO, is attached to a bibliographic record that you identify as electronic and is in an electronic location, it is changed to the corresponding electronic standing order line type by the P2E process.

    Further Information

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

    Appendix

    FTP Drop Point Delivery and Form

    Each time data files are provided to Ex Libris in the formats indicated in Expected File Formats on page 7, place them on an FTP drop-point on the Ex Libris FTP server with the access credentials provided by your Ex Libris project manager.
    The following is the default naming convention:
    CustomerName+DataType+sequence+date+[.<file_extension>].
    For example: centralu_bib_01_20120420.mrc, centralu_bib_02_20120420.mrc, centralu_bib_03_20120420.mrc, etc.
    Ex Libris recommends a maximum of 200,000 records per MARC file and 400,000 for other types of records (items, orders, etc).
    All records in a single file must be homogenous – all of the lines in the file must have the same number of fields, and those fields must contain the same type of data. Additionally, all of the records must be delimited in the same manner.
    For security purposes, the file names listed on the FTP server are not displayed after you upload them.
    Provide the Libero Delivered Files Form along with the submitted files.

    Post-Migration Process Statuses

    The process statuses (codes) from Libero 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?