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

    Sebina to Alma Data Delivery and Migration Guide

    Sebina is an Integrated Library System (ILS) produced by DM Cultura, used primarily in Italy and France.   This guide will help you provide files from Sebina to Ex Libris using the Delivered Files form and the Field Mapping form, assist in filling out the Migration Form, and answer questions you may have on how your data moves to Alma.

    This document serves three purposes:

    • A description of data elements expected, and how they are mapped using the Sebina Field Mapping form.
    • A step-by-step guide to filling out the Sebina Migration Form.
    • An explanation of general migration rules which do not require any customer input.

    Recommendations for Using this Guide 

    This document is divided into four areas:

    • Inventory
    • Fulfillment
    • Acquisitions
    • Physical to Electronic

    Each area has the following sections:

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

    We recommend that you look at the Questionnaire tab section and the individual tabs in each area to assist in filling in the migration form.

    For more information 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 the Sebina Migration Form - an Excel spreadsheet that is used directly by the migration programs.
    • Prerequisites: Basic knowledge of Alma key concepts and architecture, and the requirements (including the migration-related approach) described in Getting Ready for Alma and Discovery Implementation, as well as the Electronic Resource Handling in Alma Migration document. Additionally, knowledge of the concepts and architecture of Sebina is necessary.
    • 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.

    Migration Overview

    The procedure for migrating from Sebina to Ex Libris’ Alma consists of the following steps:
    1. Indicate which local fields correspond to Ex Libris' expected fields using the Sebina Field Mapping form, prior to data delivery (customer responsibility).  
    2. Extract the relevant data elements from the Sebina into flat files (customer responsibility).  Previous customers were not able to extract data from Sebina directly, and instead requested data extracts from DM Cultura.
    3. Upload the files to Ex Libris’ secure file server (MFT) along with the Sebina Delivered Files form (customer responsibility).
    4. Transform the data elements, based on the Field Mapping form, into an intermediate conversion XML format (Ex Libris responsibility).
    5. Load the transformed data into Alma (Ex Libris responsibility).
    Deliver the Sebina Field Mapping Form to Ex Libris along with the Sebina Migration Form prior to the actual delivery of the data. The lead time depends on your project schedule. Provide the Sebina 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.
    Provide the data elements in flat files, and place them on an Ex Libris secure file server. Prepare the data files in the exact format as specified in Appendix A – File Delivery and Delivered Files Form with the naming conventions as described there.

    Files Requested from Sebina

    Ex Libris expects a certain set of files to be exported from the incoming ILS, listed below. As files are extracted, be sure that the extracted file description, such as data elements and lengths, matches the description in Expected File Formats.
    The data elements listed are those that Ex Libris expects to use in conversion. Not all data elements that exist in Sebina are necessary to transfer to Alma.
    The scope of your specific conversion is agreed upon in your Alma contract.  Specifically 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.
    • As you extract data from any area listed below, provide it to Ex Libris via a secure file transfer connection to the MFT. This facilitates the transformation analysis and expedites the conversion process. For delivery instructions, see Appendix A – File Delivery and Delivered Files 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.

    Expected File Formats

    All the files listed in the tables below are expected in CSV format with one record per line, and fields delimited by commas and multi-values within fields delimited by semicolons. The following is an example of a record with multiple values for the third field:
    “field1”,”field2”,”field3a”;”field3b”,”field4”
    The following are the only exceptions to this expected format:
    • Bibliographic records (which are Unimarc standard files)

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

    Dates can be in any format, but they must be consistent. For example, do not use YYYYMMDD and then MMDDYYYY in the same file.

    Sebina Field Mapping Form

    Prior to submitting your extracted files, complete the Sebina 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 field names and how they map to Alma's expected field names.
    On all of the tabs in the Sebina Field Mapping form, there is a ##Foreign Key## column. Customers should not fill out this column – it is for internal use only. In addition, there are various note fields for each data element which are for information purposes only. Fields that are not expected by Ex Libris, because there is no functional place for the data element in the corresponding Alma data structure, can be placed in a note in the record. Specify the note type that you want the field to go to at the bottom of each tab in the Sebina Field Mapping form.

    Sebina Delivered Files List

    At the time you submit the requested data files, submit the completed Excel spreadsheet Sebina Delivered Files form. List the files, record counts, and encoding for each file delivered to the secure file (MFT) server.

    Sebina Migration Form

    Fill out the questions in the Sebina Migration form, using this page as a guide. The questions and mapping tabs in the migration form are used for data elements which require user input.   Submit the migration form along with your data.  

    Inventory

    Bibliographic Records

    Bibliographic records are expected in  UNIMARC or MARC format.The character encoding expected is UTF-8 or ANSEL/MARC8. If your library prefers to export in a different format, inform your Ex Libris project manager. All bibliographic and authority files should be delivered with the same character encoding.
    Each Bibliographic record MUST have a single unique source key/identifier in a consistent single source MARC/UNIMARC field. Records which do not conform will be rejected.

    Suppressed Records

    Suppressed records are those bibliographic records that you want to have in the database, but not show to the public. Examples of this are:
    • titles on order
    • missing or damaged titles where you want to keep the record but not show it to the public
    • titles that are for internal management only, such as equipment
    Provide a text file that contains the source BIB key/ID, one key per line, for bibliographic records that are suppressed.

    Linked Bibliographic Records

    If you use standard linking fields for linking between bibliographic records, they are leveraged during migration and create appropriate bibliographic-level linking in Alma.  Links which use standard numbers such is ISSN or ISBN require no intervention by the migration programs; links can be created automatically.  However, links which use the Sebina internal identifier, a unique key used only in Sebina, must be changed to the Alma internal key (MMSID). 
    No exported files are necessary for this category: use the migration form, Questionnaire tab, questions LINKED_ENTRY_W and LINKED_ENTRY_PREFIX, to indicate if your bibliographic records contain linking fields which use the Sebina internal identifier.

    Deleting Extraneous Linking Fields 

    In Alma, when bibliographic records link to each other, only one source tag is required.  Alma will make reciprocal links between records based on a tag in a single record.
    For example, bibliographic records representing Pieces have a Unimarc tab 410 which links the Piece up to the main Series record.   The Series record has multiple 463 tags linking down to each Piece.
    Series record
    463: links to piece 1
    463: links to piece 2
    463: links to piece 3
    Piece 1 record
    410: links to Series record
    Piece 2 record
    410: links to Series record
    Piece 3 record
    410: links to Series record
    In the example above, the 410 tags in the Piece records are sufficient to create reciprocal links between the Piece records and the Series record. 
    The 463 tags in the Series record are extraneous, and can be removed prior to load if your bibliographic records are extremely large.  The related note tags (311) are also removed.  

    Swap Sebina Bib ID with SBN ID 

    In 4XX linking records, you can choose to swap the 4xx $1001 Sebina Bib ID with the related record's SBN ID.  SBN is the National Library Service for Italian libraries.  The swapping of identifiers involves: 

    Original record:

    4xx $1001 = Sebina bib number 123

    Find this bib number in a related record 123

    Related record:

    001 = 123

    017 $a = SBN number 456

    Original record: 

    Update the 4xx $1001 with the related record's SBN number.

    4xx $1001 -> SBN number 456

    To use this option, inform your Ex Libris customer representative, who will notify the migration team.

    Authority identifiers

    Additionally, in the same manner that the Bib ID can be swapped with the related SBN ID, you can choose to swap the Sebina identifier in field 7xx $3 with the related SBN Identifier from an authority file.

    Non-Filing characters

    Sebina uses a non-displayable character to indicate non-filing text.   Using '*'' as the non-displayable character, Sebina stores text like this: 

    *The *quick brown fox jumped over the lazy dog.

    Alma Migration translates this non-displayable character to << and >> so the sentence is now:

    <<The >>quick brown fox jumped over the lazy dog.

    << and >> are supported characters for indicating non-filing text in Alma.

    To use this option, inform your Ex Libris customer representative, who will notify the migration team.

    Electronic Link Resolver Records

    If you have SFX MARCIt records, 360MARC records from 360Link, or equivalent electronic records from another link resolver in your ILS that are also represented by your link resolver system, Ex Libris recommends that they be excluded from the data provided to Ex Libris.  Excluding them from migration will avoid unnecessary duplication with the link resolver system data. If these records are NOT removed, you will likely see a record in Alma migrated from the ILS and the same record migrated from SFX, 360Link, or other link resolver.
    An exception to this is if the records have active orders or physical inventory that are also being migrated, these records should be kept. If you choose to provide a string to indicate records to be removed/not migrated, the migration programs remove records with no attached orders or inventory and keep records with attached orders and items.
    No exported files are necessary for this category: use the Questionnaire tab of the migration form to indicate a string that will be checked in the 035 field. Example: ‘(SFX)’.

    Holding Records

    Alma requires a holding records for all items.  If a holding record is not provided, one is generated based on information in the item record(s). 

    For Sebina migrations, holdings records can be generated in Alma in the following different ways:
    • From the CONS_consistenze file, which contains summary holdings statements
    • Based on information from the item fields, if the item is not already attached to a holdings record created from the CONS file.

    Non-MARC Serial Holdings (Consistenze)

    The Consistenze file contains summary holdings statements and call number information.  This file is used to generate holding records.
    Provide the CONS_Consistenze file in CSV format, one record per line. 
    MARC Holdings
    Expected Field Name Notes
    Id links to INVE then COLL file
    IdBiblioteca(BIB_Id) library code, use in Alma Location map
    IdTitolo(TI_Id) links to bib record
    Consistenza Summary statement 
    Nota non public note
    FlagVisibileInOpac Translates to 'suppressed' flag for holding records

    Holdings From a Bib Tag

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

    Item Records

    Ex Libris expectts mutliple files for item records from Sebina.  The files are:

    • Inventari (INVE): Inventory.  Main item file
    • COLL_collocazioni (COLL):  Locations, including the call number
    • Dati Copia Inventari (INVDC): item notes
    • Fascicoli (FAS): Issues
    • Possessori (POS): Possessor; information here goes to notes

    Also, the following files contain linking information (relations) between the above files:

    • RELFASESE: Legami Fascicolo Annata; Links between FAS (Issue) and INVE (Items)
    • RELFASVOL: Legami Fascicoli Volumi; links between FAS (Issue) and bound volume file.  This is used to determine if an issue has been bound
    • RELPONSINVE: Legami Possessori Inventario; links between INVE (items) and POS (Possessori)

     

    Files should be delivered to Ex Libris in CSV delimited format. Items that do not have a BIB key are not migrated.

    Suppressed Item Records

    All suppressed item records are migrated to Alma as regular items (not suppressed). However, specific locations can be marked as suppressed in Alma so that groups of items can be suppressed from public view.  Also, items can be given a particular processing status which can also be suppressed from public view.

    Item Files

    Item Record
    Expected Field Name Repeatable Notes
    File: INVE_Inventari (INVE):  Inventory.  This is the main item file
    Id   links to RELFASESE and INVDC files
    IdTitolo(TI_Id)   links to bibliographic record
    IdBiblioteca(BIB_Id)   use in column A in Alma Location Map, Alma Migration Form
    CdSerieInv(SERINV_Serie)   When SERINV_Serie = abc and NrInventario = 123, barcode is abc000000123 (add zeroes to make 9 digits for NrInventario)
    NrInventario   When SERINV_Serie = abc and NrInventario = 123, barcode is abc000000123 (add zeroes to make 9 digits for NrInventario)
    Appendice    SERINV_Serie + NrInventario + Appendice = INVENTORY_NUMBER
    IdCollocazione(COLL_Id)   links to COLL file
    IdConsistenza(CONS_Id)   links to CONS file
    Sequenza   Item Call Number (852 $h), only used for monographs (non-serials)
    CdTipoMateInve(TAB_Cd_MATI)   use in Material Type map, Alma Migration Form
    CdTipoProvenienza(TAB_Cd_TPRV)   provenance code
    CdStatoCopia(TAB_Cd_SCOP)   use in Item Base Status map, Alma Migration Form
    DataIngresso   Inventory date
    CostoAcquisto   inventory price
    ValoreInventariale   replacement price
    Nota   Item description for bound volumes
    CdTipoCircolazione(TAB_Cd_TCIR)   use in Item Type map
    IdOrdine(ORDI_Id)   order number
    File: COLL_collocazioni (COLL):  Locations, including the call number
    Id   INVE links here using this number
    CdSezione(SEZI_Cd)   use in column B (location) in Alma Location Map; also item call number
    Collocazione   item call number
    Specificazione   item call number
    Descrizione   description; also Non_public_note_1 if serial
    File: INVDC_dati_copia_inventari.csv (INVDC): item notes
    IdInventario(INVE_Id)   links to INVE file
    TipoDatoCopia(TAB_Cd_DCIN)   type of note: we need a map of these, see below
    DatoCopia   note
    File: RELFASESE_Legami_Fascicolo_Annata.csv: Relationship between issues and items, but the primary information here is item notes
    Fascicolo(FAS_Id)   links to FAS file
    Inventario(INVE_Id)   links to INVE file
    StatoCopia(TABFTSC_Id)   Item Base Status map; also public note (see below)
    StatoFascicolo(TABFTSF_Id)   public note (see below)
    File: FAS_Fascicoli.csv (FAS): Serial Issues.  Only migrate an issue if it is not present in the RELFASVOL file.
    Id   links to RELFASESE file
    Etichetta   item description for issues
    DataPubblicazione   Issue date
    FascicoloPagine   Pages
    File: RELFASVOL_Legami_fascicoli_volumi.csv: Relationship between issues and bound volumes
    Fascicolo(FAS_Id)   If the issue is present in this file, then it is bound and therefore covered by items.  Issues not in this file are migrated as issue/items.
    File: RELPOSINVE_legami_possessori_inventario.csv: relationship between inventory and possessor (owner)
    IdInventario(INVE_Id)   links to INVE file
    IdPossessore(POS_Id)   links to POS file
    File: POS_Possessori.csv: Possessor (Owner)
    Id   statistics note
    Descrizione   public note
     

    Item Notes

    Any additional fields not listed above may be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris. If you use other field names or have fields that you want to include in the migration but are not expected by Ex Libris, you can rearrange, add, or subtract fields on the right, as necessary. If you want to include multiple local fields in the same Alma note, make as many copies of the line in the spreadsheet as needed for all note name/local field combinations.
    When specifying the field to put into a note, be sure to indicate the file name.  For example, say INVE.NotaInterna or POS.Descrizione
     
    Note Name Default Local Field
    PUBLIC_NOTE Shows to the public
    FULFILMENT_NOTE Pops up at circulation activity
    NON_PUBLIC_NOTE_1 Internal notes
    NON_PUBLIC_NOTE_2  
    NON_PUBLIC_NOTE_3  
    STAT_NOTE_1 Statistical notes
    STAT_NOTE_2  
    STAT_NOTE_3  

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

    Note Type Mapping (TipoDataCopia)

    The file INVDC contains item notes, with a coded note.  Use this table to indicate how to place each note type into an Alma field 

    Dato Copia Note Type Description Alma Note Field
    CP Previous location

    For this column, select the Alma field where you you want to place the note.  The options are: 

    PUBLIC_NOTE
    FULFILMENT_NOTE
    NON_PUBLIC_NOTE_1
    NON_PUBLIC_NOTE_2
    NON_PUBLIC_NOTE_3
    STAT_NOTE_1
    STAT_NOTE_2
    STAT_NOTE_3
    STAT_NOTE_3

    CV Conservation status
    DC Notes and decorations
    LE Binding
    PR Proposal for restoration
    Item Notes Mapping tab

    For Sebina, there are item fields which represent notes but are stored as codes in the database.  These codes must be translated to text in order to be shown properly in Alma.

    Edit the 'Item Notes' tab so that the codes are properly translated to text.

    The fields which require note translation are: 

    RELFASESE.StatoFascicolo(TABFTSF_Id)
    RELFASESE.StatoCopia(TABFTSC_Id)
    FAS.TipoFascicolo(TABFTFA_Id)

    Finally, indicate where to put each note in the "Item Notes" section of the Items tab. For example, you may put  RELFASESE.StatoFascicolo(TABFTSF_Id) in a PUBLIC_NOTE, and FAS.TipoFascicolo(TABFTFA_Id) into NON_PUBLIC_NOTE_1. 

    E-Resources Indication (P2E)

    Provide a list of bibliographic system numbers that represent electronic resources and an indication if these electronic resources are portfolios, packages, or database resources. Prepare the list as a comma separated text file containing lines that represent each e-resource. Structure each line as follows:
    <bibnumber>,<resource type>
    For example:
    000000001,Portfolio
    000000003,DB
    Note that the words portfolio and db are not case-sensitive, therefore both portfolio and Portfolio are acceptable.

    Customer Input - Inventory 

    The following questions and tabs are in the Migration Form, and relate to Inventory.

    Questionnaire Tab 

    Institution Code, Customer Code, Institution Name, Customer Name, Time Zone 

    Codes: INST_CODE, CUST_CODE – these are filled in by Ex Libris

    INST_NAME and CUST_NAME: fill these fields in with your institution’s name and your customer name (this is only different from the institution name if you are part of a consortium). These are mandatory and must be filled in.

    Default: N/A

    Time Zone: Select your time zone from the drop-down list. If your time zone is not listed, contact your Ex Libris project manager.

    MARC Organizational Code 

    Code: MARC_OC

    Default: None; this is not mandatory

    Options: Enter your MARC Organizational code, which will be used to construct the former system number in Alma. Only one code is allowed.

    Further Information: The migration moves the value in the exported record’s former system number field (bibliographic system number) to the 035 $a field:

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

    <(moc)> is the MARC Organization code specified here. <customer code> is the customer code specified in the CUSTOMER_CODE question above.

    For example: (AbC)u12345-01abc_inst

    Usually the former system number can be in the 001 field of the bibliographic record. Customers should specify where the former system number is in the Bibs & P2E tab of the Sebina Field Mapping form.

    List Prefix for bibs from SFX or other management system 

    Code: SFX_PREFIX

    Default: ‘(SFX)’

    Options: String. If not indicating a link resolver management system, leave blank.  Multiple strings are allowed, use a semicolon to separate: (SFX);WaSeSS;EBC

    Further Information: If your catalog contains records imported from SFX or another electronic resources management system and you are also migrating bibliographic records directly from SFX or the other management system, this may result in duplicate bibliographic records in Alma. You can enter a prefix here so that the migration programs can identify these bibs and not migrate them to Alma to avoid creating duplicate SFX records in Alma. The migration programs do not make any attempt to physically merge the two records into one.

    The default response to this question is ’(SFX)’, but you can enter any prefix that represents bibs that you want to exclude from loading into Alma. The migration programs search for the string in the 035 $a field of the MARC record. If you do not want to exclude any such records, leave this field blank.

    If the migration programs identify bib records containing the prefix in the 035 $a and the records in your incoming records are connected to a purchase order line and/or physical items, these bib records are still migrated so that the purchase order and/or items can be migrated, but they are automatically suppressed in Alma to avoid end-user discovery duplication.

    Do you use internal system numbers in Linked Entry fields? 

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

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

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

    Code: LINKED_ENTRY_W

    Default: No

    Options: If you answered Yes to this question, the internal system numbers in the subfield $w or $1001 of the specified tags are converted from the former system number to the Alma system number.

    Internal record designation for Linked Entry fields $w 

    Code: LINKED_ENTRY_PREFIX

    Default: Blank

    Options: If you answered Yes to the previous question and the internal system numbers have a prefix, enter the value to be matched to identify the local system number. If the system numbers in $w or $1001 do not have a prefix, or if you answered No to the previous question, leave this question blank.

    Further information on LINKED_ENTRY_W and LINKED_ENTRY_PREFIX: When bibliographic records are related to each other, such as a journal title that is superseded by a second journal title, your previous ILS may store the information in bibliographic fields 76x-78x, 80x, 81x, and 83x $w for MARC, and 423, 461, 462, 463, 464 for Unicode.  If the number in the $w or $1001 of the linking tags is the internal legacy ILS system number, these numbers must be changed to the Alma representation of the system number. If your library does not use the internal system number to link and instead relies on more general identifiers such as the ISBN, ISSN, or shared cataloging DB (OCLC or DLC), these numbers are not modified.

    In Alma, the system numbers in the linking field are used to link two related bibliographic records together using the related records process. Related records can be found by clicking the More Info link on the Alma Search Results page.  For more information on configuring related records, see Configuring Related Records for Physical Inventory.

    Indicate which 852 subfields to use to determine unique holding records 

    Code: 852_SUBFIELDS_FOR_HOL

    Default: bc (library and location only, not call number)

    Options: To group all items on a single bibliographic record by library and location only, select bc here. If you have many items in the same bibliographic record in the same llibrary/ocation but different call numbers WITHIN that library/location and you want each of them to have their own distinct holding record, specify additional call number subfields.  Acceptable subfields: bchijklmp.

    The library and location codes are matched after the Alma Location Mapping has been performed, meaning the match is done on the Alma version of the library/location codes.

    Further Information: See Determining Groups of Holding Records and Changing the Holding Record Grouping.

    Limit exported records by location 

    Code: LIMIT_BY_LOCATIONS

    Default: No

    Options: If your export contains all of the data from a shared database, and you wish to only migrate a part of that export to Alma, then the migration programs can filter the data according to locations listed on the Location Tab. In this case, the ALMAME_VALUE_NOT_FOUND line on the location tab is not used. Inventory is filtered by locations on the Location Tab, and Fulfillment is filtered based on campus codes in the Campus Code Tab. Use this option only if agreed upon with your Ex Libris project manager.

    Bib Key Prefix 

    Code: BIB_KEY_PREFIX

    Default: empty

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

    See also: MERGE_PATRON_PREFIX in Fulfillment

    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 a Network Zone (in a consortium), 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 an NZ, then this question is likely not useful.  Default: 035

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

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

    001 12345

    003 OCoLC

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

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

    Add institution suffix to Bib ID 

    Code: BIBID_INST_SUFFIX

    Default: No

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

    Yes = include suffix

    No = do not include suffix

    Use subfield indicators in item call number (AltCallNo)

    Code: ITEM_CALLNO_SUBFIELD

    Default: Yes

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


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

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

    Add $9 LOCAL to specified tags

    Code: NZ_LOCAL_TAGS

    Default: empty

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

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

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

    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: !@#$%^&*()+=/?><.,\|]}[{`~ and the space character.

    The Alma Library Code may not be the same as the Alma Customer Code nor the Alma Institution Code . 

    Alma Library name: Maximum 255 characters. This is visible to the public.

    Address lines: Alma allows you to specify address, phone, and e-mail information about each library. It is mandatory for a library to have a shipping/billing address in order to place orders in Alma. The migration process sets the designated address provided with all possible types in Alma (shipping, billing, claiming, etc.). At least one address line is mandatory.

    Email: An email address is mandatory. The migration process sets the email address provided with all possible email address types in Alma.

    Phone: The phone number must contain dashes (nnn-nnn-nnnn). A phone number with no dashes is not accepted by the migration program. Not mandatory.

    Default language: Indicate the language of patrons and/or staff members if it differs for each library. Use two-letter codes as defined in ISO 639-1. Consult the codes at https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes

    Further Explanation: The Alma library is the higher level of location. The Location or sometimes Physical Location is the lower level of location. Your ILS may or may not have an existing higher level of location. If you have a higher level of location already, you may likely simply copy those libraries to this tab here. If you only have one level of location, you can list new libraries here and then map existing locations to a library/location combination using the Alma Location tab.

    Use the Alma Libraries tab in the Sebina Migration Form to indicate your list of Alma libraries. The actual mapping from the legacy library to the Alma library is done in conjunction with the Physical Location in the Alma Location tab.

    If you use an error library (for example “EMPTY”) in the ALMAME_VALUE_NOT_FOUND line of the Alma Location Map tab, be sure to list that library here on the Library Tab. It is not mandatory to use an error library; you may also choose to use one of your regular libraries plus a lower-level error location for the items that encounter errors during the mapping process.

    Alma Location Tab 

    Use this tab to map your legacy libraries and locations to libraries and locations in Alma. Filling in this tab is mandatory.

    One level of location or two levels of location

    If your legacy ILS has only one level of location, put the values for that location into the ‘First Level Location’ column (Column A), and leave Column B blank.  In this case, the field mapping form, item tab, has that single level of location placed in the LIBRARY field, and LOCATION is blank.

     

    If your legacy ILS has two levels of location, use both Column A and Column B.  In this case, the field mapping form, item tab, has both LIBRARY and LOCATION filled in.

    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.

    Library: First level of location - Value from the Library field in the item extract or the 852$b in the MARC holdings extract from your legacy ILS. The ALMAME_VAL_NOT_FOUND line is required to catch any location codes you may have missed. Incoming locations cannot have special characters or spaces. Allowed: - and _ (hyphen and underscore). Not allowed: !@#$%^&*()+=/?><.,\|]}[{`~ or the space character.

    Location: Second level of location - Value from the location field in the item extract or the 852 $c in the MARC holdings extract from your previous ILS. Incoming locations cannot have special characters or spaces. Allowed: - and _ (hyphen and underscore). Not allowed: !@#$%^&*()+=/?><.,\|]}[{`~ or the space character.

    Alma Library Code: The library that contains this library/location combination in Alma. You can use the same library codes that you used in your legacy ILS, but it is not required. This code must be present on the Alma Library Tab, column A. The match is case-sensitive.

    Alma Location Code: The new location code for this library/location combination in Alma. It can be a maximum of 10 characters. You can use the same location codes in Alma that you used in your legacy ILS, but this is not required. You may also use this form to collapse locations if desired, for example refa and refb both map to ref in Alma. Mixed case is valid, but not recommended. Do not use special characters or spaces. Allowed: - and _ (hyphen and underscore). Not allowed: !@#$%^&*()+=/?><.,\|]}[{`~ or the space character.

    Call Number Type: List the call number type for any newly created holdings records, based on the values for the 852 first indicators. (http://www.loc.gov/marc/holdings/hd852.html). If we cannot determine the call number type from the item or holding record itself, we use this as a default for all items in the location.

    Alma Location Name: A description for this location as seen/used by library staff members. The same location name cannot be used for different locations in the same library, but the same location name can be used for different locations in different libraries. See the examples in the Further Information section below for what is acceptable and not acceptable. Maximum 255 characters.

    Alma External Location Name: A description for this location as seen/used by the public. The same name can be used for as many different locations as desired. For example, the location names may be Archives A and Archives B, but the external location names can both be Archives. Maximum 255 characters.

    Electronic Location? (Yes or No): Used by the P2E migration process to determine if a holding/item/order should be converted to electronic. See the Physical to Electronic (P2E) Processing section for more information.

    Suppress from Externalization? (Yes or No): Indicate if the location should be suppressed from being visible to the public. The items are not marked as suppressed, but no holdings or items with this location code are exported to Primo.

    Further Information: Do not leave the Alma location and library code fields blank. If you want to stop using a location code after migration, map the incoming code to an easily identifiable code such as XXX or unused just in case any stray items are still in your previous ILS database. The ALMAME_VALUE_NOT_FOUND line must be included at the top of the list of locations, in case any location codes were overlooked when completing this map. For example, you may think that you do not have any items left in a certain collection, so you leave it off the location map. However, there may be one or two items left or a stray holding record, etc.

    By default, the location code for the ALMAME_VALUE_NOT_FOUND line is UNASSIGNED, which is the default catch-all in Alma in production mode. Ex Libris recommends that you select your primary/largest library as the library code for the line, for example MAIN as in the example line below. In this case, the items inherit the configurations for the MAIN library.

     
    Incoming Library code Incoming Location Code Alma Library Code Alma Location Code Alma Location Desc Alma External Loc Desc Suppress from Externalization

    ALMAME_

    VALUE_NOT

    _FOUND

    ALMAME_VALUE_NOT_FOUND

    MAIN

    UNASSIGNED

    Problem location from Migration

    Problem: See Library Staff

    Yes

    Post-migration, search for items in the UNASSIGNED location and correct the records appropriately.

    Alma Location Name and Alma External Location Name 

    The Alma Location Name column contains the names of the location codes that are displayed in the staff interface. The names cannot be repeated in the Location Name column when the location codes both belong to the same library, but you can use the same name for two different locations, if these locations belong to different libraries. The Alma External Location Name column contains the names of the location codes that are displayed to library patrons. These names can be repeated within the column without regard for libraries. For example:

    The following is acceptable:

     
    Alma 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:

     
    Alma 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 your legacy ILS 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 incoming code to an easily identifiable code such as XXX if any stray items are still in your library database.

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

     
    Incoming 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 three values in bold italic above (ReserveElec as the External Location name, and Yes for Suppress from Externalization and Electronic location) are not used in Alma. Since the locations are being collapsed, the first line for the RESERVES Alma location is used, and all subsequent lines below it use the values from the first line.

    Item Type Tab 

    Use this tab to migrate the incoming INVE.CdTipoCircolazione(TAB_Cd_TCIR) to the Alma Item Policy. This tab is optional. The item type in Alma is not required, so if you leave this tab blank, no item policies in Alma are created.

    Incoming Item Type: The value in the CdTipoCircolazione(TAB_Cd_TCIR) field from Sebina. The item type is usually used to differentiate between items when determining how items circulate.

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

    Alma itemPolicy: The Alma value for the item type. This sheet can be used to collapse item types if desired.

    Alma itemPolicy Description: This description is loaded into Alma as the display text for the item types. These values can be changed after migration. Maximum 255 characters.

    You can optionally include an ALMAME_VAL_NOT_FOUND line at the top of the map. If this line is included, any value not found or any blank value is assigned the value in the ALMAME_VAL_NOT_FOUND line. If the ALMAME_VAL_NOT_FOUND line is not included, any value not found, including blanks, is left as blank in Alma.

    Item Base Status Tab 

    Use this tab to map an incoming item status to an item status in Alma. Item statuses are typically assigned to an item on a temporary basis, such as MISSING, MENDING, or BINDERY.

    Incoming Item Status: List all of the values from the two fields INVE.CdStatoCopia(TAB_Cd_SCOP) or RELFASESE.StatoFascicolo(TABFTSF_Id), from Sebina.

    Description: A short description of the incoming item status, if desired, for note purposes while filling out this form. This column is not used for migration.

    Base Status: In Alma, the base status indicates whether or not the item is on the shelf. Indicate whether or not an item with this status is on the shelf. For example, NewBooks is on the shelf (1), but Withdrawn is not (0).

    Further Information: Alma has a process type that indicates the status of an item depending on the Alma workflow (item is on loan, item is on shelf for request pickup, etc.), but the process type is dependent on the corresponding Alma workflow. For migration, all item statuses that are indicated as not on the shelf (0) from this mapping tab are given the process type of TECHNICAL in Alma. Item statuses which are indicated as on the shelf (1) are NOT given the process type of TECHNICAL. The TECHNICAL process status will indicate to the public that the item is not on shelf/not available. Further, the item status description field is written to internal note 1 for all items where there was a status, regardless of the shelf/not on shelf designation.

    Post migration, you may search for items with a particular value in Internal Note 1, make a list of them, and use Alma item tools to work with the items. They may be given a new Alma status, or moved to a different department, or the list can be used as a configurable criterion for suppressing items from display in the GetIt services screens in discovery systems. See Appendix A – Post-Migration Process Statuses for more information.

    Incoming item statuses which indicate no status

    Include in column A any status that may indicate no status, for example Available, but leave column B blank and say that the item is on shelf (1). This migrates the item to Alma with no status at all, which is how Alma indicates that an item has no status. Empty status = no status. If any status is in your data but is NOT included in column A, basically meaning that it was not found, it is given a note of Unknown status.

    Item Material Tab 

    Use this tab to migrate any incoming Material type to the Alma Material type. The material type is not mandatory; if no material type is indicated for an item, one will be generated based on information from the bib fixed fields.

    Incoming Material Type: The value in the CdTipoMateInve(TAB_Cd_MATI) field from Sebina.

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

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

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

    Further Explanation – Inventory 

    Bibliographic Records 

    Bibliographic records are migrated as is and 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) is marked for OCLC publish, if relevant.
    • The LDR position 9 (character coding scheme) is set to 'a', indicating Unicode.

    Determining Groups of Holding Records 

    The permanent location and call number in Alma is only stored in the holding record. All items attached to the holding record have the same permanent location and call number. On migration, the call numbers for any new holding record created are generated from the first item found in the group of equivalent items. By default, a group of equivalent items is determined by the location of each item attached to the same bibliographic record. For example, if a bibliographic record has five items:

    • Item 1, 2 in Location A
    • Item 3, 4 in Location B
    • Item 5 in Location C

    The migration program generates three different MARC holdings records, one for each location A, B, or C. The items for each location are then attached to the newly created holding record. If there are any call numbers that differ from the holding record’s call number, the differing call number is stored in the item’s Item Call Number field.

    Changing the Holding Record Grouping 

    You may decide which 852 subfields are used to determine what makes items belong to the same group. The 852 subfields as mapped, described in the Library, Location and Call Number sections above, are: $b Library $c Location $h Call Number. By default, the migration programs compare $b and $c, but you may decide to change this based on items in your collection.

    When the holding record group is based only on $b (library) and $c (location), some item call number information is not reflected in the holdings record call number if the call numbers differ from each other in the same library/location. However, the differing call number is stored in the item’s Item Call Number field, so the call number is not permanently lost.

    For example, if there are four items on the same bibliographic record with the following call numbers, all in location main:

    item 1 $b main $c stacks $h PN 567 .M4

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

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

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

    When only $b and $c are used to determine a holding record group, two holding records for the above items are created: Holding record $b main $c stacks $h PN 567 $i .M4

    item 1

    item 2 (with PN 567 .M457 stored in ItemCallNo)

    item 3 (with PN 567 .M457 stored in ItemCallNo)

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

    item 4

    When the holding record group is based on more subfields, for example $b $c $h, three holding records are created: Holding record $b main $c stacks $h PN 567 .M4

    item 1

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

    item 2

    item 3

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

    item 4

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

    Attaching Items to Existing Holding Records 

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

    For example, consider the following incoming records:

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

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

    item 1: PER,MFORM PN 567 .M4

    item 2: PER,MFORM PN 567 .M4 2010

    item 3: PER,MFORM PN 567 .M4 2011

    item 4: PER,CURRENT PN 567 .M457 2012

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

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

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

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

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

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

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

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

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

    item 1

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

    item 2

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

    item 3

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

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

    item 4

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

    Boundwiths 

    Items that are shared by multiple bibliographic records are called boundwith items.  Examples of this are small items bound together in a single volume, or journal issues which changed names in the middle of a bound volume.

    Ex Libris does not expect to receive Boundwith records from Sebina.

    Item Barcodes 

    While many legacy ILS systems allow item barcodes to be duplicated, Alma does not. The item barcode must be unique in Alma, although it may be left blank (and many of them can be left blank).

    During Sebina migration, the barcode is constructed the following way: 

    When SERINV_Serie = abc and NrInventario = 123, barcode is abc000000123. We add zeroes to make 9 digits for NrInventario, so if SerINV = abc and NrInventario = 1234, then the barcode is abc000001234.

    Then, the item barcode is migrated according to the following rules:

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

    Material Type from Bib Fixed Fields 

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

    All customers may provide a material type in a subfield of the item record, and use the Material Type tab to map them to valid Alma material types (see the explanation for Material Type tab, above). The material type you indicate determines the item's material type.

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

    Fulfillment

    This section describes the files expected and a description of individual fields, if necessary.

    Patrons

    Ex Libris expects patron records in CSV delimited format. Patron records without a record key identifier are skipped, since this is the minimum required patron information. The record key identifier is used to link the patron to other records such as loans and fines.
    The following fields are expected. Indicate the local field names for the expected fields in the Patrons tab of the Sebina Field Mapping form.
    Patrons
    Field Name Notes
    FILE: UTE_Utenti: Users
    Nome LAST/FIRST MIDDLE
    IdAnagrafica This may also be used as an identifier, below
    Id this may also be used as an identifier, below
    TipoPersonaFisicoGiuridico gender
    Sesso gender
    DataNascita birth date
    Lingua language
    DataInserimento create date
    DataModifica modify date
    UserMod(OPER_IdUser) modify user
    UserIns(OPER_IdUser) create user
    FILE: BIBUTE_Associazioni_Utenti_Biblioteche.csv: User library
    TipoUtente use in User Group map
    File: ABIPRES_Abilitazioni_Prestito_Utenti_Biblioteca.csv: Blocks
    Biblioteca(BIB_Id) put in block note
    FlagAbilitazione if N then make block
    Note block note
    File: IDENT_CodiciDocumenti_Biblioteche: User Identifiers
    IdAnagrafica links to UTE file
    TipoDocumento(TABTDI_Id) type of identifier.  If you want to use an identifier from this file in the User Identifier section, list a value from this field.  For example: TipoDocumento 2
    NumDocumento identifier

    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. Enter fields from your institution’s patron extract that include identifiers. 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 Sebina Migration Form.
    All patron primary identifiers MUST be unique across all users, as required by Alma. If they are not, the migration program disambiguates them. by putting a hyphen and a number after the duplicate value, like -1, -2, etc.
    User Identifiers
    Alma Identifier Type Migrated value
    UNIV_ID

    List the identifier you want to place in the Alma field.

    Choice here include:

    UTE.IdAnagrafica

    UTE.Id

    IDENT.TipoDocumento value:  If you list the TipoDocumento value, then the NumDocumento (identifier) for that value will be placed here.

    BAR
    ADDL_ID_1
    ADDL_ID_2
    ADDL_ID_3
    ADDL_ID_4

    User Address, Phone, and Email

    There may be a number of addresses, phone numbers, and email addresses in the patron record. You may decide which addresses, phone numbers, or email addresses are the preferred ones in Alma. If the preferred entry is empty, the secondary one is preferred.
    Additionally, select a type for each address, phone, or email. All can be selected so that the address, phone, or email can be used as any type.
    User Preferred Address
    Address Field Instructions
    File: IND_Indirizzi_Biblioteche_Utenti.csv: User Addresses
    IdAnagrafica links to user file
    TipoRecapito(TABTRC_Id)

    use address type map in Field Mapping to specify what type of address this is, for example home or office.

    FlagIndirizzoPrincipale primary address flag
    Via2  
    Via  
    Cap  
    Citta  
    Provincia(TABPVC_Id) use Province Map tab in Sebina Field Mapping form
    Paese(TABPSE_Id) use Country Map tab in Sebina Field Mapping form
    File: RCP_Recapiti_Biblioteche_Utenti.csv (phone and email)
    IdAnagrafica links to user file
    TipoRecapito(TABTRC_Id) use email/phone type map in Field Mapping for to specify what type of phone or email this is, for example home or office.
    DescrizioneRecapito  
    FlagIndirizzoPrincipale primary email/phone
    Province Map and Country Map

    The Province Map and Country Map in the Sebina Field Mapping form translate codes to text for Province and Country.   These maps are used for Patron addresses and also for Vendor addresses.  The maps are pre-filled in based on previous Sebina migrations.  Please verify that the numbers map to the correct provinces and countries for your Sebina instance.

    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.
    When you specify a local field name, be sure to indicate the file.  For example, IND.Paese(TABPSE_Id) or BIBUTE.TipoProvenienza(TABTPV_id)
    User Statistical Categories
    User Statistical Category Local Field Name Field Label
    USER_STAT_CATEGORY   SCHOOL:
    USER_STAT_CATEGORY   DEPT:
    USER_STAT_CATEGORY    
    Up to 10 incoming fields can be mapped. To map the values, use the UserStatCategories map in the Sebina 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.

    Notes

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


    Loans/Circ Transactions

    Extract only current circulation transactions.
    Provide the loan files in comma delimited format. The following fields are expected. Use the Loans tab of the Sebina Field Mapping form to indicate local field names for the expected fields.
    File: MOV_movimenti.csv
    Active loan transactions are migrated from Sebina to Alma.
    Completed (historical) loan transactions are counted per item and placed in the 'Number of Loans' field of the item record. 
    The most recent 'Date Returned' date is retained an placed in the 'Date Last Returned' field of the item record.
    Loans/Circ Transactions
    Field Name Notes
    TipoMovimento(TAB_Cd_TMOV) Use Loan type map in Field Mapping Form
    BibliotecaMovimento(BIB_Id) use in Migration form, Alma Location map, column A
    Utente(UTE_Id) links to user file
    IdOggetto item id
    TipoOggettoMovimento Use Loan Item Type map in Field Mapping Form
    DataInizioMovimento check out date
    DataStimeFineMovimento due date
    DataFineMovimento return date: if this has a date, then we do not migrate this loan
    NumProroghe number of renewals:  we check if this > 0 only.  If you want to keep the actual number of renewals, also put this field in a note
    Loan Type map and Loan Item Type map

    The MOV_Moviemento.csv file contains very many item movements.  Not all of them represent loans, or at least not all of them need to be transferred to Alma.  Use the Loan Type Map and the Loan Item Type map to specify which types of records to move to Alma. 

    The two choices in these maps are 'Migrate' and 'Do Not Migrate'.  When you choose 'Do Not MIgrate', then the loan record for this particular type or item type will not be transferred to Alma.

    Loan Notes
    Any additional fields not listed above may be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris. If you use other field names or have fields that you want to include in the migration but are not expected by Ex Libris, you can rearrange, add, or subtract fields on the right, as necessary. If you want to include multiple local fields in the same Alma note, make as many copies of the line in the spreadsheet as needed for all note name/local field combinations.
     
    Note Name Default Local Field
    NON_PUBLIC_NOTE  

    Customer Input - Fulfillment

    The following questions and mapping tables are in the Migration form and relate to Fulfillment.

    Questionnaire Tab

    Complete the following in the Questionnaire tab:

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

    Code: PATRON_LANG

    Default: en

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

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

    Code: PATRON_PRIMARYID

    Default: UNIV ID

    Options: Using the Sebina Field Mapping Form, map the identifiers exported from Sebina to the following list: UNIV ID, BARCODE, ADDL ID 1, ADDL ID 2, ADDL ID 3. Then, select the identifier to be used as primary for all patrons.

    See also: Identification Numbers, Internal? Question on the User Group tab

    How should we handle duplicate identifiers in the same patron? 

    Code: DUP_ID_SAME_PATRON

    Default: DISCARD

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

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

    Default: DISCARD

    Currency for patron fines 

    Code: CURRENCY

    Default: USD

    Options: Use the three-letter code (for example, USD, EUR, GBP) for the currency used for patron fines. For a list of valid codes, consult http://en.wikipedia.org/wiki/ISO_4217.

    Use a map for the 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: If the requests file does not contain a destination library/location, the library you enter for this question is used as the default for where patrons will usually pick up requests from the hold shelf.

    Merge Patron Prefix 

    Code: MERGE_PATRON_PREFIX

    Default: No

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

    See also: BIB_KEY_PREFIX in Inventory

    User Group Tab 

    The user group is used to distinguish groups of patrons from each other in determining different levels of circulation policies. Typical user groups are faculty, staff, and undergrad.

    If patrons are being migrated, then this mapping table is mandatory.

    Incoming patron group: The incoming values for the patron group, in the Sebina BIBUTE.TipoUtente.

    Description: A description of the patron group code, for informational purposes only. This column is not used in the mapping to Alma user group.

    Alma User Group Code: The mapped group code in Alma. You can use the same codes that you used in your previous system, or you can use different codes. You can also collapse groups if desired, for example, having Freshman and Sophomore from the legacy ILS both map to Undergrad in Alma. Do not use special characters, for example, slashes (/) or spaces in the code.

    Alma User Group Description: The description of the Alma User Group. This description is loaded into the Alma code table as the description displayed in the user interface. This description can be changed easily after migration.

    Internal? Y or N: Alma categorizes users as either external or internal. External patrons are managed by an external system, such as through a regular load from the bursar’s office/campus student information system. Internal patrons are created and managed internally. Examples of internal patrons are community borrowers or alumni. If you select Yes, all of the patrons in the Alma userGroup are categorized as internal. If you select No, all of the patrons in the Alma userGroup are categorized as external.

    Notes/Comments: Add any notes or comments for the user groups. This column is not used during migration.

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

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

    See also the section on internal/external patrons.

    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 Sebina to Alma Field Mapping form which fields from your legacy ILS are migrated to statistical categories in Alma. You can include a label before each category to distinguish between categories in different fields. For example, you can have LAW in USER_CATEGORY1 and also LAW in USER_CATEGORY2. If desired, use a prefix to distinguish between the two, for example, CAT1: LAW and CAT2: LAW. 

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

    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.

    Further Explanation – Fulfillment 

    Internal/External Patrons 

    Alma categorizes users as either external or internal. External patrons are managed by an external system, such as through a regular load from the bursar’s office/campus student information system. Internal patrons are created and managed internally. Examples of internal patrons are community borrowers or alumni.

    Identify patrons as internal or external by user group on the Sebina Migration Form, User Group tab, Internal? Yes or No column. For example: all faculty are EXTERNAL and all community borrowers are INTERNAL.

    Identification Numbers 

    The migration program allows for six different types of user identifiers: University ID, Barcode, and Additional ID 1, 2, 3, and 4. Select one of these identifier types as the primary ID – the primary unique identifier for the patron.  You may map multiple identifiers from your previous ILS.  You may also consider mapping email address, a common matchpoint in authentication systems, to an additional ID field.

    When selecting the primary ID, the first identifier found in the field is used as the primary ID, and all subsequent identifiers are kept in the userIdentifier section. The primary ID must be unique, so if there are duplicates, the first unique ID found is migrated as is, and the IDs for the second and subsequent patrons with the same ID are given a suffix of -1, -2, etc. 

     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.

    Identifiers may not be duplicated, even within the same patron record. See the questionnaire question DUP_ID_SAME_PATRON for options.

    Select BARCODE, UNIV_ID or ADDL ID 1, 2, 3, or 4 as the primary ID type for internal or external patrons in the Questionnaire tab of the Sebina Migration Form.

    Acquisitions

    When Acquisitions is included in the migration – meaning that the customer has contracted for migration of acquisitions data elements, a few questions are necessary. These questions are listed under Customer Input – Acquisitions Data Migration.

    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.

    Vendors

    Provide the vendor file in comma delimited format. The following fields are expected.

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

     

    Field Name Notes
    Cd  
    RagioneSociale  
    Url  
    Via  
    Via2  
    Cap  
    Citta  
    Provincia  
    CodicePaese(TABPSE_cd) use Country Map tab (shared with Patrons)
    Telefono  
    Fax  
    Email  
    EmailReferenteAcquisti  
    EmailReferenteAbbonamenti  
    PartitaIva  
    Lingua  

    Vendor Notes 

    Any additional fields not listed above may be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. 

    Note Name Default Local Field
    VENDOR_NOTE  
    VENDOR_NOTE  

    Funds

    Two files are used to generate funds and related fund transactions from Sebina.

    Field Name Notes
    File: IMPE_Voci_di_spesa.csv: Expenditures.  Links between fund and order/invoice.
    Id links to orders and invoices
    IdCapitoli(CAPI_Id) links to CAPI file
    File: CAPI_Capitoli.csv: Funds and initial allocation
    Id links to IMPE file
    IdBiblioteca(BIB_Id)  
    Anno  
    Cd  
    Descrizione  
    Stanziamento Initial allocation.  Effective balance is calculated by Alma after Orders and Invoices are loaded.
    Nota  

    Orders

    Alma migration generates a purchase order and related order lines from the files BUONO_Buoni and ORDI_Ordini.    The status of the order is determined from the file COMU_Iter_stati_ordine.  Order lines are linked to inventory via a link to the field in the item INVE.ORDI_id.

     

    Note Name Default Local Field
    File: BUONO_Buoni.csv: Order header
    Id  
    IdFornitore(FRN_Id) links to vendor
    IdBiblioteca(BIB_Id)  
    Numero  
    Data  
    Nota  
    PO_ERP_NUMBER  
    File: ORDI_Ordini.csv: Order lines
    NumOrdine  
    OrdinePermanente  
    Buono(BUONO_Id)  
    Titolo(TI_Id)  
    VoceDiSpesa(IMPE_Id)  
    DataOrdine  
    DataPrevistaArrivo  
    TipoOrdine(TABTPORDI_Cd) use in PO Line Type map
    TipoAcquisizione(TAB_Cd_QTOR) use in PO Acq Method map
    StatoAmministrativo  
    Quantita  
    PrezzoIndicativo  
    PrezzoEffettivo  
    Valuta(TABAVAL_valuta)  
    PrezzoEffettivoInValuta  
    CambioImportoEffettivo  
    PercentualeSconto  
    ImportoIva  
    Utente links to User file
    NoteInterne  
    NotePerFornitore  
    Urgenza(TAB_Cd_QUOR) When 60, then Rush = True.  Else False
    File: COMU_Iter_stati_ordine.csv: Order status
    Id  
    IdOrdini(ORDI_Id) links to order file
    StatoAmministrativoOrdine(TAB_Cd_QSOR) use in PO Entry Point map

    Any additional fields not listed above may be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. 

    Note Name Default Local Field
    POL_VEND_REF_NO This line cannot be duplicated; place only one local field name here.
    POL_ADDL_NO This line cannot be duplicated; place only one local field name here.
    POL_RECEIVING_NOTE This line cannot be duplicated; place only one local field name here.
    POL_NOTE_TO_VENDOR This line cannot be duplicated; place only one local field name here.
    PO_NOTE This line can be repeated as many times as necessary; multiple local fields can be placed in this note.
    POL_NOTE This line can be repeated as many times as necessary; multiple local fields can be placed in this note.

    Orders '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.  

    Invoices

    Note Name Default Local Field
    Invoice to Order: FATTOR_Legami_ordini_fatture.csv  
    IdOrdini(ORDI_Id)  
    IdFattura(FATT_Id)  
    Invoices: FATT_Fatture.csv  
    Id links to FATTOR file
    IdFornitore(FRN_Id) links to vendor file
    NumFattura  
    DataFattura  
    IdBiblioteca(BIB_Id)  
    StatoFattura(TAB_Cd_QSFA)

    use Invoice Entry Point map on Field Mapping form, Invoice tab. 

    The values from Stato Fattura are listed, and you can specify what the invoice status is for each value.

    Available invoice statuses: NEW, WAITING_PAYMENT,CLOSED,CANCELLED

    IdVoceDiSpesa(IMPE_Id)  
    ImportoFattura  
    ImportoSpeseAccessorie  
    ImportoSpeseCommissioni  
    Valuta(TABAVAL_valuta)  
    DataPagamento  
    NumProtocollo  
    DataProtocollo  

    Any additional fields not listed above may be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. 

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

    Default currency for Ledgers and Funds

    Code: ACQ_CURRENCY

    Default: USD

    Options: List the currency used for all of your funds. Orders can have other currencies and be translated to the default currency, but funds must have a single base currency.

    The currency should be a three-letter code, as listed in http://en.wikipedia.org/wiki/ISO_4217

    Fiscal Period Cycle Pattern

    Code: FISCAL_PERIOD

    Default: 01-07-1 (fiscal period starts on July 1 (01-07) and lasts for one year (-1).

    Options: To have functioning ledgers, fiscal periods are required. Specify your fiscal period as DD-MM-C (Day-Month-Cycle). For example, a one year fiscal period starting on January 1 is indicated by: 01-01-1. A one year fiscal period starting on July 1 is indicated by: 01-07-1.

    Alma currently supports one-year fiscal period cycles.

    Which year do you use to name the fiscal year?

    Code: FISCAL_PERIOD_NAME

    Default: second

    Options: Specify if the fiscal period is named with the first year or the second year.

    • second – if fiscal period runs July 1 2014 through June 30 2015, then the fiscal year is named 2015.
    • first – if fiscal period runs July 1 2014 through June 30 2015, then the fiscal year is named 2014.

    If your fiscal period runs from January 1 through December 31, this question is not necessary.

    Current Fiscal Year

    Code: CURRENT_FISCAL_PERIOD

    Default: determine by date of conversion

    Options: This question is important around the beginning/end of the fiscal period. 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.
    • Select a year from the dropdown box.

    For example if the date of conversion is June 15, 2017, and your fiscal year ends on June 30, 2017, then selecting ‘determine by date of conversion’ will place the active fiscal year as 2016-2017. If you wish to start fresh on July 1 with the new fiscal year, then select the year from the drop-down that corresponds to the 2017-2018 fiscal period.

    Accrual Accounting

    Code: ACCRUAL_ACC_FY

    Default: No – do not make an additional fiscal year

    Options: If your library uses accrual accounting, you can instruct Ex Libris to make an additional fiscal year. When an additional fiscal year is created, it will be after the current fiscal year. For example, if the current active fiscal year is 2016, then the additional year, also active, will be 2017. The options are the following:

    • No – do not make an additional fiscal year.
    • Yes-No Funds – make an additional fiscal year but leave it empty. The library will then need to create funds for this fiscal year after go-live.
    • Yes-duplicate funds – make an additional fiscal year and also fill it with funds that are the same codes as the funds in the current fiscal year. No allocations are made.

    Yes-duplicate funds can only be used if the customer has contracted for Acquisitions migration.

    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 Order Location field specifies the order location for orders in the previous system. The migration attempts to map the location field to the corresponding Alma Library. If you want to override this field and instead assign an order library to all orders migrated, fill in a value for the Central Order Library question. Otherwise, if you want to use the order location field to determine the order library, leave the Central Order Library question blank and fill in a value in the Default Order Library question. In this case, the migration attempts to determine a library based on the order location field and only when a library is not specified or a mapping is not found does it use the Default Order Library as a second choice.

    Default claiming period

    Code: ORDER_CLAIM

    Default: 90

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

    Physical to Electronic (P2E) Processing

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

    123475,portfolio

    12346,db

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

    During the P2E process, all resources must either be categorized as a portfolio or a database (DB).  It is not possible to generate packages during P2E processing, since packages require at least one portfolio.   A database is essentially a zero-title package.  Post migration, when you add portfolios to the db, you can change them to type 'package'.

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

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

    Customer Input - P2E

    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 Marc field code + subfield: 856u. Only one field/subfield is allowed.

    Recommendation: 856 u

    Default: If this is left empty, no tag is used.

    Which Holding or Bib field stores electronic link public note

    Code: P2E_NOTE

    Options: Provide a Marc field code + subfield: 856z. Only one field/subfield is allowed.

    Recommendation: 856 z

    Default: If this is left empty, no tag is used.

    Which Holding or Bib field stores electronic provider name information

    Code: P2E_PROVIDER

    Options: Provide a Marc field code + subfield: 856m. Only one field/subfield is allowed.

    Recommendation: 856 m

    Default: If this is left empty, no tag is used.

    For the questions on the Questionnaire tab, only one field/subfield is allowed per question.

    Alma Location Tab

    Electronic Location Column

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

    Further Explanation – P2E

    If you have multiple 856 links in a single bibliographic record identified as electronic, a different inventory link for that bibliographic record is created for each URL found in the record. In addition, if you have two item records with different electronic locations attached to the same bibliographic record, a different inventory link is created for each location, as well.

    For more information on the electronic migration approach to Alma, refer to Electronic Resource Handling in Alma Migration.

    Appendix A – Delivering Files and 'Delivered Files' Form

    Place any data files that you provide to Ex Libris in the formats indicated in Expected File Formats on the MFT server which has been specified to you by your Ex Libris project manager. 
    The following is the default naming convention:
    CustomerName+DataType+sequence+date+[.<file_extension>].</file_extension>
    For example: centralu_bib_01_20120420.mrc, centralu_bib_02_20120420.mrc, centralu_bib_03_20120420.mrc
    Ex Libris recommends a maximum of 200,000 records per MARC file, and 400,000 for other types of records (items, orders, etc).
    All records in a single file must be homogenous – all of the lines in the file must have the same number of fields, and those fields must contain the same type of data. Additionally, all of the records must be delimited in the same manner. For example, do not delimit with quotes and commas for some records and pipes for others within the same file.
    Provide the Sebina Delivered Files form along with the submitted files.
    • Was this article helpful?